Starforce 3 - The gravestone?

[dyn!o]

I don't want to get into brawl, my friend. Also I don't want to get into endless discussion.

"They did modify the protected files, protect.dll has been patched. Where do you think the cd-check is?"
And you answered yourself. What for you need to reverse all the drivers if it can be done by reversing single file only?

"I don't believe in your psychological argument of "getting discouraged" by a post on a forum."
And that's ok for me .

"...if you really do get discouraged by what I said..."
Mate, please read my posts carefully. I only asked the question ("Are we here to learn or get discouraged?"). Did I told that you discouraged anyone? Probably you got offended, unnecessarily.

"e-mailing groups for help is never going to work.. "
I know that, that's why I have written about contacting tasks too.

"You did not understand what I said about the drivers. I am well aware of what they are doing, and they are playing an *ESSENTIAL* part in the protection. For example, they are responsible for (but not limited to): - heavy anti debugging - all ring3 and ring0 hooking (ex: S-F virtual file system, anti-emulation) - ..."
I just quoted your sentence and analysed your words, not mine - you would notice that if you read carefully instead of getting nervous. Starfoce drivers are pretty essential indeed. But let me tell you one thing pretty straight: reversing them won't allow you to run all Starforce games because it's simply impossible. Why? Because, as you know, the CD check is in protect.dll which changes in every version. You can change all drivers but they are not responsible for our problem (CD check). They are Starforce engine heart but not Starforce CD protection heart. I will make it even more clear: let's take Xtreme Protector as example. Its driver play almost the same role like Starforce drivers. By patching Xtreme Protector driver you can run all Xtreme Protected software? Never. So, general idea of drivers patching is useless (so far).

"If you really know how the driver works, then tell me how the ring-0 anti- NTice works."
Man, I am just an lamer without serious cracking knowledge. Calm down and realise that even if I would own so cosmic knowledge I don't have any obligation to answer your unkind order.

"*From the assumption that the crack was driver-based*"
How could you had such assumption if the previous posts made it clear? (protect.dll was modified)

"You can't just cut what I say in the middle and then draw bogus conclusions."
Did I call any of your post "a bougus conclusion"? Aren't you a little nervous?

"the protection is going to change now that the information is available."
And it will (if Starforce developers are wise... so far they are). I don't see any problem here. It's endless game, like ASProtect or Armadillo cracking. They are fixing holes and crackers reveal another ones.

Regards.

In my opinion the EXE file isn't an important Starforce file, I think it's only a loader to load the crypted EXE inside the protect.dll. The protect.dll is the real crypted EXE.

You can test this by taking other Starforce files from other games.

I think the protect.dll isn't the Starforce driver...


Best Regards, DeeYeah

[dyn!o]

Yes, protect.dll is heavily protected with Starforce virtual machine but... what's interesting... some game exe/dll files can be protected with virtual machine too, making it really hard to crack. That's why it's wiser to find a generic hole.

Of course, as you said, protect.dll itself is not a driver, but takes hardocore usage of them . It's the place responisble for the critical task: the CD check.

Regards.

Originally Posted by dyn!o

protect.dll itself is not a driver, but takes hardocore usage of them . It's the place responisble for the critical task: the CD check.

As far as I know (from about a dozen of SF-protected apps), protect.dll contains _all_ code of original EXE.
Try to analyze "main" executable of protected app with hiew or any other PE editor. There is code section inside but it is initialized to zero!
Moreover, OEP of main EXE points inside zero-initialized section!
Actually Windows loads protect.dll before passing control to OEP, protect.dll checks presence of original CD and either terminates application or decrypts code section of main EXE (which stored in protect.dll) and places it in right position in memory. But some part of processor instructions are converted to pseudo-code which interpreted by SF engine (drivers + protect.dll).

So, modifying protect.dll does not means patching of SF engine only or application data only. Most probably both SF engine and application data where modified.

[dyn!o]

Nice information you gave us

I didn't call protect.dll an engine but the critical place responsible for CD check. Furthermore, I suggested that it could be a good idea to crack Starforce that way because it requires the modification of single file only (protect.dll). And if you ask if Starforce engine was modified together with game exe/dlls, then no. Only protect.dll was modified. If you put xpandrally.bin (protect.dll) into original game - it will be cracked .

Regards.

Backdoor in StarForce driver, really?
Read more about:
h**p://www.freewebs.com/starforcemeat/index.htm

Originally Posted by RideX

Backdoor in StarForce driver, really?
Read more about:
h**p://www.freewebs.com/starforcemeat/index.htm

looks authentic. funny