1

I recently acquired an exploit for an image viewer program and started analyzing.

Specific details cannot be given, but basically it is a SEH overwrite exploit using malicious image file.

Using immunity dbg, I saw that SEH being overwritten by 38 4c 5c 36. But dbg fails to execute that memory address.

Exploit executes calc just fine, but by attaching a debugger to the viewer program, it hangs trying to execute 38 4c 5c 36.

I tried to jump to that address but dbg says it is a unspecified address. I have a few questions about this memory address

  1. what kind of data is loaded in memory address near 38 4c 5c 36 ? (looking at the memory map it is between loaded dll files and nothing is loaded it seems)

  2. is 38 4c 5c 36 where the exploit is loaded in the memory or am I making a wrong guess?

  3. If it is where exploit is loaded, what should I do to further analyze using a debugger?

Thank you in advance :)

Improve this question
7
  • 4
    We have no way to give you an answer with so little information about the flaw. You need either to strip down you question to something that is self-contained or give more information about what you are actually doing.
    – perror
    Commented Dec 25, 2013 at 8:07
  • If it fails in a debugger, it's entirely possible it's stack exhaustion with spray. I saw that with a pdf exploit once. As already noted... it's nearly impossible to help you with no detail though.
    – RobotHumans
    Commented Dec 25, 2013 at 12:13
  • Which CPU and which OS? What do you mean with "that memory address"? The address that contains 38 4c 5c 36, or some other address? In 32-bit x86 code 38 4c 5c 36 is cmp [esp+ebx*2+0x36], cl. In x86-64 code 38 4c 5c 36 is cmp [rsp+rbx*2+0x36], cl. Anyway, you need to give more data, otherwise the question can not be answered.
    – nrz
    Commented Dec 25, 2013 at 16:28
  • Sorry guys, I forgot to give info about OS and stuff :( It works on Windows XP SP3 on x86 CPU. 38 4c 5c 36 is the value of the EIP when dbg cannot continue. SEH is overwritten by 38 4c 5c 36 also. If I string search 38 4c 5c 36 inside the malicious img file and change that to 41 41 41 41, image viewer's EIP is hijacked to 41 41 41 41. So I am guessing the exploit writer intended to hijack the control flow to 38 4c 5c 36. This is about everything I found out right now.
    – Jaewon Min
    Commented Dec 26, 2013 at 0:17
  • Looking at the memory map in the debugger, 10030000 ~ +2000 (LTIMGEFX .reloc ), 3A700000 ~ +1000 (IMKR12 PE header). There is nothing in between. I am new to this field and I am lost from this point :(
    – Jaewon Min
    Commented Dec 26, 2013 at 0:22

2 Answers 2

Reset to default
2

Standard exploitation of SEH based BoF will try to point the SE Handler to a POP/POP/RET instruction. This is not always the case depending on enabled memory protections. (use Mona plugin for Immunity to check this using the command !mona mod, or simply inspect the vulnerable binary characteristics)

If your SE Handler is pointing to 0x384c5c36, you should put a break point at that address and hit Shift+F9 to continue execution up to your breakpoint.

The rest will greatly vary on the nature of the exploit and the kind of limitations it has to bypass. As it an image viewer, I doubt the exploit will use any techniques like heap spraying as it can execute any code that will spray the heap, like JavaScript, but you never know.

For more information on SEH based overflows, I would strongly recommend the Corelan Tutorial.

Improve this answer
3
  • I found out that this imageviewer has 2 modes: preview mode and fullview mode. In the preview mode the SEH is overwritten by 0x384c5c36 and just crashes. If I run the exploit image in the fullview mode, SEH is overwritten to a pop pop ret sequence in the image viewer code and returns to the shellcode in the stack.
    – Jaewon Min
    Commented Jan 3, 2014 at 0:45
  • Just being curious, why jump to a pop pop ret and return to the shellcode instead of putting pop in the shellcode itself if the exploit writer want to pop a value from the stack?
    – Jaewon Min
    Commented Jan 3, 2014 at 0:46
  • P/P/R is a classical exploitation technique for SEH based overflow. The prologue of the exception handler puts next SEH at EPS+8. P/P/R allows to point EIP and execute the code at this address. The classical way would be to include a short JMP at this address, which will finally execute the shellcode.
    – 3asm_
    Commented Jan 3, 2014 at 8:04
2

38 4c 5c 36 is the value of the EIP when dbg cannot continue.

Based on your comment above, in response to your questions:

  1. The exploit's payload.
  2. It's the location in memory where the exploit's payload is loaded.
  3. If you're only looking to analyze the payload (and not the exploit/trigger), set a breakpoint on that address and debug from there.
Improve this answer
2
  • Jason Geffner, I think this address is rather the address somewhere in the module that contains the opcodes (pop , pop , ret) which will jump to the actual payload which probably is on the stack.
    – PhoeniX
    Commented Dec 30, 2013 at 8:04
  • Actually that address was wrong :( Program had 2 different viewing mode. But you were right - when the exploit work, it jumps to the pop pop ret and then to the actual payload. thanks!
    – Jaewon Min
    Commented Jan 3, 2014 at 0:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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