Before we delve into the intricacies of individual methods of anti-debugging let’s use this post to define the classes of anti-debugging that we will be discussing. While other classes may exist, the definition of these classes is an attempt to include the majority of anti-debugging methods in use today. There is some overlap between classifications and we may have left out some methods due to limited exposure or effectiveness.

API Based Anti-Debugging
API based anti-debugging is the most straightforward and possibly the easiest to understand for a typical developer. Using both documented and undocumented API calls, these methods query process and system information to determine the existence or operation of a debugger. From single line calls such as IsDebuggerPresent() and CheckRemoteDebugger() to slightly more complex methods including debugger detaching and CloseHandle() checks. These methods are generally trivial to add to an existing code base and many can even be implemented in as few as two or three lines.

Exception Based Anti-Debugging
Exception based anti-debugging is slightly different than your basic API based techniques. Many times when a debugger is attached to a process, exceptions are trapped and handled by the debugger without regard to passing the exception back to the application for continued execution. Occasionally these exceptions can even crash or terminate a process when run under a debugger and be handled gracefully when running clean. It is these discrepancies that makes exception based anti-debugging techniques possible.

Process and Thread Block Anti-Debugging
Some of the API based anti-debugging methods use published functions to query information from within the process and thread blocks for our running code. Many API based detections can be subverted within a debugger by hooking the API call and returning values that indicate a clean process. One way around this subversion is to directly query the process and thread blocks, bypassing the API calls. Direct analysis of the process and thread blocks, while more complex, can lead to a more accurate and high assurance result.

Modified Code Anti-Debugging
One of the methods that a debugger uses to signal a breakpoint is to insert a break byte into the running code at the location that it wishes to stop execution. The process execution breaks when this value is seen, giving control to the debugger. When the program is resumed, the breakpoint value is removed and replaced with the original byte, the execution backed up one byte, and the program is resumed. Detection of software based breakpoints can be achieved by analyzing the process for modifications from the expected norm.

Hardware and Register Based Anti-Debugging
A second way that a debugger can break the execution of a process is by using a hardware breakpoint. A hardware breakpoint relies upon CPU registers to store the pertinent information and to detect when the target break addresses are seen on the bus. A break interrupt is triggered at the appropriate time based on these register values. Reading or modifying the hardware can allow for the detection of a debugger.

Timing and Latency Anti-Debugging
Finally timing and latency can be used as an effective anti-debugging method. When executing a program within a debugger, specifically when single stepping, a much larger latency occurs between execution of instructions. This latency can be detected and compared against a reasonable threshold to detect the existence of a debugger attached to our process.

Each of the classes of anti-debugging outlined above has merit when used individually to protect a process. While none of them can be assured to ever protect a program from a determined reverse engineer or debugger, implementation of these techniques (or many of them if appropriate) can sufficiently slow down the debugging process and hopefully make the attacker spend his time on other, easier, ventures. In the remainder of this series on anti-debugging we will review in depth some of the more interesting methods of each of the above classes. So bring along your debugger and your development environment and let the games begin.

The problem is that (Chris’ analysis is) completely impractical. I’ll take a recent, and fairly typical situation as an example. I was taking issue with the manner in which remote access was being provisioned for a third party vendor to connect to a system hosted by one of our European business units. To cut a long story short, it was not only a breach of policy but highly insecure. I wanted the access to be disconnected, the business unit director wanted my risk assessment. And he didn’t want to wait for it.

To quote Chris Hayes, spending time on working out the expected effectiveness of controls, over a given timeframe, as measured against a baseline level of force was not going to pacify an angry Italian fearful that my decision was going to cost him money. He wanted my explanation of the risk and more importantly, what I was going to offer as a solution to keep his business functioning

As Chris is someone who actually does this for a living in a large company, and this is typical of his actual day job, I really find Stuart’s “impractical” comment to be, um, misinformed.

Also, I think Stuart mistakes the purpose of a risk analysis.  The purpose of the risk analysis is not to force someone to be “secure”, but to provide knowledge for decision making.  Using it as a “hammer” to knock in the nail of your personal risk tolerance impairs efficiency and in the long run retards “security” as it creates political resentment.  Seriously, who cares if something might violate policy or not in a pre-implementation discussion?  Policies are not stone tablets handed down from on high, they are state-in-time codification of the data owners risk tolerance.  This risk tolerance changes sometimes, and that’s OK.

