Breaking Samsung Android Passwords/PIN
#21
WOW Smile

Well someone can write a script that generates rules based on that file, would be rather useful Smile
Reply
#22
It seems to log into a rooted device you only need to *remove* this policy file and reboot:
http://www.digitalmobile.in/community/th...vice.1893/
EDIT: But of course it is nicer to get the persons plain PASSWORD/pin, hehe

Furthermore, this pdf highlights some (in)security measures of android: https://hacktivity.com/hu/letoltesek/arc..._final.pdf

This is really a big FAIL. There is no sign of security
Reply
#23
Some examples for "salt conversion" for those that are not sure how to get the hex string, the steps are easy, but were not descibed in detail.
Of course this conversion is easy, but maybe someone did not get it at fist glance (including me, since the negativ number could be anything... if not explained):

Basically we have a 64 bit number (SIGNED). The steps:
Code:
standard hex: 0123456789abcdef
hex:    pos:
0        0
1        1
2        2
3        3
4        4
5        5
6        6
7        7
8        8
9        9
a       10
b       11
c       12
d       13
e       14
f       15

example: -660806340342588628:
660806340342588628 : 0000 1001 0010 1011 1010 0111 1101 1101 1000 1101 0111 0010 0010 0100 1101 0100
2s complement      : 1111 0110 1101 0100 0101 1000 0010 0010 0111 0010 1000 1101 1101 1011 0010 1100
Decimal            :   15    6   13    4    5    8    2    2    7    2    8   13   13   11    2   12
Hex                :    f    6    d    4    5    8    2    2    7    2    8    d    d    b    2    c
Note: 2s complement is (very basically said/reduced) flip the bits and add 1
Note2: you of course only need the 2s complement if bit 64 (sign bit) is 1, the first from the left
=> f6d45822728ddb2c

example2: -1945496149554231618
1945496149554231618: 0001 1010 1111 1111 1100 1010 0111 0000 1011 1010 0001 0001 1111 1001 0100 0010
2s complement      : 1110 0101 0000 0000 0011 0101 1000 1111 0100 0101 1110 1110 0000 0110 1011 1110
Decimal            :   14    5    0    0    3    5    8   15    4    5   14   14    0    6   11   14
Hex                :    e    5    0    0    3    5    8    f    4    5    e    e    0    6    b    e
=> e500358f45ee06be

example3: 4982169084343208092
4982169084343208092: 0100 0101 0010 0100 0011 1000 0110 0010 1011 0011 0011 0101 1100 1000 1001 1100
2s complement      : not needed since positiv!
Decimal            :    4    5    2    4    3    8    6    2   11    3    3    5   12    8    9   12
Hex                :    4    5    2    4    3    8    6    2    b    3    3    5    c    8    9    c
=> 45243862b335c89c

Hopes this could be of help to someone. Best
(P.S. Yes I know you can but it into the calculator OR print it via ANSI C printf too. hehe)
Reply
#24
Glad to see other people are reversing handset hashes, I've only noticed this 'more secure' version of hash storage in the galaxy S3 and newer; What other devices have you guys seen this on?

I checked the S2 and it was using the typical plain sha1 on iteration.

^
Edit: If the S2 is running Android 4.x or higher it seems to be using the 1024 iteration but prior to that it is a single sha-1 round

Edit: my last post salt code conversion had a couple issues, the main one was the sql table stores the salt as a signed 64 bit number, java store longs as signed 64 bit numbers, but when long.tohexstring is called on a long it is first converted to an unsigned long and then converts to hex; The bellow code should work for all salts
Code:
def get_salt(salt):
        int_salt = int(salt)  
        int_salt = (int_salt & 0xffffffffffffffff)
        salt= hex(int(int_salt)).lstrip("0x")
        salt= salt.rstrip('L')
        #print salt
        return salt
Reply
#25
(04-12-2013, 11:04 AM)philsmd Wrote: @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?

It's not the way you think. For some devices the data fits the device password. For others, structure is different, but also information is sometimes wrong. That's why I didn't post about this file.
Reply
#26
(04-12-2013, 10:22 AM)gat3way Wrote: 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.

I really doubt that. I'm currently optimising all three common android encryption variants (including dmcrypt) using gpu, it's no big deal. Some variants samsung introduced however are a lot more secure and also fips standardized, as I think they intend to use them for business devices.
Reply
#27
Could you simplify on how you convert the salt value to binary as I don't understand the method shown by phil.

eg: how did you get this to binary?

