TL;DR - IoT is really bad atm, and this post shows how bad it can be. /TL;DR

Summary - to get the most out of security assessing hardware, you should ideally be proficient in numerous areas of security testing - infrastructure, web, mobile apps - as these are all presented attack surfaces on modern devices. Hardware hacking can greatly enhance the testing of these surfaces, and offers up some new attacks and a level of detail that is completely missed if the device’s debug/terminal functionality is not explored.

Motivation

A matter of longevity

The ‘half-life’ of a vulnerability - the length of time for half the users to have their service/software patched against an identified threat - is nowadays very short; minutes for a hosted web service, even hours for a maintained executables and services, to weeks with clients who have strict roll-out testing requirements. However, a vulnerability in hardware will be around for YEARS. Once a device is installed, it’s there for the long run, and if there is one guy who procured it, went on the training course, but then left under a cloud and never wrote down how to update it - you’re really stuck until you upgrade. This is the true facts of hardware based security models.

Looking past just getting a shell

There are 1001 guides online for doing ‘Hardware Hacking’ and they mostly stop at ‘…and now you’re connected’, leaving the reader to come up with the relevant attacks, tests, and experience for themselves. Few places deal with what the risks really are.

Yes, I understand (more than most) the value of having a r00t shell on a device, delivered to you through UART, but let’s be honest for a moment - this is not a viable attack vector! There is no way that you’ll actually execute access to a UART on a victim’s device without either their noticing you, or travelling around fully equipped to perform the installation and assessment of the development header.

So, given I did a post about getting UART for under a tenner (£10 for those wondering what opera has to do with this) I alluded that getting UART is just the beginning - and it is! There is much that you can do with low-level access to a device’s hardware that is hard-to-impossible without such access.

I will give details for UART in a later post, but for now, I just want to explore more on what I precisely mean, as a security person, by ‘hardware hacking’ and why it’s useful.

What hardware hacking means

First, a quick digression into what I mean by ‘hardware hacking’. This is a very broad topic - it covers circuit bending, repurposing tech, breaking DRM on games consoles, accessing debug functionality on IC’s built into product PCB’s, designing and getting an arduino/RasPi/(generic microcontroller) to achieve a certain task for a project you’re making, accessing/writing to protected ROM areas, reverse engineering IC’s that don’t have public datasheets, etc. etc. etc.

Hardware hacking is a vast topic, and I don’t want to get bogged down with definitions - they’re all valid uses of the term ‘hacking’.

Specifically, for me, the phrase hardware hacking is linked to my work as a pentester and security researcher where I would analyse IoT/hardware from the standpoint of an attacker looking to get some malicious leverage on a system - so, my point of view for ‘what to do when you have access to a debug/terminal interface with a chip?’ is to use this deep level of access to test for vulnerabilities and security flaws. This is what I’m interested in, and so I’m making this explicit from the start.

As such, here are the kinds of questions I ask of a device I come into contact with:

• What else can you do besides (generic product description)? (you could argue this is a definition of ‘hacking’ in a generic way…)
  • are you really a microcontroller being used to flash a light?
  • Do you have a firmware-controlled radio that could be repurposed?
  • Do you have some advanced functionality that goes above and beyond what you need for the task at hand, and that I can use for other stuff?
• Can I turn you into a malicious device for blackmail?
  • e.g. bugging, video recording, disclosing sensitive user data or Personally Identifiable Info (PII) - that kind of thing
• Can I get data out of you that relates to your owner?
  • e.g. PII again, usernames, passwords, secret keys for 2FA, private keys for encryption, etc.
• Can I add you to a botnet/BTC miner?
  • easy ways to monetise pwned devices - get them to mine BTC to a wallet you control, or add them to a botnet and sell DDoS services a la Mirai clone botnets
• Can I think of any other malicious activity that would benefit me in some real way, that I can leverage to this device and others?

Some Attack Scenarios and Common Vulns

So, you’re a pentester and you’ve been given a device to hack as part of a test - what now?!? In fact, many categories of attacks relate to Hardware hacking from this security standpoint, in particular:

• Outdated Software

There is a major supply chain issue in IoT. A recent mass hack in the UK showed that there are some serious flaws in the generic underlying software presented on the devices. But how the hell are these vulns here? Well, in part it’s a supply chain problem.

Often (incorrectly) referred to a ZyXEL, Allegrosoft manufacture software for embedded systems, including the very popular RomPager server software. It was clear that there was some issue with this software in the wake of this hack. However, according to sources, Allegro FIXED THIS VULN IN 2005, which was revealed when checkpoint disclosed the ‘misfortune cookie’ issue, which was similar in nature.

So what went wrong? Well, Allegro make money, like any other company, so they sell their software to IC manufacturers directly. In turn, these manufacturers develop a chip, and then sell/give away an SDK with the chips so that companies can quickly get products to market. As such, the problem was specifically that the manufacturer had never upgraded, so the product designers never upgraded, and these devices are in place for years and years - so a vuln from 2005 can and will be a major pain in the arse in 2017 because of this major problem in the supply chain delay-line effect.

You will find web servers you’ve never heard of (because they were discontinued in 2003, like D-Link’s Boa webserver), DNS servers older than most of your underwear, kernel versions that belong in museums, and best not to mention what versions of busybox they are running.

• Wi-Fi woes

Many attacks have been found against commercial Wi-Fi setups. But from this to this, it’s clear that all your Wi-Fi experience as a teenager has not gone to waste.

• Remote Command Exec (RCE)

Many instances where you can send a command over the internet and run commands on the local device as r00t. This is quite obviously bad - and there are many sources for ‘what to do’ if you find this kind of vulnerabilty. Many devices also run everything (even web pages) through BASH scripts because then they don’t have the overhead of including a (probably as vulnerable) PHP service. As such, injecting RCE strings all over is likely to find something, somewhere, on the web-app used to manage the devices.

• Remote Code Exec

Likewise, connecting to some exposed service on the external device presentation and send crafted payloads to exploit BOF, format string vulns, etc. These service, if vulnerable, can easily be found using shodan and the like.

• Cross Site Reqeust Forgery (CSRF)

Using CSRF to fire in a user’s browser, connect to the ubiquitous web based apps/API’s used to manage the devices, and either get RCE or directly manipulate settings is a common vulnerability I have found on firmware-based devices. The required CSRF-Token checks needed to mitigate this can produce lines and lines of code, which is a hefty price to pay on storage-light firmware chips (remember - the max for most firmware chips is 16Mb). This vuln is going to be a common theme.

• Cross Site Scripting (XSS)

XSS is always bad, and if there is a way to compromise the device with, say, a stored or reflected XSS, the user’s browser as well as the device can be compromised. I’m not going to write here on the evils of XSS as many others have done this before me! But your honed bug-bounty/web-CTF skillz are not lost here!

• File Upload vulns

Linking into my nightmare CSRF scenarios, file parsing is almost always comically bad on devices, and I will put money on that if there’s a file upload on a new-to-market device, it’ll have some vulnerability related to either Local File Inclusion, Directory Traversal, or straight up pwning (as seen with a device that just unzipped a file as root into /, including the malicious /bin/evil-ELF I included).

• XML/SOAP based attacks

More and more devices are using mobile based android/iOS apps to manage these devices. As cool as this sounds, these devices open up a SOAP/XML/JSON based API to talk to the app (rarely implementing any authentication), and UPnP attacks, enumeration, TR069 attacks and enumeration (and others) fall into this category, too - but see ‘cloud’ for more.

• Authentication / Session management issues

Default credentials are everywhere - literally! admin:admin or similar used to be a joke in the office, until it was everywhere on every device you could talk to that used some embedded platform. It is also a myth that most users even can change their passwords to these devices (many don’t support this anymore - see ‘cloud’) so this is also worth reporting. Authentication information enumeration (usernames/emails) is also rampant, as well as authentication bypass - I remember doing a test on one device where just having a valid cookie (which you could guess or bruteforce to get) was enough to bypass username/password requirements.

• Information disclosure - READ

If the device passes through much of the user’s data (as in CPE’s) then this data is at risk if the device is - and so these devices can act as a source for further malicious activity (dumping CC data, seeing if someone is in the house for IPCams, etc.). Don’t forget, setting malicious DNS servers is very, very easy on CPE’s once you’ve compromised one, and most users (even tech savvy IT people) won’t notice, not ever.

Additionally, if a devices offers up access to other services that they then manage (SIP/VOIP, FemtoCell or IPTV access) then disclosure of the internal mechanisms on these devices can reveal private keys for encryption, common shared secrets or credentials (often unencrypted/unhashed), certificates for authentication and encrypted access, DRM information and access methods, etc.

• the ‘Cloud’

…is just someone else’s computer. But aside from all these issues (which are dealt with much better elsewhere) there is another concern. Amid this melange of written-at-4am-with-no-sleep and updated-when-West-Virgina-last-voted-Democrat software (see, US-relevant jokes… how international of me), introducing new and modern services is as bad an idea as you might thing.

All I can say is that there is little reason for a user to be able to change their firewall settings on their router from the other side of the planet (read; over the internet) but that hasn’t stopped manufacturers’ efforts to ‘solve problems people didn’t know they had’, thereby creating more problems that nobody whatsoever needs.

Hardware Specific stuff

There are also some specific issues relating to hardware devices themselves:

• More Supply chain woes

Example: U-Boot doesn’t support secure booting. At all. Secure boot mode has been in ARM processors from 2005/6 time, but the most common bootloader in existence doesn’t support it. This means that your bootloader probably doesn’t support checking if the firmware is malicious. Again, tie this into a CSRF vuln (see above) and you can upload a malicious firmware file (I’ll probably do a blog on how to make these).

But how is this a supply chain issue? Well, ARM is sold under license, and as such, many of the cheapest chips use licenses of older chip designs. So we see the precise same issue as above - Jazelle mode is an old ARM exec mode that supports native Java bytecode execution (YES YOU READ THAT RIGHT). It was ‘replaced’ by a new mode in ARMv7 called ‘ThumbEE’, but you’ll still see Jazelle in millions of chips in the wild worldwide.

• Development Headers

Kinda obvious from the outset, but the reason these are left on the boards is that the cost of tooling a ‘consumer safe’ board is very high. Prototyping can take weeks, and when you double that time to create a ‘secure’ version of a PCB layout, most project managers would shelve such an idea on the grounds of cost alone.

Also, ‘omitting’ a connecting resistor when going from dev board to production board isn’t fooling anybody…

• Bootlog Oracles

