Hardware WODE CFW?

[gudenau]

Has anyone managed to reverse engineer the WODE yet?

Would be great to be able to figure out all the commands and potentially create custom firmwares with more features. (nkit dumping/reading for example)

 

[The Real Jdbye]

Wasn't the Wode open source? I could have sworn it was.

 

[gudenau]

Wasn't the Wode open source? I could have sworn it was.

The code that ran on the Wii was, but as far as I remember (and could dig up) the GCN portion, custom ARM stuff and FPGA sources where never released.

I did find a DFU blob for it, so it might be possible to use that to "get my foot in the door".

 

[The Real Jdbye]

The code that ran on the Wii was, but as far as I remember (and could dig up) the GCN portion, custom ARM stuff and FPGA sources where never released.

I did find a DFU blob for it, so it might be possible to use that to "get my foot in the door".

Since the official forum seems to be gone and I don't remember the URL to check it on Wayback Machine, I can't be 100% sure, but I'm pretty sure there were talks about open source and that people could write their own functionality for it. Maybe they just never went through with that.

IIRC, it runs Linux, so if you can manage to get shell access through a debugging port, root should also be possible (given that it likely uses an ancient Linux kernel I'm assuming there are exploits)
I'm guessing they would have had to have some sort of debugging port to use during testing, especially when testing new firmware updates before release, but there might not be test pads left for it on the board, and it's possible the firmware released to the public has debugging disabled.
If you could somehow have a look at the rootfs it might go a long way in figuring out how to interface with the FPGA. Either through shell access or by decrypting/decompressing the firmware update blob.

 

[gudenau]

Since the official forum seems to be gone and I don't remember the URL to check it on Wayback Machine, I can't be 100% sure, but I'm pretty sure there were talks about open source and that people could write their own functionality for it. Maybe they just never went through with that.

IIRC, it runs Linux, so if you can manage to get shell access through a debugging port, root should also be possible (given that it likely uses an ancient Linux kernel I'm assuming there are exploits)
I'm guessing they would have had to have some sort of debugging port to use during testing, especially when testing new firmware updates before release, but there might not be test pads left for it on the board, and it's possible the firmware released to the public has debugging disabled.
If you could somehow have a look at the rootfs it might go a long way in figuring out how to interface with the FPGA. Either through shell access or by decrypting/decompressing the firmware update blob.

The updates don't immediately look like anything so I'm pretty sure they are encrypted. And according to the DFU documents they snuck the debugging port into a ribbon cable so that's not really practical.

I'm thinking figuring out the DFU blob and disassembling that is the best bet. The NXP software used to flash it has to be able to read it somehow.

Here's the DFU thing, turns out I missed the open WODE thing. Too bad it's not archived.https://web.archive.org/web/*/http://www.wodejukebox.com/download/openwode.rar

 

[The Real Jdbye]

The updates don't immediately look like anything so I'm pretty sure they are encrypted. And according to the DFU documents they snuck the debugging port into a ribbon cable so that's not really practical.

I'm thinking figuring out the DFU blob and disassembling that is the best bet. The NXP software used to flash it has to be able to read it somehow.

Here's the DFU thing, turns out I missed the open WODE thing. Too bad it's not archived.

Might be fiddly but soldering to the pins on the ZIF socket should at least be doable.

Currently running a scan, already found something.

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
917084        0xDFE5C         ARM instructions, function prologue
3217793       0x311981        ARMEB instructions, function prologue
3585371       0x36B55B        ARMEB instructions, function prologue
6423409       0x620371        ARM instructions, function prologue


Scan Time:     2020-08-18 16:57:06
Target File:   /mnt/d/Temp/wode/wode.dfu
MD5 Checksum:  50919a3e8c2a603c4939a6ec3e499806

The .bin files look like they might be an entirely custom format, and I'm guessing the .dfu just contains the code to flash install.bin and bootstrap it judging by how small it is. Might have to reverse engineer that code to get any further.

 

[gudenau]

Might be fiddly but soldering to the pins on the ZIF socket should at least be doable.

Currently running a scan, already found something.

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
917084        0xDFE5C         ARM instructions, function prologue
3217793       0x311981        ARMEB instructions, function prologue
3585371       0x36B55B        ARMEB instructions, function prologue
6423409       0x620371        ARM instructions, function prologue


Scan Time:     2020-08-18 16:57:06
Target File:   /mnt/d/Temp/wode/wode.dfu
MD5 Checksum:  50919a3e8c2a603c4939a6ec3e499806

The .bin files look like they might be an entirely custom format, and I'm guessing the .dfu just contains the code to flash install.bin and bootstrap it judging by how small it is. Might have to reverse engineer that code to get any further.

I did look at the file in a hex editor and it looks almost like there's an exception table at the beginning, but I've got no idea. I'm sure I'll be able to find the NXP documentation for the format when I look.

 

[The Real Jdbye]

I did look at the file in a hex editor and it looks almost like there's an exception table at the beginning, but I've got no idea. I'm sure I'll be able to find the NXP documentation for the format when I look.

I got a lot of this

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
2174          0x87E           Raw deflate compression stream
2192          0x890           Raw deflate compression stream
2684          0xA7C           Raw deflate compression stream
2996          0xBB4           Raw deflate compression stream
3001          0xBB9           Raw deflate compression stream
3031          0xBD7           Raw deflate compression stream
3033          0xBD9           Raw deflate compression stream
3093          0xC15           Raw deflate compression stream

And it just keeps going on. It's taking a very long time to scan though. Using binwalk.
All of this is still in wode.dfu. And it's extracting/decompressing the data as it goes.
Takes a very long time to scan through the entire file though. So far it's just looking like garbage data.

 

[gudenau]

I got a lot of this

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
2174          0x87E           Raw deflate compression stream
2192          0x890           Raw deflate compression stream
2684          0xA7C           Raw deflate compression stream
2996          0xBB4           Raw deflate compression stream
3001          0xBB9           Raw deflate compression stream
3031          0xBD7           Raw deflate compression stream
3033          0xBD9           Raw deflate compression stream
3093          0xC15           Raw deflate compression stream

And it just keeps going on. It's taking a very long time to scan though. Using binwalk.
All of this is still in wode.dfu. And it's extracting/decompressing the data as it goes.
Takes a very long time to scan through the entire file though. So far it's just looking like garbage data.

I think I am on to something, and if I am reading this right they key to decrypt the code is just 91EC6C69EACEE0D06972503AF69228BF.

 

[The Real Jdbye]

I think I am on to something, and if I am reading this right they key to decrypt the code is just 91EC6C69EACEE0D06972503AF69228BF.

View attachment 222051

Nice. binwalk ended up segfaulting, so I didn't get very far.

 

[gudenau]

Nice. binwalk ended up segfaulting, so I didn't get very far.

Page 93 or so has the details.

 

[nitr8]

Just for clarification:

91EC6C69EACEE0D06972503AF69228BF

is the encryption key used for TEA ("Tiny Encryption Algorithm") encryption. Writing a tool that does just that (encrypt and decrypt) using the provided key and IV works on those binaries within the LPC binary package over at the website of "Embedded Artists" (the creator of the WODE development board).

It does NOT work for the WODE firmware binaries. Those are most likely encrypted using an AES-128-CBC encryption key which is stored within the LPC OTP area (master key) while there is a second key located and used within the u-Boot binary of the WODE (data key) when reading the Linux Kernel off the MX25L6405DMI-12G (SPI-NOR flash).

Anyway, the data key usually is encrypted using the master key. Tests have shown that it's not possible to decrypt the WODE binaries using the encrypted data key and IV. The output is just garbage. So if there's no way to access OTP to gain the master key then you'll never be able to decrypt the WODE's firmware binaries.

Aside from that, once the WODE has booted, the "OTP READ LOCK protection bit" has been set. Once this bit has been set, it can only be reset by RESET of the LPC.

 

[wildbomb]

Regarding getting access to the linux shell, there is a way over serial console. Look up wode.obeygravity.de/YouAreRoot in the archive.org

I also went through my old backups and found a copy of the openwode.rar
ufile.io/89h0xdk2

(Sorry, can't post links since I just registered)

 

[gudenau]

That's incredible, I'd give you some money if I had a job. Thank you very much!

 

[contezero]

Regarding getting access to the linux shell, there is a way over serial console. Look up wode.obeygravity.de/YouAreRoot in the archive.org

I also went through my old backups and found a copy of the openwode.rar
ufile.io/89h0xdk2

(Sorry, can't post links since I just registered)

Thank you for sharing this file. Unfortunately is now expired. Can someone upload it again ? Maybe in the gbatemp download area?

 

[nitr8]

Just to be clear:

The WODE Unbricker DFU file is created by first compiling it, then being encrypted using AES and then once again being encrypted using TEA.