View Full Version : SoftIce and tElock 0.92a

October 8th, 2001, 05:48

I have packed a progi with tElock 0.92a and i made a inlinepatch. But is only working, if Sice is not loaded, or Frogsice is running.

I have found two (known tElock 0.90) SiceChecks and i patched them; (Frogice Code 07, code 02) ....and there are 2x int3 (Frogice Code 00)

There is a SiceCheck that i was'nt able to find and bypass, and the Progi crashes, because tElock find SoftIce. (sorry for my english )


Ich habe ein Progi mit tElock 0.92a gepackt und einen Inlinepatch dazugemacht. Patch funktioniert aber nur, wenn SoftIce nicht geladen ist. Ich hab zwei SiceChecks entfernen können( FrogSice: Code 07,Code 02), finde aber den dritten nicht.

Frogsice zeigt noch zwei int3 an, Code 00; damit kann ich aber nicht allzu viel anfangen.

Meine Frage: Wo erkennt Progi noch, dass SoftIce am Laufen ist? Es dürfte etwas mit den INT3 zu tun haben, wo FrogSice Code 00 ausgibt. Wie kann ich diesen SiceCheck entfernen? (Progi entschlüsselt sich falsch, wenn der noch vorhanden ist)


October 8th, 2001, 10:55
I'm sorry but you didn't translated your question in English, you should edit your message (if already done, do not consider what I said)



October 8th, 2001, 11:11
He is asking how to locate the (and remove) the int03 checks to locate Softice. He is also asking if anyone knows where in telock these checks are hiding, so as to make it easier for him to find them, plus how one removes them.

Having never played with telock, I can't say where in the code, they're hiding. I usually just trace the code, till it either takes a wrong turn, or till I find the int 3.
Anywho, search Tsehp's mirror, and look for tut's on packers, that use anti-sice. That should give some good hints.


October 9th, 2001, 10:12
i haven't checked out latest telock version like u, but maybe u know that iam one of the authors of the good old tEunlock...

