First published June 2010
by Dominik Weber, Senior Software Architect for Guidance Software, Inc.
My co-worker did isolate some sector differences between the individual acquisitions. She found out that it was a series of sectors located in “Unallocated Clusters”.
While looking at the real sector data it changed every time the sector refreshed. It was a series of hex patterns like “44 00”; sometimes they would change to “40 00”, “18 00” or “00 00”
Then we used a disk editor to read the same sector and the same behavior persisted. Same results with other tools. On different computers.
I then paused and thought about the way most flash drives are created. A controller chip sits on the USB bus and communicates with the host machine and the actual flash storage chip. The flash storage chip is usually a flat, thin rectangular chip with a series of pins on both sides. Some flash drives have more than one such flash chip.
The controller is responsible for performing the actual sector writes/reads. Should the write switch be set to “read only” mode at device insertion time, the controller would tell the host that this drive is read-only and ignore / fail out write requests. The host on the other hand then would use this bit of information in the file system driver and mount the drive in read-only mode.
For instance the $Log file on improperly dismounted (“dirty”) NTFS drives would not be processed in order to roll back partial transactions.
Furthermore, the controller usually drives a LED to show disk activity and that the device actually is plugged in.
In order to perform sector reads, the sector number must be mapped to an area of the flash chip. This is similar to the way that physical memory pages get mapped to virtual memory in a running process.
The associated address for the to be read sector gets put on the address bus (which is connected to one set of the pins of the flash chip) and once the signal stabilizes on the address bus the chip select line for the flash gets activated. Then the data is being read off.
It is important for the voltage levels to stabilize in order to reliably read from the chip. Chips have spec sheets where these times, voltage levels and access patterns get described in detail. It is possible to exceed these specifications but then system instability might occur (as when people overclock their computer too much).
Another factor is that bits of flash chips only have a limited number of writes before that bit gets “stuck”. Unfortunately many file systems predated these chips and do have write patterns that will include frequent writes to the same sector; usually for meta data, last mount times, read times and such.
That is why most of the controllers implement wear-leveling schemes in order to more equally distribute the writes across the whole flash chip in order to extend the total life time of the device.
There are two main strategies in use – dynamic and static wear-leveling.
This particular device was using dynamic wear-leveling, by which the number of times that a particular block of flash memory had been written to was being stored in a look-up table along with the address of the block.
After opening the device it was determined that the controller of that particular flash drive was “UT 165” and had a single flash chip. It seems that the chip select bit was stored along with the address bits and write count for a particular block of sectors. For an unused sector all of these bits were zero, meaning that the flash chip’s data lines were electrically disconnected (tri-state). This effectively turns the data lines into small antennas that can pick up electromagnetic noise. Due to the routing of the data lines some bits were more susceptible to this noise than others. While this is normally not problematic when the flash chip is providing a stable voltage level, in this unselected state these bit patterns were read at random.
This would only happen on sectors that had NEVER been written to, thus only appearing in unallocated space and not cause any other issues.
When acquiring from certain flash drives that employ wear-leveling, it depends on the controller’s firmware if unwritten sectors could get random reads. It would be interesting to see if the emerging SSDs would exert similar behavior.
Furthermore the readout and subsequent analysis of the sector to block lookup tables would yield interesting side-band information and could be used to speed up acquisitions since the contents of never written blocks of sectors could be set to zero or ignored.
Of further note, the UT 165 controller is a high-speed USB 2.0 compatible chip that supports password-protected partitions and other enhanced features and forensic research of this and similar devices would be quite interesting.
This theory was tested by writing to one such sector and these random reads did not appear again, which would be consistent with the theory above.
In conclusion, this was a very interesting journey from the high level of drive acquisitions through firmware and chip specifications to signal theory.
Click here to discuss this article.
Dominik Weber is a Senior Software Architect for Guidance Software, Inc. He has a Masters of Computer Science from the University of Karlsruhe, Germany and worked for video game companies (Activision) and on computer animation / motion-capture projects (Jay Jay the Jet Plane) before joining Guidance Software in 2001. He can be reached at firstname.lastname@example.org
Guidance Software is recognized worldwide as the industry leader in digital investigative solutions. Its EnCase and Enterprise platforms provide the foundation for government, corporate and law enforcement organizations to conduct thorough, network-enabled, and court-validated computer investigations. Worldwide there are more than 30,000 licensed users and thousands attend its renowned training programs annually.