.DATA
MsgBoxCaption db "My MsgBox", 0
MsgBoxText db "Hello World", 0
The above code produced a 1.5KB file.
.CODE
jmp @F
MsgBoxCaption db "My MsgBox", 0
MsgBoxText db "Hello World", 0
@@:
The above code produced a 1.00KB file.
1. Is defining variables in .CODE better then inside .DATA?
2. I understand jmp will unconditionally jump to another location, but what is @F and @@: ?
Thanks in advance!
MsgBoxCaption db "My MsgBox", 0
MsgBoxText db "Hello World", 0
The above code produced a 1.5KB file.
.CODE
jmp @F
MsgBoxCaption db "My MsgBox", 0
MsgBoxText db "Hello World", 0
@@:
The above code produced a 1.00KB file.
1. Is defining variables in .CODE better then inside .DATA?
2. I understand jmp will unconditionally jump to another location, but what is @F and @@: ?
Thanks in advance!
@f means the following anonymous (@@) label searching from the line you are referencing it and @b means the reference the backwards label.
The reason of the size difference is that you are using just one section to hold both, constant data and code so the file uses one section and hence it waste less space.
The reason of the size difference is that you are using just one section to hold both, constant data and code so the file uses one section and hence it waste less space.
Yep.
@F(orward) and @B(ackward) to the nearest @@: (Anonymous) Label
@F(orward) and @B(ackward) to the nearest @@: (Anonymous) Label
01. start:
02. jmp @F
03. MsgBoxCaption db "My MsgBox", 0
04. MsgBoxText db "Hello World", 0
05. @@:
06.
07. invoke MessageBoxA, NULL, addr MsgBoxText, addr MsgBoxCaption, MB_OK
08. invoke ExitProcess, 0
09. end start
Showing above is the complete code example (with line numbers added).
Q1. Since @F jumps to @@: .... order of execution by line number is 01,02,05,06,07,08,09. How does the 2 variables - line 03, 04 - get initialized to its string values?
Q2. Why does the program crash without usage of @F and @@: ?
02. jmp @F
03. MsgBoxCaption db "My MsgBox", 0
04. MsgBoxText db "Hello World", 0
05. @@:
06.
07. invoke MessageBoxA, NULL, addr MsgBoxText, addr MsgBoxCaption, MB_OK
08. invoke ExitProcess, 0
09. end start
Showing above is the complete code example (with line numbers added).
Q1. Since @F jumps to @@: .... order of execution by line number is 01,02,05,06,07,08,09. How does the 2 variables - line 03, 04 - get initialized to its string values?
Q2. Why does the program crash without usage of @F and @@: ?
Q1: the variables are right there in your code section, emitted as raw data bytes.
Q2: if you don't put the @F, your CPU will effectively be executing (or trying to) your strings... try tracing your program with OllyDebug and you'll see.
Mixing code and data in this way is plain silly, you should put your variables in a .data section... if you insist on putting them with your code, at least move them before the "start:" label so you don't need any jumps.
Q2: if you don't put the @F, your CPU will effectively be executing (or trying to) your strings... try tracing your program with OllyDebug and you'll see.
Mixing code and data in this way is plain silly, you should put your variables in a .data section... if you insist on putting them with your code, at least move them before the "start:" label so you don't need any jumps.
The JMP only occurs during EXECUTION of the program.
During DEFINITION, it does not occur, so the lines defining data strings are reached.
During DEFINITION, it does not occur, so the lines defining data strings are reached.
I am new to assembly programming and like to understand things properly before moving on .... please bare with me :-)
1. Placing the strings before "start:" and opening the new .exe in ollydbg, causes ollydbg to initially open a "Suspicious Breakpoint" dialog box. I assume this means a problem. Is this correct?
2. Tracing a program in Ollydbg is something I need to learn properly, any good tutorials on this area? I have only read the single tutorial on Ollydbg's website.
3. Why is mixing data and code "plain silly"? If using "jmp @F" in the .CODE produces a smaller .exe file, wouldn't defining our strings in the .CODE be better then .DATA?
4. What do you mean by the DEFINITION and EXECUTION phases? Doesn't my .exe simply jump into the .CODE section and execute my code line-by-line? What happens in each of these phases?
Thank you for your patience in helping me understand things better.
1. Placing the strings before "start:" and opening the new .exe in ollydbg, causes ollydbg to initially open a "Suspicious Breakpoint" dialog box. I assume this means a problem. Is this correct?
2. Tracing a program in Ollydbg is something I need to learn properly, any good tutorials on this area? I have only read the single tutorial on Ollydbg's website.
3. Why is mixing data and code "plain silly"? If using "jmp @F" in the .CODE produces a smaller .exe file, wouldn't defining our strings in the .CODE be better then .DATA?
4. What do you mean by the DEFINITION and EXECUTION phases? Doesn't my .exe simply jump into the .CODE section and execute my code line-by-line? What happens in each of these phases?
Thank you for your patience in helping me understand things better.
#1 - not a problem, it's just ollydebug following hardcoded heuristics based on what executables "normally look like".
#2 - get basic assembly knowledge, write small programs, load in OllyDebug, play around... dunno any better way to learn things :)
#3 - the smallest cluster size you're going to see will be 4kb. Any space saving under 4kb is pretty irrelevant, since you'll always take up at least a full cluster on the harddrive. Separating code and data is a good idea, especially with writable data (one thing is keeping code read-only, another is the performance penalty on some processors for having code and modified data too close together). Besides, it smells of DOS mentality :)
#2 - get basic assembly knowledge, write small programs, load in OllyDebug, play around... dunno any better way to learn things :)
#3 - the smallest cluster size you're going to see will be 4kb. Any space saving under 4kb is pretty irrelevant, since you'll always take up at least a full cluster on the harddrive. Separating code and data is a good idea, especially with writable data (one thing is keeping code read-only, another is the performance penalty on some processors for having code and modified data too close together). Besides, it smells of DOS mentality :)