Actually Hacking the PhatBox

[m509272]

I'm no linux programmer but you might get some hacking ideas over at
http://www.dealdatabase.com/forum/
which is a Tivo hacking forum.  It seems there might be similarities with how things are protected and how they've been gotten around.  Search for monte which is the procedure they use to jump around various bits of code during startup.

[ralph.deratt]

I've been looking at the phatbox linux source trying to figure out how they enforce signed executables.

So here's my theory.

They use their own bootloader which checks the signature of the linux image and the ramdisk before booting.

The system boots and eventually calls init, which is a busybox link on the signed ramdisk.  The rcS script calls /dos/phatd.  

There is nothing in the kernal source that supports checking the signature of an executable.  so I'm left to conclude that signature checking is a part of busybox.

Busybox is statically linked and is GPL (not LGPL), therefore, Phatnoise must provide, their modified busybox source.

Has anyone got the source of the phatnoise version of busybox?

RdeR

[RobM]

The system boots and eventually calls init, which is a busybox link on the signed ramdisk.  The rcS script calls /dos/phatd.  

There is nothing in the kernal source that supports checking the signature of an executable.  so I'm left to conclude that signature checking is a part of busybox.

I believe phatd and/or 51d do signature checks.  This would be easy to verify if someone replaces phatd with another executable (maybe one to flash the LED or something?) and see if it runs.

[judb]

I've been looking at the phatbox linux source trying to figure out how they enforce signed executables.

So here's my theory.

They use their own bootloader which checks the signature of the linux image and the ramdisk before booting.

The system boots and eventually calls init, which is a busybox link on the signed ramdisk.  The rcS script calls /dos/phatd.  

There is nothing in the kernal source that supports checking the signature of an executable.  so I'm left to conclude that signature checking is a part of busybox.

Busybox is statically linked and is GPL (not LGPL), therefore, Phatnoise must provide, their modified busybox source.

Has anyone got the source of the phatnoise version of busybox?

RdeR

You are right, we should be able to get the busy box soruce and the decoder code they use from them, however I highly doubt that they modified busy box much... I think you can run unsigned code on the phatbox IF we had shell access.. but I dont think the phatbox will boot if certian files (probably listed in the bootloader code) dont match the sigs or dont have the sigs.

As for the Tivo, they have very little in common with the methods to secure the systems as far as I can tell.

[bushing]

I'm no linux programmer but you might get some hacking ideas over at
http://www.dealdatabase.com/forum/
which is a Tivo hacking forum.  It seems there might be similarities with how things are protected and how they've been gotten around.  Search for monte which is the procedure they use to jump around various bits of code during startup.

This is actually not a bad idea.  I, uh, have a Tivo, so I guess that gives me license to talk out of my ass on this matter?

Early Tivos didn't have muc in the way of protection -- in fact, you could stick the drive in your computer, edit the /etc/rc.sh, stick a bash statement in there, and you'd have a shell on your serial port, no problem.

Contractual requirements with DirecTV made them start foiling our fun -- in a way similar to PhatNoise, except that instead of just blinking at you if you corrupted a file, it would copy over a hidden backup, erasing your changes.

I recall three different ways this was overcome:

1. The BOOT rom code would allow them to actually send commands over the serial port (I think) to change the kernel boot parameters-- they were able to use this force the kernel to run a command.

2. Tivo reflashed the boot rom to prevent the above attack, so people started deliberately downgrading to the older version to get the older BIOS, and then went from there

3.  Eventually, with the Series 2 boxes, Tivo got wise to both of the above tricks.  The last hacks I saw were extremely sophisticated -- it turns out that Tivo wrote some custom tool to package together A. a header B. a kernel image C. a ramdisk  D. a signature of B and C into one big file.  Hackers figured out a way to corrupt the header A, such that signature D would still check out, but that kernel B would not load ramdisk C, which was what had had the code to check the rest of the system.  Get it?

In any case, although some of the challenges they caced are similar to ours, the countermeasures were more sophisticated, which left far more room for errors and exploits.

Please, though, anyone correct me if I'm wrong!

Ben

[Genesis]

The most complex is usually the easiest to foil, once you point the blade in the right place.

In this case, if the boot loader is checking signatures, then the obvious thing to do is to replace the boot loader.  Once you've done that, then running a hacked library that contains a dummy return for the call to check signatures is trivial.

