However that doesn't mean we can't pull the same tricks on the debugger as we do on living people. When stepping through script with the debugger, the statements get executed as you step. If you sit around and do nothing 1 minute while the debugger is currently on line 1, execution is halted and line 2 will not be executed until you give the command to continue. You know where I'm going with this? That's right, the timing mechanism. If the request to hidden.asp is not made within 1 second of the corresponding call to hide.asp the fake code is served instead of the real code. And if the fake code is served, the fake code will also be executed, line by line.
This means we need to create a delay for the debugger. It doesn't even have to be a full second, as it takes almost a full second for the debugger to start up.
HashEncode = 0x
This loops has a two-fold effect.
Along with everything else this technique isn't foolproof, breakpoints can be set up at certain locations within the code. All code up to the breakpoint is executed in real time. This means a breakpoint can be set on this line:
effectively bypassing the delay loop. If a breakpoint is set there and the developer works fast enough, they can step through quick enough to get the real code. However deception is on my side, why would the developer want to try and beat a clock they don't even know exists. As it turns out tomaney figured this out (but couldn't be certain). He may have actually seen the real code through the debugger but dismissed it as the same old code he kept getting (heh heh). What tipped him off to the theory that fake code may be involved was that when the debugger ran the code, no alert() happened. Logically he came up with the idea that I somehow detected the debugger's presence and pulled a code switch. Maybe some kind of time sensitivity was disrupted by the use of a debugger...
© 1997-2000 InsideDHTML.com, LLC. All rights reserved.