Memory accessing

[vandenab]

Hi all,

Through a Kernel-Mode driver, I am trying to read memory locations that belong to another kernel executable. Unfortunately I'm getting nowhere. Actually, all disassemblers seem to give wrong memory addresses. To ease up my research, I decided to first try to read memory locations from a really simple routine that I made.
Here is the code :

Code Select Expand


mov    Chk, 2h
lea      edx, Chk
mov    ecx, edx
mov    Chk, 99999999h


The disassembler tells me Chk is located at memory address 00010662h. This is consistent with the disassembly code :

Code Select Expand


mov    dword ptr ds:[00010662h], 2h
lea      edx, ds:[00010662h]
mov    ecx, edx
mov    dword ptr ds:[00010662h], 99999999h


When I replace the disassembly lines into my original source code, Chk isn't altered by the two mov instructions. When I retreive the result of the lea edx, Chk, I get EBACD662. This is nowhere near 00010662h.

You might say why bother, you found the exact address ! Actually I got it thanks to the fact that it's my code and I can modify it. Nevertheless, if I'm trying to acces memory from a program I don't have the source of, I'm in deep sh... since what I just showed above prooves that I can have no certitude what so ever about the memory addresses given by the dissassembler.

To disassemble, I used dumpbin (Visual Studio) and PE Explorer. They both gave the same information.

Any thoughts or theories?

Thanks in advance.

Nico.

[hutch--]

Nico,

Your application appars to be outside of the rules of the forum which prohibit access or modification of files that you don't own. Let us know exactly what you are doing as we cannot allow posting of this type of material.

[vandenab]

OK, I'm sorry, let me clarify all this.

It's actually only for information purposes. I am trying ti understand how KeBugCheckEx works. This is the function that is called when a fatal exception occurs in Kernel-Mode. The definition of that function resides in the file ntoskrnl.exe which is a huge system file.

Thanks to PE Explorer, I found the entry point of KeBugCheckEx. I juste want to know what execution path it follows untill the PC is rebooted. Unfortunately, there is a lot of branching, on KeBugCheckEx's parameters, but also on various variables, which may be altered during booting time.

To understand fully what is happening, I want to know what are the values of some variables during regular system functionning.

I can assure you my intentions are nowhere near malicious. I'm working on a hardware security project for a bank in Belgium. I can unfortunately not tell you why I want to know how KeBugCheckEx works.

Thanks for your help in case the topic is OK with you.

[hutch--]

Nico,

It sounds OK but please be careful as we get our share of virus dudes trying to post crap in here.

[vandenab]

Hi,

Hutch, don't you have any idea on the subject?

[Jibz]

vandenab,

It's not because your program is being relocated when loaded by Windows, but not when shown by the disassembler?

[vandenab]

Maybe that's it, I really don't know. It has to be something like that. This would mean I'm not gonna acheive what I want...
So actually I hope it's not that !  ::)

[zooba]

When I retreive the result of the lea edx, Chk, I get EBACD662. This is nowhere near 00010662h.

On the contrary, EBACD662 = EBABD000 + 00010662

The address returned by the disassembler is actually DS:00010662. When the program actually runs, Windows assigns a base address (because obviously you can't have all programs running in exactly the same section of memory) which everything else is then relative to (hence, DS [data section I believe it stands for]). So unless you can find a way to enforce a specific base address for your program, or find out what the base address is, there is no way of knowing the absolute location in memory of your data.

[AeroASM]

DS is actually Data Segment, and is a 16 bit register used in DOS

[vandenab]

How can I have not seen that EBACD662 = EBABD000 + 00010662? Weird ...
In fact the base address EBABD000 changes at every execution, which is quite regular since Windows alocates memory space to programs at the beginning of every execution. I think, as you said, that it will not be possible to extract the base address of an application I do not own.  :'(

Thanks for your kind replies.

Regards,

Nicolas.

[The Dude of Dudes]

I believe Windows loads your driver at an arbitrary address, the Kernel is  static when loaded (I believe, someone correct me if Im wrong please). Meaning  KeBugCheckEx would always be loaded at the same address on a given  version of windows.

[vandenab]

That could be good news if I could know which address that is. Any ideas ?