Starforce protection as I see it...

[Tryst]

No doubt someone will flame me if I'm wrong here but I won't respond to a flame war. All I am doing is relating what I've deduced about the Starforce protection method from various reading sources across the net.

The protection relies on drivers installed silently onto your system. They have been known to disrupt USB devices and cause system slow-downs, CD read errors and other problems. A simple Google search will show that there is a removal tool available since, like a virus, they just re-install themselves again and so manually removing them from device manager will not work.

Here's my theory about how they work and why it isn't possible to crack them so easily.

1. A key is written onto sectors of the CD in batches. Therefore only a certain amount of CD's will work with the key they supply with the game.

2. The drivers decrypt the key written on the CD and so are necessary, however destructive they can be.

3. the Key they supply is entered and combined XOR'd or whatever with the one written on CD.

4. Verification is done by decrypting certain files on the game and checking certain strings of bytes to see if they match a template.

5. The resulting key is used to decrypt the game files.

Since the game files are encrypted using the final key, it's safe to say that the game files are also different on each batch since the CD key and the supplied key are different.

To crack it, you first have to read the key on the CD, decode it and combine it in the same way with the one you manually enter.

Creating a NOCD exe version of the game file will not work since it cannot decrypt the game files. To do this, you would have to crack a 192bit encryption (not easily done and would certainly take time to run).

This is just my conclusion from what I've read about this protection method, don't take it as gospel. I don't claim to be accurate.

[Morglum007]

I can say you are almost 100% wrong, and thats why:

1.- There is no physical key written on the CD surface. Starforce just read some sector at the CD, and then, codifies an internal key with the timing it last to, which with RSA algorithm makes the final testing. Mastered ( silver ones) CDs/DVDs will always have same timing, and will always launch "without" problems. Thats why Starforce differences from originals and copies.

2.- The drivers doesn't decrypt anything from CD. SF have two (2) virtual machines: first for CD checking/antidebuging, and another one for the game itself. Decrypting is done internally, and have nothing to do with CD key.

3.- As stated above, there isn't any key written on CD ( thats why no CD can be detected as StarforceD by sector checking, unless Key on Data preparer field CD structure). It is not a "XOR" comparison, it is a RSA algorithm..

4.- Starforce reads certain sector ( different at different games) and then obtain a timing, which codes into a code. If this code is correct ( original), RSA will succeed, and game will launch. If timing is incorrect, code will not match, and RSA decryption will fail.

5.- Resulting time will be coded into another code, and this will launch first VM which will check game integrity and hardware limits. Once done, another VM launchs the game.

Finally, every game is different, cause every code is different per mastering mill. The provided code will be interpreted with starforce as a sector reading and timing. This timing will be almost the same for originals, and different for copies.

Cracking SF is not so easy, cause there is something called p-codes. SF uses about 500 stolen functions, registry obfuscation and conditional jumps inside VM. Thats the problem with SF. Every game have different p-codes, and there is no tool could extract (exist) and patch ( in progress) such functions.

SF uses a very poor 64 bit RSA encrypting key, so no 192 bit encrypting......where have u read such thing?

Please, don't miss people.

Morg @ CdSTeam

[Tryst]

OK, I got it wrong but I only theorised based on what I've read. Some of the info came from Daemon Tools forums and other bits came from various other game copy forums. Most of these seem to be giving tidbits of info but not the whole story so I tried to tie these bits together as best I could. I did remember Gamecopyworld was who said it was 192 bit.

I only know of p-code as being a product of compilers like VB. Is this the same code you are talking about here?

Surely timing could not be a factor due to access speed differences on different CD readers. Unless you are talking about clock cycles for machine code operands.

Would it be possible for you to decribe blow by blow how this RSA encryption system works?

[Luciel]

yup its p-codes all the way on SF3, and dont worry, we wont flame ya (the ones who do will get a taste of my fury )

[Morglum007]

Well, then, now you know how exactly SF works.

Analysing more in deep key and method is it sure it uses a 64 RSA algorith, We know that cause we needed time ago making a keygen, and our conclussions were irrefutable. A coleague did it, but there is still a problem. We got such keygen, but for one game we discover there were almost 150 valid keys that launched SF machine. When we studied SF at physical level, we noted how many sector SF checks and how it does. There were an impressive timing between certain checks, regular with almost every SF game, but so irregular in copies. Thats what SF is looking for. We tried too to insert twin sectors in those checking sector, and when launching, SF said literally: "There were a problem when checking the timing in the disc: please clean it up, and try again..."
We have logging od SF sector, and it is the same in every game, but different sectors.

Concerning diferent drives, besides every drive read at its own, all of them preserves a pattern when reading. For example, one drive can read certain sectors at 12 ms, 24 ms 36 ms 36 ms, and other at 6 ms, 12 ms 18 ms and 18. Besides speed is different, both have same patterns, so no matter what drive we are talking about.

Yes, p-codes are assemblers native system, and SF uses it to avoid debugging. To running SD ( Safedisc) or SecuROM we can fool the guard module and launch Softice with it, but with SF, even launching Sice with it, will result useless. SF gets all the control, and it is like a compiler ( as u named). There is only ONE at once, so Sice or SF, choose....xD

I asure u, timing is the key with SF. SF copied the CD Cops system, and protected a little more, but it is the same in essence.

If u means, step by step, this is a industrial secret of SF, and will be unfair for it. Just read any tut about RSA. It is no difficult. Manual ( or data decryptor block) key is the "public" key, and the inner one is the "private" one. Only a valid combination will launch VM. SF uses a very smart system cause no physical info is on CD, just reads its nature.

Sorry could not help on that.

Morg @ CdSTEam