New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Android 4.4 FDE #1442

Open
GrepItAll opened this Issue Nov 13, 2017 · 6 comments

Comments

Projects
None yet
4 participants
@GrepItAll

GrepItAll commented Nov 13, 2017

Although Android 4.4 has been released for 4 years now, approximately 16% of Android devices still run this OS version (as of August 2017). KitKat (4.4) has also continued to receive Security Patches as recently as September 2017.

As the last major release of Android before hardware backed FDE started to become common, it would be great if support for Android 4.4 FDE could be added into Hashcat.

This was referenced in a Twitter conversation with Nikolay Elenkov in 2014: https://twitter.com/kapitanpetko/status/484653251355082754

The python script that he referred to (https://github.com/nelenkov/Santoku-Linux/blob/master/tools/android/android_bruteforce_stdcrypto/bruteforce_stdcrypto.py) has been updated since that Twitter discussion to check magic values for ext4, as well as additional encryption checks.

Devices running 4.4 FDE continue to frustrate many people, so it makes perfect sense for the world's fastest password cracker to implement support for this ;)

I can provide sample data if needed.

Thanks in advance!

@philsmd

This comment has been minimized.

Show comment
Hide comment
@philsmd

philsmd Nov 13, 2017

Member

Is this a duplicate of #411 ?

Member

philsmd commented Nov 13, 2017

Is this a duplicate of #411 ?

@GrepItAll

This comment has been minimized.

Show comment
Hide comment
@GrepItAll

GrepItAll Nov 14, 2017

No, although key elements are similar. #411 deals with FDE on devices where hardware backed FDE is enabled, but where the hardware keys are leaked out of the processor in the case of Qualcomm devices. 4.4 FDE does not use hardware backing. Both use scrypt however.

GrepItAll commented Nov 14, 2017

No, although key elements are similar. #411 deals with FDE on devices where hardware backed FDE is enabled, but where the hardware keys are leaked out of the processor in the case of Qualcomm devices. 4.4 FDE does not use hardware backing. Both use scrypt however.

@jsteube

This comment has been minimized.

Show comment
Hide comment
@jsteube

jsteube Nov 21, 2017

Member

I see this is PIN only. For only PIN, it should be fast enough on CPU. What am I missing here?

Member

jsteube commented Nov 21, 2017

I see this is PIN only. For only PIN, it should be fast enough on CPU. What am I missing here?

@GrepItAll

This comment has been minimized.

Show comment
Hide comment
@GrepItAll

GrepItAll Nov 21, 2017

You are correct that this PoC code is only for PINs. However, Android 4.4 lockscreens can have a password set instead, which is then used as the basis for the FDE encryption. So whilst most users would have PINs for which this script is sufficiently fast, it is not fast enough to use for passwords which are still frequent enough to cause problems when attempting to recover data from these devices.

GrepItAll commented Nov 21, 2017

You are correct that this PoC code is only for PINs. However, Android 4.4 lockscreens can have a password set instead, which is then used as the basis for the FDE encryption. So whilst most users would have PINs for which this script is sufficiently fast, it is not fast enough to use for passwords which are still frequent enough to cause problems when attempting to recover data from these devices.

@brandoncasaba

This comment has been minimized.

Show comment
Hide comment
@brandoncasaba

brandoncasaba Dec 9, 2017

To be clear, the PIN 1234 is the same as the password 1234 in the implementation. The password is simply treated as a string.

brandoncasaba commented Dec 9, 2017

To be clear, the PIN 1234 is the same as the password 1234 in the implementation. The password is simply treated as a string.

@GrepItAll

This comment has been minimized.

Show comment
Hide comment
@GrepItAll

GrepItAll Dec 11, 2017

Correct, apologies for the ambiguity. I meant that the device password can be non-numeric, whilst the python script will only handle numeric codes.

GrepItAll commented Dec 11, 2017

Correct, apologies for the ambiguity. I meant that the device password can be non-numeric, whilst the python script will only handle numeric codes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment