PhatHack
The Hacking Hoedown => PhatBox Hacking => Topic started by: spin on May 23, 2005, 05:27:16 am
-
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 ;-)
-
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.
-
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.
-
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...
-
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.
-
Box should be here in a couple weeks at least, have you tried downgrading your firmware?
-
I spent a few minutes auditing the latest firmware update and it seems that getting custom code is not that difficult.
;D
[ /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
-
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 :-)
-
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:
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:
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. :P
Ben
-
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.
-
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
-
* 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.
-
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...
-
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:
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
-
(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.
-
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
-
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)
-
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. :o
-
Hehe, it's in CVS already - seek and you shall find ;D 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???
-
i thought the logs were written to /dos so they should be in the root of the phatsys partition...
-
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.
-
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
-
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.
-
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.
-
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
-
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?
-
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.
-
A reminder. A sector is 512 bytes.
-
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
-
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
-
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.
-
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. :D
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
-
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 ;-)
-
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...
-
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.
-
Done. Please see:
http://forum.phathack.com/cgi-bin/yabb/YaBB.cgi?board=dmshack;action=display;num=1117956547