Results 1 to 6 of 6

Thread: PACE interlok TPKD anti-debug tricks

  1. #1

    PACE interlok TPKD anti-debug tricks

    I've been trying to get some help on debugging (and eventually unpacking) a PACE protected target. This is not an iLok protected application but it utilises the PACE wrapper based around the paceilui.dll and TPKD.sys device driver.

    I made some progress into the heart of TPKD.sys (many many reboots and crashes etc) but I could use the help of someone with experience in this protection. Information is hard to find as the tutorials on this go back to the .vxd and were published in 2000. The posts regarding this protection on this forum are quite old also and nobody has posted anything conclusive.

    The first trick in Windows 2K/XP/2K3 is the check for ntice.sys in the system32/drivers folder. Nothing new here and easily defeated by returning an INVALID_FILE_HANDLE condition back from FindFirstFileA.

    I've then caught the first call into the device by stopping on deviceiocontrol. By tracing into this I have (eventually) found where I believe the anti-debug protection resides.

    It seems to me there are MANY anti-debug features in PACE. This is what I think is happening:

    (1) the TPKD device sets up an exception handler, it then sets the protected page bit and attempts to write into this memory area thus delibrately causing an exception. SoftICE captures this exception however and breaks so this immediately prevents the TPKD exception handler from executing correctly as SoftICE doesnt parse on this condition.

    .text:00011E88 push ebp
    .text:00011E89 mov ebp, esp
    .text:00011E8B sub esp, 20h
    .text:00011E8E push ebx
    .text:00011E8F push esi
    .text:00011E90 push edi
    .text:00011E91 mov [ebp+var_C], 88h
    .text:00011E95 pushf
    .text:00011E96 cli
    .text:00011E97 mov ebx, cr0 <--- start of enable page prot.
    .text:00011E9A and ebx, 0FFFEFFFFh
    .text:00011EA0 mov cr0, ebx
    .text:00011EA3 popf
    .text:00011EA4 mov byte ptr [ebp+var_8]
    .text:00011EA8 pushf
    .text:00011EA9 cli
    .text:00011EAA mov ebx, cr0 <--- restore page prot.
    .text:00011EAD or ebx, 10000h
    .text:00011EB3 mov cr0, ebx
    .text:00011EB6 popf
    .text:00011EB7 mov [ebp+var_B], 3

    (2) I can clearly see that the debug registers are being screwed around with which isnt good for SoftICE.

    .text:000113FF mov [ebp+var_1C], eax
    .text:00011402 mov eax, dr7
    .text:00011405 and eax, [ebp+var_10]
    .text:00011408 or eax, [ebp+var_1C]
    .text:0001140B mov dr7, eax
    .text:0001140E mov [ebp+var_1C], eax
    .text:00011411 push [ebp+var_1C]
    .text:00011414 push 0Ah
    .text:00011416 mov ecx, [ebp+var_20]
    .text:00011419 call sub_10876
    .text:0001141E pop edi
    .text:0001141F pop esi
    .text:00011420 pop ebx
    .text:00011421 leave
    .text:00011422 retn 0Ch

    (3) I think, PACE obtains the address to the IDT and redirects some of the table entries to it's own code

    Now, I'm hardly an expert on this stuff as it is all very new to me. In fact, I have played around in ring0 much until looking at this stuff. I need some advice from more experienced people here please?

    The issue for me is getting to the point where I can debug the application, finding the OEP, dumping and rebuilding the target will not be a problem, it's just getting past these anti-debug problems that has me scratching my head.

    If anybody can help it would be appreciated. Thanks.
    Last edited by Exocist; September 4th, 2005 at 20:31.
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  2. #2
    see your private messages...
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  3. #3
    Registered User
    Join Date
    Feb 2002

    some hints...

    hello, as I receive lot of private message (1 each week) about these protection, here are some infos :

    As far as I remember

    here what is happening with your pa*eap

    pa*ed application call 70060 Tp*d

    70060 tp*d -> decrypt tp*d services 70080, A0, B0, initialise structures, retrive some execution times and then instaure an EPA protection scheme on int1 and int 3

    the tracing is obfuscated by use and abuse of DR, imbricated calls, utilisation of three crypted sturcture to pass data between calls, some tricky push rtn etc etc ad nauseam

    but what is interesting is the EPA at the end of 70060

    the EPA protection scheme is responsible of softice reboot (softice use int1 on F10, F11, F12) and trick it on F8 who use int3

    pac*d application create two threads

    pac*d application call 70080 Tp*d

    70080 tp*d create three timeseed based on time that are sended to paceap

    threads decrypt on the fly based on results of multiple call 700A0 tp*d and 700B0 tp*d

    these service are short but very very tricky and can reboot your computer if timestamp? manipulation are not good

    one prg decrypted 70070 Tp*d patch back trampoline int1 and int3 and release handlers

    If you are just interested in dumping the program, here what some friends have done :

    find read and reread edgar barbosa tut on EPA protection

    0. make a good backup of your system

    1. prepare a bypass epa program for your computer

    2. launch your application, the paceap box appears

    3. run your bypass epa proggie

    4.debug and do your dumping

    I was just interested in reversing why t*p*d.sys was detected as a malware rootkit, I am now reversing less popular licencing scheme

    good luck

  4. #4
    thanks for the info lisa. This is the place with the most upto date info on interlok. Just wondering if the technique u suggested would be effective for mac too.
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  5. #5
    Registered User
    Join Date
    Feb 2002

    interlok for mac

    I was told that on mac the antidebug routine is more easy to bypass. The crypting routine seems more complicated than on pc.
    But I am not mac expert...There is somewhere a post here or on exetools about that and some exemples of mac cracks on peer to peer to disassemble to get clues.
    for Pc some clever reverser are now emulating the sys drivers response with a process like this :
    device IO control hook store response for 70060; 70070; 70080 and logs packets emitted by 700B0 and 700A0.
    then fake t*p*d.sys is built to respond the same without of course any crap.
    This work fine for some application but other require that int1 and int3 exception generated py the pa*ce*d application be handled by the fake driver.


  6. #6


    Thanks for the info Lisa. Lets see if the emulator coming is gonna get released! meanwhile, like you said, the crypting routine definitely is more complicated. The fake drivers are easier built on the pc, though.
    I promise that I have read the FAQ and tried to use the Search to answer my question.

Similar Threads

  1. How to get around anti-disassembly tricks on Olly?
    By Sunk in forum The Newbie Forum
    Replies: 2
    Last Post: March 20th, 2012, 14:08
  2. Collection of anti debug tricks
    By Harding in forum Advanced Reversing and Programming
    Replies: 4
    Last Post: November 18th, 2007, 08:58
  3. Windows Anti-Debug Reference, nice collection of anti-debug tricks
    By dELTA in forum Advanced Reversing and Programming
    Replies: 1
    Last Post: September 16th, 2007, 01:34
  4. morpheus anti-sice tricks
    By ignatz in forum Malware Analysis and Unpacking Forum
    Replies: 7
    Last Post: January 10th, 2002, 12:57
  5. anti disassembler tricks x86
    By dominator in forum Malware Analysis and Unpacking Forum
    Replies: 1
    Last Post: January 4th, 2002, 13:50


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts