Spotlight: Tracking a User’s Whereabouts with simplekml

The Spotlight series highlights useful Python libraries and their forensic application.

You’re no doubt aware that major technology companies, like our great benefactor Google, retain a great deal of data regarding their users. It shouldn’t come as much of a surprise considering how important users are to a company’s livelihood. Wouldn’t you want to know, if you could, every detail about your customers and who you do business with to better engage them? And as disturbing as that can be (have you seen Google’s location history timeline?), I think we can all agree that we have wished for similar omniscient-like knowledge in our investigations. I hate to disappoint you, but this isn’t a post about that.

One thing that can give us the appearance of omniscience is a history of the user’s whereabouts. It can be hard, for example, to discount a mobile device’s reported location at the scene of the crime at the time the crime occurred when the user’s alibi places them a few towns over during that same time. In this day and age who do you think you are fooling with the “My phone wasn’t with me” gimmick.

Continue reading “Spotlight: Tracking a User’s Whereabouts with simplekml”

Spotlight: Tracking a User’s Whereabouts with simplekml

Recovering Data from Damaged USBs

What happens when you receive or take custody of evidence that ends up being non-functional? Without the right tools and training, the answer might be nothing. Perhaps the owner purposely tried to damage the device or it is due to some internal malfunction. Either way, data on these devices can be of great evidentiary value that proves or disproves previously held conclusions. And while there are an ever-growing number of data recovery shops, their services can be costly and may introduce significant lag time to a case.

Whether it is due to budget or time constraints, it may be worthwhile to assess the situation yourself (after getting permission from the appropriate authorities, of course). When it comes to USBs, we will discuss a few methods we can use to extract data from the broken device. Please be aware the methods we will discuss involve using high heat to separate the memory chip from the USB logic board. It is possible to further, and even irreparably, damage the device this way. Practice, as always, is key.

Basic Structure of a USB

The first task is to remove the USB logic board from its enclosure. Oftentimes there is a seam that can be pried open with a plastic spudger tool. The board will likely be held in place by a few plastic latches or with adhesive. Once we have removed the logic board from its enclosure we can examine the board for any obvious signs of damage.

Indicators of damage could range from melted components, scorch marks, bad solder joints, or cracks in the logic board. While one could attempt to repair observed damages, we will instead transplant the NAND storage chip to a functioning same model device. For this post, I tore down two USBs I had close at hand. One older unmarked 2 GB USB and a newer 8 GB SanDisk Cruzer. Both devices are pictured below.

USB_Structure

Both devices are made up of the same basic anatomy. The primary components of a USB that we will concern ourselves with are the USB connector (1), the USB controller (2), and the NAND storage chip (3). The SanDisk has its USB connector integrated with the logic board as opposed to the soldered on USB connector more commonly seen with most USBs.

If the USB connector is damaged there will likely be obvious damage to the gold-plated pads within the connector or the solder joints connecting it to the logic board. A typical USB has four gold pads each corresponding to a specific signal: power, data -, data +, and ground. The gold-plated tabs should be straight, flat, and free of any residue. The solder joints where the connector meets the logic board should be holding the connector firmly in place. There should also be continuity between the gold pads and the solder joint where that electrical signal meets the board. If there is any apparent damage or the connector is not secured to the logic board, reflowing the joints may solve the issue. Failing that, one could use hot air (i.e., a hot air rework station) to remove the defective USB connector and replace it with a functioning one.

The USB controller typically comes in a TQFP (Thin Quad Flat Package1) package with leads on all four sides of the chip. Discussing how to diagnose and fix issues with the controller is out of scope here.

The NAND chip(s) houses all of the data on the USB. These chips are fairly durable and in most scenarios are not damaged. These chips are often one of two packages: TSOP (Thin Small Outline Package2) or BGA (Ball Grid Array3). In the photos above, both chips have a TSOP-48 NAND memory chip. The number 48 represents the total number of leads on the chip where two sides contain 24 leads each. These chips are easier to work with than their BGA counterparts where the leads are underneath the chip rather than on the side of it. Some USBs have more than one NAND chip. In that case, both NANDs would need to be swapped.

In our scenario, we will discuss the steps necessary to transplant the NAND chip from a non-functioning USB to a same-model counterpart. Let’s get started.

Recovering Data from a USB

With the NAND chip(s) identified, let’s discuss how to remove the chip from the board. There are a number of different methods we could employ, but the end goal remains the same: melt the solder joints holding the chip in place long enough to remove it from the board. The most popular method would be to use a hot air or IR rework station. Other methods, like using a low temperature solder, exist and are worth exploring to determine the best tool for the job. Each come with their own pros and cons.

When heating an electronic component to high temperatures there is always a change it may be damaged in the process. In addition to that, care needs to be taken to avoid overheating other components on the board. This is especially true when using a hot air gun. With that said, let’s continue our discussion on the assumption we have elected to use a hot air rework station.

