View Full Version : interlok protection
LiSa
August 30th, 2003, 11:01
hello, I am currently working on an application protected with latest pace interlok protection.
Debbugger detection is made by a device driver TKpd.sys which currently detect softice, ollydbg and windbg and as soon as action is taken reboots the computer.
I read tshep essay about installshield 6 but his approach don't work now.
the TKpd.sys also perform runtime crc to prevent patching.
has someone a clue to help me bypass debugger detection ?
thanks+
LiSa
naides
September 1st, 2003, 08:28
Quote:
Originally posted by LiSa
hello, I am currently working on an application protected with latest pace interlok protection.
Debbugger detection is made by a device driver TKpd.sys which currently detect softice, ollydbg and windbg and as soon as action is taken reboots the computer.
I read tshep essay about installshield 6 but his approach don't work now.
the TKpd.sys also perform runtime crc to prevent patching.
has someone a clue to help me bypass debugger detection ?
thanks+
LiSa |
LiSa or some one else.
Could you PM the name and/or URL of this InterLok and TKpd.sys protected app?
Thank you.
OHPen
September 1st, 2003, 13:32
me too , pleaz,
OHPen@gmx.de
dELTA
September 2nd, 2003, 07:01
For everyone wondering where the driver reversing posts in this thread went, I just started a new mini-project about this subject, and moved them to that thread. It can be found here (http://www.woodmann.net/forum/showthread.php?s=&threadid=4992). You are all very welcome to follow, join and contribute to this project!
dELTA
maintain
September 5th, 2003, 02:43
set only one bpx at a time , and unset immediately after it breaks, then set new bpx and so on
do this until app is unpacked in mem then dump, sort reloc, and sort out any api stuff still remaining
demo stuff is done via a checktoken pace api which returns true/false, sometimes the pace uses the resources of the paced file to decrypt at runtime im sure you can figure a way around this
alternatively u can hook kernel api and use this to dump without even using debugger
maintain
September 5th, 2003, 02:50
i forgot to add
DONT TRACE THROUGH THE APP !!! one bpx, unset, next bpx, unset
no F7,F8 etc
LibX
September 28th, 2003, 09:00
Check astalavista.box.sk 4 my patch

After u apply the patch first start softice otherwise the program will give u a bleu screen
LiSa
September 28th, 2003, 14:14
Hey LibX,
A patch??, for the TPkd.sys ?? for an application ? tell me more...
I don't want the pace protected application (You can use UCF unpaker to remove pace shield then easely
patch the paceuilui calls and restore limitation.=)
What I want is control and emulate the Tpkd.sys as we already do for dongles.
I explain now my tpkd.sys trace results. does someone experienced with such a protection?
i quickely found the TPkd_internal_dispatcher and put a bpx on it.
the tpkd.sys is first called by the pace dll with deviceiocontrol with 70060 as control code
After browsing this control code ([irpstack+38h])dipatcher lead us to sub_10A32.
starting from this point we enter a massive call imbrication where each call leads to an another call
with a good control flow obfuscation, look a this sample:
.text:00011286 sub_11286 proc near ; CODE XREF: sub_11276+8p
.text:00011286 55 push ebp
.text:00011287 8B EC mov ebp, esp
.text:00011289 68 7C 25 01 00 push offset sub_1257C This will be the call n+1 location
.text:0001128E 6A 01 push 1
.text:00011290 B9 10 C2 01 00 mov ecx, offset Tpkd_Control_Object_unk_1C210
.text:00011295 E8 02 F6 FF FF call Hide1_sub_1089C
.text:0001129A E8 1B 06 00 00 call MACILACI_sub_118BA
.text:0001129F 5D pop ebp
.text:000112A0 C3 retn
.text:000112A0 sub_11286 endp
then, at the end of MACILACI_sub_118BA :
text:000119E2 6A 01 push 1
.text:000119E4 B9 10 C2 01 00 mov ecx, offset Tpkd_Object_unk_1C210
.text:000119E9 E8 0C EF FF FF call show_from_hide1_sub_108FA show the n call location
.text:000119EE 89 45 FC mov [ebp+var_4], eax
.text:000119F1 68 3C 1E 01 00 push offset sub_11E3C this will be the n+1 call location
.text:000119F6 6A 01 push 1
.text:000119F8 B9 10 C2 01 00 mov ecx, offset Tpkd_Control_Object_unk_1C210
.text:000119FD E8 9A EE FF FF call Hide1_sub_1089C
.text:00011A02 FF 55 FC call [ebp+var_4] : offset sub_1257C !!!!!
.text:00011A05 5F pop edi
.text:00011A06 5E pop esi
.text:00011A07 5B pop ebx
.text:00011A08 C9 leave
.text:00011A09 C3 retn
at the end of the whole call chain is the last call [ebp+var_4] :
.text:00010994 Finish&go_back_sub_10994 proc near ; DATA XREF: sub_11E3C+89o
.text:00010994 ; .text:0001850Bo
.text:00010994 55 push ebp
.text:00010995 8B EC mov ebp, esp
.text:00010997 5D pop ebp
.text:00010998 C3 retn
.text:00010998 Finish&go_back_sub_10994 endp
during this call call lot of weird things are done prodected by simple SMC or
push code on stack_loc / call stack_loc
basically
out 70,80
in ah,71
out 70,0
which means retrieve RTC second (RTC1) in al with NMI disabled (Am I right???)
then
in al, 21
which means retrieve PICW1 status in al w (Am I right???)
after that a new TPkd_control_object is created
an sidt retrieve IDT base
the int 1 and int 3 are patched by a crude jump to tpkd code at their beginning :
8:80465A96 jmp sub_11252 !!!
after that again :
out 70,80
in ah,71
out 70,0 to retrieve a second RTC : RTC2
then RTC2 and RTC1 are compared and accordinglely one of the following is pushed for call n+1
sub_118FE (endless loop, freeze application) or sub_11FFA (mysterious) or sub_11ac2..
with softice on (so we are detected..) we take sub_11ac2
basically this sub
out 70,80
in ah,71
out 70,0 to retrieve a third RTC : RTC3
int1 handler is putted in dr0
int3 handler is putted in dr1
dr2 received 1f85c unknown loc
dr3 receive RTC1RTC2RTC3
and dr7 is put to 70703 wgich is not good : break on int1!!, doing that burn softice to death
What I did is :
confuse TPkd with int1 and int3 handler and clean dr7 to protect my softice
then.... I falled into endless_loop_sub_12500
I patched it to Finish&go_back_sub_10994 and I land again in deviceiocontrol with 70080 as service code
the Tpkd dispatcher then go through a dummy proc which lead to a page fault
I redirected the flow to the tpkd_int1_handler_sub_11252 but I crash my computer again (maybe the stack
was not clear or an important flag was not set)
can someone tell me if I am on the right way with this intersting drivers
bye
LiSa
LiSa
September 29th, 2003, 12:23
Hello Libx,
your patch is for TPkd.vxd (A345 size) ie version 2, now the Tpkd driver is .sys and version 4 or 5 (DBB1 size).
So your patch can not apply
Also this patcher Nop the call [ebp+var4] inside macillaci_sub and RET the keyboard reset subroutine. Things have changed, this is not enough now....
Powered by vBulletin® Version 4.2.2 Copyright © 2018 vBulletin Solutions, Inc. All rights reserved.