Actually Hacking the PhatBox

[spin]

I spent a few minutes auditing the latest firmware update and it seems that getting custom code is not that difficult. Unfortunately, my PhatBox is still on order, so I will not be able to try these methods for another couple weeks [ I didn't place the order until I had a decent amount of confidence that this wasn't going to be a problem ]. On the with the show:

[ /dos/phat ]
No signature is included for this binary in the 9.0 release for the BMW model. This binary is executed by /dos/phatd and it should be possible to replace this with a shell script that does some hackery and then calls the real binary. Not sure how to convince phatd to execute this, but it seems like thats how this is supposed to work (phatd and 51d both reference this binary).

[/dos/playssahelp]
If help is enabled, this binary is executed, most likely without a signature check.

[/dos/phatd]
When phatd removes a file, it creates a command line with sprintf(): sprintf("rm -rf %s/%s", dir, file). This string is passed directly to system(), it should be possible to create a file containing a shell metacharacter and use this to execute a custom binary or shell script.

[/etc/profile]
If for some reason, the shell is executed with the --login parameter, it will parse the script in /etc/profile. This profile will execute /dos/bin/bash if it exists, allowing another way in.. assuming /bin/sh is ever executed in a way that the profile is read.

The SHELL action under 51d looks like it was defanged by changing the shell out with /bin/false...

Anyhow, there are more tricks than this, but I figured this is a start. If anyone can verify these, that would rock ;-)

[judb]

The /etc/profile option is interesting to me (I found that some time ago) but I need a working arm version of bash and posted about that and have gotten no responses.  the question that remains is, would /dos/bash need to really be a shell, and does it have to be signed to run?

We cant modify the contents of the ram disk, i tried that, the ramdisk is signed and wont boot if you toy with it.

[RobM]

Instead of putting a real bash executable there you can put a shell script that uses the busybox built-in ash shell (as /bin/sh in the ramdisk).

I've actually got the softgun ARM emulator running with a Linux image (not the PhatBox image, another one) and I've been playing around with the PB executables in it.  If I can get strace running in the image then I can see what system calls the 51d, phatd, etc. executables are doing.

[spin]

Install a shell script called bash in /dos/bin/bash, then create a configuration file (I forget the name, but it has to exist before bash is launched), place that also into the /dos/[directory]/, and it should launch if the login shell is executed.

The "/dos/playssahelp" and "/dos/phat" options seem like the best bet stil...

[judb]

I tried that already, the file is not signed so it didnt work.  or at least thats what I think, its hard to say until I get my serial port working.  Im working up a serial voltage converter that was mentioned in another thread.

[spin]

Box should be here in a couple weeks at least, have you tried downgrading your firmware?

[bushing]

I spent a few minutes auditing the latest firmware update and it seems that getting custom code is not that difficult.

[ /dos/phat ]
No signature is included for this binary in the 9.0 release for the BMW model. This binary is executed by /dos/phatd and it should be possible to replace this with a shell script that does some hackery and then calls the real binary. Not sure how to convince phatd to execute this, but it seems like thats how this is supposed to work (phatd and 51d both reference this binary).

Hmm... I don't see that.  Judging by the modification time, it looks like "phat" is just left over from an old version of the software.  I don't see any evidence that it's referred to by either phatd or 51d -- can you point me to where you saw that?

[/dos/playssahelp]
If help is enabled, this binary is executed, most likely without a signature check.

Again, I don't see any evidence that it's executed. It checks for its presences, "does something" (probably plays the help), and then deletes the file.  I'd imagine that this is used to automatically play the help upon first poweron, but it should be easy to check (it may be a few days before I can) -- just create a file called /dos/playssahelp and see if it plays the help...
 

[/dos/phatd]
When phatd removes a file, it creates a command line with sprintf(): sprintf("rm -rf %s/%s", dir, file). This string is passed directly to system(), it should be possible to create a file containing a shell metacharacter and use this to execute a custom binary or shell script.

Very interesting.   I'm not real sure what it's doing here, or why it's deleting files, but yeah - something like "/dos/data/record/blah;echo test >>test" should work.


Nice work!   What are you using to perform this analysis, and does anyone have any idea what version of libc (or glibc or uClibc) they're using?  I'm using IDA Pro, and it'd sure be nice to have some FLAIR signatures...