To that extent, I appreciate (and I’m sure Chris does, as well) that risk analysis does not create rationality in the data owner.  Someone who sees you as a speedbump on the route to progress they may not be ready to appreciate your point of view even if it is stated in the most rational manner possible.   But it’s worth noting (and Stuart’s example is indicative of this point) that risk analysis does not create rationality in the analyst, either.  If one is being so “security minded” as to ignore the risk tolerance of the business owner - we’re bound to get a reaction similar to that Stuart encountered.  In fact, a practical risk analysis like Chris performed on his blog, done in 30 minutes, should identify the critical point of disagreement between Stuart and the data owner (again, Stuart doesn’t own the data, the agitated Italian does).

But let’s stay rational and open to alternatives to what Chris offers.  Stuart states his approach to risk analysis as:

When I need to document a risk assessment I use a very simple form: list the threats, state the level of vulnerability, list the associated operational costs and potential revenue hits. High, medium, or low risk? Describe the controls and options. Write up who needs to do what, and how much of their time it’s going to take. Job done.

At first glance, I don’t think what Chris has done is any less efficient, and it provides greater insight (using Frequency and Capability instead of just ‘listing the threats’).  But what is key here is that Chris’ approach is consistent and defensible.  Less generous risk geeks and CSO’s I know would have no little difficulty with Stuart’s approach.  But to particularly answer Stuart’s main objection (impracticality) I would offer that with practice, Chris’ work is probably quicker and easier than Stuart’s described process as it eliminates much of the ambiguity an immature risk analysis creates - reducing the need for further discussion and arguments with data owners (regardless of disposition or nationality).

Finally the irony of Stuart’s post is that the reason he had this confrontation may in fact be because he was incapable of bringing a salient model for risk to the table, one that identified the factors that create risk and developed a defensible belief statement concerning risk.   We’ll never know if one would have helped him in this isolated instance, but I can tell you that in organizations like Chris’, good risk models and strong risk anlayses create operational efficiencies, reduce costs, and streamlines intra-departmental communications.

First, I enjoyed DeepSec conference and I am grateful for the invitation to speak there. I love European conferences – and not only for having infinitely (with that being an under-statement of the year) superior coffee during breaks :-)  In particular, I liked the audience for my presentation (slides will be posted here soon) and I think the audience liked my material and myself too :-)

What also impressed me a lot was Ivan Ristic speech, which was the second day keynote. He started by simply stating that ‘security industry has failed’ and that ‘a desktop is lost.’ His proof was in typical numbers like “75% of corporate systems are infected with at least 1 malware piece per system”, “1 million of malware types” and “25,000 unique malware samples a day seen.”  However, he then broadened the subject and talked about how not only “a trusted desktop” is gone, but the entire world of “trust everything [on a system], all the time” is gone (his ideas were similar to what I planned to present in my HITB 2008 presentation about “the 0wned world”)

I also like how he positioned all those “security user prompts” (in Vista and even before) as a proof that security technologies have failed and now we have to rely on the user to make security decisions (which will obviously fail as well since users are now fully conditioned to “see a chunk of technical mumbo-jumbo, then click OK”)

It was also interesting how he connected a lot of security failures to his “#1 reason: all programs run with all privileges of the user that runs them.”  In fact, he illustrated it by reminding the audience that “everybody runs untrusted code every day today [web browser + Javascript, etc] while nobody did this 30 years ago.”  He also beat up blackisting as an approach to security (but then again, everybody does it today :-)) - what was interesting that he opined that “we will spend the next 10 years proving that whitelisting will fail just as we spent previous 10 years proving that blacklisting fail.” His main point was that global “onslaught” of whitelisting and code signing will kill all sorts of useful things AND provide little security.

He then called for everybody to think about solving the hard, possibly non-sexy problems. This is the part where I could have used more details :-)

So, a fun speech (even though my telling of it is a bit jumbled… check out his slides whenever they are posted) – and a fun conference overall. Worth a 12 hour flight :-)

