First post, by Akuma
Life of an executable: keep it original
There are many reason why executable files change, the most common are
mentioned below. If the content changes, the size, timestamp and checksum
will likely follow. This can be good or mallicious depending on the cause.
This is a major reason why there are so many different executables being
mistaken as updates. Optimization shrinks the file size while new features
make it grow. Bigger doesn't always mean newer or better. The lack of version
control in the days of old still causes a lot of trouble today.
I wrote this to shed some light on the subject and hopefully make support
for everyone a bit easier 😁
Versioning & Updates
Back in the day when distribution of software relied on physical
media, updates where not that accesible. You were mostly stuck with
what you got on the retail media. Customer support could provide
users with updates through the postal service, but in my experience
this only happend when there were major bugs/problems.
The only way you could determine differences was by timestamps, size
or content. If you were lucky the programmer added a version number.
Virus & Anti-virus
The introduction of viruses onto a platform did not make it any better.
Viruses change executables by attaching themselves. Changing the
execution order to load themselves into memory first and then then jump
back to load the original program.
The weirdest thing in retrospect was the counter action taken by some
antivirus vendors with immunization. It works almost the same except
that it does not have a mallicious payload. The code loaded tries to
prevent further alteration of the executable.
Antivirus cleaning actions are another horror to file integrity. Try to
restore the executable by undoing the actions of a virus is a good thing.
But this does not always return it to its original state. It is common that
cleaning leaves trailing data behind, nopped or nulled, and/or does not
fix the execution order by only disabling the payload.
Immunization can be removed by either the antivirus product itself or
unpackers like UNP by Ben Castricum. Which brings me to the next item:
Packers & Encryption
In order to save diskspace and later as a form of protection packers and
encryptors came on the market. Spacemaker (+-1982) from Relia comes to mind
as the first, although I'm not really sure when (it seems the author died
before a date could be established, which is a shame).
Many software companies wanted effective use of diskspace so there was a
demand to slim things down. As a respons Microsoft added exepack to their
asm, c, cobol, fortran and pascal compilers. After linking the exepack
program would remove empty space, to reduce the filesize. This did not
come without any problems of their own. Did you ever get the "packed file
is corrupt." message when starting a program ?
In the early 90's LZexe and PKlite were starting to dominate, they had way
better compression than exepack and could be used in conjunction with it.
Although I know that LZexe alerted users that exepack was used and advised
them to just use LZexe for better compression. This was not always the case.
I have seem many examples that using both would result in a even smaller file.
Packers compress the executable similar like zip/arj/lzh, but have a loader
to decompress itself into memory on the fly. Because this does not change
anything for the end user and still delivers the same experience, it was
quickly adopted. Disk access times were slow in those days and smaller
programs loaded significatly faster even if they had to decompress in memory
Ofcourse viruses started to make use of this too. By compressing or encrypting
the payload they would mask their signature and would no longer be recognized
by the antivirus programs. Thus there was a real need to decompress them in
order to scan for viruses.
Unpacking will decompress/decrypt the executable but does not always return
it to its original form. Although still 100% executable, like the cleaning
with antivirus products it suffers from the same problems like traling data.
Especially when memory is dumped in order to retrieve it.
All these interactions will bring new variaties into the world with
their own little problems accompanying them. This why some collectors
have dozens of versions of a game not realizing that they are in fact
the same. Which brings us to the point I am trying to make: when asking
for help on this forum, please mention your version, and if not found
the year,filename, filesize or checksum hash (CRC/MD/SHA). I always
found that to be really helpful.
Ofcourse the most obvious rule does still apply, make sure you can
reproduce your problem on the original version too.
Just to make clear, I am just a user on the vogons platform, my opion
may differ from those running it 😁.
Feel free to comment, correct and add to the subject matter