How to find address of kernel32.dll in memory

[NOVARSEG]

https://0xdarkvortex.dev/index.php/2019/03/18/windows-shellcoding-x86-hunting-kernel32-dll-part-1/

[SpriggsySpriggs]

Is this a question?

[NOVARSEG]

Not that easy to obtain the address of kernel32.dll in memory and even harder to get the address of the routines it contains

[SpriggsySpriggs]

I'm lost.

[SMcNeill]

I'm lost.

+1

Is there a point/question/reason for this?  Why does one want to hunt kernel32.dll?  What for?  Why do you need to know the address of the functions inside it?  What the heck are you trying to do/teach/illustrate, and what’s it got to do with QB64?

[SpriggsySpriggs]

Is there a point/question/reason for this?  Why does one want to hunt kernel32.dll?  What for?  Why do you need to know the address of the functions inside it?  What the heck are you trying to do/teach/illustrate, and what’s it got to do with QB64?

Kernel32 is something I use quite often in my API stuff but I can't think of why anyone would need to do what that post is showing. I can't think of any reason to investigate the DLL like that. I've never done this but I have used Dependency Walker to open a DLL that I can't find documentation on to see which functions it contains. Even then, not very helpful.

[NOVARSEG]

Part 2
https://0xdarkvortex.dev/index.php/2019/04/01/windows-shellcoding-x86-calling-functions-in-kernel32-dll-part-2/

The link shows some of the internal workings of how a  CALL is made to API code.   Notice the convoluted way in which the addresses for the actual API code itself are calculated in a DLL. We don't really have to know how this is done but surely windows itself must go through the same process when the  DLL is loaded into memory.

[SpriggsySpriggs]

I still don't understand what the point of this is.

[NOVARSEG]

Ok just having some fun. Programming is supposed to be fun?

How can we tell when the file kernel.dll gets updated.

see here  part 2
https://0xdarkvortex.dev/index.php/2019/04/01/windows-shellcoding-x86-calling-functions-in-kernel32-dll-part-2/

****
 Now the thing is if I could just add this value to our kernel32.dll’s address and try to run it, it would run in my system, but it will most probably not work in any other system. The thing is Microsoft keeps updating their kernel32.dll, and because of this there may be new functions/symbols added to the DLL. And because of this, the address of our function will fluctuate depending upon the updates of kernel32.dll.

****
So if the address of a function (API code) changes inside kernel32.dll then we know that kernel32.dll. has been updated.

Why would anyone want to know that?

OK so these DLL are not some chunk of code written in stone as they morph into the soup de jour so to say, to add features, bug fixes, security etc or just make it hard to reverse engineer.

[SpriggsySpriggs]

This is still, like I said, highly unnecessary. I simply declare the library in QB64 and add the functions I need. I don't have to know where they are in the DLL. A slight bug fix or security update isn't going to change up using the DLL functions. The functions there have been available for years and will still be available for years. I still don't understand what it is you are wanting to do with this. I know you are saying you could tell if it was updated by doing that. There is no need to have your code do some sort of online check or investigate the DLL. Just do a GetFileVersion on the DLL.
https://stackoverflow.com/questions/940707/how-do-i-programmatically-get-the-version-of-a-dll-or-exe-file