Reverse Engineering Continued (Am I on the right track)
Quote:
> push ebp
> mov ebp, esp
> mov eax, [ebp+8]
> mov ecx, [ebp+0Ch]
> with a load of code followed by....
> pop ebp
> retn 18h
> Am I correct in the assumption that it does:
> a) Push the old frame ptr
Right.
Quote:
> b) Copy the stack to the frame ptr
Right.
Quote:
> c) Copy parameters from epb to epc+n
Right, but in more interesting routines those parameters may be used
directly from their place in the stack frame at some later point(s) in
the code, rather than copied to registers on entry.
Quote:
> d) Restore frame ptr
Right.
Quote:
> e) Return, dumping n bytes of passed parameters
Right.
Quote:
> 2. I have seen a couple of oddities in some of the exported functions,
> 000107C4 MpegPortGetPhysicalAddress proc near
> 000107C4 xor eax, eax
> 000107C6 xor edx, edx
> 000107C8 retn 10h
> 000107C8 MpegPortGetPhysicalAddress endp
> No I may be missing something here but does this not do nothing and
> lose you stack space. Should I be assuming some sort of Self Modifying
> Code at work?
No, do not assume Self Modifying Code. It wouldn't hurt to check my
theory by finding out what that routine is really for; But the code
seems pretty obvious. They defined an entry point for a more general
(possibly future) system, in which this routine takes some input (0x10
bytes of it) and returns an answer based on that input. In this version
of the code, all the callers will follow the defined prototype and pass
the 0x10 bytes of input; But the routine itself ignores the input and
returns a fixed answer (a 64-bit zero).
It is fairly common to put things like that in growing code.
Quote:
> 3. Tools
> I think that IDA is quite neat. Have I found the best tool for the job
I think so.
--
http://www.erols.com/johnfine/
http://www.geocities.com/SiliconValley/Peaks/8600/
