Tableau USB writeblocker and protected partitions

Hi Hujarl -

Using the writeblocker, are you able to at least obtain a full DD image?
If so, I would then suggest you could mount a copy of the DD image in r/w and use the logintool2090.exe to then access the other files. You could then conduct another image as necessary to the decrypted files.

Please keep me updated and good luck,

Originl,

Thanks for the response. Unfortunately I am unable to obtain a full DD image (with Encase, FTK Imager) as the physical drive is only reporting as a 1MB drive through the writeblocker.

I'm assuming its some sort of HPA or DCO that is inhibiting the access, but could be wrong?

Interesting.

Just to confirm, even in disk management of Windows it states your attached USB is only 1MB; correct?

Have you tried connecting the device to a *nix machine and obtaining a DD image from there? If you see the same things being reported to you under *nix, then perhaps you are correct on the HPA/DCO theory. Although, I never really thought to apply HPA/DCO to USB devices (exclusive of its embedded firmware).

I did do a quick search on the executable you mentioned and found a youtube clip in which they use OllyDbg to "crack" the password to the stick. This is assuming you don't already have the password and have a legal requirement to source the password as done so through OllyDbg. They mention reference to the chipset CBM2090, so perhaps more searching on that will bring out the answer.

Other searches mention "umptool", but how it could be applied toward your application is not clear to me.

Sorry, this is as far as I can go now. I am assuming this is a personal drive and this is a test? If so, where did you purchase this drive? It'd be an interesting test and hurdle to overcome.

Thanks,

Thanks again for the response.

You are correct in your confirmation regarding disk managment within Windows.

Also correct regarding the availability of cracking tools, unfortunately these all require read access as well.

This is for an active investigation, but of course am testing with an identical (make/model,etc) drive. If needed I can input the pswd into the original media and grab the data that way, but would rather figure this out and aquire it via a write-blocker.

I have an inquiry out to the manufacturer of the devices to see if they have any read-only mount utilities to assist, though am not holding my breath 😉

I'll update if/when I get more info.

Cheers!

My opinion I would say at this point the accessing the drive with write-access may be the only way to go. As long as you document everything you're doing, *ideally* anything subsequently found would still be admissible.

Likewise, you could use your identical drive to do the testing and report on what timestamps are changed, etc. when you do access in write-enabled mode. In fact, I'd probably do this part first so then you know what level of evidence spoliation to expect. Then you can decide if it's worth the risk or not.

What about software write blocking via the registry hack, or one of the software write blocking tools?

If that won't work, then I agree with originl, and document your efforts, first to use a hardware writeblocker, then accessing the drive without write blocking.

Hey Hujarl,

This sounds like the protection mechanism used on a lot of USB flash drives involving a p/w entered to an exe on the small partition before it will allow mounting the data partition on the drive. My understanding is that the USB controller on the flash drive won't make the USB mass storage device containing the data partition accessible on the bus until the correct p'w is entered. This means you have no physical access to it without getting past the gatekeeper, in this case 'logintool2090.exe'. Because data is stored in a non-linear fashion in the flash memory modules, you can't just swap the controller, even if you are nifty with a soldering iron. The USB controller is the key in pulling the data back off the flash modules into a linear bitstream.

So, I would agree with the software write blocking method and remember that with these sorts of devices, data will often change every time you mount them anyway. More important to hash what you have so that you can show later on that the data you examined is the same as what you acquired. Hope this helps.

Thanks all for the responses!

I am on board with the suggestions regarding documentating my process and running without the writeblocker as needed to aquire the data. This has really gotten my interest up to try and figure out a way though )

Will keep everyone updated if/when I make any progress.

I admire your optimism about trying to decrypt the data if you get in. I think you might have an easier time cracking the password but it is worth a try and you certainly have nothing to lose. I have to agree with jekyll and I am sure you figured that this was what you were looking at. You need more information from the manufacturer and I would invoke any law enforcement connections you have while begging for mercy from their engineers. They are likely to tell you to come back with a warrant or court order before divulging any information about a back door or secret unlock code. I hate to say it but you probably need to work on cracking the password and if you don't have Access Data PRTK or the equivalent password cracking tool then you may want to tell your boss to talk to the client and offer to farm it out to someone who does. That is if the information is worth the extra expense. Good luck and please let us know what happens.