Hello World Disassembly

[why06]

Assembly 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

.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:

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

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.

[Hell_Demon]

invoke MessageBoxA, NULL, addr HelloWorld, addr HelloWorld, MB_OK
invoke ExitProcess, 0

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

CALL <JMP.&kernel32.ExitProcess> = CALL JMP DWORD PTR DS:[<&kernel32.ExitProcess>]
basicly you push the params onto the stack(reversed order), then call a jump to kernel32.ExitProcess

Comprende?

[why06]

basicly you push the params onto the stack(reversed order), then call a jump to kernel32.ExitProcess

Comprende?

Si, Muy Comprehende!

The colors helped a lot too. especially since the function params are symmetrical it would be impossible to tell.

[Hell_Demon]

No habla espagnol!
and make sure to ask BA if I was correct, been a long time ago since I used asm

[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

[why06]

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

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.

[Void]

The parameters go in reverse order.

caption db "Caption",0
text db "Text",0

push MB_OK
push offset caption
push offset text
push 0
call MessageBox

I think.

[why06]

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.

[Obama]

I love this, great jobs guys , so beautiful everyone learning

[why06]

Hey it worked.

Guess your off the hook David.

.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

I love this, great jobs guys , so beautiful everyone learning

Awww... Obama can't wait for us too make him a personal VIP. xD

[B1ackAnge1]

pretty simple eh why?
remember this thread? https://www.mpgh.net/forum/34-assembl...ld-anyone.html

[why06]

pretty simple eh why?
remember this thread? https://www.mpgh.net/forum/34-assembl...ld-anyone.html

Are you kidding me? That's the first thing I read. When I decided to learn MASM. I copied ur program. It really helped a lot btw. Anyway haven't seen you in a while. Anyway don't be a stranger, or I'm gonna have to hunt you down. D:

Especially starting masm I need your old wisdom. :P

[Hell_Demon]

oi BA:

(ok hint : you'd see something more like this but without the nice readable variable names)

...
push MB_OK
push offset HelloWorld
push offset HelloWorld
push NULL
call MessageBoxA
...

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

.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

would translate into(roughly)

push MB_OK
push hello.00403000
push hello.00403000
push NULL
call MessageBoxA

and

.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

would rougly translate into

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

[why06]

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

I thought stdcall and cdecl were the same. anyway... what does it matter. It's symmetrical anyway... D:

[B1ackAnge1]

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