Crack it, don't break it
This document explains a cleaner approach about cracking dynamic libraries. Have you ever needed to use a library which has already been expired?, Have you ever needed to bypass a validation method?, and the most important: Have you ever needed to crack a library but you know that modifying the binary is illegal? If the answer for one of these question is
Yes, this article is for you.
Do not use the information on this article for illegal or malicious use.
I'm not responsible of your acts.
The situation
Some months ago, I had to use a dynamic library which, in association with a hardware fingerprint reader, provides fingerprint reading. The case was that the library only works until
January of 2004.
When I contacted the vendor, he told me that they do not provide support anymore for the library, and, subtly, suggest me to
crack it.
In order to don't violate any legal right, I wont expose the real library nor the real code. Instead, I created a
replica to explain this technique.
Cracking
In order to read from the fingerprint reader, I have to create a CardReader object, and call read_card() from it. This is a good point from where to start.
The library in question is:
libcardreader.so. I started for disassembling it:
(piping to
c++filt is for demangling the nomenclature)
After skipping some sections, we have:
Here
je (jump if equal
74) is checking the condition after calling
is_valid_date() (b42, two lines before). Here is where the library is validating the date. It works only
if is_valid_date() is true.
What we need to do here, is the ABC of cracking, just to change
je (74) for
jne (jump if not equal, value
75), and after this, the library will work because it will check for
not is_valid_date().
Putting the thing clear: In order to work, the original library, checks that the date is
before January of 2004, now, after cracked, it checks that the date is
after January of 2004. So that, the library now works.
Giving a look at the Intel x86 reference manual, we can corroborate the values for je = 74, and jne = 75.
The next is open the library with your favorite hex-editor, and change this 74 for 75
Calculating the offset (B49), and for the adjacent values, we know this is the 74 we need to change.
After changing the value, we disassemble again
Now we have 75 on the offset B49, and the wanted
jne instruction.
The library is cracked.
A cleaner approach
Of course, even when the vendor proposed me to crack its library, I didn't feel comfortable with the idea of modifying the executable, furthermore, I had a recall in my mind where someone had cracked using linking rules and making the library call his methods instead of the library methods! Yes, he did something like: When
read_card() method calls to
is_valid_date(), the library calls to his
is_valid_date() version, where, of course, he did whatever he wanted inside hes methods. This is a cleaner approach because
he was not modifying the binary.
Having this in mind, and after I read about the internal composition of the ELF format, and symbol resolution rules, I started with the tries and, after few ones, I found the way :)
Symbol cracking
Well, I don't really know how to call this technique. Maybe after explaining how it works, the name will make more sense.
The idea is to provoke a symbol collision. To collide the symbol, in this case the declaration of the function
is_valid_date, with a symbol in the file of our
main.
How can we do it? Easy, just declare a function with the same prototype in the
main.cpp (actually where you have the main function declared) file.
We can know the
is_valid_date() prototype by looking at the declaration on the library header, or we can try to guess, since we know that the function is checked out for its truth value within an if sentence, so that, this function prototype and definition is a good candidate
Since we are declaring a function with the same prototype, and in the same namespace (global), we are colliding the symbols, and, in opposite to we can expect, the library resolve to call
our is_valid_date version.
Before creating the symbol collision
After creating the symbol collision
In this fashion, we can simply bypass the validation returning always true.
In case that the validation is method (a function class member), we have to generate the symbol including the class name ambit, as we were redefining it.
A more interesting case is when the validation method is private. If we try to
redefine it, the compiler say that the method is private and we can not do that in that context.
To bypass this
problem, we can
redefine any other
compatible public method of the class, where we call the private validation from there. We need to redefine this private validation as well. And of course, we lose the original public method functionality.
A compatible method is that one that allows us to check its return value in the same way we check for
is_valid_date(). These could be: a boolean, or a integer.
Further details
This happens for a historical reason, and is related to the first shared library implementations were created so that the default semantic for symbol resolution exactly mirrored those application linked against static equivalents of the same libraries.
If a symbol is defined in multiple libraries, the resolution of that symbol is bound to the first definition found by scanning libraries in the left-to-right order in which they were listed on the static link command line.
Avoiding symbol cracking
Of course, it is possible because the library vendor made an error, he exported all the symbols of his library (the default behavior with gcc).
We can check this out by running nm -DCg on the library
Here we can see the validation methods exposed, creating this security hole.
These methods
must be hidden from exportation. We achieve this by adding the hidden attribute to each of these
__attribute__ ((visibility("hidden"))) allows as to control what symbols we export from our libraries.
A well designed shared library should make visible only those symbols that form part the its application binary interface (ABI), for the following reasons:
1) A user of the library could try to use a symbol that we don't want they use, and we can not change it on later library versions without breaking his code.
2) Exporting unnecessary symbols increase the size of the dynamic symbols table, and this table must be loaded at run time.
3) The security hole that this article is about.
The -Bsymbolic parameter
We can specify the linker parameter
-Bsymbolic to indicate that the library preferentially should resolve the symbols (if they exist) within that library. This works for symbols duplicated on another libraries, but not for those defined on our
main.
Summary
Cracking could be achieve by modifying a binary, or by playing around with symbol resolution.
A definition of a symbol in the
main program, overrides a definition in a library.
Export only the symbols you want the users of your library use. This brings not only performance advantage, but security improvement.
