Sunday Studios

I, like many other iOS developers have installed XCode 4.2.x and encountered all sorts of problems using SVN (and probably the same goes for GIT). When using the organiser window you will be confronted with ‘Host is unreachable’ every time you try to access your repository. Or a little red light next to the repository, which you know means there’s going to be trouble.

If like me you turned to the internet for the answer, you may have gotten lucky and your SVN now works. However you may not, and your SVN is still broken. You may have even ask yourself, this is a computer program whats luck got to do with it? That is a very good question.

The reason that some people have got it working is that there are two parts to the puzzle. Some people already have one of the parts setup and when you perform the second part hey-presto SVN works again. Enough jabbering onto the fix.

Close Xcode if open.

In Keychain Access remove all of the certificates relating to your SVN server (keys and certificates).

Next open Safari (has to be Safari) and visit your server, for example I’m using VisualSVN so I type  https://myserver:8443. You will be presented with a certificate screen, edit the certificate and tick on ‘Always trust’. Then click ok.

Now at this point in Xcode when you look at your repositories you will see a green light, however you will not be able to access your repositories. This is because you only have a certificate to access the server and not SVN.

So lets create a certificate to access SVN. Open a terminal, and type

svn list https://myserver:8443/path/to/repo

Depending on your SVN setup you will need to modify the line above. When you hit return you will be asked for a password, this is the password for your SVN account. Enter your password and press return.

Done.

Run Xcode, enter the organiser window. You should see a green light and the history from your repository. Everything should now work. This fix probably also works for GIT (untested).

On with the iPad version of Tank Raider…

In my previous post I talked about the GCHQ recruitment crack. At the end of the post I discovered I had only cracked the first of three parts. In this post I’ll talk about how I tackled the second part (which turned out to be my favourite part). Throughout the series of cracks I want to draw your attention to details that seem superfluous, details that seem insignificant, but I want you to keep them in mind.

The solution to the first part revealed a web address, lets take a look. Incase the website is no longer available the contents can also be viewed here.

The web page is a piece f Javascript code. The comments detail a set of rules that define a virtual machine. There is also block of data, which is byte code. Looking at the function that executes the byte code it is apparent that somebody has forgotten to write the virtual machine! Now you may wonder how I have derived this so quickly, it’s plain and simple experience. If you write enough computer games, sooner or later someone will say ‘do you know what would be great? a scripting language!’. Before you can stop this person and their special brand of crazy they’ve sold this idea to the powers that be. Before you know it you are splicing a version of lua into the codebase, or worse still you are hand-cranking your own scripting language. Whilst this is a painful experience, it does teach you how scripting languages work. Most scripting languages take human readable text and convert (or compile) it to a form known as byte code. This byte code is easier (and faster) for the computer to run. The byte code is usually made from a relatively small subset of instructions.

The great thing about byte code is as long as you know the rules, anyone can write the implementation, in pretty much any language (incase the penny hasn’t dropped this is how Java works). The code is presented in Javascript, however there is no real reason to implement the VM in Javascript. I took the view that Javascript has a pretty poor debugging environment compared to c++ (especially when using Visual Studio). So I decided I would write the VM in c++.

When implementing a VM you are writing a CPU emulator, so a grounding in how CPU’s work is advantageous. If you got this far, that’s probably not a problem as you will have had to deal with assembly language in the first part. CPU’s are made up of several parts, registers, instruction pointer, cpu flags (your Intel CPU is a more complicated version of this design). The CPU variable definition gives us a good idea of what we need. C++ is slightly better at dealing with bit shifting than Javascript, this allows us to do some nice things. Rather than bit shifting and masking the data I have created a bit packed structure which represents an instruction (visible on the right). I can map this structure over the memory to give me a representation of the next instruction. Registers are represented by an array [0-6], and a single byte is sufficient to represent the cpu flags. The only other detail is an instruction pointer, the architecture stipulates that address space is segmented (16 bit). Originally segmented architecture was used as cost cutting exercise, it meant you could manufacture boards with less address space, yet were still able to access large addressable spaces. What this means in our implementation is that register 5 [code segment] provides an offset to the instruction pointer. Register 6 [data segment] provides an offset to memory that we access.

