OK, this topic comes up pretty regularly and its time to add a little EE background to this problem. I'm no expert in this, but I have had some good experience which may help others. Good (ie most) U3 security is implemented very similarly in some ways to SIM cards and it is VERY hard to get around. 96HZ and Zuran have the concept mostly right.
In a USB thumb drive you esentially have a controller chipset and flash memory. Encryption aside (which is another issue) in U3 devices, as discussed, the controller presents itself to the host as two separate devices, a CD-ROM device and a removable storage device. When security is implemented in these devices, only the CD-ROM device and CDFS are presented to the file system where some software resides controlling access to the removable storage device. The removable storage device component of the U3 is not accessible by the host and does not even appear on the bus until this security mechanism allows it. You therefore cannot take a physical image or start to try to brute force encrytion. You don't even have access to it. In most cases, if you enter the password incorrectly a number of times, the control chipset will initiate the entire flash memory being overwritten.
You cannot just remove the control chipset and replace it. Flash memory implements wear leveling through this chipset
http//
This means the chipset keeps track of which parts of the flash memory have been used the most and re-maps data to different parts of the physical flash memory to even things out. The data is not stored contiguously on the flash memory, so if you change the controller, it will have no idea about the order data is stored in on the flash media.
Here are the best ways around this that I have found
Easier
- take advantage of poor implementations as others have found
- check pagefile and hiberfile for passwords or find some other way to get the password
Harder
- if you trigger the wipe process (which also clears the pw), you can sometimes kill power to the device before it has a chance to overwrite all the storage space. You then may have access to unallocated space and carve away, however this will overwrite some data and is taking advantage of a poor implementation. This may be fixed in newer implementations by having a flag in the controller that only allows access back to the removable device when overwrite is complete and just resumes overwrite on power up. To perfect this technique, get an electrical engineer to work with you to monitor power consumption of the U3 device chipset to characterise when the overwrite begins, it should be a big sustained jump in power as the control chip initiates overwriting of all blocks. You can then develop an automated way to cut power within a millisecond of the overwrite process starting and maximise available data.
Hardest
- identify the control chipset and work with an electrical engineer to reverse engineer the chipset. Identify the tables where the mapping for wear leveling is being stored and reverse engineer this by comparing data read directly from the flash memory modules to a physical image of the flash taken through the USB interface. Then, once you have identified the location of wear leveling data, copy it out of the control chipset of your locked device and into the same location on an unlocked control chipset. Swap the chipsets over and cross your fingers. I've never done this, its a theory and all these techniques should be tried on test media first. Its not easy stuff, its hard and takes a lot of time and a lot of resources.
I've also had some success with the power cutting technique on locked SD cards and been able to carve out lots of pictures from unallocated space. Hope this helps someone out there.
Good one Paul. You can recognise the S…B school straight away, accurate, comprehensive and concise submission.
Regards,
ecophobia
You can recognise the S…B school straight away, accurate, comprehensive and concise submission.
I beg to differ. (about the "accurate") (
I'm no expert in this, but I have had some good experience which may help others.
Here are the best ways around this that I have found
Easier
…
Harder
…
Hardest
….
I've never done this, its a theory and all these techniques should be tried on test media first. Its not easy stuff, its hard and takes a lot of time and a lot of resources.
From what I can get, "Hardest" is "pure theory".
May I ask if also "Harder" is? ?
And "Easier"?
Or if you actualy tested the approaches and had some results?
If yes, with WHICH devices (Make/Model/Controller used, please).
BTW, not *all* flash controllers have wear leveling.
jaclaz
Hmmm…
Can U3 be uninstalled from a flash drive?
Or, can you do what
Can U3 be uninstalled from a flash drive?
Yes.
But it won't help with accessing the stick contents.
You can change the actual CD device content (lpinstaller and the like) or use the appropriate Manufacturer Tool to completely remove the CD part.
And also to remove the protection, but the data will be *wiped* in the process.
On some controllers this is just a "high level" format, so data can be recovered, on other it seems like a proper 00 writing is performed.
Please, do understand that EACH controller may have different capabilities and the appropriate Manufacturer Tool may be available/unavailable or it may contain or miss one of these features.
jaclaz
Thanks to ecophobia for some encouragement. I'm not publishing a paper, but rather trying to share some experience and knowledge here. Those with experience in forums I would expect to know that people from diff backgrounds and experience share in forums and it should be tempered with your own experience and testing without getting snarky.
The 'Harder' method I have tested on U3 USB thumb drives and locked SD cards. It worked well, but the percentage of data overwritten depended on the size of the media, how fast the controller is and how fast you kill the power. The principal is pretty sound, it takes time to write 00s to every sector of the device, so cut the power after it starts this process and then carve away. This techniue is dependant on the password being cleared prior to the data blocks being overwritten and not after. It therefore probably won't always work but it has worked for me. You could potentially either use a manufacturer tool for removing the security, or just enter the wrong password three times, either way triggering an overwrite of the data blocks.
I have not had the time and resources to test the 'Hardest' theory and there are a lot of blanks in there (Hmm.. I guess thats why I called it a theory… intresting). Such is the nature of reverse engineering, however I have used this technique to reprogram and replace ICs implementing security in other devices. If you want to dispute the theory, offer some credible reasons why it won't work and offer a good alternative. I know enough to know its not as simple as whiping out the soldering iron to change the controller as others have suggested. Good luck finding a U3 device with no wear leveling, U3 devices tend to only be leading brands (as the technology is licensed and costs money to implement last time I looked).
Its been a couple of years since I did this work so I don't have exact models, but from memory, most of my testing was done with Toshiba U3 devices and Sandisk SD cards, and yes different manufacturers will implement security differently. For each manufacturer and model you encounter, you will have to figure this out for yourself. Even if I gave specific makes and models, you should still test on identical non-evidentiary items first as the manufacturers may change controllers from time to time.
Its been a couple of years since I did this work so I don't have exact models, but from memory, most of my testing was done with Toshiba U3 devices and Sandisk SD cards, and yes different manufacturers will implement security differently. For each manufacturer and model you encounter, you will have to figure this out for yourself. Even if I gave specific makes and models, you should still test on identical non-evidentiary items first as the manufacturers may change controllers from time to time.
Yep ) , additionally SAME Brand, SAME model may have different chips (i.e. made by a different manufacturer).
I have seen reports of EXACTLY the same stick, bought in the same shop, physically taken from the same container, have different controllers/behaviour.
From the little I know about the electronic part of these devices, a SD-card is "very" different from a USB stick, that sports a "real" controller, I doubt that "reverse engineering" a controller is something actually doable in a "reasonable time" and with a "reasonable cost".
The "cutting the power off QUICKLY" (at the cost of losing a small amount of data) seems like the best option.
That is great for Data Recovery, though in actual Forensics it is far from being a perfect solution.
Since these controllers do have a "clock", maybe it would be possible to clock them "slowly", thus increasing the chances of wiping less data.
I presume there is even another approach, AFAIK the password is stored inside the actual controller chip, whilst of course the data is in the flash chip.
Maybe the "electrical engineer" may find a way to cut the link from the controller to the flash in such a way that once the internal password is reset, the "wipe command" reaches not the actual flash.
In any case, from a Forensics viewpoint, I would image the contents of the flash chip anyway (even if the contents are fragmented/scattered around by the eventual "wear leveling" provision), so that the whole data is available and can be always attempted a traditional carving/re-assembling.
I mean something like this
http//
?
jaclaz
That's a brilliant idea, basically isolate the flash modules from the controller whilst it is trying to overwrite, or move the controller to another identical device for that phase, then return it afterwards. That way all wear leveling is preserved and the password is gone.
Yeah, the reverse engineering of controllers is not trivial at all. Even if you have access to the firmware image. You would have to know something valueable is there to devote the resources. If you are LE, go to the manufacturer. They are sometimes really happy to help and often have unpublicised back doors.
Good points on forensic process, but sometimes you have to do what you have to do. If I used any of these techniques I would document it well, test it on non-evidence identical items first and it wouldn't be a problem to use in court. Almost all other forensic disciplines than digital forensics are destructive of evidence in their application. I think if the method is tested well and shown to work, the process will stand up.
Good points on forensic process, but sometimes you have to do what you have to do.
Yes, of course. )
If I used any of these techniques I would document it well, test it on non-evidence identical items first and it wouldn't be a problem to use in court. Almost all other forensic disciplines than digital forensics are destructive of evidence in their application. I think if the method is tested well and shown to work, the process will stand up.
Yes, but you see, when it comes to USB sticks (which are commonly "exchanged" or "attached" to ANY possible computer, both at home and at office - and of course at friend's, etc. etc.) there are lots of issues at hand, as I see it.
Let's say you are dealing with a "common" case of forbidden pornography.
If you find a file on an internal hard disk AND you find a given URL from where the picture was downloaded AND you have a definite timeline for the creation of the file, you have ALL the data you need to "nail" the picture to a voluntary action performed by the suspect.
But if you find the same image on a USB stick, in the UNallocated space, without any element to say WHERE it came from and WHEN it happened it may be tough to prove anything apart the fact that "at some time in the past the file has been copied to the USB stick".
Compare with this
http//www.forensicfocus.com/index.php?name=Forums&file=viewtopic&t=6791&start=10
Given that there are many "rogue" apps that do things without user knowledge it is possible that the suspect may get away blaming something/someone else (and this could actually be what really happened).
Different is the case for - as another example - a copyright/patent kind of issue where suspect employer - who was forbidden to copy a given file to removable device - is found in possession of a USB stick where traces of the files are found.
Well, you cannot have EVERYTHING, the way you would like to have it. wink
jaclaz
I did a test with the harder way, the data is still there but it is encrypted so no luck there.
It seems previous versions of the sandisk u3 cruzer micro doesn't encrypt the data. Anyone know where I can find that. The firmware version of my Stick is 3.27.