Category Archives: hacks

For Lisa, the World Ended in 1995

If you try to set the clock in Lisa OS 3.1 to 2010, you’re out of luck:

You can only enter years from 1981 to 1995. That’s a span of 15 years – why? And what happens if the clock runs past the end of 1995?

Well, it wraps around to 1 Jan 1980.

But why does it not allow entering 1980 then? That’s why:

Whenever the clock is set to 1980, it thinks the clock is not set up properly. So it is a 4 bit counter. Too bad, a 5 bit counter could have made it into 2011, and we all know that’s way more than ever needed.

Internals of BRK/IRQ/NMI/RESET on a MOS 6502

After 35 years of measuring the behaviour of the MOS 6502 CPU to better understand what is going on, the Visual6502 simulator finally allows us insight into the chip, so we can understand what the CPU does internally. One interesting thing here is the question how the 6502 handles BRK, IRQ, NMI and RESET.

The Specification

Let’s revisit the documented part first. The 6502 knows three vectors at the top of its address space:

Signal Vector
NMI $FFFA/$FFFB
RESET $FFFC/$FFFD
IRQ/BRK $FFFE/$FFFF
  • On a RESET, the CPU loads the vector from $FFFC/$FFFD into the program counter and continues fetching instructions from there.
  • On an NMI, the CPU pushes the low byte and the high byte of the program counter as well as the processor status onto the stack, disables interrupts and loads the vector from $FFFA/$FFFB into the program counter and continues fetching instructions from there.
  • On an IRQ, the CPU does the same as in the NMI case, but uses the vector at $FFFE/$FFFF.
  • On a BRK instruction, the CPU does the same as in the IRQ case, but sets bit #4 (B flag) in the copy of the status register that is saved on the stack.

The four operations are very similar, they only differ in the location of the vector, whether they actually push data onto the stack, and whether they set the B flag.

Signal Vector Push PC and P Set B Flag
NMI $FFFA/$FFFB yes no
RESET $FFFC/$FFFD no no
IRQ $FFFE/$FFFF yes no
BRK $FFFE/$FFFF yes yes

BRK

Ignoring opcode fetches, the PLA ROM defines the following cycles of the BRK instruction (6502 Programming Manual, page 131):

  • store PC(hi)
  • store PC(lo)
  • store P
  • fetch PC(lo) from $FFFE
  • fetch PC(hi) from $FFFF

IRQ

An IRQ does basically the same thing as a BRK, but it clears the B flag in the pushed status byte. The CPU goes through the same sequence of cycles as in the BRK case, which is done like this:

If there is an IRQ pending and the current instruction has just finished, the interrupt logic in the 6502 forces the instruction register (“IR”) to “0”, so instead of executing the next instruction, the PLA will decode the instruction with the opcode 0x00 – which is BRK! Of course it has to kick in a few cycles later again to make sure a B value of 0 is pushed, but otherwise, it’s just the BRK instruction executing.

NMI

Not surprisingly, NMI is done the same way: “0” is injected into the instruction stream, but this time, some extra logic makes sure that the addresses $FFFA/$FFFB are put onto the address bus when fetching the vector.

RESET

RESET also runs through the same sequence, but it is the most different of the four cases, since it does not write the current PC and status onto the stack – but this was hacked trivially: The bus cycles exist, but the read/write line is not set to “write”, but “read” instead. The following trace was created with the transistor data from the Visual 6502 project and shows the first nine cycles after letting go of RESET:

#0 AB:00FF D:00 R/W:1 PC:00FF A:AA X:00 Y:00 SP:00 P:02 IR:00  READ $00FF = $00

Cycle 0: When a 6502 is turned on, the stack pointer is initialized with zero. The BRK/IRQ/NMI/RESET sequence pulls the instruction register (IR) to 0.

#1 AB:00FF D:00 R/W:1 PC:00FF A:AA X:00 Y:00 SP:00 P:02 IR:00  READ $00FF = $00
#2 AB:00FF D:00 R/W:1 PC:00FF A:AA X:00 Y:00 SP:00 P:02 IR:00  READ $00FF = $00
#3 AB:0100 D:00 R/W:1 PC:00FF A:AA X:00 Y:00 SP:00 P:02 IR:00  READ $0100 = $00

Cycle 3: The first stack access happens at address $0100 – a push first stores the value at $0100 + SP, then decrements SP. In the BRK/IRQ/NMI case, this would have stored the high-byte of the PC. But for RESET, it is a read cycle, not a write cycle, and the result is discarded.

#4 AB:01FF D:00 R/W:1 PC:00FF A:AA X:00 Y:00 SP:00 P:02 IR:00  READ $01FF = $00

