Why doesn't Olly's analyzation work properly in this code section?

Question

I'm not sure if there are any legal hinderances to me asking this question, so if asking for unpacking advice is against the rules I apologize.

I am new to reverse engineering and trying to manually unpack a PEtite 2.2/2.3 as a learning experience and have been trying to follow this guide: http://users.freenet.am/~softland/tutorials/Petite.v2.3.MUP.txt. The program I'm unpacking is the original PEtite packer itself.

I have disabled passing on exceptions as it feels like cheating and I haven't fully grasped how exceptions work in this context, seemingly used here to derail the debugger, so I'd like to know why and how to work around it myself. I've come to this part in the guide:

and this exception program generates for jumping to exception handler, so at that line put
breakpoint on exception handler (goto to 4164E3 and press F2), then press SHIFT+F9 and
you are at the beginning of exception handle

When using OllyDbg 1.10 (non-patched), this is what I find at the address of the exception handler (this address is also where Olly said the OEP would be when I tried out the auto-unpacker SFX ability):

In the guide it says that I should find the line 004164E3 CALL PETGUI.00416537 here. As you can see there is really nothing here, however it was the address I always ended up at no matter the method I tried to use (or saw in tutorials etc.), so I did a process dump and suddenly I got this:

Now it struck me that since the program is self-modifying that might naturally confuse Olly, so I told Olly to re-analyze the code (before dumping the process), and I ended up with this:

I got the expected result, but there's something missing... the CALL instruction can be seen in the opcode section but it hasn't been parsed by Olly. Now to my questions:

1. Why doesn't Olly parse this CALL instruction properly?
2. How come E8 4F000000 somehow magically becomes CALL 416537? I don't see any 416537 in the opcodes. Found this answered here, leaving it for reference: https://stackoverflow.com/questions/10376787/need-help-understanding-e8-asm-call-instruction-x86.
3. At the MOVS instruction where the exception is raised before ending up in the exception handler, if I press Shift-F7 or Shift-F8 to single-step instead of Shift-F9 I somehow end up at 4E3137 which is full of ADD BYTE PTR DS:[EAX], AL instructions, presumably an area of filler instructions that will later be overwritten. How come I ended up here? If I try to keep stepping I'm told EIP is set to 00000000 and can't proceed. This seems to be the case whenever I choose to exception-single step; errors show up that would be smoothly ignored if I had just used Shift-F9.

I have the same problem in OllyDbg 2.01 aswell.

Answer 1

Because the code at 0x4164e3 is never referenced in a CALL or JMP instruction, but (probably) used as data somewhere else (as you said the program is self-modifying), Olly thinks it's data, and has no reason to assume there's code there. See https://stackoverflow.com/questions/13812554/in-ollydbg-how-do-you-force-hint-disassembly-at-a-location for how to make sure olly treats that address as code.

(In case the link goes away: Right Click -> Analysis -> During Next analysis, treat selection as -> Command, Or at least "remove analysis from section" to tell olly NOT to assume data.)

The problem with single-stepping exception handlers is: If you do any kind of single-stepping, the debugger will place a breakpoint at the next instruction, execute the code at the current instruction, and hope for the breakpoint to return control to the debugger. However, the exception will call the exception handler, but the debugger doesn't even know the instruction is going to raise an exception, so it can't put the breakpoint at the exception handler's address. So, your single-step executes the exception handler (without returning to the debugger), which probably checks for the breakpoint after the instruction it came from (to actively detect a debugger) and, if it detects a debugger, jumps to "nowhere" to make the program crash/confuse the debugger user.

There are lots of explanations on the internet that are more thorough than what i could write in a short answer, googling for "exception handler single step" brings up a few nice examples.