NASM Forum > Using NASM

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

<< < (2/3) > >>

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:

--- Quote from: debs3759 on August 04, 2019, 07:35:14 PM ---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 :)

--- End quote ---

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

Navigation

[0] Message Index

[#] Next page

[*] Previous page