I'm not complaining about the fact that I can't see what I'm typing. I understand and laud that feature, because I don't want someone looking over my shoulder at the password I'm typing, and this even applies when I'm at home. I love my children, but I certainly don't want them knowing the password to my bank account!

No, what I'm bothered by is how a typical password text box behaves on a form that may incur multiple post-backs before it's finally submitted. If you use the built in ASP.NET TextBox control, it purposely does not repopulate the password text, which means if you press a button on the form that performs a post-back, or if you have a multi-page form that posts back on every step, that password disappears, and the user typically has to re-enter it. You could solve this with liberal use of ASP.NET Ajax UpdatePanels, but that adds its own complexities. I wanted a simpler solution.

So I did a little research to see what others had discovered about this problem, and I ended up deriving my own custom control from TextBox to make a much more user-friendly (and developer-friendly) TextBox control. I called it PasswordTextBox, and it acts just like a TextBox in password mode, but it retains the password while still giving the user the same level of protection the standard TextBox supplies.

My PasswordTextBox operates very simply: it stores the password in control state, and renders a series of fixed characters (with the same length as the actual password) into the text box so that it "looks" like the user's password has been rendered. Since control state is part of view state, and since view state is stored in a hidden field on the form, I encrypt the password before putting it into control state.

The result is quite nice - the user can post your form back as many times as she needs to, perhaps moving back and forth across wizard steps or tabs, and when she finally presses the "Finish" button (or whatever you call the last step of your input form), your code will be able to read the password by simply accessing the Text property on the PasswordTextBox. The user will believe that her password is sitting there on the form while she's working, as the same number of obfuscated characters will show up in the field as she typed in originally (what she doesn't know is that those characters aren't her real password anymore, but what she doesn't know won't hurt her!)

Note that to keep this simple, I used DPAPI to encrypt the password, which suited my purposes. But if you have a web farm, that won't work well at all if you don't know which machine the user's going to post back to, so you'll want to replace that with something more robust. I could see looking up the <machineKey> for entropy, as that tends to be sync'd already across the farm, but I've not yet spent the cycles to go down that road, since unfortunately all of the code for generating keys based on that config section are off limits in ASP.NET (most of the useful stuff is marked internal). I don't think it'd be that hard to do though.

Anyway, without further ado, here's the code, which you'll see is quite simple. I'd love feedback, especially if you see any glaring problems with the idea or the implementation!

public class PasswordTextBox : TextBox
{
    // unlikely that a string of these would be used for a password
    const char PasswordPlaceholderChar = '}';

    string password; // stored encrypted in control state

    protected override void OnInit(EventArgs e)
    {
        base.OnInit(e);
        Page.RegisterRequiresControlState(this);
    }

    protected override object SaveControlState()
    {
        byte[] encryptedPassword = ProtectPassword(password);

        object baseControlState = base.SaveControlState();
        if (null == baseControlState)
            return encryptedPassword;
        else return new Pair(baseControlState, encryptedPassword);
    }

    protected override void LoadControlState(object savedState)
    {
        byte[] encryptedPassword;

        Pair pair = savedState as Pair;
        if (null != pair)
        {
            base.LoadControlState(pair.First);
            encryptedPassword = pair.Second as byte[];
        }
        else encryptedPassword = savedState as byte[];

        password = UnprotectPassword(encryptedPassword);
    }

    /// <summary>
    /// This control always uses TextMode=Password
    /// </summary>
    public override TextBoxMode TextMode
    {
        get
        {
            return TextBoxMode.Password;
        }
        set { }
    }

    /// <summary>
    /// TextBox doesn't render value attribute for TextMode=Password
    /// So we add code that renders a placeholder text instead
    /// </summary>
    /// <param name="writer"></param>
    protected override void AddAttributesToRender(HtmlTextWriter writer)
    {
        base.AddAttributesToRender(writer);

        string text = Text;
        if (text.Length > 0)
            writer.AddAttribute(HtmlTextWriterAttribute.Value,
                GetPlaceholderPassword(text));
    }

    /// <summary>
    /// TextBox doesn't save the "Text" viewstate in
    /// TextMode=Password and we don't want our behavior to break
    /// if ViewState is turned off so we store the password in
    /// Control State, encrypted with MachineKey
    /// </summary>
    public override string Text
    {
        get
        {
            return password ?? string.Empty;
        }
        set
        {
            // this prevents us overwriting the actual
            // password with a placeholder
            if (!string.IsNullOrEmpty(password) &&
                value.Equals(GetPlaceholderPassword(password)))
                return;

            password = value;
        }
    }

