Breaking Samsung Android Passwords/PIN

[atom]

I've used 0.15 beta which is not yet public. You need to wait for next release.

[cdurex]

I've used 0.15 beta which is not yet public. You need to wait for next release.

Uhm Ok ok I understand now, thanks for the info.

Great tool! Hoping to get v0.15 soon!

Keep up the good work!

[cdurex]

Hey everybody good day , since I could not wait for a new version to come! . I dug myself in the android world and found that the algorithm just adds the two hashes in the "/data/system/password.key" file, like so the (SHA1 + MD5); so as in the OP bkerler is using the SHA1 part only(the 40 digit long part of the string), we could use the same command to break the password/PIN using the MD5 value to get the same value.

So we could do a:

"./cudaHashcat-plus64 -a 3 -n 80 -u 1024 -m 10 3bf54dbf16c58965f93bf164a6612c38:636bb8161c861503 ?d?d?d?d"

Using the MD5 part of the string, the 32 digits long.
To brute force it.

Any feedback welcome

PD: OH and I'm using my own string of the password.key file
here it is:

Code:

21faa15e0409fa961f0c2b2e8e2fde96cfe4a9e53bf54dbf16c58965f93bf164a6612c38

[philsmd]

omg, is this for real?

so you can attack both algorithms? I mean, you can attack the least secure, the faster?

My question here is, is this really Samsung specific?
This post e.g. says this is how "Android" does it: http://digitalinvestigation.wordpress.co...passwords/

IFF not specific 4 Samsung, we may consider to change the thread title, or?
Somebody can confirm which vendors/model really have this algo (which Android versions etc). Thx

UPDATE: it seams that the SHA1 part (number of iterations and concatenation etc) is Samsung specific, but the SHA-1 + MD5 is used by *all* Android devices. Is it?

[gat3way]

Yes, salted SHA1/MD5 is generic, iterated sha1 is apparently Samsung-specific. Yes, it makes no sense to attack sha1 if you can attack md5. BTW you would be surprised how weak the pattern lock is, it doesn't even make sense to attack it on GPUs. Still, long passwords or PINs can be relatively secure (and even more secure on Samsung). Pattern lock is VERY easy to crack.

P.S as of Android Jellybean 4.2.2 (Nexus 7), the sha1/md5 scheme is still in use.

[philsmd]

Yes, we recently discussed the pattern hash here too: http://hashcat.net/forum/thread-2165.html

I know that there are so many stupid and unbelievable things out there, especially if you do some security research, (embedded) device exploitation, password research or even reverse engineering. You come accross ,very* stupid things that you simply can't believe. And you learn you shouldn't cry because things are AS IS and vendors etc only change things if you FORCE them to change it somehow!?
This is definitely one of those things that is also very absurd to me.
Why in the world Google uses this/those schemes? Are they collaborating w/ governments?
This cannot be for real! There is no reason to append a (faster crackable) MD5 hash to a SHA1 hash...

So the 1024 iterations ARE completely a lose of energy! Believe me Google. Skip that SHA1 if you really need to append the MD5 (and of course to calculate this digest too), please skip it. This is maybe why my Android phone is always connected to the charger. hehe

There must be some clever decision/discussion behind this hashing scheme, but I really don't get it!!! Sorry.
Maybe "older" devices are too lame to calculate SHA1 fast? Is this a serious reason to calculate both SHA1 and MD5. NO

I didn't do any major research about this topic. Maybe someone can explain... BUT this is really a big *FAIL*
I like my Android phone, but this is really *for shame* (maybe also the "Encrypt phone" feature is completely broken, someone should dig into that!).

How many Android devices are out there? OMG!

[gat3way]

The "encrypt phone" feature is based on dmcrypt/LUKS and it is (usually) much more secure as compared to Samsung's algo. I say "usually" because key derivation iterations depend on the hardware the encrypted block device was created on and phone CPUs are slower than most desktop CPUs thus lower iteration count.

That said, I think many people underestimate password security on mobile devices and passwords like 4-digit pins may be common and that is feasible even for bruteforce attacks. Anyway I haven't tried to crack encrypted android volumes yet, so there might be specifics (like you definitely gotta be root in order to dd from the device node). BTW my program has a plugin to crack LUKS volumes on GPU and it's slow (speeds of like 1k-2k c/s are common for volumes created on a desktop system). It also supports only AES-128 and AES-256 block ciphers in CBC-ESSIV mode, while Android may use other scheme. Some time ago someone asked me about cracking encrypted Android volumes and from what I read about Android's FDE implementation, it should already be supported. I asked for a dd dump to test if it works, but still noone sent me one.

[philsmd]

@gat3way
Found another strange file on my phone /data/system/device_policies.xml

Code:

<policies>
<active-password quality="131072" length="4" uppercase="0" lowercase="0" letters="0" numeric="4" symbols="0" nonletter="4"/>
</policies>

I think they are missing an important attribute here, namely: plain="1111"
Lol

What the hell? Any valid reason for this file?

[gat3way]

This looks fun. I don't know what exactly it is used for though. Hopefully that's not about the device password

[philsmd]

It is the device password! If I change my pin to 8 digits there is a very slight change:
length="8" ... numeric="8" ... nonletter="8"

It seems fun, but it really isn't. For shame!!!
Anyone can confirm?