PDA

View Full Version : CRC checksum / Anti-Tampering


opc0d3
October 15th, 2012, 13:49
Hello folk i've coded an antitampering.. the source is http://pastebin.com/PqzPpRCg

But i've had some problems with the code.. i've tested the memory position of the functions and the main() is greater than doEverything().. but when I alter the code inside of the MAIN() function, it's changing the hash.. don't know why..

other fact is, somebody know any way to automate the CRC check using a script with PyDBG to verify if the code has a CRC cheking in it ?
My goal is to identify if the .EXE is doing hash checking.


thnks..

rendari
October 15th, 2012, 14:45
Best way to check if a program is CRCing itself at runtime is to just set a hardware breakpoint on access somewhere in the code section, and run the program.

As for your first question, I don't understand what you are asking.

opc0d3
October 15th, 2012, 15:19
Quote:
[Originally Posted by rendari;93443]Best way to check if a program is CRCing itself at runtime is to just set a hardware breakpoint on access somewhere in the code section, and run the program.


Sorry I didn't get it well.. cause I need to do it in automated way.
But how can I know if it is doing a CRC checking ? it's confuse..

I'm kind lost... I could see if any function reads a sequence of code.. don't know.. :S

Quote:
[Originally Posted by rendari;93443]Best way to check if a program is CRCing itself at runtime is to just set a hardware breakpoint on access somewhere in the code section, and run the program.

As for your first question, I don't understand what you are asking.


I searched before post here asking about how to hash in my function to compare it (in this way i can know if there is any Soft Breakpoint), but in C doesn't have a official way to know the size of a function.
Then i did it in a simple way.. I get the memory position of MAIN() function, subtracts with the doEverything() function memory position and I assumed that the result is the size of doEverything() function.

So with my code I was supposed to hash only the doEverything() function but when I alter the code inside the Main() function the HASH generated is changed, I don't know why it's happen, because i only hash the doEverything() function.

But reading on the wild, I found many people saying that the compiler can realocate the function in memory and it could ruin my logic of getting the function size to hash at runtime.

And now i'm looking for some help :P
Thanks!!

rendari
October 16th, 2012, 11:10
Quote:
[Originally Posted by opc0d3;93444]Sorry I didn't get it well.. cause I need to do it in automated way.
But how can I know if it is doing a CRC checking ? it's confuse..

I'm kind lost... I could see if any function reads a sequence of code.. don't know.. :S



I searched before post here asking about how to hash in my function to compare it (in this way i can know if there is any Soft Breakpoint), but in C doesn't have a official way to know the size of a function.
Then i did it in a simple way.. I get the memory position of MAIN() function, subtracts with the doEverything() function memory position and I assumed that the result is the size of doEverything() function.

So with my code I was supposed to hash only the doEverything() function but when I alter the code inside the Main() function the HASH generated is changed, I don't know why it's happen, because i only hash the doEverything() function.

But reading on the wild, I found many people saying that the compiler can realocate the function in memory and it could ruin my logic of getting the function size to hash at runtime.

And now i'm looking for some help :P
Thanks!!


With the hardware breakpoint, if the program reads itself, the hardware breakpoint will trigger. Thus you know it is checking itself, and with a bit of debugging you can see if the checking algorithm is CRC.

As for the memory locations of the functions inside the executable: You could always load the program in OllyDBG and see for yourself where everything is, and debug the program to see what's going wrong.

-rendari

opc0d3
October 16th, 2012, 14:27
Quote:
[Originally Posted by rendari;93459]With the hardware breakpoint, if the program reads itself, the hardware breakpoint will trigger. Thus you know it is checking itself, and with a bit of debugging you can see if the checking algorithm is CRC.

As for the memory locations of the functions inside the executable: You could always load the program in OllyDBG and see for yourself where everything is, and debug the program to see what's going wrong.

-rendari


