I have a Windows program in Haskell (hence 32-bit). I want to access the 64-bit view of the registry. The Windows API says to use RegOpenKeyEx and to OR in KEY_WOW64_64KEY (0x200). (I am using the standard Haskell bindings to the Windows API that come with the Haskell Platform.)
In my program this ends up being:
import qualified System.Win32.Registry as W32
import qualified System.Win32.Types as W32
...
let kEY_WOW64_64KEY = 0x200 -- has no binding in the library currently
let regSam = kEY_WOW64_64KEY .|. ... other flags
bracket (W32.regOpenKeyEx rootCode kname regSam) W32.regCloseKey $ \k -> ...
However, I get the exception RegOpenKeyEx: invalid argument (The system cannot find the file specified.)
Inspecting the call in Process Monitor shows the following output:
The API call somehow ended up dropping the flag and going into the Wow6432Node subtree. Also illustrated, despite the event alluding RegOpenKey I think it's really calling into RegOpenKeyEx as shown in the event's stack (and the binding's error message).
Any suggestions?
Thanks!
The alternate registry view flags are:
KEY_WOW64_64KEY 0x0100
KEY_WOW64_32KEY 0x0200
But you wrote:
let kEY_WOW64_64KEY = 0x200
So you are actually asking for the 32 bit view. You need to write:
let kEY_WOW64_64KEY = 0x100
Related
As I see, extern WinAPI functions in assembly code have names like _ExitProcess#4.
What is the meaning of the #4 part, and how to determine what number to use after # ?
I know that this has something to do with DLL we are linking against, but in many cases it's not known what number to use after the #, and this leads to many nasty undefined reference errors.
As Andreas H answer said the number after the # is the number of bytes the function removes from stack before the function returns. This means it should be easy to determine that number, as it's the also number of bytes you need push on the stack to correctly call the function. It should be the number of PUSH instructions before the call multiplied by 4. In most cases this will also be the number of arguments passed to the function multiplied by 4.
If you want to double check that you've gotten the right number and you have Microsoft Visual Studio installed you can find the decorated symbol name from the Developer Command Prompt like this:
C:\> dumpbin /headers kernel32.lib | find "ExitProcess"
Symbol name : _ExitProcess#4
Name : ExitProcess
If you're using the MinGW compiler tools to link your assembly code, you can do this instead:
C:\> nm C:\MinGW\lib\libkernel32.a | find "ExitProcess"
00000000 I __imp__ExitProcess#4
00000000 T _ExitProcess#4
You'll need to replace C:\MinGW with the directory you installed MinGW.
Since not all Windows APIs reside in the kernel32 import library you'll need to replace kernel32 with the name of the import library given in the Windows SDK documentation for the API function you want to link to. For example, with MessageBoxA you'd need to use user32.lib with Visual Studio and libuser32.a with MinGW instead.
Note there are few rare Windows APIs that don't use the stdcall calling convention. These are functions like wsprintf that take a variable number of arguments, which the stdcall calling convention doesn't support. These functions just have an underscore _ before their names, and no # or number after. They also require that the caller remove the arguments from the stack.
The # symbol is, as the leading underscore, part of the function name when the stdcall calling convention is specified for the function.
The number specifies the number of bytes the function removes from the stack.
The compiler generates this number.
The suffix is added so that the function is not accidentally called with the wrong calling convention or the prototype in the source code specifies the wrong number or size of arguments. So the intention is to provide a means to avoid program crashes.
See also https://msdn.microsoft.com/de-de/library/zxk0tw93.aspx
If you want to get the number to use, make sure you have _NT_SYMBOL_PATH defined to the correct value.
Like:
srv*https://msdl.microsoft.com/download/symbols
or
srv*c:\MyServerSymbols*https://msdl.microsoft.com/download/symbols
For example (in cmd.exe, windows command line):
set _NT_SYMBOL_PATH=srv*https://msdl.microsoft.com/download/symbols
Then use:
dumpbin /exports /symbols kernel32.lib | findstr _ExitProcess#
You'll have to be in the directory where kernel32 is and you'll have to have grep.
Probably is a way to use built in find command. You could also redirect it to a file and then view it in your editor.
I have been doing some x86 programming in Windows with NASM and I have run into some confusion. I am confused as to why I must do this:
extern _ExitProcess#4
Specifically I am confused about the '_' and the '#4'. I know that the '#4' is the size of the stack but why is it needed? When I looked in the kernel32.dll with a hex editor I only saw 'ExitProcess' not '_ExitProcess#4'.
I am also confused as to why C Functions do not need the underscore and the stack size such as this:
extern printf
Why don't C Functions need decorations?
My third question is "Is this the way I should be using these functions?" Right now I am linking with the actual dll files themselves.
I know that the '#4' is the size of the stack but why is it needed?
To enable the linker to report a fatal error if your compiler assumed the wrong calling convention for the function (this can happen if you forget to include header files in C and ignore all the compiler warnings or if a declaration doesn't exactly match the function in the shared library).
Why don't C Functions need decorations?
Functions that use the cdecl calling convention are decorated with a single leading (so it would actually be _printf).
The reason why no parameter size is encoded into the decorated name is that the caller is responsible for both setting up and tearing down the stack, so an argument count mismatch will not be fatal for the stack setup (though the calling function might still crash if it isn't given the right arguments, of course). It might even be possible that the argument count is variable, like in the case of printf.
When I looked in the kernel32.dll with a hex editor I only saw ExitProcess not _ExitProcess#4.
The mangled names are usually mapped to the actual exported names of the DLL using definition files (*.def), which then get compiled to *.lib import library files that can be used in your linker invocation. An example of such a definition file for kernel32.dll is this one. The following line defines the mapping for ExitProcess:
_ExitProcess#4 = ExitProcess
Is this the way I should be using these functions?
I don't know NASM very well, but the code I've seen so far usually specifies the decorated name, like in your example.
You can find more information on this excellent page about Win32 calling conventions.
I am using gSoap to generate ANSI C source code, that I would like to build within the LabWindows/CVI environment, on a Windows 7, 64 bit OS. The gSoap file stdsoap2.c includes several instances of the _setmode() function, with the following prototype:
int _setmode (int fd, int mode);
Where fd is a file descriptor, and mode is set to either _O_TEXT or _O_BINARY.
Oddly enough, even though LW/CVI contains an interface to Microsoft's SDK, this SDK does not contain a prototype to _setmode in any of its included header files, even though the help link to the SDK contains information on the function.
Is anyone aware of the method in LabWindows/CVI used to set file (or stream) translation mode to text, or binary.
Thanks,
Ryyker
Closing the loop on this question.
I could not use the only offered answer for the reason listed in my comment above.
Although I did use the SDK, it was not to select a different version of the OpenFile function, rather it was to support the use of a function that an auto-code generator used, _setmode() but that was not supported by my primary development environment (LabWindows/CVI).
So, in summary, my solution WAS to include the SDK to give me definition for _setmode as well as including the following in my non- auto-generated code:
#define _O_TEXT 0x4000 /* file mode is text (translated) */
#define _O_BINARY 0x8000 /* file mode is binary (untranslated) */
So, with the caveat that this post describes what I actually did, I am going to mark the answer #gary offered as the answer, as it was in the ball park. Thanks #gary.
It sounds like you just want to open a file as either ASCII or binary. So you should be able to replace the instances of _setmode() with the LW/CVI OpenFile() function as described here. Here's a short example reading a file as binary.
char filename = "path//to//file.ext"
int result;
result = OpenFile(filename, VAL_READ_ONLY, VAL_OPEN_AS_IS, VAL_BINARY);
if (result < 0)
// Error, notify user.
else
// No error.
Also note this warning from the page:
Caution The Windows SDK also contains an OpenFile function. If you
include windows.h and do not include formatio.h, you will get compile
errors if you call OpenFile.
I have the offset address's of all symbols (obtained with libelf executing on its own binary .so). Now, at runtime, I would need to calculate the absolutue address's of all those symbols and for that I would need to get the base address (where the shared library is loaded) and do a calculation:
symbol_address = base_address + symbol_offset
How can a shared lib get its own base address? On Windows I would use the parameter passed to DllMain, is there some equivalent in linux?
On Linux, dladdr() on any symbol from libfoo.so will give you
void *dli_fbase; /* Load address of that object */
More info here.
Alternatively, dl_iterate_phdr can give you load address of every ELF image loaded into current process.
Both are GLIBC extensions. If you are not using GLIBC, do tell what you are using, so more appropriate answer can be given.
This is an old question, but still relevant.
I found this example code from ubuntu to be very useful. It will print all your shared libraries and their segments.
http://manpages.ubuntu.com/manpages/bionic/man3/dl_iterate_phdr.3.html
After some research I managed to find out the method of discovering the address of the library loading by its descriptor, which is returned by the dlopen() function. It is performed with the help of such macro:
#define LIBRARY_ADDRESS_BY_HANDLE(dlhandle) ((NULL == dlhandle) ? NULL : (void*)*(size_t const*)(dlhandle))
How can I convert an offset in text segment of an Win32 executable into a pointer at runtime?
When using a disassembler, I can see the relative addresses. But how can I convert them to an absolute address at runtime?
For example:
.text:402BE620
Which address is that at runtime? How can I convert that number into a pointer?
Some background: I have to fix a bug in a end-of-life DLL and we don't have access to the source code. For that I want to hook a specific function and override it at runtime.
(It contains a call to WaitForSingleObject where MsgWaitForMultipleObjects had to be used, and because of the additional parameters it cannot be fixed with a hex editor)
EDIT: Thank you for your suggestions, but I added that stuff about hooking only to give you some context. I don't need a hooking framework!. I have a good hooking framework which does all the heavy lifting and - at least for now - I don't need any more information about hooking itself.
I just have to provide the address of the function to hook to my hooking framework and for that I have to know how to calculate it and I don't know how to determine it.
EDIT 2: I have used two different disassembler, both show the address as noted above. Somewhat odd: Both reject "402BE620" as an offset if I use their "goto" feature. I have to enter the offset as "2BE620" to make it work...
I don't know the answer to your specific question, but even if I did, I don't think your plan will work. I take it you are planning to dynamically patch the function call with a call (or jump) to your own code? However, what happens if the page that contains the patch is discarded by the OS and then re-loaded (from the DLLs disk image) sometime later? How are you going to detect this and re-patch it?
Just a thought....
To do something like this you would usually use detours
It allows you to create a thread in a running process and hook/replace any function in it.
Usually it works by looking up the symbol but there shouldn't be a reason it won't work with an offset.
To specifically answer your question, In the dll file you will usually find relative addresses. relative to the start of the file. When a PE (dll, exe) is loaded into memory all of the relative addresses are replaced with absolute addresses using the base address where the PE is loaded. You can check the base address of a specific DLL using GetModuleHandle()
402BE620 doesn't look like a relative address at all. it really looks like an absolute address so you better be sure what the disassembler shows you. relative addresses can't be larger than the size of the DLL file they are in.
Another hint you might find useful - When you attach a debugger to a process it usually lists all of the DLLs and their base addresses.
i don't know about the offset from the .text segment specifically, but in the debugger look at the address you want and subtract the module load offset from it. it may get loaded at a different address every time, even if the base address is explicitly set.
an alternative to runtime patching may be to simply patch the dll itself. OllyDbg is a great free assembly level debugger and code analysis tool that lets you easily patch a binary.
edit:
just for fun here's some sample code i used for using an extension to binary patch out some functionality i didn't like in an app -- at runtime. i made some simplifications and didn't recompile and test, but you should get the idea.
(i had the complication that the binary was periodically updated, hence the additional work to pattern match within a small range from the known offset.)
void MyCrazyPatch()
{
static bool patched = false;
if (!patched)
{
patched = true;
DWORD dwPatchOffsetStart = 0x5310;
DWORD dwPatchLength = 22;
BYTE rgPatchMatch[] = { 0xab, 0x07, 0x37, 0x56, 0x50, 0xe8, 0x92, 0xfb, 0xff, 0xff, 0x83,
0xf8, 0x01, 0x89, 0xb5, 0xfc, 0x0f, 0x85, 0xb2, 0xaa, 0x00, 0x00, 0x8b };
HMODULE hmod = GetModuleHandle(L"mybinary.dll");
if (hmod != NULL
{
MODULEINFO modInfo;
if (GetModuleInformation(GetCurrentProcess(),
hmod,
&modInfo,
sizeof(modInfo)))
{
DWORD dwIncrement = 0;
dwPatchOffsetStart += (DWORD)modInfo.lpBaseOfDll;
while (dwIncrement < 0x200 &&
memcmp((void*)(dwPatchOffsetStart + dwIncrement),
rgPatchMatch,
sizeof(rgPatchMatch)) != 0)
{
dwIncrement++;
}
// Sanity check then add nop's to stomp out the offending code.
if (dwIncrement < 0x200 &&
memcmp((void*)(dwPatchOffsetStart + dwIncrement),
rgPatchMatch,
sizeof(rgPatchMatch)) == 0)
{
DWORD dwOldProtect = 0;
VirtualProtect((void*)(dwPatchOffsetStart + dwIncrement),
dwPatchLength,
PAGE_EXECUTE_READWRITE,
&dwOldProtect);
memset((void*)(dwPatchOffsetStart + dwIncrement), 0x90, dwPatchLength);
VirtualProtect((void*)(dwPatchOffsetStart + dwIncrement),
dwPatchLength,
dwOldProtect,
NULL);
}
}
}
}
}
This milw0rm paper on API Interception via DLL Redirection (PDF)
discusses a couple of ways that should give you an idea where you are venturing.
While there are several methods which can be used to achieve our goal, this tutorial will
examine only DLL redirection. This approach was chosen for several reasons:
It is relatively simple to implement.
It allows us to view and modify parameters passed to an API function, change return values of that function, and run any other code we desire.
While most other methods require code to be injected into the target process or run from an
external application, DLL redirection requires only write access to the target application's
working directory.
We can intercept any API call without modifying the target (either on disk or in memory) or any
system files.
Once we have redirected the program to load our DLL, we need to have all the functions it
is looking for. Let's say that we want to intercept every call that Internet Explorer makes to
MessageBox. MessageBox is located in user32.dll, so we will need to create a DLL called user32.dll
that contains an exportable function named MessageBox, create the iexplore.exe.manifest file, and
place our newly created user32.dll and iexplore.exe.manifest files in the C:\Program Files\Internet
Explorer directory. Now when IE imports its API functions, it will load MessageBox from our
user32.dll file; then, whenever IE calls the MessageBox function, the code we placed on our
MessageBox function will be executed.
The catch is that MessageBox is not the only function that will be imported from user32.dll.
There could be hundreds of functions that IE will be looking for in user32.dll and if any of these are
missing then IE will fail to load. Since we don't want to re-write all of the user32 DLL functions, we
will simply forward the rest of the functions to the original user32.dll file