Now we have a CPU defined I need to implement all of the instructions that our VM supports. The VM supports the instructions shown in the image on the left. Implementing each of these instructions in a case statement will be sufficient to form the basis of our execution unit. Each instruction can perform slightly different operations depending on the mod bit. The different operations are detailed in the brief. Writing each instruction didn’t take long as by themselves they don’t really do much. Within about 30 minutes I had completed my VM. So now what? What does the program do? Looking at the instruction set, specifically at xor is seems very likely that the program decodes some kind of message. This is where the decision to write the program in c++ paid off. The program didn’t work first time, I had a few typo’s and had not properly implemented some of the instruction. These problems were fairly easy to pick up from the Visual Studio debugging environment. About 20 minutes later I had fixed all the bugs. So I put a break point on the hlt instruction (end of the program) and ran the code.

The break point hit, but what was the result? The VM isn’t sophisticated enough to display the results of the program, so the results (or decoded message) will be lurking around in memory. The program has a pretty small addressable space, so using the memory debugging inside Visual studio I was able to locate the results. Behold!

There in memory was the decoded message ‘GET /da75370fe15c4148bd4ceec861fbdaa5.exe’. It had worked! Again on completing the second part I have to reflect on an even smaller demographic that these challenges target. Whilst this is by no means true of all graduates, most of todays graduates are unfamiliar with CPU architecture and low-level programming. I don’t draw any conclusion from this only point out that it’s interesting.

Remember the superfluous detail we were keeping an eye out for? Did you spot it? Check out the listing, see anything there that we didn’t use? That’s right, firmware, doesn’t seem to be important to the VM or the decoding of the message. So why is it there? All will be revealed in the final article ‘bringing it all together’.

You can check out the full listing of my VM here.

Last Thursday I saw an article about a website setup by GCHQ (The Government Communication Head Quarters). The website was a recruitment drive, but not your average recruitment drive. In order to get to the recruitment page you had to crack a code. Well if that isn’t a red rag to your average programmer bull I don’t know what is. I thought I’d write a small article on how I approached the cracking.

Upon visiting the site you are presented with the screen on my left. The picture consists of a small grid of numbers, a time limit and a box where you can enter a keyword (presumably by decoding the numbers). Looking at the numbers and being a programmer it seemed immediately obvious that these numbers were base 16 numbers, or as we refer to them hexadecimal. I decided to make the assumption that absolutely nothing on this web page was ether an accident or a coincidence. Why were the numbers in hex? Well you could argue that by recognising the numbers are in hex you have cracked the first code, after all if you are a programmer hex is second nature to you. It seems this test is targeting a certain demographic, one that so far I fit into.

Static analysis of the numbers didn’t yield any obvious answers, a few patterns were notable 41414141 and 42424242, they’re ASCII, could there be more ASCII? I would need to look at these numbers in an editor. Remember I said that nothing on this page was left to chance? This isn’t really part of the code cracking, however this is where they give you a massive clue. The grid of numbers is a picture, a png, now that’s weird why wouldn’t they be text? Are you seriously going to make me type these numbers in? The answer to this is yes, and the only reason I can think of is to re-awaken a dorment memory of owning a ZX Spectrum. Why is this important? Well any Spectrum owner will have at some point typed in pokes for infinite lives from ZZap!

The code would be printed in the magazine and you would type it in before loading the program. As a young boy I simply could not get my head around how this worked, and it seemed somehow like magic. Here’s an example

chuckie egg 2 (P 'n' C)
loader (or use Multiface to enter POKEs)
100 FOR x=23296 TO 23308: READ a: POKE x,a: NEXT x: RANDOMIZE USR 23296
110 DATA 55,62,255,221,33,0,64,17,0,192,195,86,5

Once I’d typed in all the numbers from the grid I try a few basic tricks, looking for strings, reversing the byte order, xoring various parts of the message. Meanwhile in the back of my mind I’m thinking about things I haven’t thought of for 25 years, thinking about typing all those data statements from the Spectrum, this voice gets louder and louder until I actually listen to it. Yes of course, the numbers are a program. I point the disassembler at the data and sure enough it looks like code, but does it run? And if so what does it do?

The code in the disassembler looks like this. Fortunately I used to write a lot of assembler on my Amiga (68000), so I can read assembly language pretty well. The first statement in the program is both weird and later on important. There’s a JMP statement over the first 4 bytes, weird eh? Remembering the mantra, nothing is a coincidence. The importance of this JMP was not not obvious so I carried on working out what the program did. The program operates in two stages, during the first stage the program creates a dictionary, a cypher lookup table, encoded with phrase DEADBEEF (another thing to remember). Once the dictionary is created the program makes a fake call from the end of memory, this fake call allows the popping of addresses just after the call. It uses this popped address as the location of the message to be decoded. These addresses are checked to see if the contents match 41414141 and then 42424242. The program passes the first test but then fails on the second test. What? Did I miss something? I have the cypher key, but no message? I have to say this stumped me for a little while, as I was convinced the message was inside the code, after pointing the decoding at various bits of memory and ending up with nothing I decided to have a think.

I went back to the website and starting looking through the HTML, nothing obvious stood out. I remember doing a similar hack before and I found some information in a pictures alpha channel. So I loaded up the image of the numbers and looked at the alpha channel, nothing. Then I thought, I’ve also seen chunks embedded in files (like a spare IFF chunk). I loaded the image into a hex editor, scrolled up and down and nothing really stood out. I stepped back from the monitor and starred out the window for a little while, as my wondering gaze returned to the monitor I noticed that PNGs had a comments section. I never knew this, and it’s something I’d never used. The reason it didn’t stand out was because the comment was close to binary, however on furtherr inspection it was actually ASCII, could this be the message? Maybe I thought!

I appended the message to the end of the decoding program, excitedly I ran the program, only to see it bomb out. Hmmm, is it possible this isn’t the message? Well lets step back and think. The encoded message would probably not be completely within the ASCII readable character range, after all our dictionary is 255 bytes in length and contains all kinds of products when xored with source message. Yet the message in front of me is completely in the readable ASCII range. If at this point you have ever done any PHP coding, or worked with web cookies you will be screaming the answer. The trailing == should have really given the game away, however it’s all about familiarity and exposure to technologies.

The question is, how do we represent all the values from the ASCII range 0 – 255 in a readable text form, such that would be required for a comment field? The answer is of course Base64 encoding. Again I felt the pace quicken, I found a website that decoded Base64 into hex (very handy). When decoded the message began with 42424242, followed by a length, this was 100% the message, as that’s the signature the code was looking for.

As I ran the code I felt a rush of adrenaline (come on for programmers this is exciting stuff!). I had now become quite familiar with the decoding program so inserted a break point after the decoding section. I knew that EDI pointed to the decode buffer, below is what I saw in the memory.

This was pretty damn cool, from nothing I had unearthed the answer. Hang on though, that’s not the code I need to enter into the box, that’s a web address, what’s going on? If you go to the web site (assuming its still up) you are lead onto the second part of of the puzzle. Seems that the grid of numbers was only the first of three parts. In my next post I’ll talk about how I solved the next part, the VM!

The listing for my decoding program is here.

First of all I’d like to thanks everyone for supporting Tank Raider, I’m glad you’re enjoying it.

We’re currently working on additional content for the forth-coming release. We’ve taken on board your suggestions and combined them with our ideas.

To keep everyone up-to-date I thought I’d give you a sneak preview of some of the features we plan to release in the next update.

• Levels – more levels! Lots of levels. We’ll also be introducing an urban landscape, which should add an extra dynamic to the game play.
• Additional weapons – amongst the new weapons you will find mines, heat seeking missiles.
• Online high scores – see your world wide ranking and compete against your friends.
• New collectables – Level secrets and new gems types
• Physics – Improved game physics and collision system
• Game balancing – game difficulty is reduced in the early levels.

We hope the release will be ready in the next few weeks, we’ll keep you posted on an final date.

Happy Raiding!