The original idea of this project was to create a generic application that is capable of "Gluing" together two independent application - and run them as if they are glued head to tail.
This application is supposed to run in a win32
environment, and work with Portable Executable files.
When one wishes to run an executable in win32 environment
he just double-click it, and here the file starts running. What he
doesn't know, is that Windows works fairly hard behind the scenes.
When windows wants to run a file, it first need to setup the memory space
needed for the executable, load the executable's code itself in this memory,
then load and prepare any external code and other resources the executable needs.
After all this is done, the OS can finally start running the executable's code.
Doing all those steps, prior to running the first code from the executable,
let us (as programmers) more power in writing complicated softwares.
In the old days of DOS, we had COM files, where COM stands for Copy Of Memory.
in those days, in order to run such files - the OS needed only to load the
image into memory, and start processing the first instruction.
This was indeed easy to implement and manipulate, but in DOS we
didn't had Dynamically Link Libraries (aka dll), nor we had
Resources (and a whole bunch of cool stuff). In order to support
such concepts - the OS should work a bit harder than just load an
image into memory, this is what the Windows Loader does.
Every PE file that uses even one windows' API,
needs to have an Import Table (a table where the Compiler 'tells'
the OS what dlls it needs, and where to put them). By using this
table - the OS can set the proper environment for the application.
setting the environment cannot be done in runtime, it must be done
prior to any application's code execution. But we have only one
chance to set the environment for two applications.
If the file use resources (like most windows applications), things
became even harder. The loader keeps a pointer to the resource
section of an application - and use it when any Resource related API
is being called. Again, we have one pointer, but two
resource sections (assuming both applications are using resources).
The main challenge in this project, was to fool
each application to think that the windows loader set the
environment as it should, while a loader we created is the one that
sets the environment for the applications.
In our eyes - the highest revenue from this
project was our education. We studied a lot about how windows
handles executable, what can and what cannot be manipulated in the
loading process and how windows builds the environment prior to
executing code. we learned how to use windows APIs, how to write
assembler and how to use disassembles and debuggers. but mostly we
learned how to search, investigate and finally master an unknown and
The application we created can be downloaded in
the Binary section, this application is not perfect - and was never
intended to be perfect, it is merely a proof of concept application
(all though it has been successfully tested with a lots of files).
please see release notes in Binary Section.