Hardware WODE CFW?

gudenau

Largely ignored
OP
Member
Joined
Jul 7, 2010
Messages
3,882
Trophies
2
Location
/dev/random
Website
www.gudenau.net
XP
5,313
Country
United States
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)
 

gudenau

Largely ignored
OP
Member
Joined
Jul 7, 2010
Messages
3,882
Trophies
2
Location
/dev/random
Website
www.gudenau.net
XP
5,313
Country
United States
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".
 
  • Like
Reactions: The Real Jdbye

The Real Jdbye

*is birb*
Member
Joined
Mar 17, 2010
Messages
23,207
Trophies
4
Location
Space
XP
13,733
Country
Norway
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

Largely ignored
OP
Member
Joined
Jul 7, 2010
Messages
3,882
Trophies
2
Location
/dev/random
Website
www.gudenau.net
XP
5,313
Country
United States
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

*is birb*
Member
Joined
Mar 17, 2010
Messages
23,207
Trophies
4
Location
Space
XP
13,733
Country
Norway
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.
Code:
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.
 
Last edited by The Real Jdbye,

gudenau

Largely ignored
OP
Member
Joined
Jul 7, 2010
Messages
3,882
Trophies
2
Location
/dev/random
Website
www.gudenau.net
XP
5,313
Country
United States
Might be fiddly but soldering to the pins on the ZIF socket should at least be doable.

Currently running a scan, already found something.
Code:
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

*is birb*
Member
Joined
Mar 17, 2010
Messages
23,207
Trophies
4
Location
Space
XP
13,733
Country
Norway
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
Code:
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.
 
Last edited by The Real Jdbye,

gudenau

Largely ignored
OP
Member
Joined
Jul 7, 2010
Messages
3,882
Trophies
2
Location
/dev/random
Website
www.gudenau.net
XP
5,313
Country
United States
I got a lot of this
Code:
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.

upload_2020-8-18_20-35-5.png
 

nitr8

Well-Known Member
Member
Joined
Apr 4, 2007
Messages
366
Trophies
1
Website
vermillion57.wixsite.com
XP
1,450
Country
Gambia, The
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.
 
Last edited by nitr8,

wildbomb

New Member
Newbie
Joined
Jan 6, 2022
Messages
2
Trophies
0
Age
39
XP
34
Country
Germany
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)
 
  • Like
Reactions: contezero

contezero

Well-Known Member
Member
Joined
Jul 25, 2016
Messages
216
Trophies
0
Age
48
XP
1,787
Country
Italy
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?
 

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
    ShdwTakashi @ ShdwTakashi: pineapple belong on pizza? The answer is yes until proven otherwise