Hi there,

I have a tiny problem today. I wonder, how I can find the original destination of code, that is marked as "map" in Olly's Memory Map window. It looks like this:



I have some problems with this.
1. I cannot change the accessflag. Neither by right-clicking in Olly (set access->full access) nor by using VirtualProtect.
2. I don't know how this mapping is done. It doesn't use MapViewOfFile nor VirtualAlloc nor WriteProcessMemory and it's already present when Olly stops at the EP (It's not present if I stop at System Breakpoint, but I can't find the mapping procedure then)
3. I don't know where to find the code of this section if I load the file not in Olly but in IDA.
4. I don't know where to look for information on this topic. So I kindly ask for some help

Thank you very much in advance.

Best regards
darkelf

Is the file packed? If it uses TLS callbacks, it could unpack before OllyDbg reaches the entry point.

It could also come from a packed DLL I guess.

A packer could also theoretically subvert any breakpoints for the memory allocation routines, so I wouldn't be so sure that these aren't used if I were you.

Thanks dELTA for your answer.

Unfortunately, the file isn't packed and so aren't the involved dll's. It's all just plain Mickeysoft VC8.0.
Some other proposal? I'm really running out of ideas.

Thank you.

Best regards
darkelf

Trace the loading of all (statically) imported DLLs (they will be loaded/executed before the entry point is reached in OllyDbg), and see when the memory region is created?

Hmm, that's what I've neglected so far (lazy me :-) ). I guess you're right and it must be done this way. Nevertheless, do you have any idea, why I can't set the accessflag the way I want?

Thanks again

About the access flag, I would suspect either a protector interfering with you, or a bug in OllyDbg (or that you're doing it plain wrong ).

OK, I found out, that it is done via ZwMapViewOfSection. I guess thats also why I can't modify the access flag.
I have to dig really deep to understand what is going on there. See me come back sweaty :-)

those regions are RegionIs Usage Vad

the maps of VirtualAddress Descriptors

mostly your 1610000 gets created after User32!DllInitialize where it initializes gdi

while you stop on system startup breakpoint
try seeting a break on gdi32!NtGdiInit

and look at memory map you may not find that map

NtGdiInit is a System call

step with f8 4 times and notice the memory map

you will find a map

they are made in kernel land with PAGE_NO_ACCESS protection

for example you can confirm this by using windbg on the same executable
and doing

!vadump
or !address

0:000> !address 1570000
01570000 : 01570000 - 000c7000
Type 00040000 MEM_MAPPED
Protect 00000020 PAGE_EXECUTE_READ
State 00001000 MEM_COMMIT
Usage RegionUsageIsVAD


Memory map, item 25
Address=01570000
Size=000C7000 (815104.)
Owner= 01570000 (itself)
Section=
Type=Map 00041020
Access=R E
Initial access=R E


you can get to know what this region means from windbg help file

RegionUsageIsVAD

The "busy" region. This region includes all virtual allocation blocks, the SBH heap, memory from custom allocators, and all other regions of the address space that fall into no other classification.

btw if you go after NtGdiInit in win32k.sys you will see it is almost Dummy Function dont ask me why that function creates this map :P kernel voodoo

lkd> .shell -ci "dps win32k!W32pServiceTable l?poi(win32k!W32pServiceLimit)" findstr NtGdiInit
bf997970 bf8e59cc win32k!NtGdiInit
bf997974 bf8a2d87 win32k!NtGdiInitSpool
.shell: Process exited
lkd> uf win32k!NtGdiInit
win32k!NtGdiInit:
bf8e59cc 33c0 xor eax,eax
bf8e59ce 40 inc eax
bf8e59cf c3 ret

Thanks blabberer, you were right.

I found out where the map has been created. Nevertheless I still wondered how this map could contain all strings that the program uses. I took me a bit of time to notice, that I was faced with managed code. Then I found all the information I needed.

Thank you all very much for your help.
I learned a lot within the past week.

Best regards
darkelf

well we could use some of the information too :P

a brief (may be obfuscated generalized if it cant be specific) account of what you looked for and how you managed to get what you looked for and how the answers above played some part in your findidngs could be usefull for future searchers

Oooops, sorry - of course I will give the information how I reached my goal.
I will redo what I did and take some notes this time, because I'm somtetimes a bit uhmm, unorganized . I will do my very best to make it in notime.
I will edit this post then.

Best regards
darkelf

Is notime really longer than 5 days?

Uhhmmmm, let me think eternity minus 5 days equals

No, serious I'm sorry again. I've been awfully busy these days. I promise I will collect all the information on this problem as soon as I have a bit of time. So cut me some slack please (with sugar on top).

Best regards
darkelf

I'm not sure about the sugar, but I guess a few more days than the already passed 13 days will be acceptable...

Just to let you know - I haven't forgot that.
Right now, I'm busy with something different, but I will get back to that ASAP.

darkelf