Hi !!

This one seems to be for optimists, dont know how protected files look, but demo version of this protector seems very atractive for those who hasn't what to do everal days

hxxp://www.anticracking.szm.sk/svkp_setup.exe


Just one example how he executes APIS

call [xxxxxxxx] ; xxxxxxxx=004xxxxx

then goes in high memory, there he emulates everal first instructions of almost each API, and after that continues in real API there where he stops in emulating (this do with jmp 7xxxxxxx)


wish you luck

*yawn*

NO more new ideas on protectors any more....

Latest Arma uses boring Fusion trick: they decrypt code in security DLL in certain places just before it executes, then run it, then re-encrypt it. Easy to fix...

*yawn*

-nt20

I think not the unpacking is the hard thing, the catching of the imports seems hard. But at all the protection is easy to defeat.

I'm not so sure it would be. Sure, emulating the first few bytes of most API's will cause current import recovery utilities to stop working, but if every import still calls the original code via a JMP, then it will not be that difficult to write a plugin to resolve the table as the addresses will still be quite unique. What protectors should be doing now is copying entire functions from the system into some of there own memory and running it entirely from there. This will then mean we'll have to use IDA-style signatures to start recognising the imports and will be much more fun to decode.

I wrote this with a very old version of svkp.. (packed sepp)
It uses this routine to get VirtualAlloc's address and then it allocates some memory in order to paste this routine there, if I remember well..


Hope it helps.

Api emulation:
--------------

This "disassembles" some part of executed api, it emulates it until
it finds an opcode not-identifyed, then it lanunches the api normally.
To launch it, writes api's destiny address at the code (next to a byte 0xE9 that
is a far jump), then restores registers that are in a table and executes the jump.

First it checks for an "int 3" (0xCC breakpoint)

Checks structure is like this:

; Being ESI a pointer to the api..

; SEH

inicio+6759 CMP AL,64 ;opcode uses fs: ?
JNZ sigue
MOV AX,[ESI] ;esi points to next byte of the api
cmp1: CMP AL,FF ;there is a push dword fs:[reg] (FF indicates that
is a dword)
JZ op1
cmp2: CMP AX,2289 ;648922 mov fs:[edx],esp
JZ op2
cmp3: CMP AL,A1 ;there is mov eax, fs:[address]
JZ op3
cmp4: CMP AX,2589 ;there is mov fs:[address], esp
JZ op4

jmp next

op1: jmp cmp3 ;- not implemented -
op2: MOV FS:[00000000],ESP and emulates next instruction
op3: if address == 0 -> MOV EAX, FS:[0] stores eax and jumps
to next emulation
op4: MOV FS:[00000000],ESP and next emulation..
next:

; NOP

inicio+6773 CMP AL,90 ;there is a nop?
JZ begin

; PUSH REG

inicio+6794 CMP AL,50 ;from 50 to 57 are pushed regs
JB sigue ;look if the byte is inside the range
inicio+67A5 CMP AL,57
JA sigue

inicio+67B9 SUB AL,50
PUSH DWORD PTR [EAX*4+EBX+00000A1C] ;here are the registers
;stored by a pushad
JMP begin
sigue:

; PUSH DWORD

inicio+6947 CMP AL,68 ;there is a push dword?
;if there is: PUSH [ESI] add 4 to esi and begin
;another time

; CALL

inicio+6976 CMP AL,E8 ;- not implemented -

; MOV EBP, ESP

inicio+698D CMP WORD PTR [ESI-01],EC8B

; SUB EDX, EDX

inicio+69C4 CMP WORD PTR [ESI-01],D22B

; PUSH BYTE

inicio+69FE CMP AL,6A ;pushes the byte and follows..

What bad protectors will start doing rather is emulating entire API calls. The point of having DLLs is so each version of Windows can have independent libraries with calls that do the same thing with different code. The protectionists would have to have every single version of that API call Microsoft ever wrote and compiled and distributed and have a way of identifing which one to use. This API emulation makes too many assumptions and is dangerous and will start causing more problems not to mention with signatures its still defeatable!