so he is using this int 3 for causing an exception... this exception must occour! he has an handler for it... (go and fetch jeremy gordon's documents about structured exception handling in win32!)

u need to understand what exceptions are and how coders use em to write anti-debugging code...!
then come back and try again!

ich weiss dass dir das im moment nicht viel bringt aber saug dir diese docs! und versuche zu verstehen was da abgeht, dann wirst du auch verstehen warum du das nicht einfach wegnoppen kannst!


October 10th, 2001, 01:58

in tElock 0.90 i have found 2 Sice check, int3 (with magic values) and int68. I NOPed the conditionaljump after the INT and the Inlinepatch worked fine.

in the new version, i made the same, but it must be another Sicecheck on int3 (SI break 2times), but there aren't any "Magic Values". FrogIce tell me Code 00:

My Question: How can i remove this Checks? or how works INT3 in this case?

i have read the manual on Exception, oh my god is difficult, but i keep trying to understand and i will read the tut's on the Tsehp's-mirror.


October 10th, 2001, 02:27
hi silber,

anyway it's not that hard int3 is causing a debug exception...
this exception is caught by the handler in fs:[0] (holds the pointer to the exception-handler)

an exception handler is setup like this way:

lea eax,[ebp+offset_handler]
push eax
push dword ptr fs:[0]
mov dword ptr fs:[0],esp

the lea eax,......
push eax

could also be replaced by:

call over_handler
mov ebx,[esp+0ch]
xor eax,eax

push dword ptr fs:[0]
mov dword ptr fs:[0],esp

now go and learn more... (tip: put a bpm @ the handler!)


October 10th, 2001, 23:58

telock .92 has a shitty bug on those lamea** dos applications
called windows 95 and 98 when dbg detection is turned on.

that's why i released .92a (one day after .92) where this is fixed.

just wanted to let you know. also want to let you know that
the entire telock project has been discarded. the last 1 1/2
years i spent much time on it with no satisfying result. in the
meanwhile the sourcecode of telock reached ~230k and it's
a pain in the *** to modify or implement new things.

i changed telock's name to tepack, since that's what describes
the program best and i want it to be. i'll work on better/faster
compression (not using aplib, even if it's nice) and compatibility.

somewhen in the near future i will start a new protector project
if i have enough free time, so better don't wait for it. when it's
ready for sale i'll let you know (lol)



October 11th, 2001, 00:27
hi ego,

hope to hear soon of u, coz we talked already yesterday to each other...


October 14th, 2001, 01:46

ok, now i have some idea about what SEH and exception is

in the handler of tElock is this:

cmp eax,C0000094 for division by zero
cmp eax,80000004 for Single Step
cmp eax,80000003 for int3

but i'm new in this things, what are the follow steps?

i have traced the Code, but i haven't understand, what's going on. ....

Okay, ein bißchen was weiß ich jetzt über SEH und Exceptions. Im Handler von tElock findet man obigen code, mit dem ich aber nicht recht weiß, was anfangen. auch ein Weitertracen im Handler hat mir nicht recht viel Klarheit gebracht.
Kann mir jemand einen Tip geben, auf was ich jetzt achten muss?

thanks & ciao

October 14th, 2001, 07:59
okay, wenn du den handler genauer untersuchst wirst du mit ziemlicher wahrscheinlichkeit feststellen dass der handler mit xor eax,eax - ret endet

die context structure erhält man über esp+0Ch, context_structure+0B8h enthält die eip! dieser pointer wird irgendwo im handler wahrscheinlich verändert, es sei denn es is ne single step exception oder ne breakpoint exception.... du nimmst einfach diesen wert denn das is die nächste eip nach der exception (zu der der handler returnen wird)

spiel dich einfach mal damit!

October 14th, 2001, 11:07
hi ich muss mich hier auch mal einmischen, weil ichs auch noch nicht so richtig versteh. In diesem Handler werden unter anderem auch die Debugregister verändert, wozu ist das genau gut, kann man so auch eventuelle Bpx's/Bpm's löschen ?


hi ^DAEMON^, the Debugregister values will also be changed in this Handler, whats the secret about it ?

October 15th, 2001, 01:59
wenn man einen bpm setzt dann wird die lineare adresse in den debugregistern der cpu geschrieben... die debugregister können normalerweise nur über ring0 verändert werden... aber wie das eben so ist mit m$... gibt's eben mehr wege! z.b über seh (also die context_structure) somit kann man wie du es schon gesagt hast die bpms killen (funzt auch unter NT/2K)


October 15th, 2001, 06:14
sorry but i thought i would be easier for those peoples if i answer the questions in their mother-language....


October 15th, 2001, 13:46
there's nothing in that german text what you don't already
know f0dder. i'm very sure about that )

October 15th, 2001, 17:43

October 15th, 2001, 17:59
thats not a kiss, is it?

October 16th, 2001, 05:40
lol te! btw your new is site is really cool...

October 16th, 2001, 13:01
ok, thanks DAEMON, but this Debugregister erase will not work in my own Code. If i set a BPM before my Handler this BPM is also working after the Handler. hm, I think i must learn still alot, but i'm on the way :-)


October 17th, 2001, 00:28
hmmm this depends on the operating system u are using!
try the following:
i assume u are using some os above w95(a,b,c)
so set dr6 to 0
and write 0155h to dr7

explanation of this would be too much...


October 17th, 2001, 01:06
...... read above .......

October 18th, 2001, 10:51
thanks DAEMON and f0dder, this should help. I have also found that this is explained in the Intel Pentium Manuals, i think i must read this to understand ;-)


October 24th, 2001, 12:43

I wrote this because all of you are talking about debugging and bypassing the a/d tricks used in tELock. Have you ever thought how to remove a protection using disassembler, compiler and brain only? This is my approach I ever use (it's about writing ungeneric unpackers). Hope you will like it :-)

The tools I use are HIEW to disassemble the program, text editor and TASM to compile the unpacker. First I disassemble at the program entry point with HIEW. If the packer does not use polymorph layers it is very easy to rip the code that decrypts the first internal encryption layer. HIEW is also good for manual removing the used fake macros which make the disassembly hard to understand (and long to trace all those JMPs without seeing the real next instruction). tELock doesnt use too much fake macros in latest versions so you'll not need additional tool like StoneHead's MOW (macro nopper) which replaces all known fake macros with NOP. So patch all that fake instructions with NOP (its offten happened to patch only the first byte of the instruction because it masks the real instruction). Then find where is calculated the relative offset (call next_line; pop ebp). Look where is the decryption loop and what is used in it. Just rip the code without the annoying macros and add to the program you will code (of course you need code that loads the PE file in memory, finds entry point of the program, etc. - all this can be found in unpacker sources on the net).
After ripping the decryption code you have to compile and run your program on the protected file. If everything is ripped OK you will get a file that has decrypted the code that decrypts the second internal layer.
Now look with hiew the code after the first decryption loop. If its good looking go rip next internal layer, add to your program, compile and run on the protected program (not on the decrypted from previous usage file!)
If you find some a/d code in the decryption layer - think a little bit if it's used for decryption (in most advanced protectors) or just to stop debugger. Rip the code and add emulation of the A/D trick (example is the tricks used by DAEMON in his protector which are using SEH: set SEH, do a decryption loop, execute invalid instruction or anything that will trigger the SEH and change decryption key in the exception handler - replace the trigger instruction with a CALL to the ripped exception handler).
That's all about getting a good looking and easy to understand main code of the protector. Maybe it will have some other internal layers but the approach is clear enough to understand it.
Now you are close to the real antidebugging stuff that makes debuggers/tracing tools to crash ;-)
Again its easy to defeat these tricks: remove all fake macros (use MOW /add macros if needed/), disassemble the file with your favourite disassembler (w32dasm need the file to be fixed) and find all a/d tricks, the code that decrypts/decompresses the sections, decryption&jmp to the original entry point. It will take you some time to understand all that code but when you rip only the parts that do the real decryption you will have an automatic unpacker. Of course you need to fix some values in PE header (entry point rva, imports rva, some other stuff).
Test the unpacker with several crypted files and fix the bugs you made.

That's the approach I use to make unpackers and to defeat a/d tricks using only disassembler and brain. There are some cryptors that are restructuring the PE file and you have to make rebuilder (imports, resource, exports, relocs) but that's advanced stuff...

Greetings to tE! and DAEMON

Best regards,
Unknown One/[TMG]

November 13th, 2001, 04:45

yesterday i was able to make the Inlinepatch for tElock 0.98 ....works now with Sice

thanks for all, who helped me on the Exceptions Handling. it was totally new for me, but very interesting.



so, hatt zwar seine Zeit gebraucht, aber jetzt läuft der Inlinepatch für tElock 0.98, und zwar mit Sice

Ich möchte mich hier bei allen bedanken, die mir dabei geholfen haben. Das mit dem Exception Handling war mir nämlich völlig neu, aber sehr interessant.