Although this shell has already been done by experts, but there is no detailed writing process, the younger brother is here to show ugly, hope experts give advice, at the same time, it is hoped that later experts will be able to write detailed cracking processes so that new students like younger siblings can learn.
Tools:
Softice
Procdump
Icedump
Uedit32
Peditor
Pe.txt (knowledge is power)
Let me do some warm-up first and set the macro command in softice:
MACRO procdump = "/BHRAMA ProcDump32-Dumper Server"
Lets goo !!!
Load softice, load icedump, run procdump32, click Dumper Server, wait ...... I usually use bpx loadlibrarya to intercept the shell. This is also used this time. After blocking, press F12, and then press F10 to come here:
0167: 0040E034 33C0 xor eax, EAX
0167: 0040E036 E811000000 CALL 0040E04C
0167: 0040E03B 8B44240C mov eax, [ESP + 0C]
0167: 0040E03F 8180b8000000090020.add dword ptr [EAX + 000000B8], 00000009
0167: 0040E049 33C0 xor eax, EAX
0167: 0040E04B C3 RET
0167: 0040E04C 64FF30 push dword ptr fs: [EAX]
0167: 0040E04F 648920 mov fs: [EAX], ESP
0167: 0040E052 cc int 3
0167: 0040E053 6A00 PUSH 00
0167: 0040E055 FF958C130000 CALL [EBP + 2017138c]
0167: 0040E05B 90 NOP
0167: 0040E05C 33C0 xor eax, EAX
0167: 0040E05E 90 NOP
0167: 0040E05F 90 NOP
Press F8 in 40E036 and run the command e eip in 40E053 and then 8 '90'. In this way, the program can be successfully run and several times the loadlibrayra interception is performed, soon find the program entry: 4010CC, where the command procdump is shelled and stored as c: empdump.exe.
The program cannot run normally after shelling. "invalid WIN32 ......", It is a PE file problem! View pe.txt. We know that there is a 'characteristics 'with a size of 16 BITS in the PE file header that records the file features. Use PEDITOR to view the Characteristics: 210E of the file and convert the value to binary: 10000100001110. In pe.txt, check the definition of each bit to see if there is any suspicious content, I found 13th characters suspicious. Bit 13 (IMAGE_FILE_DLL) is set if the file is a dll !!! DLL ??? NO! EXE !!! So I changed the 13-bit value to '0', that is, 00000100001110. The hexadecimal value is 010E, which can be modified using peditor. Now the program can run normally in WIN9X.
Run dump.exe when starting win2k1. two problems are found: 1. When the program is closed, the address BFF8D827 has an error. 2. When the file is opened, the address BFF77B5B has an error. I think an error occurs when the program calls the memory address of exitprocess and createfilea. Restart the system to win9x, run dump.exe, use bpx createfilea to intercept, open a file, block it, and clear the breakpoint of bd *, press F12 to return to the program, and press F10 several times:
0167: 0040144D 56 PUSH ESI
0167: 0040144E 8D85C0FEFFFF lea eax, [EBP-0140]
0167: 00401454 6880000000 PUSH 00000080
0167: 00401459 6A03 PUSH 03
0167: 0040145B 56 PUSH ESI
0167: 0040145C 6A03 PUSH 03
0167: 0040145E 6800000080 PUSH 80000000
0167: 00401463 50 PUSH EAX
0167: 00401464 FF1500E34000 CALL [0040E300] <--- here!
0167: 0040146A 56 PUSH ESI
When the program comes to 401464 CALL [0040E300] Here, DD 40E300, what do you see? YEAH! BFF77B5B appears in the DATA area. In WIN2K, the program fails here. That's great! In 401464 CALL [0040E300], do not move it first. Run the following command: s ds: 400000 l 10000 5B 7B F7 BF, find an address: 4063D0, run the command, next CALL [4063D0], OK !! Write down the machine code. Use UEDIT32 to modify the file. The second problem is solved!
Now the program can open the file in WIN2K. Close the program! I want to leave it for you to solve it by yourself. The method above is the same !; D. Good luck, byebye!