Question

I need to reverse engineer from machine code to C, how do I do it?

This problem will give you a chance to reverse engineer a switch statement from
machine code. In the following procedure, the body of the switch statement has
been removed:

1 int switch_prob(int x, int n)
2 {
3 int result = x;
4
5 switch(n) {
6
7 /* Fill in code here */
8 }
9
10 return result;
11 }
Figure 3.44 shows the disassembled machine code for the procedure. We can
see in lines 4 and 5 that parameters x and n are loaded into registers %eax and
%edx, respectively.
The jump table resides in a different area of memory. We can see from the
indirect jump on line 9 that the jump table begins at address 0x80485d0. Using
the gdb debugger, we can examine the six 4-byte words of memory comprising
the jump table with the command x/6w 0x80485d0. gdb prints the following:
(gdb) x/6w 0x80485d0
0x80485d0: 0x08048438 0x08048448 0x08048438 0x0804843d
0x80485e0: 0x08048442 0x08048445
Fill in the body of the switch statement with C code that will have the same
behavior as the machine code.
1 08048420 <switch_prob>:
2 8048420: 55 push %ebp
3 8048421: 89 e5 mov %esp,%ebp
4 8048423: 8b 45 08 mov 0x8(%ebp),%eax
5 8048426: 8b 55 0c mov 0xc(%ebp),%edx
6 8048429: 83 ea 32 sub $0x32,%edx
7 804842c: 83 fa 05 cmp $0x5,%edx
8 804842f: 77 17 ja 8048448 <switch_prob+0x28>
9 8048431: ff 24 95 d0 85 04 08 jmp *0x80485d0(,%edx,4)
10 8048438: c1 e0 02 shl $0x2,%eax
11 804843b: eb 0e jmp 804844b <switch_prob+0x2b>
12 804843d: c1 f8 02 sar $0x2,%eax
13 8048440: eb 09 jmp 804844b <switch_prob+0x2b>
14 8048442: 8d 04 40 lea (%eax,%eax,2),%eax
15 8048445: 0f af c0 imul %eax,%eax
16 8048448: 83 c0 0a add $0xa,%eax
17 804844b: 5d pop %ebp
18 804844c: c3 ret

Answer 1

down vote

You can't. There are steps you can take to make it alittlemore difficult but ultimately any executable on the local machineis crackable. Eventually that code has to be converted into native machine code and every application that is runnable is vulnerable. What you want to do is just make it difficult enough to crack to make it not worth peoples trouble. Some suggestions I have for you to help protect your app: Obfuscateyour code.Dotfuscatorhas a free edition and comes with Visual Studio. Usepublic/privatekeyorasymmetric encryptionto generate your product licenses. This ensures thatonlyyoucan generate your license codes. Even if your appiscracked you can be sure that theywon't be releasing a key generator for your application because it is impossible to reverse the key generating algorithm. Use a3rd party packerto pack your .NET executable into an encrypted w32 wrapperapplication.Themidais one of the better ones. This stops people fromreflecting your application in.NETReflectorand makes it a pain to unpack for reversing. Write your owncustom packer. If the 3rd party packers are too expensive, consider writing your own.Sometimes custom packers can be very effective because there aren't well published methods on how to unpack them. Thistutorialgives aton of good information on writing your own win32 packer. Ultimately though, if people want your application cracked they will. Look at all the commercial software out there that has a vastamount of resources to protect their applications and yet they are cracked before the applications are even released to the public. A skilled reverse engineer can fire upIDA-Proand slice throughyour application like butter no matter what you do. A packed application can be unpacked and obfuscation only prevents it from makingit a walk in the park. All your hard work with your complex license code can be undone with a single byte patch. You just need to accept that there is a very real chance people are going to pirate your software. There are some people whoarenevergoing to pay for your application no matter what and these are the people you don't need to worry about. There are however, many businesses out there who would never risk a lawsuit and happily buy software licenses and many computer userswho either don't want to risk it, find it wrong or are not tech savvy enough to pirate. These are your true customers and you shouldfocus your efforts on providing them with a good user experience and ignore the people cracking your software. I've had my application pirated before and I took it as a personal affront. Here I was, a small-time developer, pouring my heart andsoul into an application and these people had the gall to pirate from me?! They were taking money directly from my pocket! I immediately added in a bunch of draconian DRM code and attempted to sabotage any person using an illegitimate or cracked copy. Ishould of been working on making my application better instead of trying to stop the inevitable. Not only that, but I was hurtingmytruecustomers will all these extra protections I was putting in. After a long battle I realized I was fighting the tides and all this time wasted was for naught. I took out all the phone-home codeexcept for the barebones license functions and never looked back.