flat assembler
Message board for the users of flat assembler.

Index > Windows > Quick question about GetProcAddress

Author
Thread Post new topic Reply to topic
StakFallT



Joined: 19 Jan 2006
Posts: 48
StakFallT
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 Wink

-- StakFallT


Description:
Download
Filename: EncryptionHook.ASM
Filesize: 2.21 KB
Downloaded: 62 Time(s)

Post 16 Aug 2007, 05:38
View user's profile Send private message Reply with quote
Yardman



Joined: 12 Apr 2005
Posts: 245
Location: US
Yardman
[ Post removed by author. ]


Last edited by Yardman on 04 Apr 2012, 02:26; edited 1 time in total
Post 16 Aug 2007, 06:25
View user's profile Send private message Reply with quote
StakFallT



Joined: 19 Jan 2006
Posts: 48
StakFallT
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 Wink

-- StakFallT
Post 17 Aug 2007, 00:12
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
> double dwords didn't help any

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

_________________
Bug Nr.: 12345

Title: Hello World program compiles to 100 KB !!!

Status: Closed: NOT a Bug
Post 17 Aug 2007, 00:55
View user's profile Send private message Reply with quote
StakFallT



Joined: 19 Jan 2006
Posts: 48
StakFallT
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
Post 17 Aug 2007, 01:10
View user's profile Send private message Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 713
Location: Adelaide
sinsi
If you change this line you will find that GetModuleHandle is returning 0
Code:
        cinvoke wsprintf, tmp_buf2, <"ADVAPI32.dll handle: %i",13,10>, [DLLHandle]    

This is because ADVAPI32.DLL isn't mapped (since you don't use any functions from it) - you need to use LoadLibrary first
Post 17 Aug 2007, 01:41
View user's profile Send private message Reply with quote
StakFallT



Joined: 19 Jan 2006
Posts: 48
StakFallT
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 17 Aug 2007, 02:03
View user's profile Send private message Reply with quote
Yardman



Joined: 12 Apr 2005
Posts: 245
Location: US
Yardman
[ Post removed by author. ]


Last edited by Yardman on 04 Apr 2012, 02:50; edited 1 time in total
Post 17 Aug 2007, 04:23
View user's profile Send private message Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 713
Location: Adelaide
sinsi
Yardman: Here's the output from your code
Quote:

Original USB devices enumerator v1.0 (arafel, tsech@mail.ru)
Modified, for use as an API interceptor, by: StakFallT

ADVAPI32.dll handle: 4198400
Locating Memory Address of CryptAcquireContext for interception...
GetProcAddr on CryptAcquireContextA returned 0 (failed)!

Notice how the ADVAPI32 handle is the same? It's because of this line
Code:
        cinvoke wsprintf, tmp_buf2, <"ADVAPI32.dll handle: %i",13,10>, DLLHandle 
    

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.
Post 17 Aug 2007, 04:53
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.