Starforce 3 - The gravestone?

Originally Posted by dyn!o

I have never heard about uncracked software (including game), did you?

Yes, try to find some workaround for game Beyond Divinity (second part of the great game Divine Divinity) and I am not talking about that solutions that you mentioned in your first post like unplugging ide cables of CD-ROM drive...
I have been searching for other solution for some time but without any success..
It would be great of Ultima release some info about their method but I think they won't cause it should help the developers to improve SF3.. and this is probably the reason why were stopped some projects like SafeDisc v1 & v2 generic unpackers..
Regards.

[dyn!o]

"Then the crack is not as interesting (even though it is still impressive) protect.dll changes from game to game - the same effort that was put into this particular game will have to be repeated on others.��

With all respect, Doug:

In some previous post I suggested that maybe we should avoid so brave statements . Let��s assume some ExeTools member, who really want to learn Starforce internals, will read that protect.dll ��changes from game to game�� and it��s not interesting. Let��s try to become himself for a while: I would like to learn how to crack Starforce (this is just an example), I also see some team did it without modifying protected game files. I am pretty interested because if it works then, maybe, I will be able to learn the same trick and gain additional knowledge (invaluable if I want to know how the protections works and how they can be defeated). Unfortunately I read the following sentence: ��the crack is not as interesting�� ��protect.dll changes from game to game�� and think: ��damn, I just thought it could be what I am searching for, but this guy proved it is not��. What��s next? Ehh, you know. Are we here to learn or get discouraged? I will tell you something: when I was beginning my experience with PC software protections, I was totally out of help. I have been trying to contact some teams and even single crackers with the same kind request: ��please help me and tell me where should I begin, what should I read, what should I try to crack at first����. I have sent tens of emails. Guess how many answered? None. That made me wonder if the scene is really worth such an effect-less effort and if crackers do want to help each other, at least a little. I started to learn myself by completely partisan-like way, without knowing even trivial things like executable compressors (I didn��t know they exists and was wondering long weeks why process memory differs from executable content! He he�� good old times).

But let��s go into the details and render some logic estimations.
We have a problem called ��protect.dll��. Also we have a sentence: "A driver crack, if it existed, would activate all other games too...��. I will try to prove it was a too brave statement too . Protect.dll �C you have written that it ��changes from game to game�� - have you wondered why? Tell me. ��A driver crack�� ��would activate all other games���� �C I am sorry to say you are wrong. Have you wondered why Starforce drivers do not have to change on each game? If you don��t know then think about their purposes. Problems? I will help you: tell me which file is the only critical for Starforce security? If you know then tell me if a driver based Starforce crack, in your opinion, really would be able to defeat other games? And now, after those inferences, please tell me if ��the crack is not as interesting��? Really?

"It would be great of Ultima release some info about their method but I think they won't cause it should help the developers to improve SF3��
Well said, but Starforce developers are skilled enough to discover this trick by downloading discussed relase.

Regards.

<sigh>

They did modify the protected files, protect.dll has been patched. Where do you think the cd-check is?

I don't believe in your psychological argument of "getting discouraged" by a post on a forum. If you really want to crack the protection, that's not the kind of thing that you worry about.
Besides, if you really do get discouraged by what I said, then it's probably better this way; you wouldn't have been able to crack it anyway. You don't learn to crack any serious protection overnight.

BTW, e-mailing groups for help is never going to work.. that's like e-mailing Microsoft, asking how they programmed feature X,y,z.. they won't tell you.. Groups are competing (against other groups & protections) and keep the knowledge for themselves.


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)
- ...

*From the assumption that the crack was driver-based*, then all games would be unlocked:
The drivers are generic and backward compatible. Since a driver must work on gameX & gameY without change, cracking the driver for gameX means gameY also works.
That's all I said. You can't just cut what I say in the middle and then draw bogus conclusions.

If you really know how the driver works, then tell me how the ring-0 anti- NTice works.
Start your reasoning from ring-3 protect.dll all the way to the point the ring-0 check occurs.

Btw, Ultima hooked the starforce VM function table.. (largely responsible for the interpreter's behavior) hats off to them for that. They also seem to know pretty damn well the p-code instructions because they know what to do when the script is at particular places...
This is not a new idea, but I haven��t seen anyone use it in a crack, because as soon as you do, you let everyone (including star-force) know how you cracked their protection. As I stated above, generally people want to avoid doing this simply because the protection is going to change now that the information is available.

[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.