What do Chrome, GreenBorder, and API interception have in common?

If you may have remembered, I once made the following comment in a previous post of mine: "Interestingly, enough this was also what GreenBorder did before they were purchased by Google."  In that post I happened to be talking about a favorite program of mine called Sandboxie.

Well, with the release of Chrome... the truth has recently surfaced to as why Google snatched GreenBorder up.  Naturally, I had my suspicions after Chrome first releases given the "sandboxing" that Chrome was doing.  As I said in the past... I just haven't gotten around to doing a deep dive, thus I haven't really dug into the technical aspects of this new browser.  But, then again... I'm also a little concerned with Google becoming the gatekeeper for everything.  So, I'm going to wait a bit to see where this goes.

Anyhow, it wasn't until reading through a portion of this article on ars technica and seeing something that seemed very familiar that the little light went on.  For you see, as the author points out (using fancy language), one of Chrome's security features is to intercept and rewrite API calls.  **Ding** That is pretty much what GreenBorder hence why Google purchased them.  :>)

Disclaimer

Well, the truth is... I actually know some of the members of the development team.  I used to work with them at a little company called New Moon Systems.  That being said... these guys are a really good at understanding the internals of Windows development.  So, when it comes to the question in the article about whether or not Google reverse engineered Windows, I just need to smile.

What do you think took place?  It isn't like Microsoft is in the business of documenting the internals of Windows.  Well... not unless you count when their source code gets stolen.  In any case, when you look around at all of these other companies that have figured out really good (**cough**) hacks to either do something amazing or work around something that Windows wasn't designed to do.  It only stands to reason that something was reverse engineered.

Thus... when you think about... that is why Microsoft tends to look the other way.  If they were to really go after people they would only be shooting themselves in the foot given the pervasiveness of the practice.

Getting Back on Topic

So, what amazes me about this whole thing is the tack that Google chose to take.  In most cases, API interception is accomplished by using a device driver running in Kernel mode.  In other words, developers had always tried to patch the Windows Kernel... a big no-no and something that Microsoft has prevented in 64-bit Vista and beyond (hey good post idea).  Patching or extending the Kernel is very similar to what a rootkit does, and it is something that has always bothered me about applications that were trying to accomplish Sandboxing.  In fact... that is why I never ran Sandboxie (my favorite Sandbox) on my physical host and instead always choose to use it within an actual VM.

So... why did I say Google took a different tack?  Well, first off, Chrome is not using API interception as a method of protection.  If you look at the design document the API interception is actually being used to deal with compatibility issues that might arise with plugins that tank while running in a restricted environment.  Instead, what Google did was develop the concept of sandbox which runs in user mode, and creates a custom security model for application-level objects. 

Hmmmmm... In other words, very cool stuff.  Again... if you want to know more just look at the design document.