[Giagnocavo]Michael::Write() - Cracking code 5.1: Increasing your configuration

Thursday, March 31, 2005

Cracking code 5.1: Increasing your configuration

Yet another super-easy tutorial... (Revision 2 for legal reasons)

When attacking code, always look for the smallest, least intrusive change. The more you change, the more you have to worry about A: screwing something up and B: not being able to move your changes forward when the emitted code changes. Sometimes copy protection authors use encryption and likewise. Sometimes they even do it correctly. But many times, the critical path of code comes down to a single bit or couple of bytes.

I've talked about flipping branches (jumps) before. Some programs all boil down to an "if(boolean)...", in which case flipping a bit of a jmp will reverse the condition (jump if equal to jump if not equal). This results in the code always working when you enter invalid input, and not accepting valid input. But more complex code might actually depend on a bit more code, say, a variable being set to a certain number. For instance, maybe it has an "activation level", and the higher it is, the more features are enabled. In such cases, it's not feasible to go around flipping a bunch of branches.

Today's tutorial will use IDA Pro (www.datarescue.com). You can get a free demo to try out. However, if you're gonna do a lot of work with IDA Pro, it's only $439 for the full version. It even now supports cross-platform debugging (i.e., debug your Linux app on Windows), and supports .NET executables. I have to try it, but it sounds like this could be my solution to developing (debugging) on Windows for Linux. Very, very cool.

No sample program this time, since it is really easy to grasp. Lets take a theoretical program: MagicLineConverter. MagicLineConverter converts input data to output data and does some magical transformation on it. The program is configured for a set number of lines. So you can buy a 1000 line program, a 2000 line program, etc. They have some genius crypto people on staff, so trying to generate fake config files for it just isn't possible. You need to try it with a million lines, just to make sure it works, so you can get a purchase order to buy the program. So, you download the demo program, but it expires before you get a change to examine it. Now, you have zero lines configured for use.

Thus, we load the program in IDA Pro. After loading the program, you'll get a large disassembly view. Poke around, and you'll see names like “sub_8048400” and “dword_804967C”. As with any attack, you've got to start off by finding the real method and variable names. IDA Pro makes this not too hard, and offers a renaming function that allows you to rename functions as you go along. Thus, if you think a variable holds a value representing if there is network access, you can rename it to say "IsNetworkAvail" instead of remembering a memory location. If you work around for a while, you can probably reconstruct a lot of the program logic. The more you understand, the better your patch can be.

Well, when you run the program, output like this is probably sent:
Configured for 1000 lines.

Back in IDA Pro, goto the strings window. Search for that string. Double click it and you'll see something like this in the dissembler: ".data:001234 'aConfigured_for', 0Ah, 0. On the next lines, you'll have information like "; DATA XREF: sub_001400+E". IDA is telling us where this string is referenced. If we go there, we'll probably see something like this:

push ds:dword_0A240200
push offset aConfigured_for ; "Configured for %d lines.\n"
call printf

By now, we're probably almost done. We've found where some code is that reports the total lines the program is configured for. Somehow, this routine knows where to get the data, or the data is passed in. Since there's a dword being pushed and printed, it's safe to assume the count is stored there. Click that dword, and press 'n' to rename it. Enter a good name, such as 'possibleCount' or 'printedCount'. When the copy protection is good, there could be multiple levels of indirection leading up to printing something critical like that. Thus, using tentative names that reflect what you are certain of helps if things get more complex down the road. You can also rename the routine to something useful like "printCount".

Now, we want to see whereelse this variable is used. IDA Pro has a feature that lets us see all references an item. In the disassembly, right click our renamed variable, and select “Jump to xref to operand” (or just press x). A dialog is shown that has different instructions using this memory. Look for ones that look like initialization. Here's two common examples:

mov ds:printedCount, 0
mov ds:printedCount, ecx

The first one first. Highlight that entire line (mov ds:printedCount, 0). Then switch to Hex view. You'll see something like this highlighted: C7 05 34 12 00 00 00 00 00 00. Since it's a dword, there is 4 bytes to represent zero. Modify any of them to a value of your choosing. (thus changing mov ds:printedCount,0 to ,1000000). This patch can be as small as a single bit if your choose!

But wait... sometimes GCC won't generate a “mov something,0” to initialize it. In some cases, for some processors, and certain optimizations, it'll use a register for initialization. In such case, the disassembly might look something like the second case:

; Somewhere deep in the program
mov ds:printedCount, ecx ; After critical processing

Now we have to find out where ecx is initialized. It probably won't be too far away. If we're lucky, there will be a mov ecx, 0. However, optimized code probably won't emit that. Instead, it might have:

xor ecx, ecx

xor'ing a value against itself will always produce zero, and “xor ecx, ecx“ takes up 3 less bytes than “mov ecx, 0“. The xor is only two bytes (0x31c9). Two ideas: First, fill it with nops. Depending on the value in edx, this might work and give us some amount of licenses. However, that might not work: ecx could be zero already. Fortunately, we can address a single byte of ecx with this: mov ch,0xff. This moves ff into the high part of CX, which is the low part of ECX. That instruction generates only two bytes (0xb5ff), so it's a great replacement for the xor opcode on the same register. Assuming ECX is zero, that one byte will now make it have the value 65,280.

In both cases, it's only a two byte patch. You can distribute the patch with a simple offset:value -- 9 bytes of ASCII text. Sorta hard to stop that, and anyone could patch just from their own memory.

Moral of the story: Write obfuscated code or use a post-compile processors that will mixup your code for you. If your code is cracked by changing a single bit... that means it's just protecting the honest :). While 100% protection is never possible, it should be a lot harder than allowing a stray gamma ray to crack your code!

Code | Security

Thursday, March 31, 2005 4:26:10 AM UTC

Comments [1] | Trackback Tracked by:
"http://reversengineering.wordpress.com/2007/08/05/cracking-code/" (http://rever... [Pingback]
"http://cypvori.biz/www-whitepagescom.html" (http://cypvori.biz/www-whitepagesco... [Pingback]
"http://tpoaef7.biz/live-help.html" (http://tpoaef7.biz/live-help.html) [Pingback]

Monday, August 28, 2006 12:29:47 PM UTC

loved the moral of the story

recombinant

Name
E-mail
Home page

	Remember Me
Comment (HTML not allowed)
Enter the code shown (prevents robots):
Live Comment Preview