Snatch

I think we can say that import redirection is does nothing to really hinder an experienced cracker.

-nt20

Hey!

I downloded that file, & it says SVKPv1.11

Am wrong??

this version we know since published, Soldat seems not knows about svkp??

I was thinking more along the lines of loading the system dll in the unpacking phase and grabbing some of the routines that way - so you don't need to even store one version of the dll as you'll be pulling it all from the system. This is not perfect, as experienced crackers can see what is being copied where, but it's certainly stops Mr Average with his copy of ImpRec and LordPE.

I'm here for a year, and since then I haven't seen it was discussed about svkt (I didn't search) , this one was newsis on anticrack. Maybe is improved, I don't think is older than one year.

Have any one realized that ImpRec can't recognize svkp process?? or that's only with me.

well they finally added api redirecting , oh boy, i must buy it

PS. Do you know any application protected with svkp (except svkp

As far I did with protected demo is to make this dump. But this is just for nag screen appearing, maybe funny, but gave to me some conclusions about working (will crach after that).
He has one routine that reaches E8 (call) and after that erases previous executed part. But set further.

Here it is, if one find interesting to try. Any one has something another ??????

Select "Enable Debug Privilege" in Imprec options and restart Imprec


Apiwrapper is poor. Only inserts garbage jumps into know opcodes of api code. With "Trace Level1" and my plugin all api calls are resolved except GetModuleHandleA, GetCommandLineA and Exitprocess that are intercepted by Svkp

Gaia

Yes you are right about redirecting, ASPr has better redirection

Thanks for Plug-In

interest is maybe that after msg box the code is not unpacked and the unpacking process (or jmping to apis?) continues looking at attached..

http://www.geocities.com/attached_pic/

Soldat, SVKP.EXE's date stamp & you will know, when it released.
So then you can agree, "NEW" is incorrect to word for ws_printf..

Now some my findings about SVKP.
The Hardest version of SVKP is(was) V1.051.
It conteins quite interesting drivers(VXD & SYS),
which also must be reversed, so very interesting game is..

But soon after V1.051 came V1.11,
which conteins same fake drivers, as SEPP!

I THINK, author sad to himself:
"shit, why I published my hardest work in demo, which can used for protect??"
..& he removed V1.051.
***

By the way, that hard version of SVKP.VXD did crash W98se.
(so firstly I unpacked on XP)
I notified about crash also from one other guy.

After I also recovered crash-place on W98se & corrected VXD!
(so unpacker also can correct protector & force it to work
But(2) after some time I reinstalled W98se & this crash now NOT happens!
Very interesting fact! Someone also had such problem?

Hi Evaluator

Can you give some explanations. I'm not armadillo man, but realized that this one works in armadillo spirit. He has one encrypt/decrypt procedure, and each time when he wants to execute some part of the code he asks for its service, but before he decrypts he checks for its encryption. After decryption he encrypts it again

I tried to play little, to prevent again encryption but was caught with encryption checking. Was difficult to manage for short time. Did you know something about this or you managed for this time everything with dll

Is dll really necessary ?

Thanks for replay

I think the dll is not needed cause i packed my notepad with the encrypter and successfully unpacking it - runs without any dll. Im stucking with the way finding the OEP.

I didn't think it was needed for every file proteceted with this packer.

Just for svkpdumped.exe. For its functioning. Of course is not needed for files produced by packer.

As I can remember, I did following:

1.Go to encrypted-section start;
2.decript it & when execution returns to code,
3.Go to next encrypted-section. etc,etc..

yah, maybe I remember wrong..


DLL i done just for be clear.
This function in original SVKP copies from higher memory
registration string in data section:"Unregistered Demo Version!"
and sets eax to 1.
However, dump already conteins that string, i done only
mov eax,1

of course, you can do anything you want(patch..)

Hello Everyone,

First i need to thank Gaia for shareing the dll plugin with all of us.

How i find oep for svkp v.1.11 packed apps. Open winhex & select the target. Search for below bytes.

EB 0A 58 EB 01 48 40 EB 01 35 FF E0 61 EB 7C EB 02

On FIRST occurance notedown the offset, for my protected "notepad.exe" it was 0x10720378 we add 0x1AFA (0x10720378 + 0x1AFA) = 0x10721E72. Close all things.

Load the traget back set a bpm 10721E72 x let it run. On the break F8, F8, F8 [3 times] now check EAX = OEP

Now, in case of "svkp.exe" the protector itself we take the FIRST occurance of the above pattern outside the code section range. i.e. map32 svkp we know it starts 0x401000 + 0x389F0 size = 0x4399F0 take first occurance after 4399F0. On my machine it was 0xD7C03B0. So i added 0xD7C03B0 + 1AFA = 0xD7C1EAA. After bpm on it we reach & then F8, F8, F8 we get oep = 0x401000 which can be confirmed from evaluators excellent work. Thanks evaluator for shareing the file

There can be different ways of finding it. If u have better method of finding it please share it with all of us.

Regards
Sope!

1. i3here on
2. In Syd's loader Open, then Execute
3. Bpmb esp-4 w (esp was 12ffc4)
4. Breaks until reach 401000

This was discussed by Crusader, and was his trick

nice thx for sharing your knowledge

in olly use mw 401000,401004 for example works perfect with gaias great plugin. Break at the second access on REP. and go further with F7 until u reach 401030


of course when you break at mw 4011AB,4011AC you will sooner find the oep at 401192 after the nasty nag finally i need some unresolved Api entrys..

targets with this baby injected...

Newsbin Pro & TweakXp Pro both latest version

if i'll find more i'll tell you

NewsBin 4.1, 99% rebuilded

nbpro.exe - 1.187.840 bytes

OEP - 46A907h


All thunks resolved except:

4A41B8h, 4A41BCh, 4A427Ch, 4A42E4h, 4A43C0h, 4A43D4h


With Sice and Zen:

4A41B8h - GetCommandLineA
4A41BCh - ExitProcess
4A427Ch - GetModuleHandleA
4A42E4h - unknow (is an api related with TerminateProcess)
4A43C0h - GetVersionExA
4A43D4h - GetVersion

I need more study to get true api of 4A42E4h....

Gaia

ok, today i DLD that NewsBin4.1.
So again I see strange useless VXD & SYS.
??

If hard-type drivers discarded(probably for incomatibility),
why is need to keep this fake drivers?

Oke, whats new here:
1. program's CODE is compressed (JC).
2. from OEP (lets be 46AA28) ripped 58h length CODE & converted to PSEUDO_CODE!
heh! big workz done, my congatululus to SVKP Author
i repaired 57h.. (eh, one NOP..), but prog workz anyway.
Also this PSEUDO_CODE can be attached at free space and repair not need.
(but i'm crazy PPG).
3. SVKP api not used
4. there are 7 crypted sections, which u can decrypt as i suggested.
5. 6 Kernel's api are quite emulated:

107 000A41B8 03502A04 0000 KERNEL32.dll GetCommandLineA
108 000A41BC 03502070 0000 KERNEL32.dll ExitProcess
156 000A427C 035033DD 0000 KERNEL32.dll GetModuleHandleA
182 000A42E4 03503058 0000 KERNEL32.dll GetCurrentProcess
237 000A43C0 0350B832 0000 KERNEL32.dll GetVersionExA
242 000A43D4 0350B4AD 0000 KERNEL32.dll GetVersion

hey, GAIA!

what file you have??
I DLD today, nbpro.exe is 861184 byte.
installer nb410.exe is 944321 byte.

Hi Evaluator

nb410S.exe (setup) - 1.253.431 bytes
nbpro.exe (main exe) - 1.187.840 bytes - File version: 4.0.0.4

Different sizes that your files, but emulated apis are at the same address....my OEP (46A907h) are 100% OK, no ripped code in my version...STRANGE! I download the file today but I will do again now

Gaia

I redownloaded NewsBin......now file have lastest SVKP (same sizes as evaluator)

"bpm esp-4 w" trick to find OEP is not valid in this version

Ripped instructions at OEP are junked and muted (xor edx, edx to sub edx, edx for example). Good work in this aspect Pavol


Gaia

Hello evaluator

Can you please clarify my small doubts. Target nbpro.exe 861184 bytes.
Is the below decryption routine you mentioned as decript ?
In my case from 0x46AA28 to 0x46AA80 i have 0x90. You hinted for repaire it i just want to clarify is the bytes missing or stored somewhere or we have to understand something. I set different types of brk pt but it does not seems to get read even after the program executes.

Regards
Sope!

More OEP code ripping?

Do all protector authors just copy each other now?

-nt20

Hi Evaluator, Gaia and others

I found the same as you about IAT, and unresolved 6 APIs, but couldnt find them.

Can you explain the method you did that. My method to find other APIs was to patch API redirection procedure

I did the next

3332F3E JMP 46AA27 (FIRST NOP)

46AA27 MOVE DWORD PTR [EDI], EAX
46AA29 JMP 3330ECD (THIS IS WHERE JMP 3332F3E) Should be.

After this IAT was clean except six mentioned APIs. But with tracing them I was seems caught though exceptions.

Last API was 000A47C8 oledlg.dll 0008 OleUIBusyA

So I'm asking for 6 unresolved APIs

They are ripped, there is some stack acrobation before reaching 46AA80, but I don't see too what's going on before

So appeal for clarifying

It certainly seems that way. One author comes up with a new and interesting way of protection, and as soon as other people (eg. us) find out how it works, the other authors lurking in these forums quickly add it to there own protection software and release an update, rename the feature, call it "unique" and then offer a discount "for a limited period only" in an attempt to bag a few more sales.

yah, guys, seems you want force me for force explanation..
OKee.

1. you can find info
about SVKP's encryption block Start&End in SVKP's pacage!
(or use your eyes).

BLOCK start is 21 bytes long:

near call E800000000;
far jump FF25[address of decryptor];
blockID-byte + empty bytes: 10 byte long;

then is block himself;

BLOCK end is 16 bytes long:

near call E800000000;
far jump FF25[address of cryptor];
blockID-byte + empty bytes: 5 byte long;
***

So you will first analyse dump & determine all crypted sections & their start address;
[Very helps you, if you make first dump directly after SVKP decrypts exe,
[& second dump on OEP, so using some comparision tool, You easy find start addresses]

Now we again go in debugger, stoped at OEp, & change EIP to 1st start address;
Then you can:
A. trace into code, while it decrypts & then returns execution to decrypted code;
B. or for lasy guys: BPM EIP+15 X, so debugger breaks on decrypted code.
C. dont go into decrypted code, but now change EIP ti NEXT crypted-block's start address;
so do until you decrypt all sections & then dump happy proggie

END of 1.

2. seems SOLDAT has problem with SVKP's RDTSC future;
Here is descryption of it:

1st RDTSC;
save EDX in EBX(or ECX);
junk code;
2nd RDTSC;
SUB EDX, oldEDX;
SUB EDX, 2;
now if EDX > 0, you are catched;

e.g. IF after executing two nearest RDTSC(Read processor's TimeStampCounter),
newest RDTSC's EDX will +2 greater then old EDX, SVKP catches you.

So you need correct 2nd RDTSC's EDX to match with old EDX. OK?
(or use predefined EDX each time after RDTSC)(or do anything..);

END of 2.


3. PSEUDO_CODE

I had read about PSEUDO_CODE in STARFORCE-CDprotection, but not meet until now.

PSEUDO_CODE is method of doing same job as real code, but with other group of instuction.
Purpose: so you can't easy identify code.
(e.g.is ripped code of imported function as in STARFORCE, or is ripped OEP code).

But PSEUDO_CODE is normal working code, so if it is PSEUDO-OEP-code,
you can just attach it at free space & set EIP there.
Of course, you need some-how understand it's start.
For SVKP case, original ESP is restored & you can think, somewhere there is Start.

Better will for your skills, to understand & rebuild real code.
Also very helps us this: look at other EXE compiled with same compiler &....
I just looked at ________'s start code & recovered that last missed instruction!

So now I can say, OEIP is at 46AA27 & all ripped 59h byte code is
absolutely ________'s identical(except direct addresses)!!!

END of 3.
*********

EXERSIZE:
paste(replace) attachment in fixed dump of nbpro at .svkp section start(VA 00119000h)
& set EIP 0011B9F7.

Now rebuild true code> Length 59h

PS. maybe I will make PSEUDO_CODE crackme!?

Thanks for your replay. I caught decryption routine and after that found routine that erases with nops previously decrypted part.

I don't know if you thought on this when said about encryption.? Its start was on 3456201

Never mind, if there is another one will find it.

But did you notice that packer doesn't work as should. Try to press Register nbpro ....or what is exactly. And then do it again, he will crash. It is because he erased some previously decrypted part, and after he backs on that.



Soldat has problem with many things.....


regards

don't care about erasing..

Hi

I found seven pairs of places where decrypt/encrypt procedures are being called.

Several first bytes have to be replaced with nops, in decryption case 16 of them and in encryption case 10 of them.

How do you explain that holes.

They must be marked during program compilation with some signs so after when Svkp did his job (when exe is made by copiler) he could erect the obstacles on that places.

I saw that in Ultra Protect. But dunno if here Svkp has option for their automatic setting or you have to do that manually.

Hi,
i've been trying to unpack certain SVKP protected app for 2 days now but unsucessfully :/ Since i'm very much of a newbie in unpacking bussiness i think i done a good job so far but i need some help now :/ I searched high and low but didnt find answer to my question becouse all information i could find is outdated. Seems noone has messed with SVKP and wrote about it. So, here is test i posted on exetools board (but didnt get a reply)
---------------------------------------------------------
Hi,
I'm having trouble with imports too :/
I've been trying to unpack certain app for whole day now. I got dump, eop, i think stolen bytes are good but program crashes. Tracing through exe that crashes i noticed that i didnt resolve one (for now) import correctly. Now i attempt to resolve it correctly by debugging packed app. I run packed app, break on place where this function is called and trace into it. It was very weird. Seems that whole function is in packer code. It never jumps/calls real dll. Btw this is kernel32 function. When function is executed only eax changes and before function executes eax is address inside code section (something like 4xxxxx). BUT result doesnt seem to be parameter dependent. Here is some code (this is some really obfuscated shit):


and goes on like that.... and then:

where EAX is address in other part of packer code :/ This is all that happens there:

So eax gets value of [EBP+1AB87]. What API could this be? It's really annoying :/

I answered my own question today. I found a better place to hook to api table and resolved this one. Now i have another API entry problem :/ I'm gonna try to sove this on my own but if someone has a quick answer please post it here. This is user32 function. I tried resolving it in several ways and ended up with two possible (but in the end wrong) results: MessageBoxA and RegisterWindowMessageA :/

Me again :/
Still struggling with same import problem :/ Here is how it looks:

When packer decrypts IAT i see MessageBoxA in place where correct import name is written for other imports but when i run it this import is called 2 times.
First time program runs this import it works like a charm but second time program crashes. So, what do I do? Well, i debug packed app and check this import out. Both times packed program calls this import and both times it works but here is a weird thing. I break on import, put breakpoint on User32 code section and i get in RegisterWindowMessageA. Second time program calls this import I do the same. Put bp on User32 code section and, see this, program DOESNT break ANYWHERE in User32? How is this possible?
Boards seems to be empty last days. Weird

btw. this is Borland C++ program. I'm also having trouble with one VB prog but i'm having a few more ideas i want to try with this

Hello Nikola and others,

You might find this program i wrote useful. Since i've only worked on 1 svk_p target, i'm not sure how well it works on others, but it should point you in the right direction.
Please pm me any svk_p targets you find!
I've also included a sample dumped, crippled iat.

Have fun!