-b

[spin]

 

Hmm... I don't see that.  Judging by the modification time, it looks like "phat" is just left over from an old version of the software.  I don't see any evidence that it's referred to by either phatd or 51d -- can you point me to where you saw that?

There is a single string reference in each binary to that path,  could be it appends something to it, but it didn't look that way. I have IDA 4.5 somewhere, but most of my analysis is a hex editor and a couple eyeballs =P

Again, I don't see any evidence that it's executed. It checks for its presences, "does something" (probably plays the help), and then deletes the file.  I'd imagine that this is used to automatically play the help upon first poweron, but it should be easy to check (it may be a few days before I can) -- just create a file called /dos/playssahelp and see if it plays the help...

Ah, good point. Oh well ;-/

Very interesting.   I'm not real sure what it's doing here, or why it's deleting files, but yeah - something like "/dos/data/record/blah;echo test >>test" should work.

Just need to figure when that system() is called and whether or not we can control the path...I will start auditing for real once the box gets here, hopefully work will get me IDA 4.8 soon :-)

[bushing]

I did some more digging..

Re: /etc/profile -- the phatbox is using busybox, which runs "lash" as its (internal) shell, so check  out http://www.busybox.net/cgi-bin/viewcvs.cgi/trunk/busybox/shell/lash.c?rev=9972&view=auto.

It looks like the shell has to be run as "-/bin/sh" (or anything beginning with '-') in order to read that file.  The primary path that executes that shell is /etc/init.d/rcS, which won't do it.

Interestingly enough, inittab has it set to execute that way on "respawn" -- ie if the shell process were killed.   Which I can't see a way to do.

/dos/phat -- I took a second look, and I found it in 51d.  (We may have different versions of phatd, or I may not be looking hard enough.)

It looks like 51d does this:

Code: [Select]


main() {
     int debug_level=-1;

     debug_level=atoi(getenv("DEBUG_LEVEL"));

     if(debug_level==0)
            system("/dos/phat update");
 ......
}


here is the usage info for phat:

Code: [Select]


USAGE: phat [option]
where options are:
help       shows this screen
testmode   sends a FDh to the 51, putting it into self test
update     forces the reloading of BOOT and FIRMWARE in to the 51
update_noenc    same as update w/o decryption (faster!)


I don't see how we can set that environmental variable, but that usage info is mildly exciting.

I'm increasingly convinced that the key to unlocking the drive lies in the firmware .PAC images.

