Hi All:

I'm very much interested in this part of the protection (as I'm sure you all are ). This is because if a protection does this well enough, it might as well make our life miserable, as we rely on tracing/debugging to analyze the inner workings of the program.

Recently, I find that INT 1 is the debugger exception and that when the TR flag in EFLAGS is setup, the processor executes exactly one instruction and generates INT 1 so that the debugger can gain control.

Also, if GD (Global Debug) flag is turned off in the DR7 register, you cannot write anything to the DRx registers. It is like essentially locking all DRx registers.

My questions are as follows:

(1) Does Kernel-level debuggers (like SICE) also use INT 1?
(2) Why doesn't any protection software switch temporarily to ring 0, turn of TR flags, hook INT 1 (the new interrupt handler does nothing actually), set the GD flags in the DR7: thereby essentially *finishing* all debuggers ? (Or do some of them already do this?)
(3) Is my above postings correct or am I just having an ASM fit

Thanks for sharing your thoughts on this.

Signed,
-- FoxThree

PS: I'm planning to open an archive of all known anti-debug and anti-trace techniques (similar to CrackZ). I already have quite a few material. If you find any site/url that has such information, I'd be glad if you could share it with me so that I, in turn, can share it with the world

Hello foxthree !

If GD in DR7 is turned on, any read/write to the DR? registeres will execute an INT 1.

SoftICE uses INT 1, but not all the time. For example a BPX does use INT 3 to break, a BPM uses INT 1. BPR/BPX use INT 1 to re-enable the BPR/BPX after it has tiggered once.
You can find very usefull information about this in +Spath's "SoftICE Internals".

Some protections switch to Ring-0 to change/clear the DR? registers, but the problem is always how to do it on different operating systems. Turning off the Trap Flag wouldn't help anything if the program is running, since it isn't traced and TR is not set on anyway. Hooking INT 1 and setting GD on is a bit unsafe, since an INT 3 or the debugger's hotkey will be able to set INT 1 back and clear the GD flag again, since it executes it's own INT 1 on DR? access. And if you're tracing the code, the protector can't hook INT 1 and enable GD in one instruction (didn't you think that the debugger could also have set GD on?) and if you're stepping over a call, INT 3 comes in again and can set everything back.

No, your above posting with "GD off=DR? locked" is not correct.

THIS MSG IS QUOTED BY TSEHP...VBULLETIN BUG...

Hi DakienDX:

Thanks for your insightful post. However, my question is that if I (as the protector) hook the INT 1 handler (which the debugger would've hooked) and prevent "chaining" of the INT 1 interrupt vector, what gives?

>>it will give the following thing :
Daemon already coded an app that selftraces, hooking the int1 to decode instructions and executes them later.
But my tracer is installed here before, so it can fool the target that tries to hook this interrupt and chain it's own interrupt vector after... he he, it was there at first

Another coincidence is that of tsehps' post in the same forum about SICE behavior in WinXP. In that he writes, WinXPs' SYSENTER interrupt handler trashes the TR flag and there seems to be no way to reset it back. What if I do this + hook the INT 1 handler and prevent the Debugger's INT 1 from being called.

>>it's done at ring0 level, but again a ring0 tracer that detect this and re-enable the tf flag after this crime is done ;-)

Am I making sense or just yapping?

>>to finish : if the tracer/debugger is loaded at first, it will always have the opportunity to emulate and lie to the traced target, and all the work coding such apps is there.

regards,

tsehp

Hello foxthree !

I don't think I understand your question. I was assuming that you are the only one who handles INT 1 and that there is no chaining. You must always remember that INT 1 is not the only way to access SoftICE. How would you try to hook INT 1 anyway? (remember, different operating systems)

I think you haven't understood Tsehp's post right. Tsehp means the TR flag is switched off by WinXP, so his tracer will not continue after the system call because there is no INT 1 executed after that call. Of course you can set the flag back by hand, but it isn't done automatically. This is nothing which a protector could use, only a WinXP specific "bug".

Hi Tsehp/DakienDX:

Thanks for all your wise posts. I really appreciate you sharing your knowledge with me.

Signed,
-- FoxThree

Hi

sorry but the above isn't correct... i DON'T hook interrupt 1! it's a good old trap flagger nothing else using seh (that turns on trap flag in eflags!)

and if u are interested in anti-stuff visit my homepage

h**p://www.anticrack.de/daemon

best regards,
^DAEMON^

Hi there Daemon:

Up to your usual tricks is it? I took a look at your site and all I can say is WOW!!!

I can see a new ALERT coming up:

ALERT!!! HEAVY DUTY READING COMING UP ALERT!!!!

Signed,
-- FoxThree

yep, you're right daemon, sorry for the mistake.

you also used a lea eax, eax to do the dirty calls ;-)


two kinds of tracers actually exists :

1-the ring 3 tracer : my first versions and actual imprec 1.4.2
they must be the first seh, so always reside at the top of fs:[0] chain. they are pretty easy to defeat because they only rely on ring3 mem accesses, they can't fool the idt and you can play tricks on them to remove them from fs:[0] , they always have to emulate/avoid the instructions that can uninstall them.

2-the ring0 tracer : icedump (installed with sice) and revirgin's actual tracer; TMHK. Those tracers have the highest "power", meaning that they can access everything in mem, can modify the idt and can also produces great (bsod's) for my part ;-)
Those are more difficult to defeat, because they only rely on windows internal kernel code to work.

