protection library init
------------------------------------------------------------------------------

While some protected module, exe or dll is loaded, protection library is
loaded as well. Since protection library is shared among all protected modules
only first module triggers library init, which could include CD-check,
Trial-Check or HW-check or nothing (demo versions). When protection library
passes any of those checks, it's ready to take VM entry ID's from any
module.


module init
------------------------------------------------------------------------------

Each protected module has entry point code pushes ID and jumps to VM, examples:

GTLdemo.exe
00BCA000: PUSH 0DFED723 ;ID
00BCA005: JMP sfp.dll.#1 ;(VM-enter)

GTLDemo, net.dll
10033000: PUSH 1945CD87 ;ID
10033005: JMP sfp.dll.#1 ;(VM-enter)

This tells the VM what macro/vm-code should be executed.
Now, since this code uses JMP opcode, how does VM know where it comes from?
The answer lies in the executable header, which contains signature which
is matched later with this ID. VM checks all loaded modules and finds
correct one. If you change the header or use this ID from your custom module
VM wont find the target, and GUI will display a msg about module currupion.

Module is found, VM starts unpacking/decryption of the sections.
Then redirection list is decrypted and used to build up jumper array in some
allocated memory:

PUSH ID1
JMP VM
..
PUSH ID2
JMP VM
.. etc

Then VM writes JMP (e9) redirections in the protected modules code, which point
to any entry in this array. Some of those ID's will trigger simple redirection
of the code, but some of them will lead to execution of stolen/emulated game
function which was marked by the developers by creating an export table entry,
hence no matter what the build or game version it is, always same code is
protected. In most cases those functions are marked with "SFLB_" in their name.

Most of the games protected with starforce also use import table protection,
so the imported functions are not directly pointed in the IAT, there are 2 cases:

1) redirection using VM
2) rebuilded version of the api at allocated memory

While first way seems hard, it's not, VM exit point is easly trackable.
People who cant see the VM code, second way could be a problem,
but there are ofcourse oldschool ways which can easly lead to an answer,
a matter of lazyness and coding skills I suppose :)

Back to the stolen functions. Starforce has an option to protect idepandant
game functions located in the protected module. Those functions do not
need any JMP(e9) redirections to be written, their code in the module
is a simple RET(c3), what happened to the function code? Its executed
in the VM, before the real original entrypoint, so in some cases your
"oep" dumps are useless (PsiOps, Second Sight, PacMan world2, Toca2, Crc2005 etc)

Now, when the module is finally unpacked, redirections are written, import
table loaded, relocations fixed (protected dlls), VM uses VM-exit and jumps to
the original entrypoint.

Done.