Bootlogs are great. They’re on the list a little down from post-it notes and using your MAC address as the default Wi-Fi password. The tell you processor versions, chip ID’s (they are often covered up with heat-sinks you need light munitions to get off), kernel versions, precise software versions, and tell you all the modes that things are running in/at/on. I may do some detailed commentaries on some bootlogs to show how this works.

So… now what?

So from my point of view, that is the why for doing hardware hacking. Next up will be an in-depth look on the how - starting with UART.

Stay tuned.

I’m always forgetting, so I’m putting this here because I keep forgetting my f0rking cheatsheets on other machines.

So, in case it’s useful, here we go…

Note: this is currently mostly ARM stuff, but the majority of the commands (except the forced mode change stuff) work for x86 and the like.

Useful Commands

I also find these commands useful when debugging (on linux/posix like environments):

Acknowledgements:

HT @Fox0x01, and MW for their helpful comments and contributions :-D

Unprovability and Beyond

In 1931 Kurt Gödel was 25 and published a paper following on from his doctoral work - titled “Über formal unentscheidbare Sätze der “Principia Mathematica” und verwandter Systeme”, or in English “On Formally Undecidable Propositions of ‘Principia Mathematica’ and Related Systems”, and provided to the world one of the world’s most significant achievements in Logic. As John von Neumann put it [1]:

“Kurt Gödel’s achievement in modern logic is singular and monumental – indeed it is more than a monument, it is a landmark which will remain visible far in space and time. … The subject of logic has certainly completely changed its nature and possibilities with Gödel’s achievement.”

But little is truly understood about this result, nor why what happened in the latter part of the 20th C. was so important in our ongoing search for suitable foundations of mathematics.

What foundations to build mathematics on?

Calculus Conundrums

It’s hard for non-mathematicians to appreciate what is wrong with mathematics. It seems so stoic, and objective, but anyone who takes some time to learn in any detail the actual work of mathematics will come to a startling realisation; mathematics is a language, and like any language, it can carry opinions coded into algorithms (more on this later) and theorems carry the weight of many human assumptions.

But mathematics just ‘works’ right? Right?

Well, yes. And no.

Bishop Berkeley, an 18th Century Irish Bishop of Cloyne, philosopher and mathematician, wrote a text called ‘The Analyst’ [2], subtitled

A DISCOURSE Addressed to an Infidel MATHEMATICIAN. WHEREIN It is examined whether the Object, Principles, and Inferences of the modern Analysis are more distinctly conceived, or more evidently deduced, than Religious Mysteries and Points of Faith

Heavy stuff, no? Well, he had a problem - ‘fluxions’. What are these? Well, he describes them as follows;

It must, indeed, be acknowledged, that [Newton] used Fluxions, like the Scaffold of a building, as things to be laid aside or got rid of, as soon as finite Lines were found proportional to them. But then these finite Exponents are found by the help of Fluxions. Whatever therefore is got by such Exponents and Proportions is to be ascribed to Fluxions: which must therefore be previously understood. And what are these Fluxions? The Velocities of evanescent Increments? And what are these same evanescent Increments? They are neither finite Quantities nor Quantities infinitely small, nor yet nothing. May we not call them the Ghosts of departed Quantities?

The problem that Berkeley had comes from the following descriptions; We are all familiar with taking the gradiant of a line. On an $xy$ plane, each point on a line is given as $(x,y)$ and for a function generating a line, where $y = f(x) = x+2$ each co-ordinate on the line is given by $(x,x+2)$ (such a set is called the graph of the function - graph refers to the set, not the line). The gradiant is given by the change in y, written $\Delta y$ divided by the change in x, or $\Delta y / \Delta x$. This makes sense - we’re asking ‘what change in $y$ happens for every singular change in $x$?’.

But what about a graph that has a ‘bend’? Like $y = f(x) = x^2$? Well, this is where stuff gets tricky. Take two points - $(2,4)$ and $(3,9)$, the gradient here is clearly 5 (x changed 1, y changed 5, so it follows). But now take the gradient of $(1,1)$ and $(2,4)$ - it’s clearly 3. Now take $(2,4)$ and $(2.5,6.25)$ - the gradient is now $2.25 / 0.5 = 4.5$… so how can we make any sense of this?!?

Well, this was the coincident genius of Newton and Leibniz; Pick 2 points $(x_1,x_1^2)$ and $(x_2,x_2^2)$ where $x_1 < x_2$. Calculate the gradient of the straight line between this pair, then choose some $x_3$ where $x_1 < x_3 < x_2$ and calculate the gradient between $(x_1,x_1^2)$ and $(x_3,x_3^2)$ and you’ll see that the gradient is not as steep; it is clear that, so long as there are no breaks in the line, then we get $\Delta x / \Delta y$ approaches some value based on which $x_1$ we chose. If we make choices of points that get closer and closer and closer to $x_1$ we eventually will see that the value is approaching $2x_1$, and if we imagine some infinitely small point, an infinitesimal or fluxion, distinct from but of zero distance from $x_1$, we get that the gradient of the line ‘at $x_1$’ is just $2x_1$.

This ‘going to the limit’ was the birth of calculus as we know it today. But think about what we’ve done? As our choices of $x_n$ get closer to $x_1$, the length of the line $\Delta x$ approaches 0, and when we use an infinitesimal, the length $\Delta x$ is zero, which means we are calculating our gradient as $\Delta y / 0$!! Anyone who did high-school mathematics will remember that ‘dividing by zero is the devil’ (exact cultural descriptions may vary).

And in many ways, this and other problems of something ‘so infinitely small it can’t exist’, formed the basis of Berkeley’s critique - and it still hasn’t been resolved philosophically to this day!

But surely we can just throw it away?!?

If only it were that simple - it’s so damn useful! Calculus and related topics (Linear analysis, Complex analysis, etc.) form at least one side of the backbone framework of pretty much all science (physics, chemistry, biology) rely on (the other side being statistics, but there is a like argument for Bayes Theorem and Bayesian Statistical models have their own special philosophical problems).

Foundational Quests

With the advent of modern science - Newton graduating Natural Philosophy to Physics by means of applying mathematical rigour, and the deep theoretical as well as experimental results of physicists like Maxwell, Kelvin, et al., we have come to rely on this idea. David Hilbert, famously, announced a project to give rigorous foundations to mathematics in such a way, as he claimed [3]

For us there is no ignorabimus … our slogan shall be: Wir müssen wissen — wir werden wissen!

Essentially, there will be nothing we cannot know for sure! A bold statement, but Hilbert was on of the eminent mathematicians of his age. Frege gave a full account of mathematics through the language of sets, and the resulting set theory was a monument of mathematics, but by the pricking of his thumbs…

Something Wicked This Way Comes.

Many are familiar with Russell’s Paradox;

Let $R$ be the set of all sets that are not members of themselves. Is $R \in R$?

The proof I will omit here (sorry peeps), but it is rarely appreciated how much of a headache this made for Frege! He had to add an addendum to his great work, the Grundlagen, stating that the paradox existed, and that actually the whole things may be wrong!

Russell had effectively pulled the rug out from under the efforts of some of the finest logicians of the 19th Century, and caused them to rethink their work.

This did not deter Russell himself from launching into the fray - along with Whitehead he composed the Principia Mathematica. By building a theory of types (the essential idea of a type being that something of one type (a set) cannot refer to things of another type (an atomic element) without lots of restrictions being satisfied) they created a monument of logical reasoning - from first principles, they built an entire system of mathematics that proved that $1+1=2$, but with sound, solid foundations that were, they thoughts, unshakeable.

They were badly wrong.

From Greek Truth to German Proof

We all know the ancient Greek paradox

This sentence is false.

Is that true of fales? Well, you can’t decide. If it’s true, then it must be false. If it is false, then by the double negative, it should be true. If we try to establish such a statements truth, we will fail.

But mathematical proof is a thing we just did - we showed with reasoning and argument that something can have ‘indeterminate truth’. So, for 2 millennia, mathematical proof was seen as the tour de force of rational reasoning. Anyone can read a proof and know something, if they work through all the details. Proofs last millennia, unchallenged (cf. Euclid’s Elements), and give our further reasoning solid basis. Indeed, the notions akin to ‘standing on the shoulders of giants’ (when not Newton calling Hooke a short-arse) rely on this notion that everyone who went before and provided work didn’t mess up.

Proof was seen as an absolute - if mathematics is the queen of the sciences, then proof is her ruling sceptre.

Try telling Gödel that. His theorems are fairly straightforward to grasp - I’m not going to put the technical details here (they’re all over a duckgo search). Gödel’s first incomleteness theorem is as follows: [4]

“Any consistent formal system $F$ within which a certain amount of elementary arithmetic can be carried out is incomplete; i.e., there are statements of the language of $F$ which can neither be proved nor disproved in $F$.”

So, essentially, if your theory is strong enough, then there are always sentences that you cannot prove.

So proof is not immutable. Proof is not absolute.

Part II - Where we went next…

[1] Halmos, P.R. “The Legend of von Neumann”, The American Mathematical Monthly, Vol. 80, No. 4. (April 1973), pp. 382–394

[2] Berkeley, George (1734). Wikisource The Analyst: a Discourse addressed to an Infidel Mathematician. London: Wikisource. p. 25.

[3] D. Hilbert (1902). “Mathematical Problems: Lecture Delivered before the International Congress of Mathematicians at Paris in 1900”. Bulletin of the American Mathematical Society. 8: 437–79.

[4] anu Raatikainen, 2015, “Gödel’s Incompleteness Theorems”, Stanford Encyclopedia of Philosophy.

Digisparks are very cheap and quite versatile - and they support USB emulation! This is quite a nice property, and I’m sure I’ll release more examples of things I’ve done with this very nice ability.

I have looked at these for a while, but here’s an introductory example. This sketch can be loaded into arduino editor and compiled and sent to the digispark as usual. See here for a tutorial on how to do this.

So here’s what this does:

1. will emulate a keyboard in the usual way
2. will ‘type’ a string when plugged in.
3. will type a different string if a paperclip or something is used to bridge 5v pin hole to p0 pin hole.

May come in handy to someone wanting to have ways of securing devices with long random strings. You can generate random strings with cat /dev/urandom | tr -dc 'a-zA-Z0-9!' | fold -w 128 | head -n 1 but remember that as keys move around (like “ and @ between US/UK keyboards) you can’t add too many symbols to the tr -dc argument.

Hope it’s useful to someone!

#include "DigiKeyboard.h"
#define KEY_UP_ARROW   0x52
#define KEY_DOWN_ARROW   0x51
#define KEY_LEFT_ARROW   0x50
#define KEY_RIGHT_ARROW   0x4F
#define KEY_Tab 43

