PE Optional Header - Base of data

[bbbbbjames]

According to my exploration "Base of data" in optional header points inside to .text section. How is it possible?

F.E. XP SP3 system32\netapi32.dll
in optional header
Base of code is: 01000 -> I think that is OK, same value as in .text section
Base of data is: 4C000 -> I think that is NOT correct


in sections header
.text section
     RVA          01000
     Virtual Size 4CBC9
.data section
     RVA          4E000
     Virtual Size 027F8

I think correct values are in section header, because
RVA of .text 1000 + align(Virtual Size) 4D000 = 4E000
and that is where the .data section begins.

[dedndave]

maybe there is another segment at 4C000, like ".const"
there are a number of PEdump and PEviewer programs out there

at this link, you will find the latest PE/COFF spec in PDF form
http://www.masm32.com/board/index.php?topic=13135.0

oh - btw - welcome to the forum   :U

[clive]

I have a slightly different variant of this DLL, but the point you illustrate is there.

I'm not sure how useful these header fields (base of code/data) are, they are more of a COFF remnant, and the loader is pretty much just interested in the base of the image, and definitions in the section table.

I also pulled the symbol file from Microsoft's debugger server, it is clear from the PDB file that the file has been subject to Optimization Mapping (OMAP), a post link step where the file content is moved around to reduce the number of pages in the working set (ie migrate the high use data/code into the minimum number of 4K pages, and push the least used stuff into other pages).

This would explain the less than perfect header values, but frankly I don't think it alters the integrity or usability of the file.

-Clive

[donkey]

Have you mapped the DLL and examined the VA to see if the data is there ? The DllCharacteristics are set to relocatable and DEP aware, this might be an issue where because of ASLR the PE loader is going to ignore any value there and locate the data randomly anyway. Microsoft is very touchy these days about the usability of the PE header, they would rather that the information there is for reference only and not applicable to an actual running module since there are any number of exploits that use the PE header to inject themselves. ASLR is a pretty good way to defeat this and since the rva's don't mean anything anyway why not use them to really throw a wrench into any exploit. I have not tried to build anything with /DYNAMICBASE but it may be that this is the result.

[BogdanOntanu]

Base of Data and Base of Code are kind of obsolete fields. Consider the fact that a PE file can have multiple CODE and multiple DATA sections and in such a case where should a single "base of data/code" field point to?

Instead of using those fields one should consider using  the Section Headers (RVA/Size and FLAGS) to pre-determine CODE/DATA regions.

However code might still be stored in DATA sections and DATA might still be interleaved into code sections.

[dancho]

read this tutorial,maybe little old but info is still valid,

http://win32assembly.online.fr/files/pe1.zip

[Vortex]

PEview by WJR :

http://www.magma.ca/~wjr

[hutch--]

There is some interesting comments here but it leaves me with a problem in terms of how DEP works if there is an interchange between code and data. Pre DEP PE file were tolerant in terms of where data and code were placed but left the executable vulnerable to stack exploits among other things. By seperating code and data exploits of that type were dead but it removed trick uses of plonking code in the data section.

[donkey]

There is some interesting comments here but it leaves me with a problem in terms of how DEP works if there is an interchange between code and data. Pre DEP PE file were tolerant in terms of where data and code were placed but left the executable vulnerable to stack exploits among other things. By seperating code and data exploits of that type were dead but it removed trick uses of plonking code in the data section.

The file is marked DEP aware so there is no code in sections marked as data, there could very well be static data in the sections marked code. Tricks that involved code in the data section are better off dead anyway, it was an easy to follow obfuscation since you still have to call the address at some point so its effectiveness was negligible. Data in the code section was always more effective as a disassembler killer than the other way around, with the right data you can really screw up some debuggers stack frame identification algorithms (ie start a code based string with "U" <push ebp> and make a dummy call to it).

Edgar

[donkey]

Here's an example of obfuscation with code section strings:

Code Select Expand

START:
invoke GetModuleHandle, 0
mov [hInstance],eax

jmp >
call SomeString
:

invoke DialogBoxParam,[hInstance],1000,0,ADDR DlgProc,0
invoke ExitProcess,0


SomeString: DB "U r a pipert"

DlgProc FRAME hwnd,uMsg,wParam,lParam

cmp D[uMsg],WM_INITDIALOG
jne >.WM_COMMAND

jmp >.EXIT

.WM_COMMAND
cmp D[uMsg],WM_COMMAND
jne >.WM_CLOSE

jmp >.EXIT

.WM_CLOSE
cmp D[uMsg],WM_CLOSE
jne >.DEFPROC
INVOKE EndDialog,[hwnd],0

