±Forensic Focus Partners

Become an advertising partner

±Your Account


Username
Password

Forgotten password/username?

Site Members:

New Today: 0 Overall: 36296
New Yesterday: 0 Visitors: 165

±Follow Forensic Focus

Forensic Focus Facebook PageForensic Focus on TwitterForensic Focus LinkedIn GroupForensic Focus YouTube Channel

RSS feeds: News Forums Articles

±Latest Articles

±Latest Videos

±Latest Jobs

FAT32 strangeness

Computer forensics discussion. Please ensure that your post is not better suited to one of the forums below (if it is, please post it there instead!)
Reply to topicReply to topic Printer Friendly Page
Forum FAQSearchView unanswered posts
Page Previous  1, 2, 3 
  

jaclaz
Senior Member
 

Re: FAT32 strangeness

Post Posted: Oct 16, 09 15:18

Sure Smile ,
but you see, the problem is a bit different, from experience.

Unless you actually physically open the stick and read the chip #, any "theory" is good as the other.

For unknown reasons (though I do suspect some form of "compatibility" issues) sometimes a chip "declares" itself as "something else", to which you add that the makers of tools like USBdeview, CheckUdisk or ChiopGenius use NOT "official" data from the Manufacturers, but rather "databases" that, just like the one on the iflash.ru, are compiled by reports of users that can be incorrect, or just plainly wrong.

Even the available data from manufacturers is often partial, incorrect or plainly deceiving.

To give you just an example I have right now before me a USB microdrive that "declares itself" as being an OTi 2118 in ALL the utilities of the world, but that, once opened, reveals a chip marked OTi 2119.

Thus anything you can find is usually not really "evidence", but more like a "number of clues" or, if you prefer, "circumstantial evidence".

You could try analyzing the device through a write blocker, that may result in different behaviour. Question



jaclaz  
 
  

Fab4
Senior Member
 

Re: FAT32 strangeness

Post Posted: Oct 16, 09 17:12

Understood.

I examined the drive thru a Tableau T8 at the outset of all of this strangeness and the behaviour was as described.

Scott Moulton presented 'Solid Stated Drives Destroy Forensic & Data Recovery Jobs' at DefCon 16. DefCon vid Towards foot of page.

"Data on a Solid State Device is virtualized and the Physical Sector that you are asking for is not actually the sector it was 5 minutes ago. The data moves around using wear leveling schemes controlled by the drive using propriety methods. When you ask for Sector 125, its physical address block is converted to an LBA block and every 5 write cycles the data is moved to a new and empty previously erased block. This destroys metadata used in forensics & data recovery. File Slack Space disappears, you can no longer be sure that the exact physical sector you are recovering was in the same location or has not been moved or find out what it used to be!"


I shall watch it over the weekend, but I thought I'd post it's presence beforehand for others' interest.  
 
  

jaclaz
Senior Member
 

Re: FAT32 strangeness

Post Posted: Oct 16, 09 20:38

Yep, but "sector exchange" is rather normal when a wear leveling algorithm is used interrnally, but the change affects whole blocks, not single bytes.
This is exactly what I initially overlooked and mscotgrove pointed out, and if the algorithm is what (or similar to what) Scott Moulton describes in the snippet you posted, the "triggering" is 5 (or a similar number of) writes.
If the writes are blocked, there should be no sector exchange or shift. Question

Have you tried imaging the stick with dd or a similar tool and work on the image?

Possibly making several images and comparing them as mscotgrove suggested.

It seems like it is the only way.

jaclaz  
 
  

athulin
Senior Member
 

Re: FAT32 strangeness

Post Posted: Oct 20, 09 17:42

- Fab4
Standard VBR in logical sectors 0 and 6. Disk area allocated to volume boot was unusually large - 2,678 sectors.


What version of EnCase? (It probably doesn't matter, but late versions seem a bit bug-infested...)

You verified that the VBR is standard -- you checked the code?

Of the first 34 bytes (0-33), most remained the same regardless from which direction I returned to the sector (I actually can't believe I'm typing this...) - bytes 0-3 remained as 55 53 42 43 (USBC). Byte offsets 8-30 and 32 also remained static.


Double-check your USB drivers before you do anything else. "USBC" appears in USB command block wrapping, so my first guess would be that you see command block data (SATA over USB). That may indicate a USB driver problem; it may also indicate a USB device problem. (Also check your system log for error or warning messages.)

Wear-levelling seems an unlikely explanation -- the whole point of that is to ensure that writes are not concentrated to some particular blocks (as the FAT sectors of a FAT drive), which will wear them out before the rest of the drive. If the block changes because it has been written to, wear-levelling must be faulty.

However, it may be a side effect: wear-levelling 'knows' about unallocated sectors in the file system, and I can easily imagine that a device that does wear-levelling may return any random garbage when it gets a request for a sector it knows to be undefined -- i.e. it won't even try to make a real read, but it returns anything already in buffer memory. It won't harm anything in normal Windows -- but it does go against the current assumption that most forensic programs come with: namely, that data in unallocated sectors won't change between reads.

I find it somewhat unlikely to find wear-levelling on a standard USB stick, though, even if it is 16 GB (right?).

There are mentions on the net of finding "USBC" in data from USB drives, but those I have found all suggest some kind of device driver or hardware problem. Have you tried WinHex on another computer?  

Last edited by athulin on Oct 21, 09 00:30; edited 1 time in total
 
  

mscotgrove
Senior Member
 

Re: FAT32 strangeness

Post Posted: Oct 20, 09 18:54

With some older memory sticks, typically <= 256MB I think the crystal would not always work. The memory could be brought into life with a 'damp' finger or similar. It might also cause the type of problem reported. Newer chips do not respond to this treatment

I remain convinced it is a dodgy chip rather than wear leveling, but it would be nice to find out for certain.  
 
  

memon
Member
 

Re: FAT32 strangeness

Post Posted: Oct 21, 09 10:13

- Fab4
Thanks jaclaz - very interesting read.

So my main suspects appear to be;

1) Wear-levelling
2) Faulty disk/controller
3) A 'fake' Chinese USB

Joy.....!

Testing for item 1 shall begin soon Rolling Eyes
Now, who in the lab is looking bored? Wink


In addition to wear leveling, in SSD drives at least, there is also garbage collection going on where unused (from the disk controller point of view) sectors are being cleared for faster writes in the future. But even that does not explain some of the things you see. One thought is that there is a lot of extra information that is kept with each memory block, such as an error correction code, counts for wear leveling, etc. Is it that you are seeing these? The hardware is supposed to hide all this from you but maybe that is not happening.
_________________
Adroit - State-of-the-art photo forensics
www.digital-assembly.com 
 

Page 3 of 3
Page Previous  1, 2, 3