Inside Technique : Hiding HTML/SCRIPT... I think it IS possible! : Script Debugger

Microsoft has many flavors of Script Debuggers. A free one can be found here. The purpose of script debugger is to debug (obviously) scripts hosted in any Active Scripting environment, including Internet Explorer. If a debugger is installed and the Advanced Internet Explorer option "Enable Script debugging" is enabled, you get prompted to debug whenever an exception occurs. In addition the debugger can "attach" itself to any instance of Internet Explorer. Once a debugger has been attached it can watch any variable within that document's context, including both DOM objects and JavaScript variables. Statements can be stepped through showing you exactly every statement that gets executed. There is no hiding from the debugger, if something gets executed the debugger will show it to you.

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.

var HashEncode = 0x <%=guid%>;
var EncodeHash = 0;
for(var i=0;i<String(HashEncode).length;i++)
    EncodeHash += HashEncode%7;

This loops has a two-fold effect.

1. It makes a 32 iteration loop, there's no way a debugger will step through that in under 1 second
2. It makes it look as though I'm actually doing some kind encryption calculation. It has everything: variables names "HashEncode" and "EncodeHash", a really big Hexadecimal number, even a modulus operation involving a prime number! It must have something to do with SuperDuperTopSecretDecodingFunction()...

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:

try{if(document.namespaces[0].urn=="urn:p

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...

<- Previous (Covering Up Tracks) Index Next -> (The Solution)

© 1997-2000 InsideDHTML.com, LLC. All rights reserved.