Crypto

[E Nellie]

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.

[ASSEMbler]

Depends on how complex the aes is. You do realize aes encrypt 256 would take billions of years to crack.

[E Nellie]

Depends on how complex the aes is. You do realize aes encrypt 256 would take billions of years to crack.

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.

[ASSEMbler]

If the file is executable, do some memory sniffing

[E Nellie]

If the file is executable, do some memory sniffing

Will do. Thanks

[E Nellie]

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:

[tmbinc]

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?

[E Nellie]

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.

[tmbinc]

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.

[E Nellie]

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

Thanks.

[E Nellie]

edit.

[E Nellie]

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.

[rso]

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.

[gabe_k]

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.

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