Cycle 4: SP is now 0xFF (even if the internal state does not reflect that), so the second stack access (which would have been the low-byte of PC) targets 0x01FF. Again, the result is discarded, and SP decremented.

#5 AB:01FE D:00 R/W:1 PC:00FF A:AA X:00 Y:00 SP:00 P:02 IR:00  READ $01FE = $00

Cycle 5: SP is now 0xFE, and the third stack access, (the status register) happens at 0x01FE. SP is decremented again.

#6 AB:FFFC D:E2 R/W:1 PC:00FF A:AA X:00 Y:00 SP:FD P:06 IR:00  READ $FFFC = $E2

Cycle 6: The internal state of the CPU now shows that SP is 0xFD, because it got decremented 3 times for the three fake push operations. The low-byte of the vector is read.

#7 AB:FFFD D:FC R/W:1 PC:00FF A:AA X:00 Y:00 SP:FD P:16 IR:00  READ $FFFD = $FC

Cycle 7: The high-byte of the vector is read.

#8 AB:FCE2 D:A2 R/W:1 PC:FCE2 A:AA X:00 Y:00 SP:FD P:16 IR:00  READ $FCE2 = $A2

Cycle 8: The first actual instruction is fetched.

Since RESET is not timing critical, it doesn’t matter whether a few cycles are wasted by doing the fake stack cycles.

Playstation 3 Hacking – Linux Is Inevitable

In the talk “Why Silicon Security is still that hard” by Felix Domke at the 24th Chaos Communication Congress in 2007 (in which he described how he hacked the Xbox 360, and bushing had a cameo at the end explaining how they hacked the Wii), I had a little part, in which I argued that “Linux Is Inevitable”: If you lock down a system, it will eventually get hacked. In the light of the recent events happening with PlayStation 3 hacking, let’s revisit them.

This is the original slide from 2007:

device

y

security

hacked

for

effect

PS2

1999

?

?

piracy

dbox2

2000

signed kernel

3 months

Linux

pay TV decoding

GameCube

2001

encrypted boot

12 months

Homebrew

piracy

Xbox

2001

encrypted/signed bootup, signed executables

4 months

Linux

Homebrew

piracy

iPod

2001

checksum

<12 months

Linux

DS

2004

signed/encrypted executables

6 months

Homebrew

piracy

PSP

2004

signed bootup/executables

2 months

Homebrew

piracy

Xbox 360

2005

encrypted/signed bootup,encrypted/signed executables, encrypted RAM, hypervisor, eFuses

12 months

Linux

Homebrew

leaked keys

PS3

2006

encrypted/signed bootup,encrypted/signed executables, hypervisor, eFuses, isolated SPU

not yet

Wii

2006

encrypted bootup

1 month

Linux

piracy

AppleTV

2007

signed bootloader

2 weeks

Linux

Front Row piracy

iPhone

2007

?

1 month

Homebrew

international

SIM-Lock revenue

The table shows the relationship between the quality of a device’s security system and the time it took to hack it, as well as the original motivation for hacking and the side effects (collateral damage) it caused.

Correlation security/time to hack

There is a pretty clear correlation betwen the quality of the security system and the time required for hacking it – with the notable exception being the GameCube, which had rather weak security, but since its release coincided with the much more powerful Xbox, much of the hacker community neglected the GameCube until the Xbox was done. What can also be seen is that recently, devices tend to get hacked more quickly; probably simply because there are more and more people interested in hacking.

Correlation Linux/time to hack

The other exception is the PlayStation 3, which was not hacked until about three and a half years after its introduction. I argued that this was because there was only very little motivation to hack it: Sony shipped the devices with the “Other OS” option and even sponsored a port of Linux to it, allowing any user to install Linux if they wanted. Although Linux was running on top of a hypervisor and did not have access to all of the features of the device, it seems to have been enough to take the enough motivation to hack it out of the hacker community.

Linux/homebrew is the primary motivation

This is supported by the by the fact that the motivation for hacking every system in the table was either homebrew (i.e. running unautorized hobbyist applications) or Linux. Hackers seem to love to convert their devices into Linux computers to run a big library of existing software, or to hack the device to make it possible to run versions of existing emulators and games on the native OS.

Piracy is a side effect

None of the hacks in the table was done with the motivation to allow running copied games – but whenever the point of the security system was to prevent piracy, hacking it inevitably enabled piracy as a side effect. Some security systems protected other things like pay TV keys and SIM-locks; these also fell as side effects.

2010 update

