The fatal problem of a launcher program is that everything required to perform the client checks is included in the launcher and hence available for reverse engineering.
This could be made more difficult by using one-time launcher programs - ie, a new launcher would be generated for every connection to every server, using templates, crypto keys and a launcher program generator. Cracking one launcher program wouldn't help directly because it can't be used for new connections anyhow - unless you could figure out the generator/template combo and reverse engineer the crypto key/code out of the loader binary fast enough to take over the connection.
The real fatal problem is that at one time or the other the loader have to trust the environment the loader is running in, and as you point out, that's the easier attack anyhow.
That might have negative consequences on latency unless the encrypter is somehow able to be in the same address space as the verified client or scheduling can be tweaked enough to force task switches right after sends.
Split the program into two parts; a loader and a.dll for the client. The standard (open source) loader just loads the dll, hooks up the i/o streams and lets the client run.
Enforcing loaders would be closed source and CRC the client.dll and handle encryption/decryption of the i/o stream.
As the encryption/decryption is in the same process as the client, there wouldn't be any context switching problems.
Extending it a bit further, the client part would not be allowed to load any data directly from a file on the host, instead doing it through the loader which can CRC the loaded data to verify that it hasn't been tampered with.
Now, what happens is of course that you move the interest of crackers from the client to the loader - if it's cracked then you can do anything you want.
A further improvement would be to download the loader from the server every time you connected to it. The server would periodically (every few minutes or maybe even for every connection) generate new loaders through some server-specific algorithm, meaning that it wouldn't be enough to crack one loader, but instead you would have to crack the algorithm used by the server to generate the loader, as well as cracking the individual loader. Also, as soon as a server suspects that its algorithm is weak, it can be changed.
The size of the resulting security hole - basically you are letting the servergod control your computer - means that it isn't a practical solution - unless, of course, you write the loader in Java.
With Java1.2 security, it should be possible to setup the security parameters allowing you to safely let the loader load the.dll files and necessary data files.
Also, using this technique, the loader interface would be open-source, and it might be possible to open-source the loader implementation template/loader generator as well, if the generated instances is sufficiently hard to crack.
Slashdot Mirror
This could be made more difficult by using one-time launcher programs - ie, a new launcher would be generated for every connection to every server, using templates, crypto keys and a launcher program generator. Cracking one launcher program wouldn't help directly because it can't be used for new connections anyhow - unless you could figure out the generator/template combo and reverse engineer the crypto key/code out of the loader binary fast enough to take over the connection.
The real fatal problem is that at one time or the other the loader have to trust the environment the loader is running in, and as you point out, that's the easier attack anyhow.
Split the program into two parts; a loader and a .dll for the client. The standard (open source) loader just loads the dll, hooks up the i/o streams and lets the client run.
Enforcing loaders would be closed source and CRC the client .dll and handle encryption/decryption of the i/o stream.
As the encryption/decryption is in the same process as the client, there wouldn't be any context switching problems.
Extending it a bit further, the client part would not be allowed to load any data directly from a file on the host, instead doing it through the loader which can CRC the loaded data to verify that it hasn't been tampered with.
Now, what happens is of course that you move the interest of crackers from the client to the loader - if it's cracked then you can do anything you want.
A further improvement would be to download the loader from the server every time you connected to it. The server would periodically (every few minutes or maybe even for every connection) generate new loaders through some server-specific algorithm, meaning that it wouldn't be enough to crack one loader, but instead you would have to crack the algorithm used by the server to generate the loader, as well as cracking the individual loader. Also, as soon as a server suspects that its algorithm is weak, it can be changed.
The size of the resulting security hole - basically you are letting the servergod control your computer - means that it isn't a practical solution - unless, of course, you write the loader in Java.
With Java1.2 security, it should be possible to setup the security parameters allowing you to safely let the loader load the .dll files and necessary data files.
Also, using this technique, the loader interface would be open-source, and it might be possible to open-source the loader implementation template/loader generator as well, if the generated instances is sufficiently hard to crack.