Hello World Disassembly
Hello World Disassembly
Assembly Code:
.386 is the processor model. Which I think is for 32 bit processors. There's also this .486 one, but that's for 16 bit I think.
I'm not sure what casemap does. I don't think I need to worry about it yet.
What's interesting is in MessageBox I pass it the address of the string Hello World rather then then the actual string.
end must have the label that serves as the entry point for the code.
Disassembly:
I think this PUSH hello.00403000 is the address of the string. It's pushed on the stack. which to be honest I don't get completely then messagebox is called.
Not sure about the last two lines, but I'll find out in a bit.
Code:
.386 .model flat, stdcall option casemap:none include \masm32\include\windows.inc include \masm32\include\kernel32.inc include \masm32\include\user32.inc includelib \masm32\lib\kernel32.lib includelib \masm32\lib\user32.lib .data HelloWorld db "Hello World!", 0 .code start: invoke MessageBoxA, NULL, addr HelloWorld, addr HelloWorld, MB_OK invoke ExitProcess, 0 end start
I'm not sure what casemap does. I don't think I need to worry about it yet.
What's interesting is in MessageBox I pass it the address of the string Hello World rather then then the actual string.
end must have the label that serves as the entry point for the code.
Disassembly:
Code:
00401000 >/$ 6A 00 PUSH 0 ; /Style = MB_OK|MB_APPLMODAL 00401002 |. 68 00304000 PUSH hello.00403000 ; |Title = "Hello World!" 00401007 |. 68 00304000 PUSH hello.00403000 ; |Text = "Hello World!" 0040100C |. 6A 00 PUSH 0 ; |hOwner = NULL 0040100E |. E8 0D000000 CALL <JMP.&user32.MessageBoxA> ; \MessageBoxA 00401013 |. 6A 00 PUSH 0 ; /ExitCode = 0 00401015 \. E8 00000000 CALL <JMP.&kernel32.ExitProcess> ; \ExitProcess 0040101A .-FF25 00204000 JMP DWORD PTR DS:[<&kernel32.ExitProcess>; kernel32.ExitProcess 00401020 $-FF25 08204000 JMP DWORD PTR DS:[<&user32.MessageBoxA>] ; user32.MessageBoxA
Not sure about the last two lines, but I'll find out in a bit.
Code:
invoke MessageBoxA, NULL, addr HelloWorld, addr HelloWorld, MB_OK invoke ExitProcess, 0
Code:
00401000 >/$ 6A 00 PUSH 0 ; /Style = MB_OK|MB_APPLMODAL 00401002 |. 68 00304000 PUSH hello.00403000 ; |Title = "Hello World!" 00401007 |. 68 00304000 PUSH hello.00403000 ; |Text = "Hello World!" 0040100C |. 6A 00 PUSH 0 ; |hOwner = NULL 0040100E |. E8 0D000000 CALL <JMP.&user32.MessageBoxA> ; \MessageBoxA 00401013 |. 6A 00 PUSH 0 ; /ExitCode = 0 00401015 \. E8 00000000 CALL <JMP.&kernel32.ExitProcess> ; \ExitProcess 0040101A .-FF25 00204000 JMP DWORD PTR DS:[<&kernel32.ExitProcess>]; kernel32.ExitProcess 00401020 $-FF25 08204000 JMP DWORD PTR DS:[<&user32.MessageBoxA>] ; user32.MessageBoxA
basicly you push the params onto the stack(reversed order), then call a jump to kernel32.ExitProcess
Comprende?
Originally Posted by Hell_Demon
basicly you push the params onto the stack(reversed order), then call a jump to kernel32.ExitProcess
Comprende?
Comprende?
The colors helped a lot too. especially since the function params are symmetrical it would be impossible to tell.
No habla espagnol!
and make sure to ask BA if I was correct, been a long time ago since I used asm
and make sure to ask BA if I was correct, been a long time ago since I used asm
Spot on HD 
Nice coloring.
.386 means it's using the 386 instruction set, you could do 486 or 586 etc, which basically would limit you to running your app on those newer CPUs. Unless you're some hardcore ASM freak and KNOW those specific instructions .386 usually works for 99.999999% of projects
Assuming you know about the flat memory model (basically how windows manages memory, and stdcall is the calling convection (which you just discovered how that passes stuff in 'reverse' order )
casemap : none means your labels are basically case sensitive so Hello != hello etc
Nice coloring..386 means it's using the 386 instruction set, you could do 486 or 586 etc, which basically would limit you to running your app on those newer CPUs. Unless you're some hardcore ASM freak and KNOW those specific instructions .386 usually works for 99.999999% of projects
Assuming you know about the flat memory model (basically how windows manages memory, and stdcall is the calling convection (which you just discovered how that passes stuff in 'reverse' order
)casemap : none means your labels are basically case sensitive so Hello != hello etc
Originally Posted by B1ackAnge1
Spot on HD Nice coloring.
.386 means it's using the 386 instruction set, you could do 486 or 586 etc, which basically would limit you to running your app on those newer CPUs. Unless you're some hardcore ASM freak and KNOW those specific instructions .386 usually works for 99.999999% of projects
Assuming you know about the flat memory model (basically how windows manages memory, and stdcall is the calling convection (which you just discovered how that passes stuff in 'reverse' order )
casemap : none means your labels are basically case sensitive so Hello != hello etc
Nice coloring..386 means it's using the 386 instruction set, you could do 486 or 586 etc, which basically would limit you to running your app on those newer CPUs. Unless you're some hardcore ASM freak and KNOW those specific instructions .386 usually works for 99.999999% of projects
Assuming you know about the flat memory model (basically how windows manages memory, and stdcall is the calling convection (which you just discovered how that passes stuff in 'reverse' order
)casemap : none means your labels are basically case sensitive so Hello != hello etc
Hey Thankyou. It's good to see you BA!
Actually I found this out a lil while ago using Izechelions (think that's how its spelled) Masm32 tutorials. What I would really like to know is how call the Message box function without invoke, but by actually PUSHing parameters.
The parameters go in reverse order.
I think.
Code:
caption db "Caption",0 text db "Text",0 push MB_OK push offset caption push offset text push 0 call MessageBox
I'll try it now.
If it works I'll thank you.
If it doesn't work I'll thank you for trying.
If it deletes my C: drive I'll have to hunt you down.
If it works I'll thank you.
If it doesn't work I'll thank you for trying.
If it deletes my C: drive I'll have to hunt you down.
I love this, great jobs guys 
, so beautiful everyone learning
, so beautiful everyone learningHey it worked.
Guess your off the hook David.
Originally Posted by Obama
Awww... Obama can't wait for us too make him a personal VIP. xD
Guess your off the hook David.
Code:
.386 .model flat, stdcall option casemap:none include \masm32\include\windows.inc include \masm32\include\kernel32.inc include \masm32\include\user32.inc includelib \masm32\lib\kernel32.lib includelib \masm32\lib\user32.lib .data HelloWorld db "Hello World!", 0 .code start: ;MessageBoxA push 0 ;The button push offset HelloWorld ;the Title push offset HelloWorld ;text push 0 ;hWnd passed NULL call MessageBoxA invoke ExitProcess, 0 ;simple invoke end start
Originally Posted by Obama
I love this, great jobs guys , so beautiful everyone learning
, so beautiful everyone learning Originally Posted by B1ackAnge1
Especially starting masm I need your old wisdom. :P
oi BA:
Originally Posted by B1ackAnge1
shouldn't push NULL and push MB_OK be swapped around? since its stdcall not cdecl?
note: I don't use Masm or whatever, __asm is all I've used so far
would translate into(roughly)
and
would rougly translate into
cdecl adds them onto stack in the order you passed them in(so A(b,c) would be push b, push c, call A) while stdcall reverses them(so A(b,c) would be push c, push b, call A)
Right?
or is cdecl automaticly turned into stdcall(or the other way around) at compile time? how would decompilers know if it is cdecl or stdcall?
Because when decompiling stuff with IDA Pro it says 'asuming cdecl by default', what if the function was stdcall? what effect would that have on the decompiler? o__O
Originally Posted by B1ackAnge1
(ok hint : you'd see something more like this but without the nice readable variable names)
Code:
... push MB_OK push offset HelloWorld push offset HelloWorld push NULL call MessageBoxA ...
note: I don't use Masm or whatever, __asm is all I've used so far
Code:
.386 .model flat, stdcall option casemap:none include \masm32\include\windows.inc include \masm32\include\kernel32.inc include \masm32\include\user32.inc includelib \masm32\lib\kernel32.lib includelib \masm32\lib\user32.lib .data HelloWorld db "Hello World!", 0 .code start: invoke MessageBoxA, NULL, addr HelloWorld, addr HelloWorld, MB_OK invoke ExitProcess, 0 end start
Code:
push MB_OK push hello.00403000 push hello.00403000 push NULL call MessageBoxA
Code:
.386 .model flat, cdecl option casemap:none include \masm32\include\windows.inc include \masm32\include\kernel32.inc include \masm32\include\user32.inc includelib \masm32\lib\kernel32.lib includelib \masm32\lib\user32.lib .data HelloWorld db "Hello World!", 0 .code start: invoke MessageBoxA, NULL, addr HelloWorld, addr HelloWorld, MB_OK invoke ExitProcess, 0 end start
Code:
push NULL push hello.00403000 push hello.00403000 push MB_OK call MessageBoxA
cdecl adds them onto stack in the order you passed them in(so A(b,c) would be push b, push c, call A) while stdcall reverses them(so A(b,c) would be push c, push b, call A)
Right?
or is cdecl automaticly turned into stdcall(or the other way around) at compile time? how would decompilers know if it is cdecl or stdcall?
Because when decompiling stuff with IDA Pro it says 'asuming cdecl by default', what if the function was stdcall? what effect would that have on the decompiler? o__O
Originally Posted by Hell_Demon
oi BA:
shouldn't push NULL and push MB_OK be swapped around? since its stdcall not cdecl?
note: I don't use Masm or whatever, __asm is all I've used so far
cdecl adds them onto stack in the order you passed them in(so A(b,c) would be push b, push c, call A) while stdcall reverses them(so A(b,c) would be push c, push b, call A)
Right?
or is cdecl automaticly turned into stdcall(or the other way around) at compile time? how would decompilers know if it is cdecl or stdcall?
Because when decompiling stuff with IDA Pro it says 'asuming cdecl by default', what if the function was stdcall? what effect would that have on the decompiler? o__O
shouldn't push NULL and push MB_OK be swapped around? since its stdcall not cdecl?
note: I don't use Masm or whatever, __asm is all I've used so far
cdecl adds them onto stack in the order you passed them in(so A(b,c) would be push b, push c, call A) while stdcall reverses them(so A(b,c) would be push c, push b, call A)
Right?
or is cdecl automaticly turned into stdcall(or the other way around) at compile time? how would decompilers know if it is cdecl or stdcall?
Because when decompiling stuff with IDA Pro it says 'asuming cdecl by default', what if the function was stdcall? what effect would that have on the decompiler? o__O
For this sample it indeed doesn't matter because you have basicallyu
0, string, string , 0
But when coding in asm I always tend to use Stdcall
so Function(A,B,C) would be
push C
Push B
push A
Call Function.
The function itself would know in which order to pop from the stack, hence why a lot of times when dealing with DLLs etc in C++ you'd see 'Extern C' which is basically saying: the functions in the dll are expecting their data to be passes using stdcall
stdcall != cdecl but that's too much typing righ tnow
0, string, string , 0
But when coding in asm I always tend to use Stdcall
so Function(A,B,C) would be
push C
Push B
push A
Call Function.
The function itself would know in which order to pop from the stack, hence why a lot of times when dealing with DLLs etc in C++ you'd see 'Extern C' which is basically saying: the functions in the dll are expecting their data to be passes using stdcall
stdcall != cdecl
but that's too much typing righ tnow 