    private string GetPlaceholderPassword(string realPassword)
    {
        int length = 12;
        if (!string.IsNullOrEmpty(realPassword))
            length = realPassword.Length;

        StringBuilder sb = new StringBuilder();
        sb.Append(PasswordPlaceholderChar, length);

        return sb.ToString();
    }

    public byte[] ProtectPassword(string password)
    {
        if (string.IsNullOrEmpty(password))
            return null;
        byte[] cleartext = Encoding.UTF8.GetBytes(password);
        return ProtectedData.Protect(cleartext, null,
            DataProtectionScope.LocalMachine);
    }

    public string UnprotectPassword(byte[] ciphertext)
    {
        if (null == ciphertext)
            return null;
        byte[] cleartext = ProtectedData.Unprotect(ciphertext, null,
            DataProtectionScope.LocalMachine);
        return Encoding.UTF8.GetString(cleartext);
    }
}

Apparently a fellow recently was indicted on charges of hacking into the Republican vice presidential nominee's Yahoo email account, by simply doing some research on the Internet to find her birthday, zip code, and the answer to her security question, "Where did you meet your spouse?" All told the attack reportedly took under an hour to complete.

Given the level of interest in Palin and other public figures, and the large amount of information about them available to the public, it makes sense that they will be some of the easiest targets for attacks like this.

A similar arrogance is happening in CEP-land, where, it seems, each and every financial services event processing application is now a “CEP application” just because someone in capital markets puts “CEP” in the same paragraph. I find it ridiculous that the same market of folks who have helped destroy the global economy are now the world’s self-proclaimed authorities on complex event processing. Amazing, if you really think about it, isn’t it?

I read many posts these days by folks in the capital markets trading world, claiming their message routing application is “CEP,” or their algo trading application is “CEP,” - feeds and speed, typical of what “turns on” the financial services folks. As an editorial note: I recall when I worked for a software company, folks on the same team who worked on Wall Street would look down on folks with many years of IT experience outside of financial services. Some would say “he is only a security guy” in their attempt to put down anyone who does not have trading floor IT experience on their resume. I found it all quite ridiculous and foolish.

My resume, for what it is worth, has a number of financial services companies, including either assessing, architecting or building large scale security systems for S.W.I.F.T, Chase or SBC. This experience does not seem to “count” with the trading floor folks, since security is more about getting things right, not just supporting a form of gaming or gambling with other peoples money, with more feeds and speeds the better.

Of late, as I have watched the CEP/EP space evolve, and unfortunately, I see a similar type of “capital markets virus” spreading into CEP-land. Folks on the trading side of financial services seem to think that whatever they say or do is right, and whatever others outside of the trading side do is wrong. These folks are quick to ridicule others who have far more experience than they do, outside of the trading floor of capital markets.

After all, mostly what they do on the trading side is route orders - and if a little old lady in a small town in Iowa loses her life savings because of a bad investment decision, it means little to the folks on the trading floor, the market folks are into feeds and speed - just keep the beast alive. Place your bet on this market or that one! Away we go, faster and faster!!!!

I am sometimes a little sad to observe the same audacity in the CEP world. Instead of focusing on the hard complex problems that require accuracy, the original set of problems defined when the phrase “complex event processing” was minted, the capital market folks have hijacked the term for their marketing purposes in algo trading and order managment systems. These same people ridicule others who are working to solve the (originally stated) complex event processing problems, problems the capital market traders seemingly cannot understand, since they have never worked on complex network or security management problems.

Nevermind, that these “ultra low latency” systems cannot accurately detect a complex money laundering scheme or an elaborate fraud. Nevermind that these “CEP engines” cannot accuracy insure that Average Joe does not lose his hard earned money in a fraud scheme.

I have no problem with folks in capital markets using the term CEP, but they should not ridicule those in technical areas that are not focused on keeping the “trading beast” alive so people can lose their life savings in a blink of an eye; but instead focused on solving complex problems such as the class of problems called out when the three letter acronym “CEP” was created.