Depending on the composition of the solder used it will likely melt (reflow) around 190°C. When solder reflows, it takes on an observable shiny characteristic. Applying flux to the leads will facilitate the reflow process. The exact temperature, air flow speed, and nozzle to use is setup dependent. Practice on test devices to get a feel for the appropriate setting. Aim to reflow and remove the chip from the board after 10-20 seconds of sustained heating. If the reflow station has a preheater, the board can be heated up to near reflow temperatures to decrease the amount of time high heat needs to be applied. Preheating also allows for the board to be more evenly heated rather than heating a localized area which may stress and damage the board.

With the appropriate temperature determined, apply hot air a few centimeters above the leads, taking turns to hit each side. It is critical that when using tweezers, or some other tool, to lift the chip up (once the leads have reflowed) to not apply much pressure. If there is resistance stop and do not continue pulling up on the chip. Continue applying heat. Ignoring this advice can result in tearing off pads which will certainly result in numerous headaches.

Low-temperature solder is much safer with the chip but takes more time and leaves a mess on the board. The process involves applying low-temperature solder liberally on the existing solder joints and create a horizontal stream of low temp solder spanning across all of the leads on each side of the NAND. Heating this mixture of primarily low-temp solder with just a soldering iron keeps it reflowed for ~10 seconds, long enough to reflow both sides and easily remove the chip.

Whichever method is preferred, remove the NAND chips from both the original and donor boards. Make sure to inspect the original chip’s leads for solder bridges (this is more likely to occur with the low-temp solder method). Solder bridges occur when one or more leads are connected with solder causing a short between those leads. Any such shorts must be removed prior to swapping the NAND onto the donor board.

With the original NAND chip inspected, we can now swap it onto the functioning donor board. As a brief aside, if you have a chip programmer, and it supports your NAND, you can read directly from the chip without needing to perform this last step.

Before swapping the NAND onto the donor board, inspect the board to make sure all pads are intact and there are not any solder bridges. It is also recommended to either even out or, preferably, remove solder on each pad with desoldering wick so the chip lays flat and in contact with all pads when placed on the board.

Let’s discuss two different options for soldering the NAND onto the donor board. We can either use the hot air rework (or IR) station or manually solder the chip with a soldering iron. Manually soldering the chip is safer for the chip as you are not applying heat directly to the chip itself. This method is more time-consuming. Hot air is just the inverse of the process employed to remove the chip. Once complete, inspect the leads one more time to ensure there are no inadvertent electrical connections between leads. In addition to this, use a multimeter and check for continuity between each lead and the pad it connectors to to ensure all are making sound electrical connections.

If all went well, reattempt acquisition of the device. Ideally it should now be recognized by your machine and allow you to image it. If that is not the case, reinspect the leads and rule out inadvertent electrical connections. Verify that the host and donor are the same make and model with similar board design. Know that this technique is potentially destructive. Therefore, ensure you practice this in test scenarios before applying it to casework.

Did this work for you? Do you have any suggestions or alternative methods? Please let me know in the comments below.

Recovering Data from Damaged USBs

Hasty Scripts: Summarizing Installed Applications on Encrypted VMs

Virtual machines are everywhere, no longer just confined to the corporate environment. It is not unheard of for consumers to use virtualization software on their personal devices these days. Examination of these VMs does not differ much from normal host investigations. Tools, like FTK Imager, support common virtualized HDDs and can be used to preserve and review them. But what happens when a VM is encrypted and password-protected? Compound the issue with an uncooperative custodian and it may be time for more creative solutions. Thankfully, VMware, a popular virtualization program, can create an artifact on the host operating system that gives us insight into what applications are installed on the VM.

Continue reading “Hasty Scripts: Summarizing Installed Applications on Encrypted VMs”

Hasty Scripts: Summarizing Installed Applications on Encrypted VMs

Hasty Scripts: Box Edit Log Parser

How often are you tasked with reviewing large data sets in less than ideal (or even terrible) formats? Everyone has likely had to review logs containing many tens of thousands of lines at one point or another. We may not have time or budget (or patience) to review every line in a text editor. What do you do?

Continue reading “Hasty Scripts: Box Edit Log Parser”

Hasty Scripts: Box Edit Log Parser

Cloud Forensics: Box Part 1

Cloud storage, like email before it, has gained wide acceptance and general adoption by consumers. Whether that is Google Drive, Amazon Drive, iCloud, Dropbox, or OneDrive, there are abundant options from which to choose from. One reason these services have become popular is the ease at which you can share and access important files on any device. That same benefit, however, can be used with malicious intent to extradite data from corporate or protected environments. In this post, we will explore the Box cloud service on Windows and discuss artifacts created as a by-product of its usage.

Continue reading “Cloud Forensics: Box Part 1”

Cloud Forensics: Box Part 1