I'm working on a new project of mine (the whole lcd with a sine_y text location while scrolling with music was just too much), something I had the idea for for a while now. More or less, it's a EncryptionAPI middleman, designed to see what encryption APIs are being called (by any process, aka: global or system) display the parameters and the result of the api call on the screen to the user, and in-between allowing the call to go through.

I've read through pages and pages of all the different methods and techniques of how to intercept API calls and from what I've seen Patching the API in the DLL sitting in memory seems to have the best elegancy to difficulty ratio.. One of the pages I read was: http://www.internals.com/articles/apispy/apispy.htm

I even worked a bit with a delphi mouse hook, which was eh.. it started out looking like it would do what I needed it to, except it only hooked messages /events not the actual APIs. When I looked into doing an API memory-patch with Delphi the code looked pretty horrific lots of ^ptr stuff, really nasty looking things. I hate symbols (no phun intended), that's why I try to stay away from C like the plague. Seemed like asm oddly enough is easier to accomplish, as it seems to have a better knack for working with numbers just as they are, no -> or ^ or & or any of that other whacky stuff..

Problem is, GetProcAddress always seems to return back all 0s in the eax register, which according to the msdn site, 0 means it failed. Now my first instinct is that the GetModuleHandle isn't completing right, but it is, at least from what I can tell. I have my code output the module_handle after it retrieves it, and it's always the same no matter how many times I run it (Haven't tried a reboot yet), so I know it's not random which kind'of implies to me it's working..

Anyhow I've attached the code. Now granted, I'm sure there's about a billion ways to rewrite the code, I've found coding to be like math in general, there's like a billion ways to arrive at the same answer. some things some may find bad, some things some may find good, which is why I'm not really too concerned with improving the layout of the code or anything, I just want it to work

-- StakFallT

[ Post removed by author. ]

changing the dwords to double dwords didn't help any.. As for the line:

invoke GetProcAddress, [DLLHandle], "CryptAcquireContextA"

As per http://allapi.mentalis.org/apilist/GetProcAddress.shtml, the reason that line exists, is to discover where that function's address is. It's not actually calling that CryptAcquireContext API. And yes, I've tried it without the Ansi postfix on the end

-- StakFallT

> double dwords didn't help any

Works perfectly for me. Download: http://board.flatassembler.net/download.php?id=2843 and look at MNPEXX3.ASM.

I looked at your code, thanks btw!

I wonder if the issue I'm having has anything to do with using invoke instead of call (I started with call), though technically they should be the same right? When I changed the dw's to dd's it still output, in the console window, blank for the address. And as a matter of fact, the DLLHandleaddr shows up just fine as a dword (Though it might also work for as a double dword).

At first, I thought it might've been an issue with the wsprintf statement I was using and not formating the datatypes right or something, so I ran it in ollydbg, and broke right after the GetProcAddress, that's when I noticed that the eax register was 00000000.. Kinda hard to format what isn't there... I guess my bigger question is why is the eax register all 0's after issuing an invoke to GetProcAddress. Anyhow, just to satisfy the test, I changed the dw's to dd's and the eax register still shows as all 0s...

-- StakFallT

If you change this line you will find that GetModuleHandle is returning 0
This is because ADVAPI32.DLL isn't mapped (since you don't use any functions from it) - you need to use LoadLibrary first

I'm a little confused.. I'm reading both allapi documents on LoadLibrary and GetProcAddr, and obviously I can see the difference in parameters, and obviously their using different descriptions for the APIs purpose, but I'm for some reason just not getting what the difference between the two are.

By the sounds of it, I'd use GetProcAddr if I we're actually using the CryptAcquireContext api since Windows will automatically load the dll it into memory, and I use loadlibrary when I'm not causing Windows to autoload it based on using the api. It sounds like LoadLibrary is a way to force Windows to load the dll into memory under circumstances when Windows would not have normally loaded it.

Both situation's kind'of detract (if I'm correct in understanding what both of thoe APIs are for) from the main purpose of the prog, to display Encryption API parameters by patching the kernel's memory.

The reason I'm bringing this up is because I have a small concern that if I'm "load"ing the module (dll) into memory, I'm now heading down a different road and not actaually working with the memory space of where advapi32 is loaded by the kernel when the OS is booted.

-- StakFallT

[ Post removed by author. ]

Yardman: Here's the output from your code

Notice how the ADVAPI32 handle is the same? It's because of this line

No brackets around DLLHandle passes the address of DLLHandle, not the contents, and the contents are 00000000 - GetModuleHandle fails with error 7E - ERROR_MOD_NOT_FOUND

Replace GetModuleHandle with LoadLibrary and it works OK.