Results 1 to 9 of 9

Thread: CRC checksum / Anti-Tampering

  1. #1

    CRC checksum / Anti-Tampering

    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..

  2. #2
    Registered User
    Join Date
    Dec 2005
    Posts
    216
    Blog Entries
    5
    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.

  3. #3
    Quote Originally Posted by rendari View Post
    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 View Post
    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!!
    Last edited by opc0d3; October 15th, 2012 at 15:26.

  4. #4
    Registered User
    Join Date
    Dec 2005
    Posts
    216
    Blog Entries
    5
    Quote Originally Posted by opc0d3 View Post
    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

  5. #5
    Quote Originally Posted by rendari View Post
    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.

  6. #6
    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

  7. #7
    Quote Originally Posted by squidge View Post
    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!!

  8. #8
    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.

  9. #9
    Quote Originally Posted by squidge View Post
    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!!
    Last edited by opc0d3; October 18th, 2012 at 00:34.

Similar Threads

  1. Help on checksum analysis
    By akimp3 in forum RCE Cryptographics
    Replies: 8
    Last Post: July 16th, 2007, 08:17
  2. Linux Anti Anti Debugging Techniques
    By JMI in forum Linux RCE
    Replies: 2
    Last Post: July 17th, 2005, 12:10
  3. CRC,checksum??!
    By ramin_rad2000 in forum Malware Analysis and Unpacking Forum
    Replies: 6
    Last Post: April 26th, 2004, 12:38
  4. Anti-trace/Anti-debug techniques
    By foxthree in forum Advanced Reversing and Programming
    Replies: 30
    Last Post: September 4th, 2002, 11:15
  5. Strong Anti-debugging, Anti-FrogsIce
    By Kayaker in forum Advanced Reversing and Programming
    Replies: 7
    Last Post: November 30th, 2000, 04:41

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •