tag:blogger.com,1999:blog-5498266518143777458.post207725852421220767..comments2008-01-27T10:32:51.030+01:00Piotr Baniahttp://www.blogger.com/profile/16139783712412229709noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-5498266518143777458.post-40582014477997563562008-01-27T10:32:51.030+01:002008-01-27T10:32:51.030+01:00Yo Vlaad, sorry for the delay in replying but it seems i'm currently hella busy :/<BR/><BR/>Well i think i got your point, one of my older techniques regarding catching the moment of a debugger attaching was hooking the NtContinue (url: http://piotrbania.com/all/anti-dattach.asm).<BR/><BR/>I think i already saw the antidebugger techniques which were basing on the synchronizaction methods. Including some of the most pure examples like creating a thread and then using WaitForSingleObject API with some cool ammount of time as the dwMilliseconds parameter. And yes they may be the pain in the reverser's arse :)<BR/><BR/>But from the other hand in the SpiderPig tracer output i was just playing with the data flow graph, it simply illustrates when some critical condition is not met the flow changes "drastically". I'm currently ending the new SpiderPig called Espada and it's currently basing on some more stable algos, but this is up to come i guess.<BR/><BR/>cyaPiotr Baniahttp://www.blogger.com/profile/16139783712412229709noreply@blogger.comtag:blogger.com,1999:blog-5498266518143777458.post-43917611597786216182007-12-25T03:50:00.000+01:002007-12-25T03:50:00.000+01:00Hi Piotr, you are such a cool guy :)<BR/><BR/>You obviously contemplated about the frozen state of the executable during the debugging and thread syncing, however, when I found this on Microsoft dot com, I became concious of two things... how to very discretely check for a debugger, unrelated to existing techniques (you'll see the link by yourself, so draw your own conclusions :) and secondly, because lot of us doing the same job and reading the same material are using the same things, this one could be recognized, possibly, as heavy to circumvent, if properly implemented. We have all seen RDTSC workaround, then changing of the CONTEXT struct of the living thread (I won't even mention CreateRemoteThread and VirtualProtectEx functions, these are making me puke, even smurfs are using them nowdays...), recognizing additional checking threads from some unexpected place, but look at this and tell me do you see the same that I do? :)<BR/><BR/>http://support.microsoft.com/kb/q173260/<BR/><BR/>In order to open my sleeves to see that I'm open :) -> I'm thinking about synchro-primitives other than threads (such as semaphores, completion routines [heh heh] and waitable timers) in order to gain the timer functionality in such way that it will be interrupted in the moment any debugger attaches to a process :) Basically, you'll stop the thread, and along with the thread all the scheduled subtle synchronizations at that moment, or, satisfying enough, these will return slightly different values... so if we continue waiting in silence for let's say few hours (LoL)... it would be very amusing to see the face of the guy that is analyzing the code :)VLaaDhttp://www.openrce.org/noreply@blogger.com