regards,

tsehp

btw your tracer gets stuck in my latest version of child - protector u can download now a public version on http://www.anticrack.de/daemon ))

(win 2k!!!)

^DAEMON^

(hihi i love my job )

Hello ^DAEMON^ !

The thread here was started by foxthree as general question and I answered him in a general way. We were only talking about anti-debugging tricks and WinXP bugs.
Then you came thinking we're all talking about you and your protector and started to tell that everything is false just because your protector doesn't use it.

We weren't talking about you, didn't you notice that?

Yep, I downloaded "protect_last_beta.zip" at 10.04.2002 00:11.
Finished unpacking at 01:55.
!!!!!!!!!!!!!DO YOU KNOW!!!!!!!!!!!!!!!!
******I unpacked it WITHOUT debugger!*******

OEP I guessed. So daemon, be so kiddy & tell me, am I RIGHT?

BTW!!! BUG REPORT!
I tried but failed protect this programs:
NOTEPAD.EXE
REVIRGIN.EXE
2 exe's from ICLEZION's tuts & all others!
Here I crash my PC..

Sorry Dakien, i noticed that of course

again sorry, if i got u angry, didn't want that

evaluator: i wrote that u should only try it @ tasm files (otherwise play with the ini file set all values to 0)
but it will fail in 90% - download a few of my unpackers and protect them... and u'll see it works (tasm ://)

^DAEMON^

OK, but you not answered on Q:
My OEP is right or no?

dunno sorry iam @ work can't check for it

but stop uploading such files here please, if u want then email me them, k ?

would be nice if u delete the post thx in advance

^DAEMON^

Maybe I will delete it after you sad:
"OEP is wrong or RIGHT"

>>but stop uploading such files here please..
>>would be nice if u delete the post thx in advance

BTW Never forget word "PLEASE" 2 or 3 times

This "protector" is buggy - don't run on my win2k sp1/2 (go to infinite loop in SEH handler in first polymorph(?) layer). May be this the "real cool protector" written as frase "If in don't runs it can't be defeated" ? ;-)

But it run under XP!

Hi evaluator,

How did you manage to unpack daemon protector without a debugger? If you did that, you are the man Tell me please, cos I'm very curious

I traced the whole protection from the beginning to the end. Yep, I'm crazy but i wanted to smell each opcode one by one (a few hours of pleasure...Nahhh, it was not a pleasure at all to trace that devil code )


About the Original Entry Point....well, there is an easy way to get it. As you can see the BPM are not working, at least that you patch the DR7 writing inside of each SEH that modifies that. The protection checks for 10h bytes in each API used by itselft or by the target program. Ok, lets put a BPX in LoadLibraryExW+XX (XX >10h). After the breakpoint, we have to make a search for the protector epilogue (where the last instruction is before passing the control to the target program). The last instructions that are executed in the protector are:

lea eax, eax ; this is cool where did u get the opcode 4 this?
pop fs:[0]
add esp, 4
ret ; intergalactic jump to the target program (OEP after this)