The entire game appears to be one of getting the hacked system to boot.  Boot loaders are not terribly complex things.....

Might everyone be going about this the hard way?

Do we understand the actual boot sequence from a hardware perspective - what boots, in what order, and which piece of hardware loads what from where?

[bushing]

The most complex is usually the easiest to foil, once you point the blade in the right place.

In this case, if the boot loader is checking signatures, then the obvious thing to do is to replace the boot loader.  Once you've done that, then running a hacked library that contains a dummy return for the call to check signatures is trivial.

The entire game appears to be one of getting the hacked system to boot.  Boot loaders are not terribly complex things.....

Might everyone be going about this the hard way?

Do we understand the actual boot sequence from a hardware perspective - what boots, in what order, and which piece of hardware loads what from where?

I agree.  We've gone back and forth on this, but it now seems that the bootloader is contained in a 128kbyte flash rom chip.  There is also approx 64kbyte of apparently encrypted data hidden on the hard drive in the first cylinder (with the first actual partition starting at cylinder 2).  The drive signature comprises the last ~250 bytes of that data.

Somehow, between those two bits of stuff, they check the signature of the drive, the linux kernel image (in the file called, well, linux), the initial ramdisk image, the shell script rc.sh, and the two userspace daemons -- phatd and 51d.  It then boots linux, which loads the ramdisk.  The ramdisk mounts the partitions and runs rc.sh, which kicks off phatd, which kicks off 51d.  At least, that's what we suspect.  No one (that I know of) had managed to dump the ROM yet, but it should be possible by setting a jumper on the board to boot into an internal monitor routine located on the EP7312, and then use a serial cable to retrieve the data.  Fortunately, that avenue should allow us to eventually reflash the ROM with a new image, which will probably be what we end up doing.   We should be able to just use a standard ARM linux bootloader to load the linux image, and away we go.

But yes, I agree with you.  Welcome to the board!

Ben

Edited to fix my units.  My Bad.

[A543]

A reminder. A sector is 512 bytes.

[jnitis]

No one (that I know of) had managed to dump the ROM yet, but it should be possible by setting a jumper on the board to boot into an internal monitor routine located on the EP7312, and then use a serial cable to retrieve the data.  Fortunately, that avenue should allow us to eventually reflash the ROM with a new image, which will probably be what we end up doing.   We should be able to just use a standard ARM linux bootloader to load the linux image, and away we go.

Assuming this works, will this method be easily repeatable by folks without opening the PB?  Ideally we want a method where we can publish a simple script or set of files simple enough to use that 95% of the PB community can take advantage of it.

John

[bushing]

Assuming this works, will this method be easily repeatable by folks without opening the PB?  Ideally we want a method where we can publish a simple script or set of files simple enough to use that 95% of the PB community can take advantage of it.

In the end, it will most likely require a firmware reflash to defeat the drive signature check.  However, if we're able to find a way to force the unit to execute something we put on the drive (a buffer overflow or something?), we should be able to reflash the firmware with software.

Ben

[Genesis]

No problem Ben.... my background is in embedded systems engineering, including real-time work, along with various types of assembler (going back to the PDP-10, -08, -11, Z-80, etc.)

There's nothing particularly complicated about booting a system if you have the hardware layout (e.g. you know what to write and read to and from where, either in I/O or memory space, to accomplish physical I/O) and you also know where what you want to load resides.

The cat's butt for this sort of thing would be a CPU emulator.  If we find someone with one for the chipset used here, its game over in a couple of hours.  Figuring out exactly "how it does it" on startup then becomes trivially easy, and once you know how the various pieces twist and turn, sticking a wrench in the appropriate place becomes trivial as well.  This would require hardware modification (to the machine being debugged) though, so it does require one "sacrificial" unit.

This sort of diagnostic equipment tends to be expensive though. You remove the actual CPU and replace it with the "pod", which is a virtual CPU that the hardware cannot differentiate from the real one.... They were my "tools of trade" when I was doing heavy real-time development work.

Indeed, when operating on a REAL embedded system (the Phat is not built to that level) they're pretty much the only debugging tool you have that's worth anything at all.

[bushing]

No problem Ben.... my background is in embedded systems engineering, including real-time work, along with various types of assembler (going back to the PDP-10, -08, -11, Z-80, etc.)