void setup() {
  pinMode(1, OUTPUT); //LED on Model A 
  pinMode(0, INPUT); // pin zero
}


void loop() {
 digitalWrite(1, HIGH);
 //for(int i=0;i<70;i++){DigiKeyboard.sendKeyStroke(i, MOD_SHIFT_LEFT);delay(500);}
 DigiKeyboard.update();
 delay(1000);
 DigiKeyboard.sendKeyStroke(0); //this is generally not necessary but with some older systems it seems to prevent missing the first character after a delay
 delay(1000);
 // by default pin0 is low. Others, like pin 3, are high, but trying to use them causes issues. The best are pin 0 and pin 1, from my experiementation.
 if (digitalRead(0) == HIGH) {
  // so we bridge with a paperclip from 5v to p0
  // in order to access this program flow...
  // this could be obfuscated or encrypted/encoded to make RevEng harder to a H/W analyst
  DigiKeyboard.println("supersecret"); 
 }
 else {
  // if the pin isn't high, then we just output a friendly warning message:
  DigiKeyboard.println("fluffy kittens");
 }
 digitalWrite(1, LOW);
 delay(6000);
}

Open Science - What is it?

Open Science is a lively movement that aims to make the culture and industry that is scientific research open, accountable, transparent, and, well, more scientific. It would be possible fill books of multiple volumes with in-depth descriptions of all that can be said about how a notion of ‘open’ can be applied to the areas of scientific research, the scientific method, the world/game of publishing, etc., but here are a few pointers:

• Open Publishing - the aim here is to get away from paywalling research publication. Research is funded publically, in almost every case, and as such it is the belief of Open Science that access to research should be open.
• Support of ‘non-desirable’ research - lots of science is doing the same thing as other people in order to replicate results. This is not grand nor glamourous resarch, and is seen unjustifiably as in some way boring/mediocre/a waste of talent.
• Open Methods and Open Data - the common belief of Open Science is that all data and tools used to generate the results for a study should be openly available, including precise versions of software used to conduct analysis, precise algorithms that have interacted with the data, as well as Open Protocols, detailing precisely how any other scientist could replicate such work. Yes, there are ethical concerns of genetic/psychological/other sensitive data, but we believe that these are manageable.

An important takeaway is that most poeple involved in Open Science are (understandably perhaps) realists. As such, the mantra don't let perfect get in the way of better is a common theme in the discussions and work around Open Science.

Open Algorithms - What’s the issue?

In short, Big Data and ‘Weapons of Math Destruction’ (a phrase I have stolen from Cathy O’Neil, whose book of the same title is well worth a read).

Many of the algorithms in use in our daily lives are opaque, used without any kind of feedback or ‘common sense’ assessment, and can be hugely impactful on people’s lives and indeed their careers. Academic publishing has not escaped the clutches of this societal problem; algorithms with great opacity are in use to ‘grade’ or ‘score’ academic articles, and these scores are used to determine a researcher’s ‘value’ (for want of a better word) to a department or research group.

This is clearly wrong. We cannot see science and judge our peers through a scorecard darkly.

Background to the Proposal

What we want to do here is introduce a version of an algorithm that is currently in widespread use in the field of Information Security, the Common Vulnerability Scoring System (CVSS).

But that’s a terrible metric!

Yes. And no. Yes, it does have its flaws. Here we are potentially talking of taking on a gargantuan task of designing a scoring system that can be used across multiple disciplines in science, and can score them with some level of sensitivity - what nonsense!

And yes, we would agree, until it is pointed out that this is already the case. This is already the state of affairs. But the difference is this; you can argue with me and my reasoning, call me an idiot, and ideally demonstrate how it should be done.

This cannot be done with the publishers, whose scores can make or break careers.

What we want to do is open this black spot on academic publishing up, and offer a tangible solution.

What it is

