Can I set the entry point outside my program?
How do I make a program that do self modifying on the run?
Are you asking if you can set the entrypoint outside the code, from within the MASM source file, at assembly-time?
No, wherever you put "START:" is where the entrypoint will be. You could write all of your functions first, then place "START:" at the bottom and call the previous functions though. But this is still not "outside the code."
For anything else, you will need to modify the PE header after assembly. This is how a compressor like UPX works -- it reads the source file and PE header into RAM, consolidates and compresses each section into a .upx section, then writes a new file with the entrypoint at a decompression routine, which then expands and recreates the original sections from the .upx section, then jumps to the original entrypoint.
A word of caution... UPX and the other file compressors are all well-known by the antivirus companies. If you write a new compression/encryption/whatever routine, the antivirus programs are going to immediately flag the executable as a "generic trojan" or similar.
Hi Mark Jones,
maybe my question is lil bit out of topic. i often compress my program using UPX. i notice no different after compression except the size file becomes smaller. i want to know is there any performance decreasing causing by UPX? after i run my compressed program, the speed is the same with the original. so, in theory, is there any increasing or decreasing performance using UPX? and is it compatible with all machine (ignoring an antivirus factor)?
thx
There is a slight performance penalty when a compressed executable is opened, because the decompression routine must first decompress the contents of the executable before passing execution to it.
At one time, hard disks were small and expensive, and a compressor like UPX provided significant size savings. But hard disks are so large today, that UPX is barely useful. It seems like "UPX" is becoming synonymous with malicious code also, since less people are using it for legitimate programs and more people are using it to hide code.
well, actually the main reason i use UPX is just to hide any strings and resources in my program. i can edit resources of a program using resource editor. so, to avoid someone do that to my program, i use UPX since i don't know any other way.. :green
thx for your explanation..
Quote from: busclock on February 02, 2009, 04:02:47 AM
well, actually the main reason i use UPX is just to hide any strings and resources in my program. i can edit resources of a program using resource editor. so, to avoid someone do that to my program, i use UPX since i don't know any other way.. :green
But UPX has the -d option to uncompress your program. So it is probably not the best way to "hide" something.
Also, the "slight performance penalty" can become a real performance problem if the binary is to be launched multiple times in a batch job.
When I use compression I use Jeremy Collake's PEcompact and it does NOT come with a decompressor or the crappy GPL licence with its weird restrictions. I mainly use compression to improve loading speed by short curcuiting paging on load.
Quote from: japheth on February 02, 2009, 08:46:44 AM
But UPX has the -d option to uncompress your program. So it is probably not the best way to "hide" something.
do the zero-fill in the beginning of the program using hex editor, then UPX won't recoqnize it anymore.. :green
Quote from: japheth on February 02, 2009, 08:46:44 AM
Also, the "slight performance penalty" can become a real performance problem if the binary is to be launched multiple times in a batch job.
what does that mean?
i often run 10 or more my compressed program at once. do u mean all those programs will get me in trouble?
Quote from: hutch-- on February 02, 2009, 11:37:05 AM
I mainly use compression to improve loading speed by short curcuiting paging on load.
wew..
which one is true? compression make improving of loading speed or not? :(
Compression makes the file smaller, which means it is read from the disk faster.
But, once the exe file image is in memory, the operating system must decompress it prior to execution.
As Mark mentioned, this may slow you down if you use the same program repeatedly in a batch.
However, for most uses, the penalty is not noticable.
Of course, this depends on the compression algorithm used and how many times the program is to be opened.
As an example, the simplest type of compression is "0 packing".
All areas of the exe file that contain repeated 0 bytes are eliminated.
A table is created that defines addresses and quantities of the repeat 0 areas (usually at the end of the file).
A small piece of code is attached that expands the file, re-inserting the repeat 0 areas prior to executing the program.
More complex compression routines may be used, like LZW compression (similar to ZIP and GIF files).
Greater compression ratios are obtained, but it takes a bit longer to de-compress the file.
Notice that the de-compression only occurs once per execution.
so what happen then after the decompression has done completely by the operating system?
does the program run as fast as the uncompressed one?
Now, back to the original question - lol.
I believe the entry point is stored in the PE header and may indeed be modified.
However, I can't think of a reason for doing it that way.
As for writing self-modifying code, it is possible, but care must be taken not to modify code that is already prefetched.
This requires a little understanding of how the CPU gets code from memory.
Also, I should mention that it is considered "bad form" to write code that way.
Personally, I don't agree with that. There are times when it is the best way to go.
Modifying code on the fly makes it harder to read and maintain a program.
It does not comply with "structured code" practices.
Now, let me guess what you are trying to do....
You want to modify the program file so that the entry point is one location the first time it is run, then modify the file so that any subsequent execution has a different entry point.
It may be much simpler to make an entry in the registry that indicates the first-run has occured.
That way, if the user has multiple copies of the program, the hook still applies.
Also, if you want it to hook on a per-user basis, place the registry entry in the HKCU hive.
If you want it to hook on a per-computer basis, place the registry entry in the HKLM hive.
Once the de-compression is done, the program executes exactly the same as an uncompressed exe.
Im thinking about to confuse cracker when they disassembling it. I saw a good anti crack software protection from my friend, his software is do self modifying which I cant understand (Or maybe he just simply compress it). When I put that software on ollydbg, it said the entry point is outside the code and I cant do anything to it. Will this topic assumed as hacking technique? I hope not.
Quote from: Farabi on February 03, 2009, 02:44:32 AM
Im thinking about to confuse cracker when they disassembling it.
Never happen. At some point your program has to actually do its stuff, and there are programs like IDA that are pretty good at getting around self-modifying code - they use it to disassemble viruses all the time.
Agreed, developers have been "building better mousetraps" for about twenty years now, but the mice have only gotten smarter because of it. :green
Perhaps something like this can help: http://www.oreans.com/
QuoteSecureEngine® defeats all current cracking tools that can be used against protected applications and it will make sure that your protected applications are only run in safe environments.
Yeah, right. Just look at securom/starforce for games - sometimes a crack is posted before the game is released (well, so I've been told...)
Remember debug scripts? They're a bit more sophisticated nowadays - just ask IDA.
(Off topic, but I download a few 'trainers' now and then and 'IDA' them - lots use the masm32 package heh heh)
Every thread that starts with a simple UPX question ends up to extreme solutions like winlicense and virtualization.
Also, masm is perfect for trainers :toothy
And PECompact is an excellent compressor choice. UPX is good, but discontinued.
So if a software are packed, there must be a routine for unpacking it first am I right?
Quote from: Farabi on February 07, 2009, 04:46:30 AM
So if a software are packed, there must be a routine for unpacking it first am I right?
Yes, the unpacker code gets executed first, it unpacks the sections of the executable, loads the dlls, creates the import table etc etc.
Then it jumps to the original entry point of the packed program. Pack one of your programs with UPX and step through it in a debugger for a live example.
if it can be packed, it can be unpacked
it all depends on how much time you want to put into it
When you are told that the Start is outside of the code or program what you are being told is that the stub contains the entrypoint and also contains the pointer to the real starting point; it merely looks like it is because the stub needs to run to decompress the code. Because of this, the Start point does not look valid until the code decompresses. OllyDebug has no way of knowing this.
I probably am not stating this very well but I am sure you can get the point I am trying to make.
Also, about hiding resources as someone mentioned here; most resources can be created in the code section. My version of Sudoku is a good example of this - 81 buttons - nothing about them in the RC file. Take a look at it. Also, Hutch has some excellent stuff about this in his SDK.
Paul
Quote from: busclock on February 02, 2009, 11:43:57 AMdo the zero-fill in the beginning of the program using hex editor, then UPX won't recoqnize it anymore.. :green
Hi, now i realized that i break this following UPX License by doing such an action..
Quote- We grant you special permission to freely use and distribute all UPX
compressed programs. But any modification of the UPX stub (such as,
but not limited to, removing our copyright string or making your
program non-decompressible) will immediately revoke your right to
use and distribute a UPX compressed program.
- UPX is not a software protection tool; by requiring that you use
the unmodified UPX version for your proprietary programs we
make sure that any user can decompress your program. This protects
both you and your users as nobody can hide malicious code -
any program that cannot be decompressed is highly suspicious
by definition.
can someone give me some real free executable compressor?
or maybe is there a way just to protect strings in my program?
thx..
Have a look at here (http://en.wikipedia.org/wiki/Executable_compression) for some exe compressors.