Stupid question: module has entry point outside of code???
 

Hello,

sorry for posting this (probably most stupid) question but not having been able to understand it alone .....
Anyway, I have an application that loaded with ollydbg makes it display the usual "Module xxxxxx has entry point outside code (as specified in the PE header). Maybe ....". Now, the application isn't packed .... but this is not the point, the point is why the message??? I mean, what does ollydbg display such a message??? I thought it was due to the entry point's section characteristics and in fact the section containing the EP does not have a CODE and a MEM_EXECUTE flag. Unfortunately changing its characteristics assigning both of them to it (going from C0000040 to E000020) has no sort of effect. What then maked ollydbg state that the entry point is outside code???

Also, I was wondering, in ollydbg's Memory Map what determines what is displayed in the "Contains" column??? I thought ollydbg analyzed all section's characteristics but by changing them with a tool such as LordPE or PETools does not cause any changes in what get displayed in that column!!!


yaa

i guess entrypoint is just outside first section (packed/protected/infected), ignore it

Thankz for both of you I got same problem .. I could not analyze it also with CTRL+A .. any advice about that..

bart,

it is not a question of EP being or not inside the first section but of EP being inside a section that is not marked as being code. And as I already said, the application is not packed (it was initially packed with UPX). Can it be that UPX does not reset PE header to its original values when used to decompress a packed app???

Anyhow, what I still don't get is how sections that are both not marked as code and as executable (based on their section flags) and that are also not marked as code (based on PE header values) can still be executed as code without problems!!



yaa

UPX decompression is not 100%
 

I just tested compression and decompression with UPX 1.24 and not even the PE header of the resulting file was equal.
Seems like the relocations are stripped anyway.
And in my special case, the "Base relocation table", the "Debug table" and the "Import address table" have been cut apart.
The flags of the sections are the same.
regards
PHaX

if you set the BaseOfCode field w/ yielding alignment to the Memory Alignment that adheres to AddrOfEntrypoint field then you wont get that message.

so like..you get this message typically w/ Packed/Protected files or viriis...anyways heres example:

3 sections:
.text
.data
.foo

So if the file was assemblded normally the entrypoint would be in .text like 1000h or something and baseofcode would prolly by rva of 1000h so if .foo is at rva 4000h just set baseofcode to that and then keep the ep of .foo like what it might be like 4028h...anyways PE loader dont give rats ass about BaseOfCode field..ive never seen it in use atleast.

Sorry guys but when you talk PE stuff to me you must be more clear.

phax, are you saying that UPX packing and upacking left PE section flags untouched but it did alter relocation, debug and import table values in PE header?

archphase, I suppose you are saying that olly's message disappears if BaseOfCode and SizeOfCode are such that the EP is included in what PE header declares being code.
But I did not understand the following sentences in your post:

1) yielding alignment to the Memory Alignment that adheres to AddrOfEntrypoint field
2) so if .foo is at rva 4000h just set baseofcode to that and then keep the ep of .foo like what it might be like 4028h

Could you please clarify their meaning?


yaa

OK, well like say our original EP was like 1010h which could be in our .text section, you'd also notice that OptionalHeader field .BaseOfCode would be 1000h or the RVA of .text in memory -- you can check this w/ .text Section Header field aswell..

Anyways if the file is packed and a new section is added like e.g: .foo at RVA 4000h and entrypoint is now 4010h in .foo and BaseOfCode is not updated then you get your info message from olly.