This is a description and justification of an algorithm based off a group workshop that took place at the 33rd Chaos Computer Congress (#33C3) in Dec. 2016. Should such a scoring system ever come to actually exist, it would be surprising to see any of the elements here in the final algrotithm, but we need to open up the debate - and the easiest way to get people involved is to no longer simply say ‘someone should do this’, but instead actually offer up a solution.

It is my firm belief that this system is incomplete, or highly localised to my field (mathematics) and locale (UK), given my use of the Research Excellence Framework (REF) criteria as a measurement of ‘Impact’, which is what our universities are mandated to use to justify their funding. These are issues I openly admit from the start.

But it is an open algorithm, that works, based off an algorithm that has a widespread usage and has been well documented and tested (CVSS is used for all PCI DSS related scoring, it is that trusted).

What it is not

The be-all and end-all in this discussion.

Requirements for a Standard

I’ve laid out my motivation, and hopefully have managed some expectations. Here is what I want to offer up:

• Description of the algorithm with justifications
• Pseudocode description of the scoring
• Actual working portable code (in Python/JavaScript/GoLang/whatever I can write at 3am)

It is by giving all these things that I think we will actually make some sort of movement. My aim is that we no longer just talk about ‘how nice it would be if we had an open scoring system for academic articles’, bur to acutally make one, provide example (possibly badly written) code that works, and use such an output as an input for future discussions.

NB - I would actually be happy if people hated this algo and publically ridiculed the ‘silly Scouse quasi-mathematician’. Why? Well, it would mean:

1. they read it
2. they understood it
3. there is a better way, and they’re likely to show the world what that better way is

But this discussion, this disagreement, is only possible in an Open Science environment. At the moment, we as researchers are at the behest of a silent and darkly judgemental algorithm, that is written by people. Algorithms in mathematics is a language like any other - you can express beauty, poetry, and yes, opinions using it. It is not infallible.

Maybe we need an algorithm per Research Council/funding body? Maybe we need an algorithm per individual science or sub-science? (perhaps what works for materials physicists doesn’t work for High Energy physicists?) It is my belief that we don’t know until we have something to argue about, disagree with, and pull apart analytically in order come to some conclusions about these questions.

TL;DR - Now we can be scientific about how we rate/score scientific articles.

Proposed Algorithm - the Common Article Scoring System (CASS)

We propose a Common Article Scoring System (CASS) that is designed to be a generic way of scoring articles based on some loose but important criteria. To do this, all we have done is renamed parts of the Common Vulnerability Scoring System, and tweaked some of the weightings to fit more generically into the scoring.

CVSS Overview

CVSS is used extensively in information security to give a ‘marks out of ten’ (a very human thing) for a vulnerability. In short, there are two sides to a score - the number, and the vector. If you take the vector, you can see how someone assessed the severity of a vulnerability, and my clients could perform their own risk management based off the ability to see how/why I considered some vulnerability a major issue or not.

CVSS is, however, quite old, and in some ways doesn’t really fit many vulnerabilities we see in the wild (I’ll spare the descriptions of how for an infosec blog post), but it is continually maintained and recently a new version was released.

CVSS sees two main areas of risk - Exploitability (how easy is it to take advantage of the vulnerability) and Impact (when taking advantage, how much control of the target system does a vulnerability give me). The break down is as follows:

• Exploitability
  • Access Vector - how do you exploit this (over a network, sat at the computer, etc.)
  • Access Complexity - How difficult is it to exploit? (Do I have to hang from the ceiling Tom Cruise style, or can I do it in my PJ’s?)
  • Authentication - do I have to be logged in once? Twice? Not at all?
• Impact - all metrics are measured as one of None/No Effect, Partial effect, Complete effect.
  • Confidentiality - can I expose sensitive data?
  • Integrity - can I modify any data on a system?
  • Availability - can I make the system/its data unavailable in any way? (Can I turn it off?)

Clearly, this has nothing to do with science, but the framework is, I think, the correct way to think about it. Especially the following requirement - every score must have its vector in order to be valid. This is very important for openness.

The aim is to have a score that is transparent. Suppose a peer reviewer does not want their comments to be made public - not an unreasonable request - having a score like this with this structure would mean that a reviewer’s thoughts on a paper can still be open without compromising their above request.

Algorithm Description

The aim is to have an algorithm that is representative of the amount of work that was put into the research. No, this is not an easy thing to do, but we aim to try in the following ways:

• Honour the scope of a study
• Determine the impact of the study in the sciences (is it fairly bland? Or is it world-leading?)
• Appreciate the scope for reproducibility and data provision - do we have copies of the data, software tools developed, and precise vesions of analytical tools brought into play to reproduce the study?

Here is the algorithm that I have in mind, based on the above criteria (you’ll see a lot is similar in the mathematics, too). The aim is to split the assessment of an article into two areas:

1. Availability - what is the ‘reach’ of the article?
   • Localisation - is the article applicable to Small/large area or study, or is it interdisciplinary?
   • Poss Values: [(S)mall area, (Large) area, (M)ultidisciplinary] * Data Provision - is the data and source, with enough detail for reproduction, provided?
   • Poss Values: [(N)o data/source provided, (M)ost data/source provided, (F)ull provision of significant data/source provided] * Methodology - is it provided with; no detail, overview, or full protocol?
   • Poss Values: [(N)o Detail, (O)verview of methodology, (F)ull details of methodology]
2. Impact - how much does the research impact science/the world? For this, I will use the UK REF criteria as follows:
   • Rigour - Low/Med/High rigour in study
   • Poss Values: [(L)ow, (M)edium, (H)igh] * Significance - Low/Med/High significance or study
   • Poss Values: [(L)ow, (M)edium, (H)igh] * Originality - Low/Med/High level of originality
   • Poss Values: [(L)ow, (M)edium, (H)igh]

The mapping for the score weightings is precisely isomorphic to the above description of CVSS, which we will make clear in the next section (cf. the description of the CVSS score calculation).

Here is a more in depth description of each area:

The Availability of a paper comments on the ways in which another researcher can interact with it. Could someone else reproduce the same results from the same data? Is the article relevant to a large audience across multiple disciplines, or is it localised to 3 blokes in a shed just outside Leeds? Here’s how I broke this down:

• Localistion - Is the study relevant to a small audience? Or a large one? Improving upon this, is it a fully multidisciplinary study?
• Data Provision - Do we have the full set/relevant chunks of data? Do we have enough data to reproduce a study? Can we accurately say what the raw data looked like from the submission by the authors?
• Methodology - Do we have access to full descriptions of methods and protocols used? Do we know what statistical methods were used to assess the data?

The Impact section of the score is used to assess the way in which the study in question can be said to have ‘impact’. This is a very sugjective score, but objectively, it is well defined in the Research Excellence Framework used in the UK. To that end, I’ve mapped those criteria to the risk assessment criteria of CVSS as low/med/high (for the none/partial/complete in CVSS) to fit the calculation as it stands:

• Rigour - how rigorous was the study? Was the sample set large enough? Were the controls suitable? Were pitfalls suitably identified and mitigated/assessed in the study?
• Significance - what is the signifcance of the study? Does it break new ground or spark a new area of study? Or does it only confirm basic results?
• Originality - how original is the study? Did they find a new, super, amazing, wonderful way of interpreting the dataset? Or did they follow only established protocols and paradigms in the field?

As is hopefully clear, the logical (to me) fact that a highly original, multi-disciplinary study that provides full data/source code and gives detailed methodologies gets a significantly higher score than those that simply reproduce well-known results without anything of real interest.

Pseudo-code Overview

Output_Score = round_1dp(((0.6*Impact)+(0.4*Availability)-1.5)*f(Impact))

Impact = 10.41*(1-((1-Rigour)*(1-Significance)*(1-Originality)))

Availability = 20*Localisation*DataProvision*Methodology

f(Impact) = [1 if Impact=0, 1.176 otherwise]

Localisation = one of the following:
	0.395 if small area
	0.646 if large area
	1.0 if multidisciplinary

DataProvision = one of the following:
	0.35 if little to no data provided
	0.62 if most data and/or some source code provided
	0.71 if full data and source code provision

Methodology = one of the following:
	0.45 if methodology not provided
	0.56 if most methodology provided
	0.704 if full methodology provided

Rigour = one of the following:
	0.0 if Low rigour is set
	0.275 if Med rigour is set
	0.660 if High rigour is set

Significance = one of the following:
        0.0 if Low significance is set
        0.275 if Med significance is set
        0.660 if High significance is set

Originality = one of the following:
        0.0 if Low originality is set
        0.275 if Med originality is set
        0.660 if High originality is set

NB - this is a shameless copy/paste effort atm. Going to do some more maths to determine whether f(Impact) is needed, for example. Probably not, is the answer.

Overview of changes from CVSS

1. f(Impact) returns 1 if Impact is zero, 1.176 multiplier if > 0 - this is because a paper can have low/low/low on the impact scorings, but still contribute knowledge and data.

Example Implementations

To follow… I’ll make a github repo.

NB Like pretty much everything on my site, I’m not writing this for the technically uninitiated. Fair warning, if the first few bits are hard, it’s probably meant to be that way. Pro tip - if you haven’t ever done any soldering, fix that first. I will assume a basic knowledge of electricity/rudimentary electronics here.

Also, some of this stuff may be controversial from the point of view of those who dislike cheap Chinese knock-offs.

Worked example for the uninitiated

Tools of the trade

To get started in hardware hacking, only two tools are really required;

1. A Logic Analyser
2. A USB to UART converter

Yup. That’s it. You can get the first from saleae, and they’re very reasonably priced, decent devices that are about the right price-point for entry level hardware hacking. However, there are also cheap Chinese knock-offs selling for £3.94p, that work with the software which Saleae provide for free. Yes, for FREE. So, do them a favour, and when you earn lots of money from hardware bug bounties, GO AND BUY A REAL SALEAE IF YOU HAVEN’T!! But I promised to have a blog post that shows you how to get into this for under a tenner, and I mean it.

Second is a USB to UART converter. Yes, you can get these for £6 on Amazon, but on AliExpress and at time of writing they are from around £0.82p, and that’s for ones using the CP2102 chip (which I would recommend).

So, assuming that you have the following devices:

• Soldering iron
• Solder
• Some insulated wire
• Multimeter
• A USB male to mini-USB male cable (to connect to the logic analyser)

The only other thing you may need to buy are some taps - these are little clips you can use to ‘tap’ onto the legs of IC’s. Here are some examples; search for ‘test folder’ or ‘test hook clip’. These are usually about £1.18p.

So, the grand total cost, £5.94p, if you don’t mind waiting up to three weeks for delivery and no guarantee that the stuff will work, is basically what it takes to get started on hardware hacking.

But what can we do with these?

Well, first off, find a device. Any device. Go on amazon, which will helpfully tell you which devices are the ‘most popular’. Look at those.

Murphy’s Law of IoT:

“The router/camera/internet toaster in your home, with access to all your data, was made by the lowest bidder…“

We’re in a scary world, device wise, and you’re about to see how bad it really is. The basic methodology is this:

Step 1. Identify developer headers

Developer what-ers? Developer headers. They are the serial connections used to debug devices when in production. For a gallery of what to look for, see this google image search for ideas. What you’ll want to do is to solder some wires or pins onto these, having removed the solder first. If you’re not sure how to do that, there are lots of videos/tutorials online. Just remember to tin wire ends before soldering, to make life easier.

Step 2. Analyse identified header pins

Ok, so now we’ve got a header, now what? Well, this is where it starts to get more interesting (and fun, in my opinion!). Find ground with your multimeter (one of the pins will have conductivity to the unified ground on the outer-collar of the power supply for example) and put that pin to the ‘GND’ pin on the logic analyser. Then put the rest of the pins to successive channels, plug in the analyser, and open up Logic.

We now need to set the sampler, as follows:

This will set the analyser to collect 4 million samples per second, for a duration of 30 seconds. So, with this set, let’s get some data! Press the big ‘Start’ button, and then turn on the router (yes, do it that way round). You’ll see Logic running…

…aaaaaand then it’ll finish, and you’ll have some sampled data! \o/

Step 3. Identify pins and data about data transfer

Ok, so we’ve got some binary data. This, by itself, doesn’t mean much. So we need to recap how UART (Universal Asynchronous Receiver/Transmitter) protocol works. Essentially, there are two ‘data lines’, power, and ground. The data lines are ‘Tx’ for ‘transmit’ and ‘Rx’ for ‘Receive’. The Tx pin of one side goes to the Rx pin of the other, and vice versa. On a standard ‘8N1’ setup, the protocol operates in the following manner:

1. The transmitter first drives down the voltage of the line. It’s held high by default, so this tells the receiver to ‘pay attention’ and this initial ‘0’ is called the ‘start bit’.
2. The transmitter then drives changes in voltage from high to low to represent ‘1’ and ‘0’ as required by the data they want to transmit.
3. After 8 bits have been transmitted, a ‘stop bit’ of ‘1’ is sent, essentially raising the voltage to how it was, and then not transmitting any more data.

The system is now ready for the process to repeat all over again, on either line. Here’s a nice little diagram of this from embedded.com

But how do the devices regulate their data transfer?!? Good question - Suppose we want to send ‘11111111’; how does the receiver know that it’s 8 ‘1’s and not just a long stop bit? Well, in short, it depends on the serial protocol in play. Most serial protocols have a ‘CLK’ or ‘clock’ signal that is used for timing of changes in bits. In UART, however, we choose a fixed bit-rate, or ‘baud rate’ with which to transfer data.

This baud rate can be literally any value at all, but in the interests of standardisation there are many common baud rates. The most common you’ll see in IoT devices and routers and the like are:

• 9600 (commonly used by arduino)
• 115200 (most common on routers and IoT device UART ports)
• 57600 (the other one I’ve seen the most).

There are lots of online lists of these, and where they are found. But how do you KNOW?!? Well, in short you don’t. There are two easy ways to identify baud rate:

1. Read the datasheet for the chip you want to talk to.
2. Guesswork/bruteforce the baud rate by trial and error.

Yes, that may sound very inelegant, but it doesn’t take very long. The easy way is to just experiment on the samples you collected earlier using the built-in ‘Analyzers’. Look at the right of the screen in Logic, and you’ll see a little box in the middle of the right-hand pane called ‘analyzers’ - click on the ‘+’. The following screen will pop up:

So, first, assign the channel - in my example, it would be ‘Channel 1’. Then choose a baud rate. Start with 115200, then try 9600, then try 57600, then google for the others and try those. However, it’ll be really obvious when you’ve got it right, because in the lower right-hand pane labelled ‘Decoded Protocols’ you shouldn’t see any weird characters, like decimal ‘2xx’ references, etc.

When this works, and if you’re curious, you’ll also be able to zoom in (mouse wheel) to a part of the digital signal and see where characters have been identified, like this:

You should be able to make out version 1.04 in the blue boxes above the signal. Kinda cool, right? Well, Saleae have done a really nice job on this software, so they deserve credit for it!

Step 5. Connecting up the UART

So, you’ve got your USB to UART converter, and you’ve soldered on some wires/pins and identified which is Tx, and with your multimeter, you can work out which of the others is Rx and +ve (Hint the one with the higher voltage is usually the power rail. If it doesn’t work, try swapping them…).

Now what?

Well, you connect! How? Just use screen.

What, screen? The one I use all the time to run things over ssh?

Yeah, that screen. When you plug in the USB to UART converter, you’ll get a new device. I use linux, so it’s /dev/ttyUSB0. We know the baud rate, so the structure of our command will be screen /dev/ttyUSB0 (baud rate) or in this example screen /dev/ttyUSB0 115200. So, connect the converter, fire up screen, turn on the device, aaaaannnddd….

(Hacker Voice) We’re in

[Oh you use Windows? I’m so sorry. Have you tried using a real operating system?

LOL… jk… I just have no idea how to do any of this on windows. Sorry. (not sorry) ]

So, now you may see a prompt such as ‘press any key for terminal’. Or you’ll just see something like

@devicename#

Which, yeah… is a root shell. Wait, a r00t shell!? Yeah, a root shell. Many of them default to booting to root because that’s what you need when you’re debugging. All that text you saw flying past? Well, that’s known as the bootlog and that’s full of very, very useful information including

• Chip ID’s,
• kernel versions,
• gcc versions,
• service server/daemon versions including
• linux build dates,
• webserver versions,
• ACS/TR069 versions,
• wpa_supplicant settings,

and much more. Plus, having a root shell gives you acces to:

• source code,
• stored passwords in /etc/passwd and /etc/shadow files,
• full configuration files
• …yeah, the works.

But I’m a pentester… how can I use this more?!?

If you have to be told that, then this blog probably isn’t for you, but here are some ideas:

1. you now have access to the firmware bootloader at startup. You can setup a tftp server and get the device to dump its firmware directly to you
2. you can test for RCE exploits by just writing to this terminal with something like input"; echo "test123" > /dev/ttyS0; and keeping an eye on the console.
3. Editing configuration files in the back end
4. flush iptables
5. …let your imagination fly…

Oh, and this is only through UART. There are other ways to hack hardware that vary in complexity, but for the effort to cost to benefit ratio, getting access to a UART port is superb. Well worth the slog!

Dirty Tricks

Sometimes manufacturers will play dirty tricks. Here are a few I’ve seen:

1. They will include two resistors on development/prototyping boards to permit access to a UART header, then ‘leave these out’ on production builds
   • nothing a quick bit of solder to bridge the gaps won’t fix, just a matter of finding them
2. Some boards detect if UART listeners are present, and deactivate the header (thanks Virgin Media Superhub)
3. Some manufacturers actually remove these development headers (ONCE! I’VE SEEN IT ONCE!)
4. Often, you won’t have nicely laid out pins, but rather, a plethora of ‘contact points’ - just metal circular pads that you can solder onto.
   • I know how to connect to these, but it’ll take a video, I think.

Thoughts and Feedback

Do get in touch over twitter or any other media you find me on and let me know what you think!

I hope it was in some sense useful. M.

This bit is like the extra bits on a DVD, but really, it’s just more maths. For those who care, WHICH SHOULD BE ALL OF YOU but I appreciated that

1. Maths is not everyone’s cup of tea
2. If this material is new, the following stuff may be too far down the rabbit hole
3. People genuinely don’t care about this stuff

The last point is the only one I have an issue with - Turing asked the question ‘is the Halting problem the hardest problem for computers?’ If yes, we have a discovered the limit of what we can do computationally, which is a profound statement! If not, then we can always build on our computational complexity indefinitely.

This is important for AI work - AI engineers just don’t understand the notion of ‘information exchange’ when writing a program. I’ll explain more on this at the end.

Tl;dr - computation and computability of problems means we have to be sensitive and understand not just the what, but also the where about the information we are working with. This is a key, and oft misunderstood point in computer science, that computability theorists know so well!

Enumerable vs. Computable functions

We have so far talked only about computable sets - that is, a set (think ‘bag of things’) where we can decide what is in/out of the set (bag) using a Turing Machine. We can ask ‘Is 53 in set $A$?’ by asking $\phi_e(x)$ and getting a ‘1’ if it is in $A$ and a ‘0’ if not. The name for such a computer function is the Characteristic Function of the set, in case you see it in books/papers/wikipedia.

But there is an idea called ‘Computably Enumerable’ that is somewhat different from this - a set (bag) $A$ is enumerable if there is a computer program $\phi_e$ where if we ask it $\phi_e(294)$ then we will get the 294th member of $A$.

We can write this more ‘mathemtically’ by saying that we can represent $A$ as $A = \{ a_1, a_2, a_3, \ldots \}$ (this is actually the usual way of notating sets, with $\{$ and $\}$ brackets). Here, $a_1$ is the first member of $A$, $a_2$ the second member, and so on. If a set $A$ is enumerable, then we can use the computer program that gives its members to define the set as $A =\{ \phi_e(1), \phi_e(2), \phi_e(3), \ldots \}$.

But what use is this? Well, this gives us yet another way to talk about functions. The idea we want to show is that if a set it computable, then it is enumerable. This may not seem immediately doable, so let’s run through it.

Let $f()$ be the function that gives ‘yes/no’ as to whether the number we input is in our set, and let $g()$ be the function that gives you the member of our set at position $n$ (so $f(24)$ gives you the 24th member of our set). For ease, we’ll call our set $A$.

First, we want to get $g()$ from $f()$; so we have our $f$ and we construct a program like so:

def g_from_f(int x):
    int counter=0
    int numbers=0
    while (counter != x):
        numbers += 1
        if (f(numbers) == 1):
            counter++
            break
        else:
            break
    else: 
        return numbers

Hopefully this is quite clear as to how it works - we run through all the numbers (positive integers) and every time we get a ‘hit’ from $f()$ (that is, $f$ returns a 1) we add one to a counter. When the counter equals the input number, then we output the number we got to, and we have made $g$ from $f$.

This is actually a theorem - and we just did a proof. WAT? yeah, really. We had an idea, we showed that it is consistent and always works, and then we demonstrated it, and now we have a proof. That’s maths, yo…

But we can also show something else that’s interesting. Take my little program above, only on line 6, replace if (f(numbers) == 1): with if (f(numbers) == 0):. What have we got now? Well we’ve made a version of $g()$ that outputs every element that isn’t in $A$. That is, they are in the bag of everything not in $A$ - we call this the compliment of $A$ (although, only desribing everything you’re not doesn’t seem that complimentary to me, but hey, it’s the word we use…), and we write this as $\bar{A}$

So what have we found here? Well, we can always do this action, so we’ve found that if we have a computer program that decides if a given number is in/out of $A$, then we always have a computer program that describes $\bar{A}$ (not-in-$A$). This is very useful - think of it the opposite way; as if we can describe everything not in a set with a computer program, we automatically get a program for everything in that set. So if describing $A$ is hard, maybe describe $\bar{A}$ instead, and you get the program for $A$ automatically! ;-)

