Hi! I'm pretty lamer so you may laugh loud at my questions.

many years ago i studied z80 cpu, later i migrated on 8086...

First serious protector i'm interested in is SF-3. At first all goes OK: exe's EP contain jmp protect_1; but first protection dll is loaded. it unpacks(or decrypts) itself, checks for debugger running, checks for module integrity, loads attached to end of dll resources. And one of them is p-code instructions with some obfuscation. This resource is copied to protect_1 address, so when exe JMPs PROTECT_1, actually it jumps P-CODE-ENTER. There indeed two enters: for JMP PROTECT_1 and for CALL PROTECT_1 I suppose (it swaps P-CODE-ID and RET_ADDR on the stack). ALL IMPORTANT APP CHECKS ARE MADE IN P-CODE. By the way p-code-id is PUSHed before jump to interpreter.
At p-code-enter it makes some stuff i didn't understand (in cycle dec esp, and test [esp]) and it seems to throw exception. But that's not the point. Most interesting is P-CODE EXECUTION. I LOVE IT. Instruction follows next instruction via JMP ESI (regular) or JMP EBX (obfuscated blocks). It makes some stuff inside. It's not difficult itself and decompiler writing wouldn't be too hard, but HERE GOES C.R.A.P. into my face:
- prot is using drivers and they don't like if i try to use INT1, INT3. so bye!bye! ring0 debuggers;
I wrote little app that creates EXE suspended waits for VM to load. EB FE at first JMP ESI. And then tries to decompile p-code. But it's too SLOWWWWWWWW. Maybe because i use SuspendThread, ReadThreadContext, ResumeThread sequence? Maybe it's better to inject my exe into prot exe and do everything inside? i tried but my programming skills are far from desired.
When decompiling this way i see about 5 instructions logs immediately then pause and so on. Finally some branch changes and there is wrong jump. I tried to trace it in ring3 debugger and i traced about 200 vm opcodes but there still was no light at the tunnel (then i realized that VM is not as easy as imps reconstruction).
I needed some help. Google gave me link to rld.re.tools (with trojan.downloader inside the zip - thanx Guys from rld make much bigger work than i did. But their logger wasn't for my version (i suppose). And it logged "sf3.sys not found" (well i hadn't sf3.sys in my package but trojan.downloader is much better
Phrases i liked: "vm exit is easy trackable" - how?
virtual file system wasn't at all (even driver)

QUESTIONS:

1. why they use RegSvr32 with their dll. Does it inject logger DLL into protected process?

2. can someone explain vm_entry hooking process

3. how they trace vm. do i necessary need sf3.sys driver?

btw why rld-guys don't write something general about them? for example i would like to know are they guys at age <=25 or they are >60 invalids. what are countries they living. sure if it's ok with theirs security. i dont even need names or e-mail. some general info

NOW YOU MAY LAUGH

yes





you mean vm_exit, right? (vm enter hook = hook #1 export of protect.dll)

sooner or later the vm is done and has to exit. the code to exit always looks like
pop eax
add esp, eax
popf
popa
retn
so just scan the vm section for this and place a hook there (the vm also exits to OEP like this)

but since the vm is crcing itself while running, placing a hook (and thus breaking several crcs) might led to crashs







they just hook all vm opcodes and log when they are used, no idea what sf3.sys is tho




btw, newer starforce versions arent as hard to debug as those old versions since they dont use int1 and int3 handlers

Thanx 0rp! Now i'll try to use this info.

And.. You're right.
some sf4.7 and sf5 i disasmed recently really got no int1,int3 hooks. differences i've found are:
- they don't use internal unpacker @ protdll init. instead is UPX (not always) and appending resources
- vm now supports 64bit registers
- some vm opcodes are SPLITTED by jmp in the middle
- much more high-level code and exception handling (maybe i'm wrong)
still interesting..

int 3 hooks are typically used for the virtualfile system, this is evident if you check the first bytes of createfilea etc and see if its a 0xCC

yes, and in newer versions (younger than 4 years) they use a filesystemfilterdriver to redirect IOs to their container

FEEL FREE TO CORRECT ME

1. I'm wondering where the key is stored on disc. Someone said it is int 16th sector. But for know I couldn't find it. Key existence on the disc is fact, cause when I got original CD it started w/o asking key.

2. Due to monitoring I've found that cd-key and hardware codes are stored in registry. And registry call retaddr points to VM. But I think protection can't measure angles between sectors in VM cause it will be very slow and maybe not very effective. Are checks are made in VM?

not yet analyzed vm-opcodes in full and still got no instruction logger so there are little question about vm operating

3. When VM have results of check or failed because of cd not inserted or disk is wrong I SUPPOSE it brings results to PROTECT_2 export proc, where it shows GUI message or starts app. Faking results surely makes only lovely GUI message like "You're starting app with test key.. not for commercial use" and then it hangs have someone detail of what is protect_2?

4. I've tried to monitor APIs of prot-dll (cause it's almost useless to monitor protected exe) but nothing found. OK, so where is somthing kinda GetVolumeInformation? is my monitoring bad or there is way without APIs to get disc letter. If it is I hope it's not in drivers cause right now i can't disasm drivers pretty good.

5. There are vm-opcodes like other but with INT3 inside. It takes eax, [vm_reg_XXX] and then INT3. i feel it's like good old DOS days with "mov ah, 1; int 21h" but don't know exactly. What is inside INT3 handler? And inside INT1? Or where I should look for it.

6. In RLD docs was written that VM_ID is matched later and trick is executable header. What this matching looks like?

7. Drivers.
helper - ? got some crypted funcs (it looks like helper and protection driver are core of all protection, and VM sure

protection driver - analyzed a little. it has some crypted funcs. there are vmware detection, checking cs reg (in kernel or not). and that's all for know other code is a little obfuscated. it isn't too hard but i really got no time now. does anyone got info?

sync - ?. I know only it deals with scsiport.sys. why? someone said it hooks some exports? why?

btw. is there GOOD X86-emulating debugger? it would be much easier to reverse drivers and viruses i suppose. all i can find are plugins but they aren't full featured. (in good old days there was CUP386 - a great wonder

how does protection detects daemon (i hope there is something except banal d347prt)? I got no idea.

also i saw drivers enable and disable write permission in CR reg. what for?

SORRY IF MY QUESTIONS ARE TOO LAME. BUT THERE ARE MORE

im no sf cdcheck expert. all i know is, that it is angletiming based, no idea what sfkey or disckey exactly do

in the sf generation you are looking at, they had the sync driver to do the cdcheck itself, which was triggered by the kernelmode vm. and they didnt use windows kernel api (IoCallDriver and co) to operate with the cddevice. instead they completely bypassed windows (and its hal) and did everything on their own using the BIOS (only IDE drives). that way they had a bulletproof and absolutely un-emuable cdcheck

the int1 instructions you noticed are another hardcore anti trick they used in this generation. int1 in usermodevm switches to kernelmodevm, int1 in kernelmode switches back to usermodevm. both, usermode and kernelmodevm shared the same vmram, and they switched alot. and dont try to replace/hook/modify the inthandler. the kernelvm will detect it and bsod you in no time.

starting with sf4 they got weak. they dont use an inthandler anymore (microsofts doesnt allow it anyway), so they use devio to switch between user and kernelvm and the cdcheck uses windows now (i think) and they dont switch that often anymore

starforce keyless = the key is stored in sector 16 [0x371] or near that area...
the keyless thing is basically used to bypass the 'request cdkey dialog' thing, if you hold down ctrl+shift on a starforce keyless program you'll see the dialog...

Guys, If someone got time could you tell me why this app cant be logged by RLD bin logger.

SF version of this app is 3.4.50.1
rld.logger as i saw can log this version
there is option sftype in theirs sf3.conf.
it can be sf34, sf34_nodrivers and sf35. I tried all this.
But it still doesn't work. Logger just says 'dll initialized.. owning' and that's all. Where is my stupidity?

http://depositfiles.com/files/6949555

P.S. rld logger avoid of logging app contain in path ctl.exe. why?

Well if some one wants to dig prot_drivers: u can download it from

http://depositfiles.com/files/7044408

There are protection and protection helper driver. There are some packed func in these drivers. I made two little unpackers for these only drivers. You must enter addresses of packed funcs in offsets.txt, and start decoder.exe. It unpacks to folder unpacked. And here you can dissasemble it.

please do yourself a favor and RE newer starforce
its less pain