https://github.com/LloydLabs/Windows-API-Hashing

This is a simple example and explanation of obfuscating API resolution via hashing
https://github.com/LloydLabs/Windows-API-Hashing

Last synced: about 1 month ago
JSON representation

This is a simple example and explanation of obfuscating API resolution via hashing

• Host: GitHub
• URL: https://github.com/LloydLabs/Windows-API-Hashing
• Owner: LloydLabs
• Created: 2018-06-02T16:38:29.000Z (over 6 years ago)
• Default Branch: master
• Last Pushed: 2020-05-25T21:53:46.000Z (over 4 years ago)
• Last Synced: 2024-05-02T18:07:57.255Z (5 months ago)
• Language: C
• Size: 9.77 KB
• Stars: 223
• Watchers: 10
• Forks: 38
• Open Issues: 0
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

• awesome-hacking-lists - LloydLabs/Windows-API-Hashing - This is a simple example and explanation of obfuscating API resolution via hashing (C)

README

        
# Windows API resolution via hashing

Although this method of API obfuscation is relatively old, my friend who was wanting to increase his skills in the Windows sphere confronted me about a way a few malware families seem to resolve APIs. It's pretty simple, however he could not find any documentation with a solid programming example on the matter at the time, so I thought I'd quickly write something up regarding it. I *was* going to write my own loader for this example (loading the desired module via `LdrLoadDll` within `kernel32.dll`, walking the `InMemoryOrderModuleList` to find the desired loaded module, finding the exported function we're after within the EAT..) - however I thought this might of have been a bit overkill for such a simple concept, I want to cover writing your own PE loader in the future though as it's an interesting subject.

If you're not familiar with the PE format, take a look at this diagram from Microsoft - it outlines the way in which the table is structured. When `EAT` is mentioned, we're referring to the export address table.







So, every DLL in theory **should** have an export table where the functions that it implements are exposed to the loader - in order for an application to use one of the exported functions. This information resides in the EAT (export address table).

When you traditionally compile an executable and implicitly use for example `MessageBox`, the compiler will add this to this to the IAT, this will contain the module (DLL) that the symbol resides in too.

But, we're talking about obfuscation here right? What if someone doesn't want an analyst to see this in the export table? This is where obfuscated resolution comes in. At runtime, we can load these functions on the fly given a name - meaning they won't reside in this pesky IAT thus making it harder to analyse.

This is now how API hashing works, API hashing is when we walk a given module's EAT looking for the **name** of a symbol which **matches our hash** we computed for it earlier. Once we get the address, we can freely use a function pointer and use the API just as normal.

In my example, I've decided not to use a cryptographically safe hashing routine as we just want a hashing algorithm which isn't too computationally expensive, but at the same time produces unique enough results. I've chosen to use `SuperFastHash` created by Paul Hsieh. Again, this is a trivial example of how API hashing is used in the real world, it's not meant to be a complex example!