In September 2009, Sony started shipping the “slim” model of the PlayStation 3, with the “Other OS” feature removed. With firmware 3.21 in April 2010, the feature was also removed from existing original models that users chose to upgrade – which was required for using any of the online features. The missing “Other OS” feature on the slim model motivated George Hotz (geohot) to hack into hypervisor mode (Jan 2010), but this approach did not lead to a working hack of the security system. In August 2010, the Australian company OzMods announced the commercial “PSJailbreak” USB dongle that hacks into non-hypervisor mode, allowing piracy and homebrew (“Backup Manager” says “backups and homebrew”).

Although this is the first time that a commercial company is first to hack a system, and the first time that piracy seems to have been a key motivation, removal of “Other OS” might have been another motivation, and geohot’s previous attempts might have helped as an entry point for this hack.

Usually, an open hacker community develops a hack, and commercial companies convert them into modchips. This time, a company developed a hack and a modchip, and the community reverse engineered it and ported the exploit code onto several other devices, allowing people to hack the PlayStation 3 without a dedicated device. And I’m sure Linux will be adapted soon to run in the new environment.

Conclusion

What do we learn from this? Linux is inevitable. Or maybe it should be “Homebrew is inevitable”. In the history of mankind, there has yet to be a popular system that is locked down to only allow certain software to run, but does not get hacked to run arbitrary code. I still dare to say that if Sony had not removed “Other OS”, the PlayStation 3 would have been the first system to not get hacked. At all.

(Here is an updated 2010 version of the table:)

device

y

security

hacked

for

effect

PS2

1999

?

?

piracy

dbox2

2000

signed kernel

3 months

Linux

pay TV decoding

GameCube

2001

encrypted boot

12 months

Homebrew

piracy

Xbox

2001

encrypted/signed bootup, signed executables

4 months

Linux

Homebrew

piracy

iPod

2001

checksum

<12 months

Linux

DS

2004

signed/encrypted executables

6 months

Homebrew

piracy

PSP

2004

signed bootup/executables

2 months

Homebrew

piracy

Xbox 360

2005

encrypted/signed bootup,encrypted/signed executables, encrypted RAM, hypervisor, eFuses

12 months

Linux

Homebrew

leaked keys

PS3

2006

encrypted/signed bootup,encrypted/signed executables, hypervisor, eFuses, isolated SPU

4 years

Piracy

Homebrew

Wii

2006

encrypted bootup

1 month

Linux

piracy

AppleTV

2007

signed bootloader

2 weeks

Linux

Front Row piracy

iPhone

2007

signed/encrypted bootup/executables

11 days

Homebrew

SIM-Lock

piracy

iPad

2010

signed/encrypted bootup/executables

1 day

Homebrew

piracy

How much change is in a vending machine?

There is only one way to find out – all you need is a giant pile of money and a vending machine that sells soda for $1.25: If you put in a dollar note and press the “return change” button, you will get the dollar note back directly. If you put in two dollar notes (the maximum it takes) at a time, it will give you change for the two dollars.

Our machine had $29 of change. It started out with 25¢ coins, and after a while returned a combination of different coins (25¢ & 10¢, then 10¢ & 5¢), finally switching to all 5¢ coins at the end.

In total, it had

  • 25¢ x 57 = $14.25
  • 10¢ x 114 = $11.40
  • 5¢ x 67= $3.35

After this, the machine refused to take bills, so it was either full with bills or, more likely, out of change.

But actually, it might still contain up to 95¢ of change – today’s homework is to find out how to measure the remaining change in the machine!

TI-99/4A BASIC as a Scripting Language

It is a good time for statically recompiled versions of BASIC from old computers.  First there was Apple I BASIC.  Then came Commodore BASIC.  Now, due to overwhelming demand, we’re proud to release TI-99/4A BASIC. For those unfamiliar the TI-99/4A was a home computer by Texas Instruments released in 1981. Unusually for the time it had a 16-bit CPU: the TMS9900.

Download the program from the project page on SourceForge. Binaries for Windows and Mac OS X are available and the source should compile on most POSIX-like systems. If you port it to a new platform please drop us a line; we’d love hear about it.

It supports the same interfaces as the previous projects.  You can use it interactively in direct mode:

$ tibasic
TI BASIC READY
>print 4*atn(1)
 3.141592654

>bye

Or you can write a line-numbered program:

$ tibasic
>10 FOR I=1 TO 10
>20 PRINT TAB(I);"Hello, world!"
>30 NEXT I
>RUN
Hello, world!
 Hello, world!
  Hello, world!
   Hello, world!
    Hello, world!
     Hello, world!
      Hello, world!
       Hello, world!
        Hello, world!
         Hello, world!

** DONE **

>BYE

You can also run programs from a file:

$ cat name.bas
10 INPUT "What is your name? ":N$
20 PRINT "Hello, ";N$;"!"

$ tibasic.exe name.bas
What is your name? James
Hello, James!

