greetz all

well, sometime back i was trying to get ntice working with sd2 and thanks to the constant egging of people here (sintax, yates, manko, nikola etc) i finally managed to get it done

well now i was trying to look at a new target namely *starforce 3*. i had heard of its powerful anti-debugging code, but didnt belive it until i saw it. i have been trying sometime to try and trace starforce code with ntice under 2k but to no avail

seems like sf3 replaces int1/int3 using its drivers. so if i load the sf3 game after loading ntice **boom** reboot. now i tried another approach of loading ntice after reaching oep, then i got into ntice, replaed int1/int3 vectors and when i quit ntice...**boom** hang again. third approach was i got into ntice after oep, replace int1/int3, but now since i was in different process context, it was responding to F8 (trace), but when i switch bak to my target process using ADDR comand, and try F8 (boom reboot) even when the idt entries are still pointing to ntice int1/int3 handlers. its very wierd and hence i thought i would ask for some opinion.

would be glad to receive any response.

best regards
pasha

i was looking a target of StarForce 3 .. can u tell me what target u are working on ? maybe i could help a lil ..

greetz labba

was workin on cycling manager 3.

best regards
pasha

greetz all

hmmm, found out the culprit i think. sf3 has some system thread running which keeps restoring the idt values back. hmmmm. time to find out what and where this thread is

best regards
pasha

greetz all

a week of work, but all in vain . i am still unable to get sf3 working with ntice.

has anyone gotten sf3 to work with softice under 9x or 2k/xp at all ? or is it virtually imposssible to get softice and starforce3 running together ? (

best regards
pasha

SO they are using this to their advantage, blue screening your computer by having a driver crash.

What about the actual Starforce driver code? They must have a sys driver of some sort. Is the code encrypted? Hard to believe it would be if it's a sys driver. Very dangerous to do such a thing.

So in other words, they have to be calling into the system somehow. If you can find the sys file you could probably try editing it so it doesn't even try that IAT stuff at all.
(if you edit the sys, make sure to use LordPE and recalc the checksum) But you know this already, having worked with sd2.


Oh, and also, is it possible to debug using OllyDbg?

-nt20

greezt nikola

i have tried with sf3 under 9x and 2k/xp. but in both sytems its really tough to get sice working with sf3. under 9x, there is not a problem as in 2k (replacing int3 causing system crash), but then under 9x, they somehow detect my sice, dunno how and display msg. and yes, i ahve trired icedump, no good .

lemme describe scenario under 2k (since i have tried every shit possible in that environment). am working now to try under 9x.

1) starforce uses drivers, yes, prohlp02.sys, prosync.sys. the driver code is encrypted. yes. they have a decrypting routine which decrypts the code as and when its executed. plus, they have loads of rdtsc to track single stepping.i found bout 200 of them for a single procedure . its crazy to be noping all rdtsc.

2) i tried ollydbg too. i stalled the target at oep (after sf3 has done its job of deteciting cd etc). then launched ollydbg and attached to active process. but when i hit F7/F8. bang. exception and eip points to some area in invalid region . guess their int1/int3 handler is global. u cant run *ANY* debugger when u have sf3.

well, i know one thing for sure. if some one can get sice working with sf3, then he can get it working with *ANY* protection there can ever be. i have never seen such a superb anti-debugging so far. hats off to the russians.

well, am trying now under 9x, since it doesnt haev that stupid int3 problem as under 2k/xp. i somehow must get sf3 not to detect sice. if someone has any suggestions, i am all ears . if everyone can throw in the detection shcemes possible under 9x . coz icedump really doesnt hide all as is evident from starforce3 detecting sice

thanks

best regards
pasha

Hats off.. maybe..
But I really don't think s-f should be considered a good protection solution.. especially when they start using undocumented tricks.

Example: (last game I checked in ~ feb 2003)
s-f script was decrypted in the protect.dll, when calls to some API functions were performed, you could see a:
mov eax,##
INT 2E
getting executed..

Now, it may be perfectly working, but on every update to your Windows nt/2k/xp machine, there is a risk that the protection stops working.. Big deal they are quick to update star-force? The game makers still have to issue a patch, which may or may not happen depending on the game. In the long run, you won't be able to play your own games like you want.

