I'm on a Windows 7 machine and I tried opening up kernel32.dll in IDA and IDA says that the address of the IsDebuggerPresent function is 0x77e2b020. I'm trying to call the function using inline assembly.
On a vs2010 platform, I tried using the following code:-
#include<iostream>
using namespace std;
int blah() {
__asm {
xor eax, eax
mov ebx, 0x77e2b020
call ebx
}
}
int main() {
cout<<blah();
return 0;
}
On building the exe, it shows the kernel32.dll is being loaded.
I tried debugging the exe in OllyDbg and the error is an "Access violation" when the "call" instruction executes.
Yes, I know that calling the API directly from C++ is the best/right way to do this, I'm doing this for fun I just dont understand why this does not work.
The address 0x77e2b020 is not static, you MUST call it by name rather than by explicit address.
When you reboot, the library will be loaded at a different address if ASLR is enabled. You also cannot guarantee the library load order, so that will affect the address too.
If you're trying to do an indirect call, consider using LoadLibrary and GetProcAddress to find the address of IsDebuggerPresent at runtime.
Another issue is that you're trashing eax and ebx. You should use pushad and popad to keep the registers safe whilst you do such inline assembly, for example:
__asm {
pushad
call IsDebuggerPresent
mov dbgPresent, eax
popad
}
Related
Fairly simple question this time. How do I write to screen the contents of a single register in Assembly? I'm getting a bit tired of calling DumpRegs just to see the value of one register.
I'm using x86 architecture, and MASM in Visual Studio, and Irvine32.lib.
Irvines's DumpReg uses repeatedly a macro of Macros.inc: mShowRegister. It can be used directly. Example:
INCLUDE Irvine32.inc
INCLUDE Macros.inc
.code
main PROC
mov esi, 0DeadBeefh
mShowRegister ESI, ESI
exit
main ENDP
END main
A documented macro with more options is mShow. Example:
INCLUDE Irvine32.inc
INCLUDE Macros.inc
.code
main PROC
mov esi, 0DeadBeefh
mshow ESI, h
exit
main ENDP
END main
Irvine32 has output functions that take a value in EAX, such as WriteDec (unsigned base 10).
See the documentation http://programming.msjc.edu/asm/help/source/irvinelib/writedec.htm which has links to WriteHex (hex = base 16), and WriteInt (signed base 10).
These functions use the Irvine32 calling convention and preserve all registers, including the arg-passing register EAX, so you can even insert them as a debug-print for EAX at least. More usually you'd use them as simply normal output functions.
Usually for asm debugging you'd use a debugger, not debug-print function calls.
Here is my code, but when I use my debugger I get an error once I reach the int21 h command which says:
Unhandled exception at 0x00007FF6E9B01034 in MP2_KyleRuiter.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.
Program:
ExitProcess PROTO
.data
string DB 4bh, 79h, 6ch, 65h, 20h, 52h, 75h, 69h, 74h, 65h, 72h, 00h ; My Name
COUNT = ($-string) ; string length calculation
.code
main proc
mov rcx,COUNT ; loop counter
mov rsi,offset string
L1:
mov dl,[rsi] ;gets character from the array
mov ah,2 ;displays character
inc rsi; points to next character
Loop L1 ;decrements rcx until 0
mov rax, 4c00h
int 21h ; displays
RET
main ENDP
END
int 21h & co. is 16-bit MS-DOS stuff, while the rest of the code you wrote is x86 64bit assembly. On 64-bit Windows you are invoking god-knows-what interrupt handler, which results in a crash.
If you want to print stuff when running under 64 bit Windows you have to invoke the relevant syscalls (GetStdHandle to get a handle to the console, WriteFile to write the data); MASM makes this relatively simple through the INVOKE directive.
You can't use DOS interrupts, like int 21h, in a 64-bit Windows executable. Modern Windows isn't a DOS-based system, so it doesn't use that interface anymore.
If you want to write a DOS executable, you'll need to use 16-bit instructions, and run it in an emulator (like DOSBox).
If you want to write a 64-bit Windows executable, you'll need to use Windows library calls.
Pick one.
int 21h with AH set to 4Ch says to terminate with a return code. It looks like your debugger does not know how to step over/into a terminate. That makes some sense, I suppose.
Belay my last. I stand corrected.
You might find this helpful, though:
Why does using "int 21h" on Assembly x86 MASM cause my program to crash?
I dont quiet understand the gcc prologue, especially for main.
Why is there the instruction and esp, 0xfffffff0 ? I know what it does but why is it necessary ?
When we call a function, we first have to push the arguments, but why gcc doesn't use the push instruction and uses movs instead ? Moreover using those movs, it creates an empty padding. It looks like a waste of memory, why so ?
Finally, gcc first uses the sub instruction to esp in order to "reserve" memory for the stack, but what makes sure that this memory is not used by on other program for instance ?
I think I understood quiet well the theory, but I couldnt find a document that explains more about memory in pratice (how do memory of several programs dont overlap, ...). Thank you for your answers.
PS : I add the assembly code and the cpp code :
Dump of assembler code for function main(int, char**):
0x08048657 <+0>: push ebp
0x08048658 <+1>: mov ebp,esp
0x0804865a <+3>: and esp,0xfffffff0
0x0804865d <+6>: sub esp,0x20
0x08048660 <+9>: mov DWORD PTR [esp+0x1c],0x3
0x08048668 <+17>: mov BYTE PTR [esp+0x1b],0x61
=> 0x0804866d <+22>: mov DWORD PTR [esp],0x8048771
0x08048674 <+29>: call 0x804863c <p(char*)>
0x08048679 <+34>: mov eax,0x0
0x0804867e <+39>: leave
0x0804867f <+40>: ret
End of assembler dump.
int main(int argc, char *argv[]) {
int b = 3;
char c = 'a';
p("hello woooooooooorld !!");}
The stack alignment is only done for main, the rest of the functions just keep the alignment required by the ABI.
The compiler uses mov instructions for locals so they can be accessed randomly. For outgoing function arguments you can ask for push instructions using the -mpush-args compiler option which might produce smaller code.
As for the wasted memory, you probably didn't compile with optimizations enabled (which would of course eliminate your b and c altogether since they are not used ;))
Each process has its own virtual memory address space, so there is no chance of anybody else using the memory allocated from the stack.
When I assemble a file using GCC tools (from MinGW package), calls to WINAPI functions from system DLLs have this form:
call label
...
ret
label: jmp dword [ExitProcess]
Instead of:
call dword [ExitProcess]
...
ret
How can I force GCC to call directly idata section pointers instead of generating that extra code?
Simple solution:
If you want (this will throw a segment fault)
call *_MessageBoxA#16
do this instead
call *__imp__MessageBoxA#16
and you will get an indirect call without extra useless code.
I am building some intel-style inline assembly code using gcc compiler on Xcode 4.
Below lists part of the inline assembly code:
_asm
{
mov eax, esp
sub esp, 116
and esp, ~15
mov [esp+112], eax
}
Under ship mode, GCC compiles the above 4 lines asm code to:
mov %esp,%eax
sub $0x74,%esp
and $0xfffffff0,%esp
mov %eax,0x70(%esp)
which are exactly what I want.
However, under debug mode GCC will compiler that code to
mov %esp,%eax
mov %eax,%esp
mov %esp,%eax
mov %eax,-0x28(%ebp)
mov %esp,%eax
mov %eax,%esp
sub $0x74,%esp
mov %esp,%eax
mov %eax,-0x24(%ebp)
mov %esp,%eax
mov %eax,%esp
**and $0xfffffff0,%esp**
**mov %esp,%eax** **//changing the value of “eax”**
mov %eax,-0x24(%ebp)
mov %esp,%ecx
mov %ecx,%esp
**mov %eax,0x70(%esp)** **//store a “dirty” value to address 0x70(%esp), which is not we want**
One way to solve the above problem is to rewrite the inline asm code using AT&T style instructions and add the register to the clobbered list. But this way would be a very time-consuming work since the code to rewrite is so…o long.
Are there any other efficient ways to solve the problem? To make the gcc compiler know that register “eax” should be reserved?
There are 2 ways:
The best way to solve it is using gcc assembly template
capabilities. Then you can tell the compiler WHAT you're doing an
the register allocator will not use your registers for anything
else.
A quickhack would be to just use "asm volatile" instead of "asm" that way gcc will not reschedule
any instructions inside that block. You'll still have to tell GCC
that you're using the register so it's not going to store anything
in there. You should also list "memory" in the clobber list, so gcc
knows that it can't trust values it might have loaded before your
code-block.
asm volatile(
"Code goes here"
: : : "eax", "esp", "memory"
);
Btw: Your code is doing some "bad things" like moving esp around, which might cause trouble down the line, unless you know exactly what you're doing.
An empty asm block after the intel-style block solves the problem, like this:
__asm volatile {
mov eax, esp
sub esp, 116
and esp, ~15
mov [esp+112], eax
};
__asm__ __volatile__ ("":::"eax", "memory");
However, if you don't restore %esp, it's going to wreak havoc.