Bonus Theorem

Theorem: If $A$ and $B$ are enumerable, then so is $A \cup B$.

The proof of this is quite easy - suppose $f_A$ gives all members of $A$, and likewise for $f_B$. We can run each program concurrently to get $A = \{ f_A(1), f_B(1), f_A(2), f_B(2), \ldots \}$, and remove any duplicates along the way. Thus, $A \cup B$ is enumerable.

Oracle Turing Machines - solving the Halting problem

I’ve read some articles (not going to embarrass people by pointing htem out) who have said “Turing Solved the Halting Problem!” (look in some old issues of New Scientist, for example). He didn’t. What Post, Kleene, Turing et al. showed was two things:

1. The Halting Problem is enumerable
2. The Halting problem isn’t the hardest problem for computers

The first one is quite straigtforward to see (the formal version can get a bit involved, so I’ll do it with words and ideas); you make a Super Universal Turing Machine that runs every program on every input. (If you aren’t convinced this can be done, just realise that every computer program has a number, $e$, and so we find every number, find every input, and run every input on every number as $\phi_e(x)$.

We then wait for things to Halt. As soon as something halts, we clear it’s computation from the tape, and leave the answer in its place. We’ll never get the full answer to the Halting Problem without infinite time spent on it, but we will get so many answers that we can use in a reasonable amount of time (within a few lifetimes). As such, the Halting Problem is enumerable.

But you showed it couldn’t be solved??

Ah yes, but this is a key idea, all computable functions are enumerable, but the converse is not true - not all enumerable functions are computable. The Halting Problem is not computable, but we can, in theory, with enough time, work out initial pieces of it. We can never have a computer program that just answers “Does a computer program $P$ halt on input $x$?”, but we can get answers for so many $P$’s on so many $x$’s (NB - $P$’ing on an $x$ is not a nice thing to do.)

Side note - we showed that the Halting Problem is undecideable. This argument shows that the Halting Probem is unsolveable; The argument for this is currently beyond the scope of this article.

Glass Ceiling

What Turing in particular wanted to know was this - is the Halting Problem it? If we solve it do we get all the computable things??

tl;dr No.

Turing asked the question - suppose we just ‘answered’ the Halting Problem. Just suppose we did. And we then wrote this answer to an infinite tape and gave that to our Turing Machines as an second tape. Kind of a ‘cheat sheet’ - like the ‘oracle at Delphi’ in ancient legends, it has answers, and we don’t care where it got them from.

This is the construction for Oracle Turing Machines - Turing Machines that have a second tape with answers to some problem already written there. But what use is this?

Well, Turing managed to show that there are, in fact, problems that are HARDER than the Halting Problem. ‘Harder’ is a very subjective term - dancing like I’ve not just OD’d on Ritalin is very hard for me, whereas getting Domain Admin through a website flaw is something I find very easy. (Don’t worry, it’s my day job… I’m a pentester remember?)

But which problems?

Well, the easiest one is $Fin$. We first need to introduce two ideas around functions - each function $f$ has two pieces, the domain, or, set of things that go in, and the range, or, set of things that come out. If $f(x)$ always equals one, then the range is just $range(f) = \{ 1 \}$, for example. With computable sets, we say that the domain of a computer program is the set of values $W_e$ such that any value $x \in W_e$ is a value on which $\phi_e(x) \downarrow$ (that is, $P_e$ halts on input $x$).

$Fin = \{ e | W_e \text{ is finite}\}$

What is this mystical notation? Well, this is a standard set prototype - we say that $Fin$ is every $e$ such that the set of values for which $e$ halts, $W_e$ is finite. The argument is too long to put here, and we’d need a lot more mathematical ‘machinery’ in order to do a full argument, but this is one of a small group of problems shown to be problems that the Halting Problem is ‘weaker’ than.

Turing Degrees and Information

I’m not going to even define the Turing Degrees, but just siffice to say that where you have a hierarchy such as I’ve described, mathematicians call these ‘degrees’. That is to say, the sets of all the sets (usually called ‘classes’) which have some equivalence under the halting problem (see Turing Reducibility on google) form a degree.

Intuitively, they all share some level of information that allows them to be reducible to the Halting Problem in some way. There are many ways to show this, as you can probably start to imagine.

The key point to all of this is as follows - computation and computability of problems means we have to be sensitive and understand not just the what, but also the where about the information we are working with. This is a key, and oft misunderstood point in computer science, that computability theorists know so well!

Halting Problem and Artificial Intelligence

This is the next article, wherein all that I’ve talked about will show a fundamental flaw in the way most people understand AI.

This is the second in what I’m hoping will be a series of articles entitled ‘Maths for Hackers’. For a ‘manifesto’ or sorts, see the ‘About’ page.

I recommend reading the other article first, as this is a continuation of that work.

The Halting Problem

This is a very famous problem - probably the most famous thing that Alan Turing did, aside from the fabled Turing Test (we’ll get to that later).

The halting problem can be stated as follows:

The Halting Problem - we know that certain computer programs don’t HALT on certain inputs. Is there are computer program $\phi_{HALT}(P,x)$ that can decide for any program $P$ whether it will halt on any given input $x$ or not?

Simple right? Well, it’s actually quite a complex problem. But first, we need to solve the hidden problem-elephant in the room - can one Turing machine simulate all the actions of another? Can we virtualise a Turing machine on a Turing machine? Is such a ‘yo dawg!’ moment really possible?

The Universal Turing Machine

This is where things get a little more interesting - so, here’s a tl;dr just in case: there exists at least one Universal Turing Machine (we’ll refer to it as a ‘UTM’) that takes two things as an input - a Turing program $P$, and an input $x$. This UTM will effectively run any program $P$ on input $x$, and the UTM’s behaviour will copy the behaviour of $P$: if $P(x)$ (read that as ‘$P$ on $x$’ - nothing to do with urination…) halts with output $y$, then $UTM(P,x)$ will halt with output $y$, and if $P(x)$ does not halt, then you guessed it, $UTM(P,x)$ will not halt.

To all those who are slow clapping the ‘idiot mathematician teaching computerers how 2 du VMs’, let me just elaborate - before Turing, there was NO unified model of computing. Computer meant a person, usually a woman (WWII Bletchley Park Wrens who did the calculations were called ‘computers’), who sat doing calculations all day. The notions of a machine simulating a machine in full was as crazy to academics back then as Google’s AI that made its own crypto is to us now. We’ll look back at this in years to come and wonder how it was ever ‘inventive’ as a use of neural nets, I am quite sure.

Turing invented the virtual machine in 1936. 27 years before IBM built their IBM 360 emulators for backwards compatibility in 1963, and 30 years before the O-Code interpreters. And his genius do not end there…

But how do you prove that this can be done on a Turing Machine? Easy. You write a program that will go between the two input strings - the program $P$ and the input $x$ and perform the computation by doing seek-left look ups for what to do, then seek-right and do the action on the current form of $x$ on the tape, and then go back and forth doing the computation.

But what does this look like? Well, that’s actually the easy bit. We can add some symbols and states that $P$ doesn’t use but our UTM does. We will use these symbols to keep track of where we are in $P$ and $x$, and use special states to let us do this seeking back and forth. Remember, $P$’s states are now symbols so we can have a state for each symbol in $P$ as it is on the tape, and use this to track the internal state of $P$ in our computation.

If you’ve done anything with writing emulators or VM software, or even just tried your hand at qemu or vmware, this should all sound very familiar. That’s because it is, and it’s not a million miles away from how Turing originally proved the theorem.

Magic.

But we still have to resolve the pesky issue of providing a…

Proof of the Halting Problem

Ok, so this is probably sounding a little intimidating, but if you got the proof in the previous section, you’ll get this no bother. Just takes a little bit of effort, but it’s well, well worth it!!

Ok, so let’s assume (because we’re mathematicians and we can because we’re cool and we really wanna go the party and … Never mind) that the Halting problem can be solved. We will show the opposite, but first we need to start somewhere. The easiest way is to assume it can be solved, and show that something weird/nonsensical/illogical captain/contradictory happens.

So, if we can solve the Halting Problem, then we have a machine, call it ‘Halt()’ that takes 2 inputs $P$ and $x$, which we know we can simulate all or part of $P$ acting on input $x$ if we have to (see why I introduced UTM’s first?). But what will it do? Well, $Halt(P,x)$ will return true if $P(x) \downarrow$ (‘$P$ on $x$ halts’) and false otherwise.

COOL! So, we’re done, right? Answer: Sodium MonoBromate…

NaBrO…

Let’s make a counter program $foo()$ (like all good programmers) and have it do this:

def foo(P.tostring()):
    if Halt(P,P):
        foo(P)
    else:
        return

So, if $Halt(P,P)$ is true, the function loops forever. If $Halt(P,P)$ doesn’t halt then $foo()$ halts. $foo()$ is one contrariwise mofo.

Now, the following thought may have crossed your mind: So what?!?

Well, consider the following:

If your reaction was WHHOOOOOOOAAAAAAAAAAAA!!!!!!! then come study Computability and let’s write some beautiful theorems together…

If not, let me explain. We’ve just created the computation equivalent of “This statement is false. True/false?”. Here’s how:

• if $foo(foo())$ halts, then $foo()$ loops forever…
  • So by this looping forever, $foo(foo())$ never halts…
    • So by this, $foo()$ must halt here, as it always halts if the input doesn’t halt…
      • Go back to the beginning…

This is an endless loop of contradictions. When a statement falls into this trap, it is called undecidable - as in, you can’t decide at all whether $foo(foo())$ halts or not.

So is $foo()$ broken? Well, no - look at it! It’s clearly a very simple program that is evidently computable (meaning ‘obvs… can totes be done on a computer, yo(lo)…’). So the problem isn’t with $foo()$ - it’s a lovely program.

This means, through logical deduction, that it must be $Halt()$ that is broken. If $Halt()$ can be so easily broken so as to create an instance where it doesn’t hold, like we just did with $foo()$, then the Halting Problem will always be inherently undecideable. We can always construct $foo()$-like functions to reprove this theorem.

tl;dr - There can be no $Halt()$ program, because if $Halt()$ does what it says it does, then we can make it do the exact opposite. Therefore the very idea that $Halt()$ exists is false. There can never be any program that answers the Halting Problem.

But this isn’t the only major result in computability I want to introduce - there’s the rather weird and wonderful…

The Recursion Theorem

The ‘Recursion Theorem’ is a type of theorem called a ‘fixed point’ theorem. They’re ace. They tell you that you have a ‘fixed point’ in any scenario of the actions proclaimed. What does that mean? Well, here’s an easy example:

The Mountain Path Fixed Point Theorem

So, to allay fears, this is not an allegory or rewrite of the recursion theorem - this is a completely different fixed point theorem! I want to use this example to show that fixed point theorems are a bit mad! This was initially taken from a Malcolm Stewart book of puzzles (they are totes amaze!) here’s the conundrum:

A man leaves at 8am one day, and ascends a mountain to the very summit. He stays the night at the summit (meditating and such), and at 8am the next day he descends the mountain. Is there a time on both days where he is at the same height up the mountain?

Now, it’s fairly obvious that the man goes up and down the mountain at different rates - he is almost certain to descend a lot faster than he ascends, for example. But there is always a time, on both days, where he is at precisely the same height up the mountain.

Wat??

Yeah, that’s the brilliant thing about fixed point theorems - they demonstrate the existence (but not necessarily the construction) of values in our functions that have some fixed nature.

But is this true of Mountain Man? Yes. Draw a graph of the man’s height up the mountain on day one. Starting at 8am, it slowly works its way up until he reaches the summit. Now plot the same graph for the second day, starting at the summit at 8am and finishing at the bottom of the mountain at some point.

On this graph, the lines must cross… else the man didn’t ascend/descend the mountain all the way. At that point, time $t$ (running along the bottom) is the same, and the heights are the same, so we have our theorem! The same height up the mountain, at the same time on each day.

Just magical!

The Recursion Theorem Statement

Due to Kleene (that’s how mathematicians say “Kleene did this… blame him…”), this is the statement of the simplified form of the theorem - specifically, Roger’s Fixed Point Theorem - taken from Barry Cooper’s book (Computability Theory).

Theorem: If $f$ is a computable function, then there exists some positive whole number $k$ for which

on any input.

[NB - if the notation is unfamiliar, read part one of this series! M.]

Proof:

Well, this probably has people a little stumped as to what it says. Well, it says that for any computable function $f$ (read: any Turing Machine) two things hold:

1. At some point, the output of $f$ codes a computable function.
2. At least one of these functions (yes, there’s more than one) is the same as the input used to get the coded function in the first place.

mind_blown.gif

So how do you prove such a thing? Well, it’s actually quite easy.

Let’s build a weird little tool called $h(x)$. What does it do? It takes input $x$, and some fixed second input $y$. It first computes the Turing Machine $\phi_{x}(x)$, and if this halts, continues to attempt to compute $\phi_{\phi_{x}(x)}(y)$. We say that $h(x)$ is:

Now, we know that $f(h(x))$ must have some $e$ such that $f(h(x)) = \phi_{e}(x)$ for each $x$ (think about it… it’s computable, remember? So there must be a number $e$ that is the Godel number coding thingy for this computation). Now set $x=e$ and realise that we get $f(h(e)) = \phi_{e}(e) = h(e)$ when they are subscript indices (in helvetica, probably), which means that:

…which is precisely what we’re after!! :-D $\square$

But what the hell does it mean?? Well, that’s actually up for debate. We know that the result holds, and we know that it holds for every computable $f$ that we choose to plug in. But beyond this, it’s a fairly mystical result.

Think about what it says (a useful question to ask of any mathematical statement); Every computable function $f$ has some input $k$ that gives output $k$. Furthermore, this $k$ is the coding of some computer program itself. It states two very important and fascinating facts that are very useful to computability theorists…

Useful?!? Yes, the Recursion Theorem pops up a lot. So long as $f$ is computable, we can find the relevant input $k$ such that we can do without $f$, and just use $k$ in its place. Veerrryyy handy, as you’ll hopefully come to see.

Tune in next time…

… for some bonus stuff aimed at those who are as excited about this as I am :P

NB Like pretty much everything on my site, I’m not writing this for the technically unititiated. Fair warning, if the first few bits are hard, it’s probably meant to be that way. Pro tip - if you don’t know all the acronyms that start in 3 paragraphs, this isn’t for you.

What is hardware hacking precisely?

Put simply, it’s a way of hacking that concentrates on the devices themselves, as opposed to just a particular application or service. In normal, modern, IT-based environments, we use keyboards to type, we use monitors to see what’s going on, and we use GUI’s to interact with a computer and tell it what to do.

In hardware hacking, we don’t really care about this. What we want is to be able to look at the hardware directly, and interact with the firmware system itself. This gives us a low-level of access to be able to find out how the particular device operates under the hood.

But what’s different?

Well, really, not much. LFI, RCE, BoF, XSS, CSRF, SSRF, XXE, etc. all work the same. There’s nothing ‘special’ about hardware hacking in that respect. What’s different is the routes that you take to get there, and the ways you can influence a process in memory or at rest.

To illustrate, let’s take an example. Suppose we think we have command execution on the device, say a router, and it’s in a ‘usual’ place such as the ‘ping something’ functionality in the web application. Before we write a CSRF exploit to run this unauth on a simulated victim’s machine, we want to know that it is indeed running our commands. Router manufacturers have grown aware of attacks such as this, and so have implemented iptables firewalls to prevent out-of-band disclosure (like doing an nslookup test), and no errors are reported to the web interface when we try and do something that we shouldn’t.

If you’ve accessed a dormant development header then you can have it write to your device and see the ouptut. What’s a ‘development header’? Well, these are basically parts of a PCB (printed circuit board) that were used in the development of the board. Commonly UART or some other serial interface, they are most commonly configured to give you a shell (often r00t).

So what do we do that’s different? Well, we’ll try a payload something like this:

http://router.admin/services.php?ping=127.0.0.1;%20echo%20"test"%20>%20/dev/ttyS0

(this is a completely made up example…)

If we look at our UART console and see that test has appeared, we’re on to something. We know we have command execution, and we know that fully exploring this is worthwhile from a research point of view.

Don’t I need a lot of theory?

Probably, but in many ways, the best way to learn is by doing, especially in this case. That said, it can’t hurt to be familiar with electronic basics - I was going to write a ‘War and Peace’ overview, but then realised a quick google search would pull up much better guides than I could write. Here’s a (growing, I hope) list:

• Instructables: Electronics - this is a nice guide.
• Instructables: How to Solder - nice overview of how to solder. Quite an essential skill.

Digital vs. Analogue Electronics

This is the a brief overview, and a quick web search will find you much more information.

The difference from our point of view is the way in which information is encoded. In analogue electronics, different voltage levels carry some level of information - think of a microphone recording sound or a speaker reproducing the same sound.

The microphone (essentially, an inverted speaker) vibrates according to the pressure waves that are the invisible thing we perceive as sound. This vibrations take place in a magnetic field, and they vary an ouput voltage as a direct result of the sound waves hitting a microphone diaphragm. The opposite process is how speakers work, to the letter. But how is this different from digital music?

Well, in digital systems we have two states - ‘on’ and ‘off’. That’s it. So, you can see why binary is such a big thing in computing - it’s how we store digital information. So, so record sound digitally, we take the sound wave, which is a continuous series of voltages, and chop it up. We then take each ‘slice’ and calculate the average voltage for that tiny (in the milliseconds) period of time, and write that number down in digital storage. This is then our digital sound file (there is a wealth of wonderful mathematics explaining why and how these things work so well).

To reproduce the sound, we reverse the process, and modulate the voltage of a system acording to these digital values for the same period of time. Easy.

So, think about what we have to be able to do these conversions:

• A regular clock signal to regulate the ‘chopping up’ of the analogue waveform
• A reliable output voltage with which we can reliably detect ‘1’ vs. ‘0’
• A protocol that is easily reproducible and implement to keep costs of the electronics down, but reliable at the same time.

… you get the idea. And these things are all inherent to our digital devices through and through. The protocols we’ll describe will exhibit these properties.

Resistance is not Futile…

…it’s cumulative and a right bitch. Remember this. The only formula you need is

which is the electronics equivalent of $F = ma$ in physics.

Resistance represents a constant drain on power in a circuit, and is given symbol ‘R’ and measured in Ohms. A voltage, or ‘potential difference’ is a measurement of energy in a system, and is given the symbol ‘V’.

However, you have to have something to give the energy to, and these are electrons - perfectly spherical little particles we have all heard of. The amount of electrons is called the ‘charge’, measured in Coulombs and is usually given the symbol ‘Q’.

We usually talk about a ‘current’ in a circuit, measured in Amperes, or Amps for short, and given the symbol ‘I’. This is the ‘rate of change’ of electrons - like the rate of change or current of a river. This means that a circuit with 1 Amp of current has 1 Coulombs worth of charge flowing past any given point per second.

Now think about the formula from above - $R = \frac{V}{I}$. If we increase the voltage of the system but not the current, then we naturally increase the resistance. If we increase the current, and maintain the voltage, then the resistance falls. Rearranging, $\frac{V}{R} = I$, so for a fixed voltage circuit, if we introduce a restance (like adding a resistor) then we reduce the current flow around the circuit.

NB These are the kinds of games physicists play when they encounter formulae. It’s a very good way of interpreting mathematics to see how it impacts the real world. But remember, maths is a human construction!

Here are some useful formulae:

• \[I = \frac{\Delta Q}{\Delta t}\]
• \(V = \frac{W}{Q}\) where $W$ is ‘Work done’, measured in Joules
• $Watt = I^2 R $

But we’re not here to do maths…

Ok. I’m in. What do I need?

That’s a very open question, but here are some key pieces of equipment I’ve found the most useful. This list will be updated on occasion, so if something isn’t here now, it may well be soon…

I should point out here that I am to do this in the cheapest way possible - I don’t really believe in spending hundreds of coins on kit that is usually single use. As such, tere are usually cheap Chinese derivatives that do the same thing, but with much less reliability. These can be found on AliExpress, usually.

Basic kit

These are the things I find useful for doing PoC’s and getting going in general:

• Wire - just plain, thin, insulated wire
• Enamelled wire - this is useful for tapping into very small contact points where larger wire would pull the contact off
• Soldering iron - get a decent one if you can, but really any will do, once you learn how to do it.
• Solder - solder is an amalgum of a few metals, predominantly tin. Cored solder is essentially a very thin pipe filled with a substance called flux. The flux is used to reduce oxidation of either the wire metals (copper) and the tin-based solder itself. Tin is very sticky to clean metal, but not to metal-oxides (like copper oxide); however, at the temperatures we’re talking, copper oxidises (‘browns’) very quickly, which would prevent a decent join. Flux mitigates this.
• Array of Components - having a ‘base stock’ of resistors, capacitors, LEDs, and transistors of various types and values is very useful when working with electronics. You can buy ‘electronics starter kits’ that are full of useful bits and pieces that regularly come in handy.

Test Equipment

There are lots of things that go here, so let’s get to it.

Voltmeter

These are great pieces of kit. They let you find out the broad structure of a circuit, find power rails - these are usually traces that go from the power input of a device and deliver power uniformly to all circuits - there can be multiple for different voltage requirements on a single board - where ground points are, whether two points have continuity, ratings of components, and with practice, likely candidates for test/development points.

Getting a decent one is advised - they cost around $25-30, and can be bought anywhere as they’re not very specialised kit.

Oscilloscope

My favourite piece of kit! I don’t own a fancy one (though you can get them second hand and quite cheap), but the two I down own I love.

An oscilloscope is a tracking, visual voltmeter. It lets you choose a test point, and then track the test point’s voltage for a period of time. With this, you can ‘see’ waveforms as a voltage over time graph.

They also have useful functions, such as ‘slope triggers’ - where you can have it record for a fraction of a second as and when it detects a ‘slope’ or ‘change in voltage’, usually indicating a circuit powering up or trying to communicate.

We’ll make much use of these, as well as logic analysers…

Logic Analysers

My other fave device. These are multi-channel digital oscilloscopes, essentially.

‘Digital oscilloscopes’?? Yes - they let you track the ‘logic’ of a chip or circuit by adding ‘taps’ to assess the voltge. These are particularly useful for tracking what different legs of an IC (Integrated Circuit - a ‘chip’) are doing, and then reverse engineering what the protocol in use may be, or even pulling data by applying software analysers and decoders.

JTAG finders

[ The JTAGulator and friends are very useful, but the second-hand one I got doesn’t work. As such, I still do this by hand. I know I need to change this, so watch this space!]

Protocol Boards

I struggled to find a name for these, but this seems to fit best. In hardware hacking, you need ways for your computer to ‘speak’ the protocols you’ll come across. As such, I’ve termed such devices ‘protocol boards’ to illustrate that they are used to ‘speak’ to devices over various protocols that you may encounter.

Bus Pirate

SUPERB! Very versatile. A little slow, compared to new versions, but there are some Polish manufacturers making these at very reasonable prices.

The Bus pirate speaks many protocols, and lets you communicate over UART, SPI, and even basic JTAG with a single device. Very versatile, and long lasting.

In the words of Alan Partridge, “Nice!”. 0xFF out of 0xFF, would recommend to a friend.

UART to USB converters

UART is the most common ‘serial’ interface; so common that when we say ‘serial line’ we usually mean UART. As such, a dedicated UART to USB converter is a must, as they will be in contsant use.

They’re also very low cost. Down side is, they’re easy to blow the chips on, so buy a few.

Bits and pieces

These are handy pieces of kit to have around.

Arduinos

Either the Nanos, Teensy’s, or Arduino Uno’s - they’re very useful for creating proofs of concept devices or for programming basic ‘glitcers’ even. The Arduinos are devices you compile C into bytecode and load onto the arduino boards as flash files. As such they are ‘single purpose’ devices that can easily (and intentionally) be repurposed time and time again.

They also easily interface over SPI and have boatloads of re-useable code online for basic functions to implementations of HCI (Human Computer Interface - keybards, etc.) impersonators all over the place.

Get one of each, as they’re fairly inexpensive, esp. the immitations.

Breakout Boards

From temperature sensors to RFID Readers, there are loads of breakout boards, usually designed to add funcitonality to Aruidino-like boards. They usually speak SPI or I2C, so are easy to integrate into projects for infinite reasons.

These can be brough in bulk as ‘arduino starter kits’ sold en masse.

Raspberry Pi’s or like computers

Sometimes an arduino doesn’t give enough control or accuracy. Where arduino’s leave off, RasPi’s and their like derivatives pick up. They let you set up Wi-Fi clients/AP’s, web clients that you can script, or any other way in which you’d want to simulate a ‘client’ or ‘server’ the target device can speak to, and you can do this with the ease of a BASH script.

Summary

This is the first step, and really only a -vvv equipment list and background overview for hardware hacking.

Hopefully we’ll get onto something meatier soon ;-)