So, after the breakpoint from LoadLibraryExW search for 83 C4 04 C3 (that's ADD ESP, 4; RET)

put a bpx in that RET and run the protector till softice pops up in that RET. You'll have the OEP in [ESP]

Regards,
Ni2

Hi ni2,

I have encountered the same code snippet before, but was unable to explain its behaviour...

isnt "lea eax, eax" and invalid instruction? When i attempt to trace over this instruction... the exception handler is always called and then i am lost... guess it is anti tracing code... if i put a bpx over on the next instruction then it runs fine and break at the next instruction... however i miss the fun of understanding what happen in between..

Would you care to explain how this works to me?

Thanx,

Perhaps the exception handler that is set up, gets the address of the next instruction as pushed into it.

For example,

push <address of code AFTER lea eax,eax>
mov fs:[0], esp

like so.

This would make the "except" of the "try" be the very next instruction after the fault, heh heh, and would be somewhat tricky. And I think with any SEH if you enter it you end up tracing thru some kernel code for a little while before you get to the "except" statement of the program, hence it's a bitch to trace..

In fact, you can't get the code "lea eax,eax" to even compile, so it must have been something that had to be entered manually in my opinion.

-nt20

Yes, the 'lea eax, eax' produces an excepcion and the installed excepcion handler (SEH, by daemon) takes the control of the processor.

Inside of the excepcion handler you can see what was the reason of the exception. If it is 'invalid opcode', daemon knows that it is because of that instruction (LEA EAX, EAX = 8D C0) and he will add 2 to the EIP register in the context register to avoid a new exception in the same instruction after leaving the SEH. Well, daemon makes this a few things in his code, the reason is nothing else than invoke his SEH handler and decrypt a block of code or just with the intention of disable the hardware breakpoints (BPM), writing in the DRx registers.

About the compilation of the instruction LEA EAX, EAX....yes, you have to do it manually or at least i havent found any illegal assembler that can assemble that

take care,
Ni2

i enjoy reading the posts! keep on guys... good work!

^DAEMON^

iceugedition.ace gives me a CRC error...
is it just me?

tried to redownload it ?

other guys told me that they also had, but disappeared as they redownloaded it

^DAEMON^

Hello, Ni2!

>"How did you manage.."
Secret

Soon after I did it on my W98SE, I installed XP.
On XP thiz "powerfull tasm-files-protector" can't does 98% of anti-tricks..

Daemn wrote:
>"i enjoy reading the posts! keep on guys... good work!"

I "manage" this phrase as LAUGH about newbies..
OK! Vendetta

Here I again uploaded my workz Now restored also mangled code..
So when you protect this file with itself (or with original one),
except last section, all will 100% identical with original one.
("cr.ini" as from package)

Questions for DAEMON:
1. Did you manage OEP for us!? (or again you are @ work
2. How we can manage other your phrase:
>"hi binh81
"iam sorry,better go and try yourself @ rea..."

eval, i don't laugh @ newbies...

ni2 did a great work! that's all... what does it take when u miss the best parts of the protector ? when i started development there were no such rebuilders... as there are today!

and iam bored of this shit i coded! i won't check the files as iam not interested in it...

eval, even better: go and develop your own protection!
iam busy with coding unpackers! and other stuff

^DAEMON^

nope...
tried redownloading with flashget, ie, mozilla, getright...
only that file get's a CRC error...
oh well

Hey Daemon:

You forgot a neato feature in ICEDump that will help in bypassing your anti-debug tricks. Can you figure out what I'm talking abt. here?

Anyways, neato packet with tons of anti-debug code

Signed,
-- FoxThree

About INT1 based dbg-detecting & XP

Daemon!
On XP I checked your INT1 dbg-detector.
RESULTS:
1. On plain XP this method not works!
program lives in memory and not responds.
then I tested also POXYLOC (it uses F1 opcode). Same result!

2. If debugger loaded, yes, it detects, if not trace wuth F8!
If trace step-by-step with F8, not detected.

RESUME:
Brocken scheme!

I find this old thread for correct my(?) mistake.

When I reinstalled XP, INT1 exception now handled very good.
I don't know why that error happens..
So SORRY Daemon from M$.
Your INT01 detector works good on XP.

Also want tell you:
I found SuperEasy way for kill INT01 detection forever.
Regards