Crypto

Discussion in 'Game Development General Discussion' started by E Nellie, Oct 24, 2010.

  1. E Nellie

    E Nellie Member

    Joined:
    Aug 15, 2010
    Messages:
    13
    Likes Received:
    0
    I have another question...maybe you guys can provide some ideas...I am trying to crack AES encryption/decryption in an executable so obviously the algorithm used to decrypt the file is in the executable. So what would be the best method to decrypt the file with what i know/can find from the disassembled executable? :shrug:

    Any ideas are appreciated.
     
  2. ASSEMbler

    ASSEMbler Administrator Staff Member

    Joined:
    Mar 13, 2004
    Messages:
    19,394
    Likes Received:
    1,054
    Depends on how complex the aes is. You do realize aes encrypt 256 would take billions of years to crack.
     
  3. E Nellie

    E Nellie Member

    Joined:
    Aug 15, 2010
    Messages:
    13
    Likes Received:
    0
    I realize brute forcing it would...but I was assuming I could disassemble it find the algorithm and use that to write my own program to decrypt the file.
     
  4. ASSEMbler

    ASSEMbler Administrator Staff Member

    Joined:
    Mar 13, 2004
    Messages:
    19,394
    Likes Received:
    1,054
    If the file is executable, do some memory sniffing
     
  5. E Nellie

    E Nellie Member

    Joined:
    Aug 15, 2010
    Messages:
    13
    Likes Received:
    0
    Will do. Thanks
     
  6. E Nellie

    E Nellie Member

    Joined:
    Aug 15, 2010
    Messages:
    13
    Likes Received:
    0
    Looking through I'm kind of confused I see string mentions of libtomcrypt 1.17 however it's loaded as follows

    lis %r11, ((aCProjectsCo_28+0x10000)@h)

    yet, the reference rdata is NULL or all 0 bytes...

    I'm confused...:confused:
     
  7. tmbinc

    tmbinc Spirited Member

    Joined:
    Oct 10, 2006
    Messages:
    103
    Likes Received:
    1
    So I assume you can run the executable, and that the executable does decrypt the encrypted file properly. In that case, you know that it has everything required included, i.e. it has the algorithm, the key and the data.

    If that's the case, you could start with static or runtime analysis. Static analysis is disassembling the binary, looking for a call to the AES function, then tracing the arguments back to see where the key comes from. Looks like you already loaded your binary in IDA - that's a great start. Now, you need to understand powerpc assembly, and understand how addresses are loaded (lis/ori), how calls work (bl, blr), and generally what the code you see is running. If you've never done that before, then this step won't be easy. But believe me, it gets easier.

    Depending on the executable, you might be as lucky to see that the key is loaded from a constant that's part of the executable - or it's derived from something before starting the AES decryption, which can be incredibly complicated if someone tried to obfuscate this.

    In these cases, it might be simpler to do a runtime analysis, or "memory sniffing" as ASSEMbler said. This requires you to be able to either run the binary in a good emulator, or having a debugger on the target system. In each case, you want to break in the AES "set key" function, and grab the key from memory. Usually, the key is passed as a pointer into memory. You need to identify which argument it is, and then, when breaking in the debugger, dump the 16 (for AES-128) bytes starting at that address. If you know that it's a certain algorithm, just grab a reference implementation, and use the grabbed key to decrypt your data. If you have the debugger running, you can grab a few pieces of encrypted and decrypted data so you have some "known good" datapair to verify that your key is correct and your algorithm is the right one.

    Do you mind sharing a few more details about your target?
     
  8. E Nellie

    E Nellie Member

    Joined:
    Aug 15, 2010
    Messages:
    13
    Likes Received:
    0
    Wow. That might have been one of the most helpful/insightful replies I've ever had to a help topic. Thanks.

    First, the target is a game that decrypts a file it uses, I would like to decrypt this file so I can see what kind of information is inside.

    And yes the executable does have everything included, at runtime the target file is decrypted/encrypted depending on the circumstance. I have a tiny bit of experience with PPC so i barely understand how the code is executing. The key however is not kept as a constant and is generated by the same algorithm every time the executable is run.

    Also, I doubt that it is obfuscated because of the fact that it is meant to be decrypted on a console. In the rdata, which is listed before the subs are strings which show the source file used to compile the decryption/encryption code and it seems that in the subs these are used as above

    e.g. lis %r11, ((aCProjectsCo_28+0x10000)@h)

    however they are all null or contain 0 bytes...the reason this confuses me is because as above it would be loading a NULL value into r11 in the higher 32 bits?

    As for the "memory sniffing"...because this is on a console I would need a debug kernel in order to break the code? Or could I use IDA+Debugger and achieve the same goal?

    Thanks for helping.
     
  9. tmbinc

    tmbinc Spirited Member

    Joined:
    Oct 10, 2006
    Messages:
    103
    Likes Received:
    1
    PowerPC instructions are 4 bytes (i.e. 32bit). That means they cannot load a 32bit constant, since some of the bits would have to specify the opcode type, target register etc. Thus, loading a 32bit constant, consists of two instructions that both load 16bit. Usually, this is "lis rsomething, upper_half" (which loads the top 16bit of a 32bit register), then "ori rsomething, rsomething, lower_half", or "addi" or "subi" (to or, add or subtract a 16bit immediate). A valid abbreviation is symbol@h (for the upper 16 bit) and symbol@l (for the lower 16 bit). (For 64bit addressing modes, you would use 5 instructions (lis, ori, rldicr, oris, ori), but because of this, 64bit-constants are usually loaded from memory instead of coded into the instructions).

    IDA automatically detects some of these combinations, and creates a reference like the one above. Likely, in your example, there is a subi %r11, %r11, aCProjectsCo_28@l following this. r11 would be loaded with the pointer to aCProjectsCo_28 (an automatically named symbol). lis doesn't load the actual VALUE there. So in your above example, after the lis instruction, r11 wouldn't be null, but the first half of the pointer.

    What you need to do is to find the function that does the AES, and trace back the source of the key.

    When debugging on a console, then you would need the proper debug console. Unfortunately I won't be able to help you here.
     
  10. E Nellie

    E Nellie Member

    Joined:
    Aug 15, 2010
    Messages:
    13
    Likes Received:
    0
    Thanks.
     
  11. E Nellie

    E Nellie Member

    Joined:
    Aug 15, 2010
    Messages:
    13
    Likes Received:
    0
    edit.
     
    Last edited: Oct 27, 2010
  12. E Nellie

    E Nellie Member

    Joined:
    Aug 15, 2010
    Messages:
    13
    Likes Received:
    0
    Would anyone be kind enough to explain the best way to insert a breakpoint into a game without the source? I have the necessary development kit and the SDK.
     
  13. rso

    rso Gone. See y'all elsewhere, maybe.

    Joined:
    Mar 26, 2010
    Messages:
    2,197
    Likes Received:
    455
    Without the source I'd say your best bet would be a debugger like OllyDbg, but since we're not talking Windows you're probably SOL since you're stuck with just the MS tools which aren't good at all at this kind of thing... I'm not sure you can even get the debugger to work without a PDB at all (too lazy to boot up a Windows machine to check that tho).
    A workaround (works for Windows apps, at least) would be is to provoke a crash so you'll get the debugger to show up w/o a PDB, maybe you can get it to set breakpoints then restart the program...
    Another (vague) idea might be to somehow generate a dummy PDB, without any source info etc just to satisfy the debugger.
     
    Last edited: Nov 8, 2010
  14. gabe_k

    gabe_k Rising Member

    Joined:
    Nov 30, 2008
    Messages:
    66
    Likes Received:
    1
    I'm guessing by your posts in here, and on other sites that the game in question is Call of Duty Black Ops. If that's the case, and you're using a 360 dev kit and sdk, open up Visual Studio, go to Tools, select Attach to Process, for transport select Xbox 360 Debugging, then select your dev kit and set your breakpoints. If I'm correct about what you're working on, then if this does lead to anything, please do not release it (the last thing we need is another MW2).
     
    Last edited: Nov 9, 2010

Share This Page