Suppose that you have to make a script to discover in automatic way, if the program its CRCing itself. But in my case i did a hashing of ONE function.. When you said to drop a Hard Breakpoint where I would drop this breakpoint ?

I'll do the debugging to see whats going wrong, thanks.

squidge
October 17th, 2012, 05:32
You can't really guess the size of a function by taking the address of one function and subtracting the address of the next, as they could be anywhere in memory, and could change each time you recompile or relink the executable. Heck, the compiler might even optimise your code in such a way that it thinks parts of a function are similar to another, so you could find that doEverything actually uses (calls) a portion of main(), or the other way around (or a part of any other function in the app). It may even breakup your doEverything function into multiple sub-functions depending on optimisation level.

So you need to stop the compiler optimising the code, and then include a 'signature' to indicate the end of the function.

What I typically do instead is checksum a random page of code on a timer event. I've seen it drive people nuts - they change a piece of code and try it, and it works, then at another random time in the future, it fails. Then they set a hw bp and its not triggered (as its not checking the code where the bp is at that particular time). They then spend ages looking for the checksum routine itself, but its obfuscated against crypto analysers so they have to do it the long way. Of course it'll still get patched in the end, but its still fun giving them a challenge, and thats what RE is all about

opc0d3
October 17th, 2012, 10:33
Quote:
[Originally Posted by squidge;93474]You can't really guess the size of a function by taking the address of one function and subtracting the address of the next, as they could be anywhere in memory, and could change each time you recompile or relink the executable. Heck, the compiler might even optimise your code in such a way that it thinks parts of a function are similar to another, so you could find that doEverything actually uses (calls) a portion of main(), or the other way around (or a part of any other function in the app). It may even breakup your doEverything function into multiple sub-functions depending on optimisation level.

So you need to stop the compiler optimising the code, and then include a 'signature' to indicate the end of the function.

What I typically do instead is checksum a random page of code on a timer event. I've seen it drive people nuts - they change a piece of code and try it, and it works, then at another random time in the future, it fails. Then they set a hw bp and its not triggered (as its not checking the code where the bp is at that particular time). They then spend ages looking for the checksum routine itself, but its obfuscated against crypto analysers so they have to do it the long way. Of course it'll still get patched in the end, but its still fun giving them a challenge, and thats what RE is all about


I compiled my program, i did a debug on it and I found what I was looking for.. the Main function is really under the doEverything function (MAIN() is in a higher memory position) and my CRC function it's doing the right hashing of the function.. So i guessed that my compiler isn't doing the optimization and it's compiling in the sequence of the C code.

NOW i need to create a PyDBG script to automate the job of detect CRC checking.. i thought that maybe I can keep a log of every CALL and see which function is reading a sequence of memory.. what do you think ? it's possible ?

I'm really beginner at RE hehehe but i want to LEARN!
I think that the best thing is when you read something, understand it and when you do in practice you know what you doing.. it's just AMAZING!

thanks for the supporting!!

squidge
October 17th, 2012, 11:14
Personally, I'd probably remove the read permission of the memory pages which have execute permission and then check to see what access violations I get. If I get them across a range of sequential pages (or even sequential addresses within a page), then chances are that the app is checking itself for some reason. You could do similar by setting up page guards, but these are one-shot deals.

opc0d3
October 17th, 2012, 20:28
Quote:
[Originally Posted by squidge;93480]Personally, I'd probably remove the read permission of the memory pages which have execute permission and then check to see what access violations I get. If I get them across a range of sequential pages (or even sequential addresses within a page), then chances are that the app is checking itself for some reason. You could do similar by setting up page guards, but these are one-shot deals.


I was trying to do something like that but i didn't find a way to do that through python.. neither with C.
How would you do that ?

Keep trying here.. thanks again!!

#EDIT

I was searching on the wild to find how I would change the memory rights... and I found a solution with VirtualProtect but it doesn't working.. The Error: 487 keeps always showing to me!

my python code:
http://pastebin.com/uxhWP0SA

can you help me ?

thanks!!