Another issue that I find annoying is the general widespread of system drivers in new protections. Star-force has 3+ sitting in your system dirs, safedisc 1, tages 2.. not the count every exe protector around.. I really think this will cause problem where drivers start competing against each others for access on low-level system resources (idt for instance).

/rant>

Back to debugging star-force, if you want insights on how it works, I suggest you get an older target (something using prodrv04), and debug the fu** out of it w/ softice.

Besides a) changing your debugging strategy
or b) reimplementing the driver without the evil-checks (that might be a while considering the amount of code that gets decrypted into memory buffers)
I don't see what you can do.

So, are the sys drivers decrypted BEFORE they get loaded, or do they decrypt themselves once loaded into mem? (Self- decrypting native system ring 0 code, hmm that would be extremely dangerous !!)

Perhaps , since they have to call the system drivers in some fashion, (DeviceIOControl, for example), you could create your own driver which emulates the correct return codes...

-niko

I don't see why self-modifying code would be so much harder or more dangerous to implement in ring 0 that in ring 3? Sure, if there is a bug in the decryption code you are likely to shoot down the operating system rather than a single process, but as long as the decryption code is not buggy I cannot see any problem? And it shouldn't be _that_ hard to write a non-buggy decryption routine, right? Please explain further nikola.


dELTA

iirc,
there is a "decrypt_code" function that is used when the authentification start, like a devio request saying "i'll start verification".. which then starts up decryption process, etc... when verification is over, the code probably gets encrypted back (or freed from memory, as I think they are now simply decrypting it in a buffer)

it is an interesting target to analyze, you should check it out, there are plenty of game patches around from which u can extract almost everything u need.

@delta:
I don't think self modification code is dangerous in drivers, but I do think crypted/decrypted code can be if not used correctly, mostly because the environment is multi-threaded. Since you never know when your threads will get cpu-time, the encryption/decryption mechanism could be stopped in the middle of it's execution while another thread that makes usage of the decrypted code starts to run.. you get to execute through half-decrypted code.. blue-screen.

However, I'm quite sure they have implemented a locking mechanism that prevents that.

Yep, that's what I meant, it wouldn't really be too hard to do.


dELTA

greetz gang

hmm, i just found yet another way to detect sice under 9x. well without sice, idt entry 41h dpl is 0 (0x8E), whereas with sice it becomes (0xEE).

the wierd part now is, if i set the dpl back to 0, under 9x, it causes a fault . but under 2k/xp this worx ok if i set dpl=0. this is crazy !!!

any idea, why it should fault on making int41 dpl=0 ? well it dies somewhere inside VMM

best regards
pasha

Hello pasha,

Well, somedays back i was reading about seh & all handling related stuffs. I did come across a very nice thread about 0x8E & 0xEE. Hope this thread (http://www.woodmann.net/forum/showthread.php?s=&threadid=3876&perpage=15&highlight=seh&pagenumber=3) helps understanding things much better about 0x8E & 0xEE .

Regards, sope.

greetz sope

thanks for the link. patching int1 dpl from 3 (0xEE) to 0 (0x8E) does not pose any problems. system remains stable.

but its only that if i patch int 41h from dpl 3 to dpl 0, the system crashes. also this is the case only under 9x, coz under 2k/xp this patch is stable.

best regards
pasha

Euhm well this is understandable, no? Without some ring-0 code, it would be too easy to defeat the protections.

I see a bigger problem with them tho.. some of these drivers give a user way too much access to the system (e.g. safedisc allowing you to grab pieces of protected memory).. I wonder how hard it would be to abuse these drivers to raise your priviledge on the machine!

But then.. windows security is already a joke, so I guess this is mood..

I just mentionned that in the long run, this is worth nothing.. crackers will just start developping their own drivers too..
-> more buggy protection drivers -> more blue screens



But just to show i'm not bullshitting:

quoted from the changelog of a s-f game:

File: wwii_fix_2ksp4.exe
Date: 21.August.2003

This file contains a program to fix a conflict between the copy
protection system used by World War II : Frontline Command and
systems running Windows 2000.

The issue only occurs with Windows 2000 systems which have been
upgraded to Service Pack 4.

--
you find that's normal and acceptable?

hello, nikolatesla20.

dld this attachment & enjoe learning R0 loading technique