How do I define a function alias for an imported function?

[ben321]

If a function is defined in a DLL file under the name abcd1234, and I want it defined in my program under the name abcd, how do I do that?

I tried this in the EXTERN line, like this:

Code: [Select]

EXTERN abcd "abcd1234"
But that didn't work. Is there a way to accomplish this?

[Frank Kotler]

Hi ben321,

Code: [Select]

%define abcd abcd1234
extern abcd1234

section .text
call abcd
...

Does  this not work?

Best,
Frank

[ben321]

Hi ben321,

Code: [Select]

%define abcd abcd1234
extern abcd1234

section .text
call abcd
...

Does  this not work?

Best,
Frank

I want to create a proxy DLL for game hacking/cheating (imagine having unlimited rocket ammo in GTA5). The game calls certain functions in a DLL file, and I want to trick it to using my DLL instead of the one supplied with the game, so my DLL must have the same name as the original DLL (and of course the original DLL will be renamed), and the names of the functions must also be the same as the names of the functions that the game is expecting.

My plan is to make the functions I want to hook, directly in my program, but the remaining functions must be forwarded to the correct DLL (a renamed copy of the original DLL).

So for example, I need to be able to do this:

Code: [Select]

%define abcd abcd1234
extern abcd1234

section .text
export abcd1234
abcd1234:
     jmp abcd

You see the problem with that? NASM will see the function name abcd1234 being external, in the top of the code, but see the function name abcd1234 lower in the code as an internal function with the same name. The will create an error.

I need to tell the assembler, "I want you to reference an external function called abcd1234, but within this .asm file it shall be called abcd, and NOT be called abcd1234". Is there a way to do that in nasm?

And you know what would be even better than that? Using the official DLL Forwarding functionality that Windows recognizes. This functionality allows a DLL file to contain an Exported function from a different DLL. That is, there is an entry in the DLL's export table, which actually points to a function in a different DLL. Is NASM capable of creating an object file which uses contains this functionality, such that when the object file is processed by a linker that it will actually create the correct forwarding entry in the export table?

[ben321]

Does nobody here know how to use the DLL forwarder capabilities of a DLL file?

[debs3759]

Does nobody here know how to use the DLL forwarder capabilities of a DLL file?

Somebody might, but this is not a very active forum, and we don't claim to be experts in any operating system, only to processor specific code. If you are patient, someone may be able to help.

[ben321]

I figured out a way to do it. You need set NASM to output to a "win32" format object file, and then use a program I wrote separately to edit the object file output by NASM. In NASM, use EXTERN with the function name you want to hook (such as SetPixel). Then create a new function with an altered version of that function name (such as HOOK_SetPixel). Then run NASM to assemble this into an object file. Then use the program, and tell it to search in the object file for the string with the altered function name (in this case "HOOK_SetPixel") and rename it to the string name of the function you are trying to hook (in this case "SetPixel"). After the object file has been edited, you use GoLink to link it, which in my example would be:
"golink.exe /entry dllstart /dll myobjectfile.obj gdi32.dll"

After that, just rename your DLL to gdi32.dll and put it in the folder of the program that you expect to call that function in gdi32.dll and it will instead call your hacked version of the function, which will then do something you want it to do with the data passed to it. After your function does what it is supposed to do, your function then will call the real SetPixel function in the real gdi32.dll in the Windows\System32 folder so the program produces the expected result, but at the same time your function can send data to a different program or log it to a file. Of course this may not work on actual system DLLs like gdi32.dll (Windows always makes sure programs use the official DLLs, not alternate versions of the DLLs), but it will work on non-system DLLs (even some graphics DLLs that are often included with Windows like the DirectX DLLs).

This has the potential to let you actually do things like hack games, making it easier to see enemy targets (if you hook DirectX graphics functions and hack them to make enemies always appear bright red).

Not ideal, but until NASM allows you to use EXTERN to reference an external function of a particular name, while calling it a different name in the assembly code itself (an alias), this hacking the object file that is created by NASM is the ONLY way to do it.

[debs3759]

If you are looking at hacking windows and game dll files, I am sure you can find better sites than one that just uses an assembler written to follow various specs and protocols. We are not Windows programming experts

[ben321]

If you are looking at hacking windows and game dll files, I am sure you can find better sites than one that just uses an assembler written to follow various specs and protocols. We are not Windows programming experts

There's actually a protocol for DLL forwarding. When one DLL function is called by a program, the DLL file can actually point to a different DLL. There's 2 ways to do this.

One way is to have your DLL import the required function, and then have a function of the exact same name in your DLL, and have that function just contain a jump instruction to the desired function in the normal DLL.

The other way is to use the Microsoft supported DLL forwarding technique. This uses a less well known functionality in the DLL's export table itself. Instead of the address table containing a pointer to the address of your function, it points to the address of a string that gives the name of the DLL file and the name of the function in that DLL file. How does the Windows loader know which kind of pointer it is? If the pointer to the function points into an area designated to be the export table (as defined by the pointer and size for the export table in the PE header) then it treats that pointer as a pointer to a string, that tells the Windows executable loader to look for a dll with a function (both the DLL and the function name are provided by the string in question). If instead the pointer to the function points anywhere outside the area designated as the export table area, the Windows executable loader will treat it as a pointer to the function contained in the current DLL file.

When an EXE file that calls a forwarded function in one DLL, behaves exactly the same as if it directly called the function in the other DLL.



I hope NASM supports at least one of these 2 ways of forwarding a DLL function.

[debs3759]

Nasm will let you write any code you want, for any x86 based OS. You just need to know exactly what the OS requires of your code, and how to implement it, and most of us are not OS experts

[Frank Kotler]

Does this help you any, ben321?

https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-redirection

Best,
Frank

[ig]

The first method is up to the author of the DLL; if it's you, you can do it - just write the (jumping) code in the DLL.
The second method (the actual Windows DLL forwarding) is, IMHO, up to the linker, not the compiler/nasm.

[vitsoft]

The second method (the actual Windows DLL forwarding) is, IMHO, up to the linker, not the compiler/nasm.

Indeed. In EuroAssembler linker is DLL forwarding implemented at export with keyword FWD=. Example of linker script:

Code: [Select]

proxy PROGRAM Format=DLL
        EXPORT abcd1234, LIB=original.dll, FWD=abcd
      ENDPROGRAM
Those three lines, when euroassembled, will create proxy.dll which exports function abcd from original.dll under a new name abcd1234.

[ben321]

Does this help you any, ben321?

https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-redirection

Best,
Frank

I'm very well aware of that. But how do I implement that in NASM?

[Frank Kotler]

Hi Ben,
It is not clear to me that you do anything in Nasm. It looks  to me as if you do voodoo with your OS. However, I am not "well aware" of the situation.

Best,
Frank