I am dealing with a Dll here (nvoglnt.dll), of which the code in the code section is altered BEFORE DllMain is executed, BEFORE IAT Entries are resolved and even before relocations happened.

I am breaking directly after ZwZwMapViewOfSection, after the Dll was mapped into memory, and then i look at certain places in the code-section and they are completely different from the exact place in the file image.

How can this be?
This Screenshot might explain what i exactly mean [1].

And i see that the original code doesn't make much sense either (eg. address 0xBEEFBEEF) so it has to be modified somehwere. But what possible fixups could that be? Does the Loader have something to do with it?
I hope someone has an idea, what happens here.

[1] http://www.abload.de/img/nvoglntv2s.png

Hey,

there are different methods, how it can be implemented to modify a image in a very early stage of loading.

1. The software you are debugging is also using a driver which has hooked some ntapis to scan for mapping of this file and then executes its "fixups".
2. TLS, maybe this is executed before you take a look at the image in memory

Probably one of those mentioned concepts will cover your application.

Regards,

OHPen

[QUOTE][Originally Posted by OHPen;76502]Hey,

Thanks for your answer.

I think the first possibility is very likely. Question is, how does the kernel graphics driver detect mapping of its own opengl-module? There has to be something different about this module. I am very sure official Nvidia Drivers don't implent dirty hooking techniques of important kernel routines.

And i think i know what. According to the Microsofts "Display Driver Model", this is a Miniport Display Driver. And i found exports named like:
DrvValidateVersion
DrvSwapBuffers

What i need in the end is a method to detect if a Dll-File is the usermode-counterpart of a Display Driver (and in the long run maybe, where the changes in the code section come from)
If i knew how nvidias kernel driver detects loading of his usermode-module, i could investigate and look what changes are applied, or at least develop a detection method for such kind of Dlls.

It is just weird to see that directly after mapping the view of this Dll, the code-section was already changed. And i saw no hooks or Image Notification Routines that could alert the Kernel Mode Display Driver, that it was loaded.

Hey,

a friend of mine mentioned that he is not the opinion of that the original code is garbage. Kaspersky Anti-Virus is also doing some weired stuff with adresses like 0xDEADBEEF and so on. In some cases this type of addresses are used to trigger a code flow transfer.

To be honest i have no idea how your image is modified if the drive does not use a hook. What you could do would be install the software in vmware + syser or softice. Maybe it is important to do it on a plain system because you don't know what happen on your system.
So set a breakpoint on write on the page where your dll is mapped and wait for the write access. This should show you who is writting the modifications to your dll.

I don't know if this works, but it would be a try worth.

Regards,

OHPen

Thanks for your answer again.

I have another test-system for these kind of forensic tests. (i once screwed up my main system with syser)
I will set it up in the near future and look into it. If i have any results i will post them here.

But i think i found the technique, that is used. It is called "Installable Client Driver"-Model. You can read about it here [1].
However, the exact internals are not disclosed. And i didn't read everything yet.

[1] http://msdn.microsoft.com/en-us/library/aa477537.aspx

Hi DeepBlueSea,

If you're still following this, can you disassemble your image file in IDA and see if you see any references to the "BEEFBEEF" code that you posted?



I've been looking at a couple of versions of nvoglnt.dll, as well as the equivalent ATI OpenGL driver, atioglx1.dll. Both have similar structure and export the same Drv* functions.

What's interesting about nvoglnt is that it seems to be constructed around hundreds of short decryption routines which use WriteProcessMemory to convert its own Calling function + a few bytes into other code. I'm not sure if it's deliberate obfuscation or just some macro for dealing with OpenGL functions. The ATI driver doesn't do this.

If anyone wants to take a look at nvoglnt.dll you can download a version from one of those dll archive sites, if you don't have it on your own system.

I'll actually have a lot more to say about this soon, but it seems the operation of the driver, and the apparent decryption routine, is based around TLSIndex values and access to 2 _TEB values, glContext (fs:0xbec) and TlsSlots (fs:0xe10).


Cheers,
Kayaker

I was just investigating this issue along the way with my project.
I developed a hook/patch scanner, that scans the static code-section of every module in every process and compares the image in memory with the file-image and shows discrepancies.
Of course it picked up these changes in nvoglnt.dll, which i wanted to filter out, because there could be other changes made by a third party entity, which i wouldnt see in the vast amount of changes made by the driver. So i decided to include nvoglnt.dll and atioglx.dll into a blacklist. Which is of course not the best solution.

All those little routines with 0xBEEFBEEF addresses later resolve to indirect jumps to addresses in the TlsSlots-Table like this:

From:
http://www.abload.de/img/beef2if.png

To:
http://www.abload.de/img/ollyqqt.png

Maybe BEEFBEEF and AFAFAFAF are some kind of signatures the driver uses to find the locations, where it can initiliaze those jmp-gates. The first instruction (mov eax, CONST_INDEX) is maybe some kind of index number to determine which gl-Function should be set up there.
But those are just assumptions, i didnt peek into the driver.



Wicked. I am very interested in hearing more about this.