660806340342588628 : 0000 1001 0010 1011 1010 0111 1101 1101 1000 1101 0111 0010 0010 0100 1101 0100

though after that part I understand it.
Reply
#28
You just need to make the base conversion.... instead of base 10 (the numeric scale we most of the time use), here we/I did use (but ofc it is not striclty necessary) base 2 (to show what happens w/ the negative sign / bit).

Most of the calculators - not only hardware ones - can change the output format (the base) to 2 (such that only 0 and 1 is possible instead of 0-9).

There are also some web sites that let you convert to binary...

Anyway, it is a very simple way to do so, maybe this explains it: http://math.about.com/od/calculuslessons...gebase.htm

Basically you just check is the original number >= the largest possible number, than we set a 1, else 0, subtracting the number if it was divisible and continue, always setting either 0 or 1.
Where in our case the largest possible number is 2^63 = 9223372036854775808, you continue by divinding this by 2 (since we use base 2)... always checking if the number fits (=> 1) or doesn't fit (=> 0).
Reply
#29
(04-12-2013, 12:02 PM)philsmd Wrote: 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?

I'm try to confirm but can't do it.
I think 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 Touch Watch Phone). Pattern lock is VERY easy to crack. 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 and more.....
Reply
#30
Hi

I read by physical aqusition with XRY data from two mobile phones:
1. Galaxy 3
2. Galaxy 4 model 9505

I found without any problems password.key file:
1. Galaxy 3: 059A4D874E851DC41B176EAA20BE1A7A9A39EF3F
2. Galaxy 4: F9784B5422627804B0AD38B87159F8049F127476

When I tried to read the salt string I couldn’t read this value from settings.db file.
I used X-Ways program (search key mode) and I found the values in file: locksettings.db-wal:

5lockscreen.password_salt-6238592000407724940_

1. Galaxy 3: -5409215673359023022 – converted to hex by calculator: B4EE9B011BF5C452
2. Galaxy 4: -6238592000407724940 – converted to hex by calculator: A96C11A10D1A9C74

device_policies.xml:
1. Galaxy 3: length="5" uppercase="0" lowercase="0" letters="0" numeric="5" symbols="0" nonletter="5" recoverable="false"

2. Galaxy 4:
active-password quality="262144" length="4" uppercase="0" lowercase="4" letters="4" numeric="0" symbols="0" nonletter="0" recoverable="false".

I used the command:

Galaxy 3: cudahashcat32.exe -a 3 -m 5800 059A4D874E851DC41B176EAA20BE1A7A9A39EF3F:B4EE9B011BF5C452 ?d?d?d?d?d

Galaxy 4: cudaHashcat32.exe -a 3 -m 5800 F9784B5422627804B0AD38B87159F8049F127476:A
96C11A10D1A9C74 ?l?l?l?l

And NOTHING happened whitch could be of use to me

Session.Name...: cudaHashcat
Status.........: Exhausted
Input.Mode.....: Mask (?l?l?l?l) [4]
Hash.Target....: 059a4d874e851dc41b176eaa20be1a7a9a39ef3f:B4EE9B011BF5C452
Hash.Type......: Samsung Android Password/PIN
Time.Started...: Fri Mar 07 09:20:16 2014 (3 secs)
Time.Estimated.: 0 secs
Speed.GPU.#1...: 217.4 kH/s
Recovered......: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.......: 456976/456976 (100.00%)
Rejected.......: 0/456976 (0.00%)
HWMon.GPU.#1...: 99% Util, 57c Temp, N/A Fan

Started: Fri Mar 07 09:20:16 2014
Stopped: Fri Mar 07 09:20:20 2014

When I used password.key an salt from forum, was well DONE

941d4637d8223d958d7f2324572c7e319dcea01f:f6d45822728ddb2c:10021981

Session.Name...: cudaHashcat
Status.........: Cracked
Input.Mode.....: Mask (?d?d?d?d?d?d?d?d) [8]
Hash.Target....: 941d4637d8223d958d7f2324572c7e319dcea01f:f6d45822728ddb2c
Hash.Type......: Samsung Android Password/PIN
Time.Started...: Fri Mar 07 08:58:18 2014 (1 min, 57 secs)
Speed.GPU.#1...: 178.7 kH/s
Recovered......: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts
Progress.......: 21135360/100000000 (21.14%)
Rejected.......: 0/21135360 (0.00%)
HWMon.GPU.#1...: 99% Util, 69c Temp, N/A Fan

Why am I not able to recover passwords from my Galaxy’s
Reply