There are a few sample programs available on the homepage that you can run in this manner.

How it works

This program works much like the already mentioned Commodore BASIC project. The original program is statically recompiled to produce a new native binary. The recompiler is the work of Michael Steil and the  support for the TI-99/4A is by James Abbatiello.

The output of the recompiler is tibasic.c which is platform independent. The support functions are in runtime_functions.c and it is this file that you would edit to port to a new system or to add new features.

There are a couple quirks of the TI-99/4A which made this a bit trickier to support than the C64 version:

  • The BASIC interpreter was not written in assembly language as you might expect. Instead it was programmed in something called Graphics Programming Language (GPL). GPL was much like an assembly language with some high-level primitives for commonly needed functions. A program written in GPL would be assembled to bytecode and then run on an interpreter that was written in TMS9900 assembly language. This made BASIC programs on the machine rather slow. The CPU would execute the GPL interpreter. The GPL interpreter would run the BASIC interpreter. Finally, the BASIC interpreter would run your program. Only the TMS9900 code is statically recompiled in this program. The GPL still runs interpreted just as it did on the original machine. While it would theoretically be possible to statically recompile the GPL code as well this would be significantly more difficult since GPL was never officially documented by TI. The only definitive reference is the original interpreter.
  • C64 BASIC outputs characters to the screen via one function (CHROUT) which was easy to trap. TI-99/4A BASIC outputs to the screen with direct writes to video memory from multiple different places in the code. This requires some ugly hacks to get anything approximating reasonable on stdout.

Limitations

The Cassette, Disk, and Sound devices are not currently emulated. Contributions in these areas are most welcome.

Links

Dangerous Xbox 360 Update Killing Homebrew

On Tuesday, Microsoft has released an Xbox 360 software update that overwrites the first stage bootloader of the system. Although there have been numerous software updates for Microsoft’s gaming console in the past, this is the first one to overwrite the vital boot block. Any failure while updating this will break the Xbox 360 beyond repair. Statistics from other systems have shown that about one in a thousand bootloader updates goes wrong, and unless Microsoft has a novel solution to this problem, this puts tens of thousands of Xboxes at risk.

It seems that this update is being done to fix a vulnerability already known to the Free60 Project. This vulnerability has been successfully exploited to run arbitrary code, and a complete end user compatible hack has been in development for some time and is planned to be released on free60.org shortly. It will allow users to take back control of their Xboxes and run arbitrary code like homebrew applications or Linux right after turning on the console and without the need of a modchip, finally opening up the Xbox 360 to a level of hacking as the original Xbox.

Because of the dangerousness of the update and the homebrew lockout, the Free60 Project advises all Xbox 360 users to not update their systems to the latest software version. The Project website at http://free60.org/ will provide the latest information on this ongoing topic, including the final hack software.

Free60 (www.free60.org) is a project that aims to enable Xbox 360 users to run homebrew applications and operating systems like Linux on their consoles. The effort is headed by Felix Domke and Michael Steil, who have a background in dbox2, Xbox and GameCube hacking, and who have spoken at various conferences about their findings. Two years ago, Free60 released a hack that allowed arbitrary code execution using a game (“King Kong Hack”) as well as an adapted version of Linux, but this possibility has been disabled by Microsoft in subsequent updates of the Xbox 360 software.

Felix and Michael have repeatedly argued that game console manufacturers should open up their platforms to Linux and homebrew, similar to what Sony has done with the PlayStation 3.

(Felix Domke, Michael Steil, Free60 Project; 11 August 2009)

Stamp Vending Machine DoS

It makes sense for a stamp vending machine to have some limits and not print any amount of stamps or stamps of any value. The vending machines from the Deutsche Post are a little weird though:


You can only buy stamps worth 100 EUR at a time. Makes sense.


The maximum face value for a stamp is 36.75 EUR. Hmmm…


You can buy up to 100 stamps at a time, and the minimum face value is 1 cent. The poor machine will print worthless stamps for five minutes. The obvious question now is: What is the minimum amount of money that I have to invest to make it run out of paper.

The Easiest Way to Reset an i386/x86_64 System

Try this in kernel mode:

uint64_t null_idtr = 0;
asm("xor %%eax, %%eax; lidt %0; int3" :: "m" (null_idtr));

This can be quite helpful when doing operating system development on an i386/x86_64 system. You can use this for the regular restart case or when a kernel panic is supposed to restart immediately and you cannot make any assumptions on what is still working in the system.

You can also use this for debugging very low-level code if you don’t have a serial port or even an LED to report the most basic information: First make sure your code is reached by putting the reset code there. Then remove it again and put this code in:

if (condition)
    reset();
else
    for(;;);

The system will either hang or reset, depending on the condition.