There is a lot computer science owes to mathematicians such as Ada Lovelace, Charles Babbage, Emil Post, Alan Turing, Stephen Cole Kleene, et al. But much of the beautiful mathematics of Computability Theory and other areas of Mathematical Logic are unknown to many in the area of computer science - and here I include hackers, makers, programmers, systems administrators, etc.

Also, much of the language of crytography is taken from mathematics, and used to bludgeon those not ‘in the know’ about such things. Whilst these language games are being played, cryptography is having a real and tangible effect on people’s lives. It is time to open the subject up and create clear, concise descriptions of what is going on - accessible to as many people as possible, with only a minimal amount of effort.

Cryptography needs demystifying, and computability theory needs to be better known.

This is the first in what I hope will be a series of posts on mathematics, specifically the bits that get left out or forgotten by comp. sci. lecturers and youtube celebs.

Computability Theory - The Hacker Theorem

TL;DR - there’s a wonderful little theorem that permits input data to be computer code, and that computer code is essentially a string. As such, all those lovely injection attacks hackers create, and even virtual machines themselves, aren’t clever overlays or autmentations of computer functionality, they are intrinsic features of computation from the very start!

More properly called the $s-m-n$-theorem, after a symbol in a proof due to Kleene, it was first published by Alan Turing in 1936. It is sadly often derided for its importance in terms of the implications you can derive from the theorem, and oft overshadowed by the Recursion Theorem (and, you could argue, rightly so).

