Hi there,
I am struggling with something weird. I am trying to put my byte string in .code section and after using it with MessageBox api, it works but Windows XP gives and error,
as you know bla. bla. an exception occured, SEND it DONT SEND IT bla. bla.
But if i put my byte string into .data section, it gives error...
Code is like this :
.486
.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
.code
_start:
push 0
push offset mesaj
push offset mesaj
push NULL
call MessageBox
push 0
push offset mesaj
push offset mesaj
push NULL
call MessageBox
mesaj db 'emre',0
_end:
push 0
call ExitProcess
end _start
Does anyone have any idea?
Tip of the day: Crossposting is bad habbit.
Your solution is here: http://www.masm32.com/board/index.php?topic=7672.0
hi
.code
_start:
push 0
push offset mesaj
push offset mesaj
push NULL
call MessageBox
push 0
push offset mesaj
push offset mesaj
push NULL
call MessageBox
ret
mesaj db 'emre',0
_end:
push 0
call ExitProcess
end _start
greets
ragdog
The easiest way to embed data into the code section is to use the 'szText' macro. It will produce the jump statements for you.
.data
szText MACRO Name, Text:VARARG
LOCAL lbl
jmp lbl
Name db Text,0
lbl:
ENDM
.code
szText mesaj,"emre"
Thank you for your replies,i got the idea behind! System tries to recognize byte string as instruction. now it works,
Thanks again :)
P.S : I got the tip of the day:) Wont be again :)
Now I have a question, why would one want to embed test in the .code section instead of the .data section? Just curious... :bg
Quote from: Tipidy on August 23, 2007, 09:44:00 AM
Now I have a question, why would one want to embed test in the .code section instead of the .data section? Just curious... :bg
1) for no apparent reason; so the string is readonly? .const section is also readonly, you can put strings there too.
2) viri-like coding
push 0
call @f
db "mesaj",0
@@:
push dword ptr [esp]
push 0
call MessageBox
3) because you can
Hi Emre,
Why do you prefer to pass manually the parameters instead of using the invoke statement?
Actually, although it's bad practice, it can be used to reduce program size. Each section has to be at minimum 512 bytes so even if you just put "Hi" into the section, it will be padded to 512 bytes minimum ("last section exemption" not taken into account). Some people put strings in the code section to make use of the space they are using there to keep from having to make an extra section which would primarily consist of unused space.
One can use also the /MERGE linker switch combining the sections to one to reduce the size of the executable.
Yea, that's effectively the same idea. If you were going to do it, I would probably suggest using the /MERGE method and let the Linker handle everything. This is because if you collect everything into one section the Linker will automatically take advantage of the "last section exemption". The last section in the section table isn't bound by the 512 byte increment rule, the linker can strip unused data from the end of the section (further reducing the file size).
How does one know what to use for the from=to parmeter, and is this method viable for shrinking a static library?
Jim,
Static libraries don't have sections like a PE executable file.
Quote from: Jimg on August 27, 2007, 07:48:01 PM
How does one know what to use for the from=to parmeter, and is this method viable for shrinking a static library?
/MERGE:.text=.drizz /MERGE:.rdata=.drizz /MERGE:.data=.drizz /SECTION:.drizz|RWEalthough static libraries object files(static library is collection of obj files) do have sections, you can't use merge command because it's not supported. other ways to shrink the static library would be to remove any .debug$S, .debug$T @comp.id, .file, assembler logo,etc. information from object files, but i'm not familiar with such a tool.
There have been tools in the past to strip junk out of object modules but its probably just as simple to build the object module without the junk in it as a release build. I don't personally see the point of chasing size reduction in an object module when the only thing that matters is the final size of the executable code built using object modules. With current 32 bit COFF object modules you have complete control of both DATA and CODE so there is no problems in controlling what you end up putting into an EXE file as long as you are not using a junky compiler that does not gve you the options.
As in the original thread question, I changed a static library lib containing only a grid control I have been working on. I moved everything from the initialized data section, .data, to the .code section, and sure enough, when loading the control in an app, the exe is 512 bytes smaller.
That's interesting to know that if you store your data in the .code section and not the .data section the exe file will be smaller when compiled and linked :dance:, I guess that's why virus writers to this :naughty:.
It only works on very small files which don't write back over their existing data. At best you can save 512 bytes but once an app gets over a minimal size the gains are very few. You usually do better using Pelle's linker and a section merge after.
The virus guys use it to concentrate their code in one place so they don't have to find the .DATA section and find a space in it to write to.
[off topic]
Quote from: Tipidy on August 28, 2007, 07:18:33 PMI guess that's why virus writers to this :naughty:.
Hutch is right, virus writers have an alternate reason. If you think about what viruses do, they infect, which means their code needs to be portable between the applications which they are infecting. Those virus writers concentrate the code so it's much more portable. I had a gig a few years ago coming up with signatures and those little buggers can be crafty by design.
[/off topic]
Some of you are seeing just the good side of this (the size optimization) but there is a reason I said this is a bad practice. It's fine for read operations but once you start putting data that's going to be written to in your code section, you're going to get some speed penalties. I suggest you profile your code regularly if you do this because in some cases you won't get the penalties, then you'll make a few small changes and bam! You're hit with almost 10x speed reduction. I'm still unsure why it does it, but it usually happened to me when I was messing with pointers. So best suggestion is just not to do it, put writable data somewhere else (the Heap maybe).
In most cases you can (should) place your 'data' in the .const section - except, of course, if you plan to modify it. The const data will be stored in the same section as the names of the imported dlls+functions, so it won't actually create an extra section. Generally this produces the same size exe as if you put the data into the code section, but with the protection and separation from being in a different section.
The slow down caused by modifying data in the code section is the same as that caused by self-modifying code (as far as the processor is concerned, any modification in the code section is a code modification). So, the cache-line must be flushed and read in again (even though it's a 'data' modification, it's on a code cache-line, so it needs to be kept coherrent. And if you happen to be executing from there at the time... poor you :bdg
I do not write viriis but I know i could! ( the reply is for those curious guys!) I am trying to create my own PE format which i will use for my compression program. It s a challenge for my class!!!
Is that enough?
By the way, thanks to all repliers and sorry for late replying:) I was in the graduation ceremony of my school "Turkish Military Academy" :) And this is my first reply as a second lieutenant:):):)