There's nothing particularly complicated about booting a system if you have the hardware layout (e.g. you know what to write and read to and from where, either in I/O or memory space, to accomplish physical I/O) and you also know where what you want to load resides.

The cat's butt for this sort of thing would be a CPU emulator.  If we find someone with one for the chipset used here, its game over in a couple of hours.  Figuring out exactly "how it does it" on startup then becomes trivially easy, and once you know how the various pieces twist and turn, sticking a wrench in the appropriate place becomes trivial as well.  This would require hardware modification (to the machine being debugged) though, so it does require one "sacrificial" unit.

This sort of diagnostic equipment tends to be expensive though. You remove the actual CPU and replace it with the "pod", which is a virtual CPU that the hardware cannot differentiate from the real one.... They were my "tools of trade" when I was doing heavy real-time development work.

Indeed, when operating on a REAL embedded system (the Phat is not built to that level) they're pretty much the only debugging tool you have that's worth anything at all.

Yeah, so, I don't know what business I have here.  I'm more like an, uh, shade-tree embedded systems hacker.

Really, any kind of actual in-circuit hardware tool is overkill here.  Compared with a lot of systems that are out there (and which it sounds like you've dealt with), this thing should be a piece of cake.  I imagine that all we really need to do is read the bootloader code out of the flash chip -- and it doesn't appear, anyway, that they've gone to any great lengths to interfere with that.

Heck, we don't even need to do that, in some sense -- we could almost just reflash it with a standard ARM linux bootloader, since we have the source for their linux kernel, and ARM bootloaders are pretty easy to come by on the net.

I just got my JTAG "wiggler" clone off eBay -- I'll try to wire it up and see if i can get anywhere.

Ben

[spin]

Finally got my PB (minus the DSP kit - jerks, its didn't ship until the PB already arrived). Some things I tried so far:

* /dos/bin/bash && /dos/conf/profile = failed. Not executed, I made a shell script called 'bash' and this executes another shell script that tries dumping system information to a log file on each partition. Same technique is used to test the other routines.

* Update the RC's the get logging info = failed. No logs even when using level 10 debug rc.sh. System seems to work fine (i updated the menus and see the new track numbers on the HU, so looks to be working)

* Metacharacters in the mp3 file names. This was a long shot, but I tried `script`;script;|script;'`script`', and all the common variants, in a few different places, with no love so far.

Still haven't tried the rm -rf %s/%s trick or just replacing /dos/phat (which has no sig in the BMW firmware). Once I get another drink in, I will march back out to the car for round #9 or so ;-)

[spin]

The debug rc script is actually working, I just got so used to ls -lart that I didnt notice it when the create time was set to 1979 =P Got a few new ideas based on the log entries, time to finish up my new phatbox ini and trek out to the car again...

[spin]

Some random fun bits:

28.76:phatd:main      : Playing file -h .mp3
28.76:phatd:start_mp3p: FILE: -h .mp3
28.76:phatd:start_mp3p: Re-setting playlist loading values
28.77:phatd:start_mp3p: Exec /dos/nmp3 -h .mp3 0 (null)
28.77:phatd:start_mp3p: player started pid 22
usage:   nmp3 [options] file [offset]
options:
        -c set number of channels (override) to
        -d set debug level to
        -h    print this message
        -i    only print mp3 info, do not play.
        -n    don't use threads
        -o<f> output to file <f>
        -p    swap left and right channels
        -q    quiet mode
        -r set sample rate (override) to
        -s    spin down the hard drive when buffer is full
        -t    use threads
        -w    set word byte swapping (LE/BE conversion)

You can also specify the filename as -o/dos/somefile, but unless you can contrl the output, this isn't that hot. If you /could/ make the first line of the output #!/bin/sh\n/dos/somescript.sh, then the day is won.. The "nmp3" binary is only authorized the first time it is executed -- you could overwrite it with a shell script and then have your shell script handle custom commands of the menu, executing the real nmp3 as needed. Unfortunately, this method wouldnt work on a restart, since the nmp3 signature would be invalid.. Back to hacking.

[spin]

Done. Please see:
http://forum.phathack.com/cgi-bin/yabb/YaBB.cgi?board=dmshack;action=display;num=1117956547