This paper shows how to solve the graphic key of the user of an Android device. This method is supposed to work only on phones with root permissions. The article is based on a problem that was solved during the online CTF (Capture the Flag, computer security competition).
Currently, almost all smartphones use a graphic key in addition to the traditional password. To unlock the device, the user must connect the dots on the screen in a certain sequence specified by them. This "new approach to security" allows you to avoid unwanted clicks and Supplement the authorization procedure. This action seems to be quite complex and safe, which is fundamentally wrong.
If you take a closer look at what a graphic key is and how it works, you can easily come to the conclusion that it is just a 3x3 matrix with some built-in conditions: the pattern that the user draws must consist of at least four points, each of which can be used only once. Since the matrix size is only 3x3, the graphic key can consist of a maximum of 9 points.
Learning the graphic key scheme
The 3x3 graphic key field can be made in numeric form (digits). In fact, the points are registered in the order from 0 to 8 (starting with 0 in the upper-left corner and ending with 8 in the lower-right corner).):
From a statistical point of view, finding all the combinations between 0123 and 876543210 is not so difficult. That's not even 0.2% of all possible nine-digit numbers. We should get approximately 895824 variants of graphic keys.
Android devices store the graphic key data in the format of an unsecured sequence of encrypted SHA-1 bytes. The code variant is roughly similar to the one shown below:
This means that instead of storing just the sequence 125874, an "unsalted" byte array named gest.key is stored in the system file. It is stored in the /data/system folder.
Most of this information can be gleaned directly from the "Android open source" java files (aosp documentation).
* Generate an SHA-1 hash for the pattern. Not the most secure, but it is
* at least a second level of protection. First level is that the file
* is in a location only readable by the system process.
* @param pattern the gesture pattern.
* @return the hash of the pattern in a byte array.
(A SHA-1 hash is generated for the key. This is not the most reliable method, but it provides at least a second level of protection. The first level means that the file is stored in a cell that is read only by the system process. @param generates a graphic key. @return-returns the hash of the graphic key as a byte array).
According to this piece of code, our example graphic key should be stored as the expression 6c1d006e3e146d4ee8af5981b8d84e1fe9e38b6c
The only problem that arises is that SHA-1 is a one-way cryptographic hash function. This means that we can't separate plain text from hashed text. Due to the limited number of possible key combinations and the fact that the Android OS does not use a "salted" hash, it will not take much time to create a dictionary containing all possible hashes of the sequences from 0123 to 876543210.
The specified file is opened in any text or hexadecimal editor:
The last step is to compare the bytes of this file 2C3422D33FB9DD9CDE87657408E48F4E635713CB with the values from the ready-made dictionary and find the hash that allows you to restore the key scheme.
The finished dictionary can be downloaded from the link at the end of the article and opened via any SQLite browser. Using it, you will find the scheme of the original graphic key using the following query::
We get the key to unlock it.
Conclusion
Hacking or bypassing this type of protection on Android is not difficult. The only catch is that we can't get direct access to /data/system/ and the gesture file.key, if the device is not rooted. This option is good for fun and satisfying curiosity, because once you have access, you can simply delete the file with the SHA-1 hash or replace it with your own. In addition, in most cases, lock files have no value from the point of view of forensics.
Currently, almost all smartphones use a graphic key in addition to the traditional password. To unlock the device, the user must connect the dots on the screen in a certain sequence specified by them. This "new approach to security" allows you to avoid unwanted clicks and Supplement the authorization procedure. This action seems to be quite complex and safe, which is fundamentally wrong.
If you take a closer look at what a graphic key is and how it works, you can easily come to the conclusion that it is just a 3x3 matrix with some built-in conditions: the pattern that the user draws must consist of at least four points, each of which can be used only once. Since the matrix size is only 3x3, the graphic key can consist of a maximum of 9 points.
Learning the graphic key scheme
The 3x3 graphic key field can be made in numeric form (digits). In fact, the points are registered in the order from 0 to 8 (starting with 0 in the upper-left corner and ending with 8 in the lower-right corner).):
From a statistical point of view, finding all the combinations between 0123 and 876543210 is not so difficult. That's not even 0.2% of all possible nine-digit numbers. We should get approximately 895824 variants of graphic keys.
Android devices store the graphic key data in the format of an unsecured sequence of encrypted SHA-1 bytes. The code variant is roughly similar to the one shown below:
This means that instead of storing just the sequence 125874, an "unsalted" byte array named gest.key is stored in the system file. It is stored in the /data/system folder.
Most of this information can be gleaned directly from the "Android open source" java files (aosp documentation).
* Generate an SHA-1 hash for the pattern. Not the most secure, but it is
* at least a second level of protection. First level is that the file
* is in a location only readable by the system process.
* @param pattern the gesture pattern.
* @return the hash of the pattern in a byte array.
(A SHA-1 hash is generated for the key. This is not the most reliable method, but it provides at least a second level of protection. The first level means that the file is stored in a cell that is read only by the system process. @param generates a graphic key. @return-returns the hash of the graphic key as a byte array).
According to this piece of code, our example graphic key should be stored as the expression 6c1d006e3e146d4ee8af5981b8d84e1fe9e38b6c
The only problem that arises is that SHA-1 is a one-way cryptographic hash function. This means that we can't separate plain text from hashed text. Due to the limited number of possible key combinations and the fact that the Android OS does not use a "salted" hash, it will not take much time to create a dictionary containing all possible hashes of the sequences from 0123 to 876543210.
Problem solving
We have enough data to analyze the file system dump. Just find the gesture. key and examine its contents:
The specified file is opened in any text or hexadecimal editor:
The last step is to compare the bytes of this file 2C3422D33FB9DD9CDE87657408E48F4E635713CB with the values from the ready-made dictionary and find the hash that allows you to restore the key scheme.
The finished dictionary can be downloaded from the link at the end of the article and opened via any SQLite browser. Using it, you will find the scheme of the original graphic key using the following query::
Code:
Select * from RainbowTable where hash = “2c3422d33fb9dd9cde87657408e48f4e635713cb”.We get the key to unlock it.
Conclusion
Hacking or bypassing this type of protection on Android is not difficult. The only catch is that we can't get direct access to /data/system/ and the gesture file.key, if the device is not rooted. This option is good for fun and satisfying curiosity, because once you have access, you can simply delete the file with the SHA-1 hash or replace it with your own. In addition, in most cases, lock files have no value from the point of view of forensics.