.DEFPROC
mov eax,FALSE
ret

.EXIT

mov eax, TRUE
ret
ENDF

Now check out how ollydbg is completely useless with this:

Code Select Expand

00401000 > $ 6A 00          PUSH 0                                   ; /pModule = NULL
00401002   . E8 F93F0000    CALL <JMP.&KERNEL32.GetModuleHandleA>    ; \GetModuleHandleA
00401007   . A3 00204000    MOV DWORD PTR DS:[hInstance],EAX
0040100C   . EB 05          JMP SHORT TestProf.00401013
0040100E   . E8 20000000    CALL TestProf.SomeString
00401013   > 6A 00          PUSH 0                                   ; /lParam = NULL
00401015   . 68 3F104000    PUSH TestProf.DlgProc                    ; |DlgProc = TestProf.DlgProc
0040101A   . 6A 00          PUSH 0                                   ; |hOwner = NULL
0040101C   . 68 E8030000    PUSH 3E8                                 ; |pTemplate = 3E8
00401021   . FF35 00204000  PUSH DWORD PTR DS:[hInstance]            ; |hInst = NULL
00401027   . E8 E03F0000    CALL <JMP.&USER32.DialogBoxParamA>       ; \DialogBoxParamA
0040102C   . 6A 00          PUSH 0                                   ; /ExitCode = 0
0040102E   . E8 D33F0000    CALL <JMP.&KERNEL32.ExitProcess>         ; \ExitProcess
00401033 > $ 55             PUSH EBP
00401034   . 2072 20        AND BYTE PTR DS:[EDX+20],DH
00401037   . 61             POPAD
00401038   . 2070 69        AND BYTE PTR DS:[EAX+69],DH
0040103B   . 70 65          JO SHORT TestProf.004010A2
0040103D     72             DB 72                                    ;  CHAR 'r'
0040103E >   74             DB 74                                    ;  CHAR 't'
0040103F >   55             DB 55                                    ;  CHAR 'U'
00401040     89             DB 89
00401041     E5             DB E5
00401042     81             DB 81
00401043     7D             DB 7D                                    ;  CHAR '}'
00401044     0C             DB 0C
00401045     10             DB 10
00401046     01             DB 01
00401047     00             DB 00
00401048     00             DB 00
00401049     75             DB 75                                    ;  CHAR 'u'
0040104A     02             DB 02
0040104B     EB             DB EB
0040104C >   24             DB 24                                    ;  CHAR '$'
0040104D >   81             DB 81
0040104E     7D             DB 7D                                    ;  CHAR '}'
0040104F     0C             DB 0C
00401050     11             DB 11
00401051     01             DB 01
00401052     00             DB 00
00401053     00             DB 00
00401054     75             DB 75                                    ;  CHAR 'u'
00401055     02             DB 02
00401056     EB             DB EB
00401057 >   19             DB 19
00401058 >   83             DB 83
00401059     7D             DB 7D                                    ;  CHAR '}'
0040105A     0C             DB 0C
0040105B     10             DB 10
0040105C   . 75 0A 6A 00    ASCII "u
j",0
00401060     FF             DB FF
00401061     75             DB 75                                    ;  CHAR 'u'
00401062     08             DB 08
00401063     E8             DB E8
00401064     AA             DB AA
00401065     3F             DB 3F                                    ;  CHAR '?'
00401066     00             DB 00
00401067 >   00             DB 00
00401068 >   B8             DB B8
00401069     00             DB 00
0040106A     00             DB 00
0040106B     00             DB 00
0040106C     00             DB 00
0040106D     5D             DB 5D                                    ;  CHAR ']'
0040106E     C2             DB C2
0040106F     10             DB 10
00401070 >   00             DB 00
00401071 > . B8 01000000    MOV EAX,1
00401076   . 5D             POP EBP
00401077   . C2 1000        RETN 10

Though a good reverser can figure this one out pretty quickly, it might stump a novice. BTW as you can tell by the Olly dump, this snippet was assembled with debug symbols so I gave Olly every chance, it even references DlgProc by name but still didn't decode it properly.

Edgar

[hutch--]

Edgar,

It would be interesting to see if IDA pro was fooled by this technique as it does complex tracing on load. Another one that is PHUN is to use a table of addresses of labels and branch on the basis of the input number, looks really ugly in a dis-assembly.

[donkey]

Hi Steve,

I don't have IDA but I doubt that this little example would fool it for a second, IDA is really a reverse engineering tool more than a debugger as it does quite a bit more in the way of program flow tracking than is required by a debugger. There aren't many obfuscations that IDA doesn't check as special cases.