API Rebuilding: Another thought for executable protection

[Guy]

I thought of another idea for a project of mine; rebuilding portions of the front-end GUI, managed by module shells such as user32.dll, kernel32.dll, etc.

What if the calls for LoadLibrary were replaced three or four levels deep? IAT and EAT hooks on these functions would be meaningless, forcing the attacker to find a deeper level function, working with an albeit unfamiliar portion of the Windows API (And more specifically, undocumented).

	HMODULE hModule;
	void *libName_String = GlobalAlloc( GMEM_ZEROINIT, 2048 );

	RtlInitUnicodeString( libName_String, libName_WChar );

	if( LdrLoadDll( 0, 0, ( PWCHAR ) libName_String, &hModule ) != 0 )
		hModule = 0;

	return( hModule );

The above is a rewrite of LoadLibraryW; using LdrLoadDll, it's still quite easily hookable, but even LdrLoadDll is replacable by LdrpLoadDll (Thanks

To view the content, you need to sign in or register

for the callchains!), or just file IO for manually mapping a DLL to memory.

Regardless, it's just an idea I had; using preprocessor macros, replacing these functions via merely including the header file for such a project would provide immediate protection; for forward-compatability, I may surround calls to volatile functions with SEH, or setup VEH, then as a fallback, use the original imported functions.

Ultimately, reversing will become a huge pain in the ass for any novice, and possibly more; thoughts?

 

[cerealnp]

Looks interesting, but rewriting some APIs looks to be a fuckload of work.

 

[Guy]

Looks interesting, but rewriting some APIs looks to be a fuckload of work.

Thanks to the WineAPI, most of the reversing work I won't have to do