Change-Offset-Rebased-Modules

Source: http://www.securitysift.com/windows-exploit-development-part-3-changing-offsets-and-rebased-modules/

CHANGING EIP OFFSETS:

Example:
the exploit for ASX To MP3 Converter only worked if the m3u file was run from the root of the 
C:\ directory because the offset to EIP overwrite was dependent upon the file path.

Previously:
26,121 bytes          4 bytes       18,852 bytes        227 bytes           4,796
JUNK                  EIP             NOPS                SHELLCODE         FILL (shellcode overflow)


The offset to EIP (when the m3u file was located at the root of C:\) was 26,121 bytes.
As we proved by moving our m3u file to the Desktop, a longer file path causes the EIP overwrite to move to the left 
into the Junk portion of the buffer (all A’s), thereby decreasing the size of the offset. 

The good thing is if the file path is the only influence over the offset, 
we should be able to predict exactly where the new offset will be given a particular path. 

Old path: C:\asx2mp3.m3u

New path:
C:\Documents and Settings\Administrator\Desktop\asx2mp3.m3u

If you count the characters between C:\ and our m3u file, we get: 45.
Adjust EIP by -45, giving us a new offset of 26,076.


------------------------------------------------------
------------------------------------------------------
------------------------------------------------------

REBASED APPLICATION MODULES

EIP has clearly been overwritten with my chosen CALL EBX address (0x01C27228 from MSA2Mcodec00.dll) 
but the program doesn’t seem to recognize it as a valid address. 

This is because we used an address from a "rebased" application module (DLL). 

Options:

1) See if we can find another application module that doesn't implement rebasing (preferred)
OR
2) Use an OS module.

We can use mona plugin to examin the loaded modules more closely and see which ones implement rebasing:
!mona find -type instr -s "call ebx"