Forensic Blogs

An aggregator for digital forensics blogs

by

Mobile App Forensics Intern Blog 2

Introduction

Over the past month, our team has analyzed the applications Expedia and Google Trips. These apps help users plan trips to locations abroad with features to order reservations and plan day trips. Our goal for analyzing these applications was to find out how much information they hold for forensic investigators. This will in turn give investigators an easier time catching suspects.

Findings

The application Expedia has very little, if any, information on the system itself. It appears to only store information if the user purchases a ticket. The only other thing we found was sometimes there may be a flight plan stored on the system, but that’s it.

Google Trips, on the other hand, stores most if not all of the information on the system itself. Specifically, it contains all reservations, day trips, and other user input on the system. The application also stores all locations and events of the city that the user is visiting. If a person uses this application rigorously it would provide investigators with a lot of information. The application relies on MIDs, or a set of identifiers provided by Google. When correlated with the locations using certain items in the database, one can easily find the location of the corresponding MID.

Conclusion

The team’s next project will involve game app forensics. What information do apps downloaded from the playstore keep? What is stored internally? The team’s goal is to find as much information as we can about internally stored device data from two game apps. The apps are unknown as of now. Stay tuned for updates by checking out @champforensicslcdi on Instagram and @ChampForensics on Twitter!

The post Mobile App Forensics Intern Blog 2 appeared first on The Leahy Center for Digital Investigation.

by

Network Scanning Team: Third Impact

The Beginning of the End

So, this is it. The final frontier. Our last blog post. We made it. High fives all around—we successfully went where no man, woman, or hyper-intelligent anthropomorphic beaver has gone before: the LCDI network.

All joking aside, our team is happy to report that we have completed the tasks laid out before us and successfully created an automated network scanner. We used the device to uncover valuable information, not only on the nature of the LCDI network, but how the individual tools we used mixed and mashed together—and how to best optimize said tools. Our report will be released soon; please take a look!

Since our last post, we ran batteries of formal tests with our script and servers on a private network, writing a detailed micro-report after each cycle of three scans. For each cycle, we passed different flags to the script, organized the results into tables, and interpreted the differences between them. Unsurprisingly, there weren’t too many differences and the fast scan was faster than the non-fast scan. We had some issues with the scanner Pi booting faster than one of the servers but fixed this without any issue. The ease with which we completed and documented all three cycles is a testament to the stability of our script.

We also ran four formal scans on the whole LCDI network, (two over Wifi and two over Ethernet) and each pair included one fast scan and one non-fast scan. These scans ranged from fifteen minutes (wired fast scan) to over two hours (full port wireless scan). Also, unsurprisingly, the results were not far off from those of our previous test scans.

The End of the Beginning

Those were a quick eleven weeks, but that’s not to say they were without their hardships. It was a daunting task to work an internship the first semester of our first year at Champlain College. In that short amount of time, we learned a lot. We wrote scripts in Python, bash, and batch and installed Linux distros and Windows IoT (perhaps more often that we would have liked). We waited for packages to install, printed ASCII cows to the console, set off countless security alarms for the network admins, and wrote some high quality Twitter posts.

See You Space Cowboy…

We didn’t just grow intellectually, however—we grew as people too. Working together with the aid of tools like Trello and Slack has made us better teammates, people, and friends. We are undoubtedly more prepared to enter the workforce after completing our semester-long internship at the LCDI and are grateful for this incredible opportunity.

The post Network Scanning Team: Third Impact appeared first on The Leahy Center for Digital Investigation.

by

FTK Tool Evaluation Update 2

Current Progress

After receiving our team-generated test data, we plugged our test scenario into Forensic ToolKit. It was intriguing to see what Forensic ToolKit would catch from our generated data.  

Data took a long time to load into FTK, but once it was in the system we could start evaluating processing speed and user friendliness.

In terms of hit processing speed, FTK had a lot of discrepancy which you can see form the table above. The number of hits and analyzed hits per second have a positive correlation, and our graph did not reach hit counts too large for the system to handle. That is why the keyword search for “e” has over 22 thousand analyzed hits per second, by far the highest indexed hits. The system analyzed more data per second based on the initial higher hit count. Moreover, FTK is shown to be a very powerful program as all the wait times were under 5 minutes.

FTK processing is fast and expansive, but in other fields of evaluation it rapidly falls behind.  One of those fields is user friendliness. We encountered a lot of user friendliness problems during our evaluation. FTK would unexpectedly crash or stop responding at least once every time we accessed it. The graphics of this program make the screen incredibly busy and confusing. To a beginner digital investigator, this program would be challenging to use because FTK tutorials are scarce, leaving the investigator on their own to figure out this visually busy program.

FTK’s graphics can be largely excused, because this program is made for functionality, not aesthetic. Lastly, it is important to note that FTK has crashed several times in regular use, usually when trying to do some sort of standard action. When trying to run an index search, for instance, the program will freeze and occasionally crash.  All of these factors put a dent in FTK’s overall user friendliness.

Conclusion

FTK is top performing in data collection but low performing in user friendliness. Our evaluation of FTK is almost complete, and the FTK intern team is currently starting drafts of our final report.

 

To learn more about this and other blogs of the LCDI visit us here: LCDI Blog.

Stay in the loop on our current and upcoming projects and events by following us on Facebook,  Twitter, or Instagram. 

 

The post FTK Tool Evaluation Update 2 appeared first on The Leahy Center for Digital Investigation.