<reverse-300> of AliCTF2014 Topic analysis

reverse-300

Tools: IDA Pro, WINDBG, UPX, Resource Hacker

Run the program first to see the effect

Click the button to crash directly, and because the program does not run in the 32-bit XP virtual machine, it should be a 64-bit program.
According to the hint program itself is problematic, so directly on Ida Pro, found seemingly with UPX shell:

Use UPX shelling to see

Success! Run Ch3_d.exe to see the effect

This effect ... Can not be run directly, but also pop-up window before shelling! And then the new shell again, and so, well, it's a trap!

Analyze the cause of the crash with WinDbg: Register WinDbg as a timely debugger and run Ch3_d.exe

The address of the crash is
00000001 ' 3FC81DCD 85c0 test eax,eax
The view in IDA Pro navigates to that address and finds that the loaded base address is incorrect (see below for the reason), and use the LM command in WinDbg to look at the module condition

Base address is 13fc80000, after rebase in Ida Pro, view the crash point

Well, as seen in WinDbg, after calling the _initterm_e function, it crashes, and the crash instruction is located in _initterm_e:
Call RCX; rcx=0x140001f2c
I have been puzzled for a long time (alas, the food), the analysis process is as follows:
Search for the Initterm function, the function is basically to execute a given function, call RCX error, estimated RCX value should be ch3_d.exe passed to initterm parameters, is a function address, so in Ida search 2c 1f 00, did find the 0x140001f2c,0x140000000 is the default loading address of 64 program, it seems Ch3_d.exe thought that he was loaded to the default address.
Analysis to here (but also analysis to understand, a word, dish!) , it is clear, is the introduction of Vista after the random base address, vaguely remember the "0day security" that book about the relevant content (Chapter 13, ASLR), looked at a glance, change the registry on the line (here do not write the specific operation, the need to check their own, Another: To change the PE head can also avoid this problem).

Change the registration form, restart, run the program, success! Excited to point "Find the Key", Collapse ~~,windbg bounce out, and collapsed! What's the situation? There's no way to continue the analysis, look at the situation near the crash point

Load DecryptDll.dll, import Rasdecrypt function, where is DecryptDll.dll? Where else, the estimate is in Ch3_d.exe "belly", with resource hacker look

Sure enough there is a DLL, export to rename, and then run, I see you still collapse!?

Well, all right, decisive ... WinDbg again, not crap, see what the situation,

In the Rsadecrypt function of Decryptdll, take a look at Ida load Decryptdll (note base),

Is collapsed in the memcpy function, according to the calling convention of the 64-bit program, memcpy three parameters are RCX (DST), RDX (SRC), R8 (Len), using WinDbg tracking to call memcpy

Register case, rcx=0,rdx=21dc56,r8=15, visible is the problem of destination address RCX, Trace RCX in Ida, most trace to
decryptdll! Rsadecrypt the R8 parameter, R8 should be a valid address.
Take a peek at Ch3_d.exe call decryptdll! Rsadecrypt parameter conditions when the

Well r8=0, no wonder, see the source is intentionally with XOR to empty
So as long as the call decryptdll! Rsadecrypt before the R8 to a writable address on the line, at the address to get the following string

But there is nothing in the pop-up dialog, but the big God says this is flag, so don't continue to analyze it.

1. k*&>(da30_q-([email protected],

Finally summarize the "Test Center" bar (rookie view):

• UPX shelling
• Debugging of 64-bit programs
• ASLR mechanism
• Resource extraction

From for notes (Wiz)

<reverse-300> of AliCTF2014 Topic analysis