Cracking by example: ARM native library

Disclaimer:

The information presented in this article is for educational and research purposes only. Any actions and/or activities related to the material contained within this article are solely your responsibility. The misuse of the information from this website can result in criminal charges brought against the persons in question. The authors will not be held responsible in the event any criminal charges be brought against any individuals misusing the information in this website to break the law.

I have an ARM library for Android for face recognition that requires a license that is generated per hardware ID. I don't know how this license works or how this hardware ID is generated. Hell, I don't even know ARM assembly. So let's get into it!

First of all, initializing the library with a license file from another device will throw the following exception (note that the library has an associated JAR that accesses it through JNI):

FATAL EXCEPTION: Thread-480 Process: com.example.testapp, PID: 23785 com.xxx.xxx.IFaceException: License has different HWID than this machine. Contact support with your HW Id: ru+xCsEr61RRABc= 

Ok, so time for disassembly. This is the easy part: just use an ARM cross-compiled objdump.

$ ./aarch64-linux-android-objdump -d ~/libiface.so > ~/libiface.so.asm


Since the library is ~60 MB, the disassembly was pretty big, ~95 MB. I opened the disassembly and looked for the word "license". Fortunately again, the library had all the debugging symbols, so I could read the original function names  without any problem. I finally found a function called ILicense_InitFromFile, which makes sense since we're using a license file.

Probably the most interesting function name here is _ZN8ILicense6VerifyEv.

This is clearly doing some calculations with the license, and it doesn't call any other function, so it clearly our target. As you can see in ILicense_InitFromFile, the return value is w0. You can see w0 is set to either 1 or 0. In the initial check, you can see that if w2 is not zero, the function branches to +0x40 (0x5b1c3c), which sets w0 from w1 and returns. Since w1 is set to 0 just before this check, this makes me think 0 is failure and 1 is success. To check this hypothesis, I will nop most of the function except setting 1 to w1, setting w1 to w0, and the return. So the function will look something like this:

Note that NOP machine code in ARM is 0xd503201f.

So we open the library in a hex editor and we find our function at offset 0x5b1bfc.

And we patch it with nops as explained above

And it works fine! We can upgrade our hypothesis to a theory ;)

I hope you liked this new article about cracking and as usual if you have any questions or suggestions, I'm all ears :)