just to bring this thread to life, we have tried this method with no success. However, we do have around 12 possible passwords that have been retreived from the suspects phone. The question is, how does the drive record the number of attempts recorded (I gather that the data is wiped after 6 incorrect attempts), if we have a software writeblocker on the USB port (confirming that Tableau does not work for these), can I get more attempts?
I tested this a while back and from that testing, the device remembered incorrect attempts even when write blocked and plugged into a different machine.
My understanding was there is an intermediary control chip (I think the one Harry suggests removing) the attempts must be stored there.
No luck recovering files after a wipe, im not sure if the device I was testing was of the encrypted variety or not thinking back.
i'm going to deal with a similar situation,
i'll have my hands on the device tomorrow, so for now i don't have much informations about it, except it's a 16gb U3 device on wich the password was entered incorrectly for 3 times, causing the device to lock.
i was wondering if it's possible to image the data partition "as is".
the only information i have is that by going to disk management in windows XP, the partition appears as raw.
so i thought "maybe i can acquire that part of the device using ftk imager and have at least some informations about the protection method/encryption algorithm used to secure the data."
is it possible?
thanks in advice.
Well you could image the encrypted drive and attempt a brute force attack, frankly most passwords fall to a sufficiently large dictionary attack (any UK LE people who need a big dictionary feel free to PM me your email). The alternative on certain select drives such as kingstons is to exploit a weakness in the cryptosystem.
With a software debugger it is possible to break execution of the decrypt program and tweak the value of the "correct password" flag from 0 to 1. Problem solved. In certain very select circumstances. The same approach can probably be applied to a large amount of usb drive crypto with a little bit of reverse engineering.
Of course in all of these situations you want a non-evidential device to experiment on, the time to do so and a good understanding of very low level programming.
i was wondering if it's possible to image the data partition "as is".
I don't think so, not without removing the password protection (which will then cause wiping).
Below is my rudimentary, rather basic interpretation of the device
[CDFS] -> [AC] -> [DATA]
The small CDFS partition holds the autorun software, password prompt etc. There is then some access control method that when successful then allows access to the data partition. In my mind there is physical seperation between the partitions (ie. seperate chips) although that may not be the case.
If you remove the password protection, you bypass this
->
[CDFS]|[AC]|[DATA]
but in my experience the data partition has then been wiped.
Xennith, thanks for the debugging info, that's not something I'd thought about before but makes a lot of sense, at least when dealing with password protected devices as apposed to encrypted ones.
Essentially you're relying on bad / cheap implementations. Theoretically the only way to the data partition should be via the chip, however its far cheaper to produce if the partitions are both visible, but one just unreadable without the intermediary crypto on the chip. It becomes a software problem rather than a hardware one, which saves per unit costs. If the only way to the data is via the chip you're looking at a physical hack in most cases (
Its going to vary device to device and manufacturer to manufacturer of course, if you get an iron key you are officially boned, if you get a sandisk, verbatim or kingston device then theres a good chance they cheaped out or made mistakes which you can exploit.
http//
Its not so much a case of password protected verses encrypted, the flaw that the datatravellers suffer from is that the password you chose is not used to encrypt the data, its just used to tell the software to decrypt that data with whatever the device specific password is. As that software runs on your machine, it is vulnerable. If the password you entered was used to do the crypto, the system would be secure.
Well you could image the encrypted drive and attempt a brute force attack, frankly most passwords fall to a sufficiently large dictionary attack (any UK LE people who need a big dictionary feel free to PM me your email). The alternative on certain select drives such as kingstons is to exploit a weakness in the cryptosystem.
With a software debugger it is possible to break execution of the decrypt program and tweak the value of the "correct password" flag from 0 to 1. Problem solved. In certain very select circumstances. The same approach can probably be applied to a large amount of usb drive crypto with a little bit of reverse engineering.
Of course in all of these situations you want a non-evidential device to experiment on, the time to do so and a good understanding of very low level programming.
can you provide me some advice about a brute force attack?
i'm pretty sure that the user used a really dumb password, and anyway it's worth a try.
can you suggest me any good tool to break through an AES256 encrypted drive? better if it's freely available )
To be honest I'd be looking at a code your own solution. With most encryption implementations a hash of the password or key is included in a header, various algorithms use specified hashing algorithms. So in many cases you can just brute force this hash. Theres a lot of AES implementations freely available which could be used as a base for this kind of program in pretty much every language.
A basic program layout would be to take a candidate password from either a dictionary file or a generator, expand that password out to fill the keyspace using whatever algorithm your target device uses, hash it (again using the same algorithm) and compare the result with the stored hash.
If the implementation you are looking at does not use a hash, then you have a tricky step of instead of generating a hash, attempting to decrypt the first block of the crypted data and then checking to see if that block contains sensible, expected data like a boot sector. Functionally not much different from a hash, but quite a lot slower.
So… there arent many tools out there that already exist for doing this kind of work, you need to know exactly what the implementation does and its likely that you're going to need to actually write a custom program to attempt the attack….. then you have to find the password.
Hi, I also have 4 usb stick that are pass protected by U3
I have bought the same type to do some testing.
The sticks are sandisk cruzer micro 2GB
When you tried the last attempt and erase the stick then all data that was on the stick is overwritten by random char. Even previously deleted data is overwritten.
I opened the stick and yes there are 2 chips present, 1 with the controller and the other one with the memory or 2 GB data.
I think removing the controller chip and replacing it with another controller chip with the same type and no pass on it would make the data readable.
If offcourse the data was not encrypted before
does any of you know the following program
http//
I contacted them and they ask 1000 euro for it, but it does not work for the sandisk micro.
Has any of you read this article
http//
http//
http//
Regards Danny
That thing was in the news
http//
The principles is explained quite well in the PDF
http//
Obviously being a proof-of-concept there is no such tool released, but it should be possible to make one, given that those Sandisk thingies you have are of the type affected by the bug.
jaclaz