** updated, because I thought of new stuff while fixing typos **
Maybe I'll take a look at the 8051 as well...I'd be very surprised if there weren't some way for us to get our own code into the chip, even if we have to fully erase the thing to make it happen.
I looked over Winbond's (very terse) data sheet on that part awhile back, and if I recall correctly the type of security the thing uses, it's basically a sort that allows the contents of the chip to be read back out, but unless the person doing the reading knows what the security key is, they can't directly read the output data. Typically, the way that type of security works is, there's an 8-, 16-, or 64-byte key that's programmed into special registers on the MCU, and when the code is read out of the processor, each N-byte block is XORed with the security key.
Often times, this type of security can be worked around if the person programming the part is lazy, because if they leave unprogrammed locations unprogrammed, then reading the chip results in a bunch of garbled code, followed by a bunch of repeated blocks of the same data, which will usually be the key XORed with 0xFF (in rare cases, it'll just be the key, because some compilers produce .HEX files that stuff 0's into unused locations).
One thing that you can often do to decide if you've decrypted the data correctly on this type of processor is to look at the byte at locations 0x0000, 0x0003, and 0x0013 - Usually, they'll all be 0x02, because those locations are the reset vectors and a couple of interrupt vectors, respectively, so the instruction at those locations is often an LJMP to the appropriate handler.
Of course, all this assumes that our primary intent is to decrypt the code that's already in the MCU- in actual fact, if our goal is just to get fully custom firmware into the thing, then the existing firmware is a moot point- we just need to be able to communicate with the ARM sufficiently well to convince it that we're a bona fide product of the Phatnoise labs, and not some poseur trying to make the Phatbox do something it's creators didn't originally intend...and based on what I recall from the Wiki, we have a reasonably good idea of what that communication looks like.
Once we've made the ARM happy, there's no reason in the world that we can't add whatever esoteric functionality we want for a given head unit, provided we have an understanding of that head unit's interface.
-c
