Set Entry Point

[Farabi]

Can I set the entry point outside my program?
How do I make a program that do self modifying on the run?

[Mark Jones]

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.

[ragdogz]

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

[Mark Jones]

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.

[ragdogz]

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

[japheth]

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.

[hutch--]

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.

[ragdogz]

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

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?

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? :(

[dedndave]

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.

[ragdogz]

so what happen then after the decompression has done completely by the operating system?
does the program run as fast as the uncompressed one?

[dedndave]

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.

[dedndave]

Once the de-compression is done, the program executes exactly the same as an uncompressed exe.

[Farabi]

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.

[sinsi]

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.

[Mark Jones]

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/