Cracking by example: MIPS 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.


A little background on this one: I have a MIPS native library that checks a license file that is unique per CPU ID. The license number itself is a 128-bit hexadecimal number represented as a string which is most likely generated taking the CPU ID seed. I have access to the native library .so and I decompiled it at Retargetable Decompiler site.

Fortunately whoever compiled the library did it with GCC and -g switch on, so we have a lot of debug symbols.

Reduced capture of decompiled functions prototypes

A quick glance over the function names gives us two interesting targets to look at: testLicense and testLock. My first idea was trying to reverse engineer the license generation algorithm (which in a quick glance at the decompiled code it is mainly XOR-ing stuff). Then I just figured out I could just crack it to bypass the license check, mainly, make it return that license is OK every time, basically the same thing I did with the .Net and Java apps I cracked.

I decided to start with testLock function, mainly because it actually wrapped testLicense and looked simpler than testLicense, especially in the number of parameters it takes.

First lines of testLock decompilation

What I rapidly found out is that the reported offset of the function on the library (0x3c308) was wrong (the decompiler probably used a different starting offset). Then I decided to use objdump, for which I had to install a MIPS toolchain. After getting the disassembly, I found the real offset.

First lines of testLock disassembly

testLock only had a couple of callers all around the library code.

One of testLock callers

We can easily see the caller checks if the return value is lesser than 1. I'm going to assume a value < 1 means error because in a lot of C APIs a negative value is an error (why 0 is error in this API really baffles me). Next step is to modify testLock() so it always returns 1.

testLock() function in Bless hexadecimal editor

For this we're just going to replace the whole function code by the following MIPS assembly:

jr ra
li v0,1

First instruction jr ra jumps to the address specified in RA register, which in MIPS is equivalent of returning to function caller (similar to x86's RET instruction). Second instruction li v0,1 sets V0 register to 1. V0 is used to store the return value of a function. So replacing the current code with these 2 functions should be equivalent of return 1 (li v0,1 is actually executed before the jump due to MIPS' delay slot). More detailed information about MIPS function calling conventions here.

But we need to keep the function size to not mess up offset references and relocation information contained on the library. Fortunately, MIPS, like other architectures, has a NOP instruction, and also forunately, all instructions in MIPS are the same size: 4 bytes. And not only that, NOP instruction is all zeroes.

Modified testLock() function

As you can see in the new function, it's all NOPs except the 2 last 32-bit words which are 0x03e00008 (jr ra) and 0x24020001 (li v0,1).

And that's all, folks!