I don't see anywhere in the executable code that verifies the signature on the linux kernel, nor do I see anything verifying the drive signature.  This agrees with the only official word I've seen: (from http://www.phatnoise.com/forum/showthread.php?s=5d8e39da3626ce9a2af673dee71b5177&threadid=709&highlight=gpl

All PhatBox/Music Keg owners are welcome to the source code for the Linux kernel under the GPL if you wish. Just ask.

Note that:
1. The changes are not very big.
2. While you can look at the code and compile new kernels all day, you won't be able to actually run them. (DRM)
3. The only insight you'll get as to why off the shelf drives don't work is that it has nothing to do with the kernel.
4. It'll make more work for me.

You're also welcome to the unmodified uClibc source, and busybox modified to handle DOS CR/LF pairs.

This makes me think that the firmware (in firmware.pac) is responsible for both checking the drive signature (which would mean it doesn't use the output of hdparm!) and checking the signature on the linux kernel.  Even if we couldn't change the firmware, disassembling it would let us gain insight on exactly how it's performing its checks.

[rude remark deleted]

It looks like they are using uClibc for busybox, and glibc for the other executables.  The jury's still out as to whether linux.sig is a decoy or really checked, but I'm starting to lean towards the latter.  

Ben

[RobM]

This makes me think that the firmware (in firmware.pac) is responsible for both checking the drive signature (which would mean it doesn't use the output of hdparm!) and checking the signature on the linux kernel.  Even if we couldn't change the firmware, disassembling it would let us gain insight on exactly how it's performing its checks.

(as an aside, I think he's lying about the uClibc part -- looks like they're using glibc? -- and I think it's possible that linux.sig is a decoy, and not really used.)

They could be using both ulibc and glibc for different executables as they're all statically linked.

As far as hdparm goes, it looks like it's only used to spin up and down the drive.  If you look around the hdparm strings in the daemon files you see -y and -Y which are spin-down commands.  I don't see any -i or -I which you'd expect from a program that uses hdparm to get a drive signature.

My guess is that the Linux kernel (even modified) boots, but phatd or 51d or one of the other programs does a signature on the kernel file and hangs if it's not right.  I've got no way to verify that just yet, though.

[bushing]

They could be using both ulibc and glibc for different executables as they're all statically linked.

As far as hdparm goes, it looks like it's only used to spin up and down the drive.  If you look around the hdparm strings in the daemon files you see -y and -Y which are spin-down commands.  I don't see any -i or -I which you'd expect from a program that uses hdparm to get a drive signature.

My guess is that the Linux kernel (even modified) boots, but phatd or 51d or one of the other programs does a signature on the kernel file and hangs if it's not right.  I've got no way to verify that just yet, though.

I think you're right.  They're using uClibc for busybox, and I think glibc for everything else -- not really sure why.  I know that we're using linux 2.4.18 and gcc 2.95.3 and busybox-0.52, but I'm still looking for the exact versions of glibc and uClibc to make it easier to match up the functions in the assembly dump with their C counterparts.

I'm with you on the hdparm bit, but I still fear that both the linux kernel and the drive signature are checked by the firmware.   Here's why:

* If the firmware is checking the drive signature and reading ext2fs to load + boot the kernel, then it already has all of the code necessary to verify linux.sig

* The firmware images (*.pac) are both encrypted AND signed, in contrast with everything else (kernel, usermode utils) which are merely signed -- this suggests that they have something to hide in the firmware, as opposed to merely preventing us from reflashing

* These guys are clever (hi, guys!), and it's the right way to do it.  If linux.sig isn't checked until phatd or 51d, then we could build a kernel module / patch the kernel to fake-out the signature checking routines.  They should make sure the kernel is intact before running it.

* grepping through everything for /dos/linux returns nothing, leading me to doubt they're re-reading it anywhere.

If this is true, then our only avenue would probably be to use the JTAG connectors to reflash something, unless we're able to use the rm %s/%s with shell escape chars, or somehow sneak in a buffer overflow.

In other words, press on -- I hope you're right!

-b

[RobM]

* If the firmware is checking the drive signature and reading ext2fs to load + boot the kernel, then it already has all of the code necessary to verify linux.sig

The PHATSYS partition on the DMS is a FAT partition, but what you say still otherwise applies.

* The firmware images (*.pac) are both encrypted AND signed, in contrast with everything else (kernel, usermode utils) which are merely signed -- this suggests that they have something to hide in the firmware, as opposed to merely preventing us from reflashing

I can see a good reason to obfuscate the 8051 firmware as a lot of hard work (or alternatively NDAs) went into the head unit interfacing.  I can't see a similar reason to encrypt the boot firmware if not just to control the drives, etc.

* These guys are clever (hi, guys!), and it's the right way to do it.  If linux.sig isn't checked until phatd or 51d, then we could build a kernel module / patch the kernel to fake-out the signature checking routines.  They should make sure the kernel is intact before running it.

True, but let's hope they did it the easy way and not the right way

* grepping through everything for /dos/linux returns nothing, leading me to doubt they're re-reading it anywhere.

That's somewhat disappointing, but I do see references to /dev/mem which looks mildly suspicious to me.

If this is true, then our only avenue would probably be to use the JTAG connectors to reflash something, unless we're able to use the rm %s/%s with shell escape chars, or somehow sneak in a buffer overflow.

This might be helpful on the buffer overflow front:

http://www.phrack.org/phrack/58/p58-0x0a

Meanwhile I'm still setting up my ARM toolchain.  I've got an all-targets binutils built.  Getting GCC up is my next step.

[judb]

There is one assumption you made that I know can't be right.  hdparm is called by phatd and by some of the player code, for instance to read an audible file, the file is tied to the phatbox drive.. it uses hdparm to get the drive info and check that against the file prior to allowing you to play it back.

if you copy the file to another DMS it wont work.  Same thing with drives that come with .pna files preloaded on them.  they only work on that DMS.

I was speculating that the JTAG route might be a better way to go.. but perhaps the serial port access method might be helpful.

I dont know which method update or update_noenc would be used when phatnoise flashes the code to the phatbox.  if they use the no decrption method we might need serial access to use the command line update option and the JTAG interface to extract the flash image from memory...

[bushing]

There is one assumption you made that I know can't be right.  hdparm is called by phatd and by some of the player code, for instance to read an audible file, the file is tied to the phatbox drive.. it uses hdparm to get the drive info and check that against the file prior to allowing you to play it back.

We're in agreement here.

Just to summarize, hdparm is used by the following code, for the following reasons:

Code: [Select]


51d:    /dos/hdparm -q -y             (when going into Standby mode)
          /dos/hdparm -q -Y              (when going into Shutdown mode)
          read to verify hdparm.sig

phatd: read to verify hdparm.sig

aadec:  /dos/hdparm -Q
            Interestingly enough, on my (modern) linux system, that sets the drive's Tagged Command Queueing depth.  But here, it's

-Q   print out the drive id only (60bytes\n)


When I'm talking about the drive ID being read by the firmware, I'm talking about the code that will prevent you from even booting if using a hacked drive.

I was speculating that the JTAG route might be a better way to go.. but perhaps the serial port access method might be helpful.

I agree -- although I haven't been able to confirm that it will throw a console onto the serial port.  It probably will.

I will be a bit disappointed if we can't come up with a general solution that doesn't require cracking the player open ... but we'll see.  (Not because I'm opposed to such things, but it's much nicer to be able to download a fix!)

I dont know which method update or update_noenc would be used when phatnoise flashes the code to the phatbox.  if they use the no decrption method we might need serial access to use the command line update option and the JTAG interface to extract the flash image from memory...

Well, there's a message saying that the noenc method is deprecated -- probably a holdover from the red phatboxes.

Although we may end up using their code to do the flashing, the reason i'm excited to see both is that I hope to compare the two execution paths to isolate the decryption routine, which has to be in there somewhere (because it has to be written to the flash unencrypted for it to execute...)

I've already figured out the header format for the PAC files, and hope to have more info tonight -- i'll post in the other thread that I made last week.

-b

[Vince]

(as an aside, I think he's lying about the uClibc part -- looks like they're using glibc? -- and I think it's possible that linux.sig is a decoy, and not really used.)

I was not lying.  Just look at the size of "Hello World" linked with glibc to see for yourself.  You should use more diligence before falsely attacking my integrity.

[bushing]

I was not lying.  Just look at the size of "Hello World" linked with glibc to see for yourself.  You should use more diligence before falsely attacking my integrity.

Hi Vince!

I'd like to publicly apologize for that -- I meant that in jest, and rereading it, it certainly didn't come across that way.

Congrats on a very-well designed system, btw... I'm truly impressed.

-b

[judb]

I agree -- although I haven't been able to confirm that it will throw a console onto the serial port.  It probably will.

I will be a bit disappointed if we can't come up with a general solution that doesn't require cracking the player open ... but we'll see.  (Not because I'm opposed to such things, but it's much nicer to be able to download a fix!)

-b

Well, I ran through everything on the ramdisk and from what I can tell about the busybox setup is the init.d setup SHOULD cause a shell to go to the console which according to the dev devices /dev/console is redirected to /dev/STTY0 if I recall correctly.  That means we should get some sort of output.  

Unless im smoking da crack again.. I hate it when I do that.

Oh and way to go ace, pissing off Vince, hes a cool Mother  (im just being silly dont take this to mean anything, anyone)

[LindsayLohan]

You should use more diligence before falsely attacking my integrity.

My, my, my.  You certainly came off a little huffy on that one.  Judging by the time of the post, you were at work.  Does your employer generally encourage this sort of behavior?
[/Rant]

Sounds like we're making some progress with both the hardware and some accompanying software (Thanks para!  Get that code up in CVS so we can all start contributing some of our own code!).  I hope we don't upset Vince anymore, tho.

[para]

Hehe, it's in CVS already - seek and you shall find I'll post an official link soon...

BTW, I need to do some debugging! I'm using Firefox's modified rc.sh but where the heck do I find the logs as /var/logs is to be found in RAM only... Is there any other way to get a bootlog or something similar onto the DMS???

[judb]

i thought the logs were written to /dos so they should be in the root of the phatsys partition...