How can I use the call op code to generate a direct call, without dereferencing a pointer?
Since the call instruction can mean any of a number of op codes such as xE8, xFF and x9A, how do I tell Visual Studio which one I want to generate when I use the call instruction?
The assembler will figure out which opcode to generate based on what expression you use.
If you write call foo it will be a near relative call E8. If you write call [foo], call [eax] or call eax it will be near indirect call FF (opcode extension 2). If you write call foo:bar (or if the assembler knows you are calling a far procedure) it will be a direct far call 9A. If you write call far [foo] it will be an indirect far call which is also FF (but opcode extension 3).
PS: not sure about far call syntax for VS, see the documentation for details. You don't normally use far calls, though.
Related
I am just starting to learn Assembly (x86 NASM) and I am currently going over function calls. Wherever I looked on the internet I saw everyone calling functions like this:
call power
Where power is the label where the function starts. But what I am trying to see is how to print something in Assembly, and interestingly enough, calling a function like in the above case doesn't seem to work. We'll use the printf function from C. Say I already used extern printf and import printf msvcrt.dll in my program (so I can actually use printf), also say I already defined a symbol in my data segment msg db "Hello World", 0 and now I am trying to print this message. If I do this:
push dword msg
call printf
Nothing happens, it doesn't work. I have no idea why. However, if I do this:
push dword msg
call [printf]
The message is printed just as expected.
This doesn't make much sense to me after all the articles that I read used just the label, without brackets. It also made a lot of sense to me when using just the label as we're using the call instruction to perform a jump to that label, so we needed the address of the label. But here it doesn't make sense at all to me why we're using the brackets and what exactly happens. I mean, what is [printf] and what would [power] be, for the example I presented at the start of my question. However, despite my confusion, this is what works and the method I initially used doesn't work.
Can you please tell me exactly what is going on? (PS: I am using Olly Debugger if that makes any difference)
It depends on what is "printf" in your assembly. If it is a function pointer (aka, the address of some function is stored at the address named "printf"), then you need brackets []. If "printf" is a function, that is, if the machine code is stored at the address that your assembler calls "printf", then you must not put brackets (or else you will probably end up with a segmentation fault, as the first 32 of 64 bits of machine code of "printf" probably don't accidentally contain an address of an executable code).
Windows API has ChildWindowFromPoint() and ChildWindowFromPointEx() functions and they differ in that the latter has uFlags parameter specifying which windows to skip.
It looks like if I pass CWP_ALL into ChildWindowFromPointEx() I'll get exactly the same effect as I would have with ChildWindowFromPoint().
Is the only difference in uFlags parameter? Can I just use ChildWindowFromPointEx() everywhere and pass CWP_ALL when I need ChildWindowFromPoint() behavior?
If it helps at all, I hacked up a quick test application that calls both functions and stepped into the disassembled USER32.DLL to see where the calls go.
For ChildWindowFromPoint, after some preamble, I reached this point:
The main processing was delegated to the call at 75612495.
Then, for ChildWindowFromPointEx, I step into the assembly and get this:
As that entry point is the target of the call from the first function, it seems pretty clear to me that ChildWindowFromPoint calls ChildWindowFromPointEx, presumably with uFlags set to CWP_ALL (my assembler knowledge is limited but I'm looking hard at that push 0 before the call - CWP_ALL is defined as zero).
If you intent to always use ChildWindowFromPointEx with CWP_ALL, you could just use ChildWindowFromPoint().
If you intent to always use ChildWindowFromPoint, you could just use ChildWindowFromPointEx with CWP_ALL.
ChildWindowFromPoint is equivalent to ChildWindowFromPointEx with CWP_ALL.
Advice: use ChildWindowFromPointEx (you may one day have usage for other flags value)
In Mac OS, that looks like the EDI stored the handle of current instance of one class. Is it right? I hope to call other class methods via it.
Even though I checked Intel 64bit manual and AMD64 ABI interface, there is no clear answer about it.
It would usually be in RDI, as it's treated as the first parameter to a function, and under the ABI, that parameter is passed in RDI.
caveat: If the return value from the method is non-trivial (i.e. it's a temporary allocated in stack) then there is an additional 1st parameter passed, which is the address of that temporary, and which comes before the this pointer.
I found the definition in below document:
http://developer.apple.com/library/ios/technotes/tn2004/tn2124.html#SECSOMEASSEMBLY
Thanks!
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.
GCC documentation states in 6.30 Declaring Attributes of Functions:
naked
Use this attribute on the ARM, AVR, IP2K, RX and SPU ports to indicate that the specified function does not need prologue/epilogue sequences generated by the compiler. It is up to the programmer to provide these sequences. The only statements that can be safely included in naked functions are asm statements that do not have operands. All other statements, including declarations of local variables, if statements, and so forth, should be avoided. Naked functions should be used to implement the body of an assembly function, while allowing the compiler to construct the requisite function declaration for the assembler.
Can I safely call functions using C syntax from naked functions, or only by using asm?
You can safely call functions from a naked function, provided that the called functions have a full prologue and epilogue.
Note that it is a bit of a nonsense to assert that you can 'safely' use assembly language in a naked function. You are entirely responsible for anything you do using assembly language, as you are for any calls you make to 'safe' functions.
To ensure that your generic called function is not static or inlined, it should be in a seperate compilation unit.
"naked" functions do not include any prologue or epilogue -- they are naked. In particular, they do not include operations on the stack for local variables, to save or restore registers, or to return to a calling function.
That does not mean that no stack exists -- the stack is initialized in the program initialisation, not in any function initialization. Since a stack exists, called function prologues and epilogues work correctly. A function call can safely push it's return address, any registers used, and space for any local variables. On return (using the return address), the registers are restored and the stack space is released.
Static or inlined-functions may not have a full prologue and epilogue. They can and may depend on the calling function to manage the stack and to restore corrupted registers.
This leads to the next point: you need the prologue and epilogue only to encapsulate the operations of the called function. If the called function is also safe (no explicit or implicit local variables, no changes to status registers), it can be safely static and/or inlined. As with asm, it would be your responsibility to make sure this is true.
If the only thing you do in the naked function is call another function you can just use a single JMP machine code instruction.
The function you jump to will have a valid prologue and it should return directly to the caller of the naked function since JMP doesn't push a return address on the stack.
The only statements that can be safely included in naked functions are asm statements that do not have operands. All other statements, including declarations of local variables, if statements, and so forth, should be avoided.
Based on the description you already gave, I would assume that even function calls are not suitable for the "naked" keyword.