A Note On Style

In mathematics, we usually keep to the following running order:

• Introduction
  • State the overview of the research
  • State the main result(s)
  • Occasionally include jabs at colleagues
• Definitions (the most re-read section)
• Elementary proofs (to induce a false sense of security)
• Main Result(s) restated and proved in full
• Closing remarks

…and so the maths research paper goes. However, there is a problem with the way that scientific data is amalgamated for study, vis a vis textbooks. The original papers generally cover the intentions and motivations for some particular work. However, owing to space and publishing costs, these are often lost. In mathematics, this can actually worsen a student’s chances of engaging with a proof, as the physically shortest proof is often chosen for publication. Whilst many don’t see a problem with this - we always want the most succinct way of obtaining knowledge - sometimes it is a detriment; the longer proof can convey a sense of the meaning of a particular result, and may be a better educational tool than a terse, lead nugget kind of proof. That said, there are some wonderful textbooks by matematicians that avoid this pitfall - my own former supervisor’s textbook ‘Computability Theory’ is, I think, a decent example of how it should be done. But I digress…

My intention here is to deviate from the ‘standard form’ of a mathematics textbook, and introduce the ideas in a verbose, possibly prosaic fashion, and offer up commentary on not just what is happening, but why and how and with what motivation.

Building Blocks

Instead of Definition 1, Defn. 2, Def. 3, etc. let’s try this. (As always, comments and feedback are gratefully received).

So, being in the world of mathematics we want to talk about computation as the process by which we take some input $x$, so something to it, and then give some output, call it $y$ (for ‘$y$-not’… geddit? It’s a joke. Tell your face.)

Normally we’d describe this as $f(x) = y$, which may have triggered some PTSD from high school maths lessons - for which I’m truly sorry. But we want to formalise what we mean by ‘computable’, and find a way to apply it to this context. To do this we take a leaf out of a monstrously persecuted, quiet and lovely gay guy’s book, and describe Alan’s…

Turing Machines

We’re probably familiar with these - they’re somewhat of a cliche these days. Let’s run through the main pieces that make up a Turing Machine (TM):

• A Program $P$
• An infinite tape on which we do our work, with marked sections
• A read/write head - this performs the actions of the program $P$ and moves along the tape left and right

There you go. That’s it. Well, no, there’s a lot more…

First question is how do we describe a program $P$? Well, it’s really simple, actually, we describe it as a series of 5-tuples. 5-wha-cha-bles? We just mean brackets that have uniformly 5 things between them. Each thing has a particular meaning depending on where it is. Here’s what we will use:

…or in a more mathematical way:

The last bit, the $ ( L,0,R ) $ bit, just says that we want our direction to be one of left/right/don’t move. But what is a symbol? Well, it’s a thing written to the tape, one per demarked section. What’s a state? This is a bit trickier, so we need to describe how this thing will work.

A program $P$ will be composed of a sequence of these 5-tuples, each one stipulating what to do when presented with some symbol $s$ and state $q$. We define what to do by stating what symbol to write, and what internal state to set, and which direction to move in.

When we have an input, this gets written to the tape, and the head is placed at the tape cell at the left-most of the input and set to state $q_1$. We will express this as a series of ‘1’s, and to make sure we can fit zero in, we’ll use $x+1$-many ‘1’s on the tape. So, we now have written our input, what now? We want to do something to this - but what? Let me show you an example program:

See what it does? If not, then think of it this way. First, we seek right, by moving right and not changing any symbols on our input. When it gets to a ‘0’, it goes left one, writes a 0 if it finds a 1, and then exits. Exits? Well, yes. That’s what that $\text{HALT}$ means. It’s a the fourth thing I didn’t put on our original list - a way to kill the computation at any point by declaring it in our program. Whatever is left on the tape after we declare $\text{HALT}$ is our output from our computation.

So we now have a program $P$ that does $f(x) = x-1$. Easy.

Turing’s Genius

Turing didn’t invent computers to save the world. Contrary to what you’ll believe from those who believe everything started in WWII, he actually derived the model of a Turing Machine in 1936 to solve a problem posed 8 years earlier, Hilbert’s Entscheidungsproblem.

The real genius at play is that he married together the two main models of computation - the lambda calculus, and register machines. He showed that they were equivalent by showing all their relevant actions could be performed with Turing Machines. Quite simply a wonderful achievement, and paving the way for his future work on computability theory proper (something I hope to elaborate on).

The upshot of all this thinking was the following item:

The Church-Turing Thesis

Every function for which there is an intuitively effective process for computing its values can be shown to be Turing Computable.

Turing’s words here are taken from Barry Cooper’s book ‘Computability Theory’. But this is not the sense in which we will use the phrase ‘Turing computable’ or just ‘computable’ to refer to the members of a set. Members of a set? Yes. We will say a set, call it $A$, is compuable if there exists a Turing Machine that accurately describes, for all $a$, a potentially infinitely list of potential members, whether $a$ is in $A$ or not. Formally, we say that such a turing machine decides whether $a \in A$, and we can formalize this as follows; there is some computable $f$ such that for any $a$:

This is different from usual introductions to computable functions - they take the route of ‘recusive functions’ which is a beautiful subject, but not very accessible. The next piece we need to take care of is what happens when we have a set where there are three possible answers: in, out, and ¯\_(ツ)_/¯

Partial Computable Functions

Take a program $P$ that adds 1 until it gets to 50, then HALTs. Input 47, and you get 48, 49, 50, and we’re done. Input 51 and you get 52, 53, 54, 55, 56, 57, 58, … the TM will never stop, as it will never reach the halt condition.

There are lots of functions and programs and algorithms like this - infinitely many! These are clearly ‘partial’ functions - the set of values for which we get an answer is not the full set of possible values.

Gödel Numbering

Sounds fancy, but really it’s just a way of assigning a unique value to a string. What strings? Well, any. Including our programs - they are essentially just strings of characters interpreted by the machinery of a Turing Machine.

Kurt Gödel came up with the idea for his own Incompleteness Theorems (monuments of modern logic, and perhaps the most significant shift in human thought in recent times). The idea is quite simple - for each symbol, assign an integer. For each position assign a unique prime. Take each prime and put it to the power of the integer representing the symbol in the position the prime represents. For example ‘LOL’ might be $2^{12} \cdot 3^{15} \cdot 5^{12}$ which equals 14,348,907,000,000,000,000. Simple.

The numbers get very large very quickly for even small sets of symbols and short strings, but the idea is this - we know from the fundamental theorem of arithmetic that each number has a unique prime factorization. As such, each string under some coding where we avoid overlaps has a unique number that represents it perfectly. Perfectly? yes, we can always reconstruct the string from the number.

What’s really nice about using this is that the coding and decoding of each number is perfectly computable. We can always generate a number, and always recover a string. The only problem is that the strings we recover by and large won’t be very meaningful as a program, but we don’t really care about that - it’s a side effect. So long as we’re always careful about choosing which numbers we decode, we’ll be fine.

We will introduce this by adding subscript $e$ to greek letters to represent funcitons. Why? Well, it looks cool, doesn’t it. So, for the program represented by the number $e$ acting on input $x$ we will write $\phi_e (x)$. If the program halts, we will write $\phi_e (x) \downarrow$.

For those more comfortable with mathematical notation such as $\exists s$ read ‘there exists $s$ such that…’ this is how we can express halting in more mathematical terms. We know that each computation has a potentially infinite, but still separate (in maths terms ‘discrete’) ‘stages’. These are represented as an additional subscript to our above notation. So, for a program $e$ at stage 29, we will write $\phi_{e,29}(x)$.

Halting can now be written as follows; for program $e$ on input $x$, there exists some stage $s$ such that the program halts, written

Neat. Now we have everything we need to talk about the…

s-m-n Theorem

But you said we’d get a ‘hacker theorem’!! yes, and I didn’t lie! This is what I called it in my MSc thesis on this subject. Ok, let’s try again.

The Hacker Theorem

Here’s the statement of the theorem:

Theorem: If $\psi_e(x,y)$ is partial computable, there is a computable $g$ for which $\psi_e(x,y) = \phi_{g(x)}(y)$

Proof: I’m not going to bore you with a formal proof. It’s much more elucidating to give a descriptive proof.

First, let’s look at the statement precisely - it says that you can take data that is an input, and there is a computable $g$ that takes this input and generates a program that can be run on a TM. We’ve already shown that any number can be decoded through the method above, so this is a total (meaning ‘always gives an answer’) computable function. But what if we decode a nonsense program? That’s fine - remember, $f$ is partial computable, so there’s no requirement for it to halt :P

If you think about it, we can always construct some $g$ that makes this true, for any 2-input $\psi$. This means that we can move the computation around $x$ in $\psi$ into $g$ as required. So, we can move information into and out of the subscript index and input parameters. $\square$

(That little box means ‘QED’ or in other words ‘drop mic’ or ‘I’m done here’.)

So there we are - it’s not a very daunting theorem, and has a nice, succint presentation.

A Little Extra

This theorem directly influenced the Recursion theorem and the Universal Turing Machine theorem. The Universal Turing machines are just virtual machines - the theorem states that you can simulate every piece of a Turing machine in itself, which is true!

This, however, is a little beyond the scope of this article, and in many ways is best kept by itself for now.

Implications

The theorem shows that programs are streams of bits as much as their inputs are. Look at common attacks:

• SQL Injection states that website input can be injected SQL code
• Cross Site Scripting shows that user web input when returned improperly can become HTML/Javascript code that runs in a browser
• Buffer Overflow attacks are the best example - the input actually rewrites part of the stack, and the input then become running code.

Hence, many of the injection attacks and activities are validated by this theorem at an abstract level. It’s kind of reassuring to me that such a simple theorem validates so much work that is done in this manner in computer science.

Although this theorem seems a little counter intuitive in a sense - can we really always find $g$?? - it isn’t much work (and I encourage people to try it) to formalise this into a neat proof.

But what have we done here? Well, in a sense, we’ve shown in an abstract way that we can move ‘information’ between storage in the inputs of a function, into the computer itself, and vice versa.

The amazing thing, for me, is that it doesn’t matter how we formulate computation for this to still work. It also amazes me that a deeper ramification is seldom spoken of - the fact that we must be sensitive to where our ‘information’ is in computation. By coding an algorithm, you are storing some information. By writing down an algorithm into a text file as, say, C code for storage on the same computer, you are storing the same information. The act of compiling this code is nothing ‘magical’ - it is a direct and computable translation process of an ‘effective procedure’/algorithm into another form. Likewise, there is nothing to stop you passing a program as input to another program. (this observation is key to proving the Halting Problem).

Future Work

I’m hoping to write some overviews of the following:

• The Halting Problem Without Tears (Unless you work in AI)
• Recursion theorem
• Universal Turing Machine theorem
• Post’s Problem (maybe in a few parts)
• Friedberg-Muchnik theorem and Priority Arguments

Maybe it’s of interest? If not, it’s a fun exercise for me.