Hacking DS-Xtreme OpenSource Firmware Project

[dib]

Well it's clearly a hash value, but notice the value before it is a specific statement for the firmware version. The same one repeats later under the url, so I assume it's not checking the current firmware but verifying the one to be added.

Other than that, it doesn't sound like there are any additional checks judging by Shuny's reverter, which is a little odd considering how easy it would be to spoof both these values and upload a bricking firmware to the DS-X. But then, if one's motivation is malicious there is inevitably a way.

I'm assuming the values under MSG all have relevance strictly to the updating process. I think that they have the DS-X lights activate while updating, so that could be the RGB values under color table. It's been a long time since I ever ran the updater so I would have to do so to try to figure out which values govern what. Paper width and paper height, margin left and margin right, view width and view height, view kind? Seems pretty self descriptive that they're aligning something. Tx increments by sums of 560, whatever the significance of that is.

 

[reveng]

@pbolmstedt
@dib

Hey Guys,

The

"AN OBSERVATION ON THE UPDATER:"

was an attempt to see if I could get the DSX team to respond, sorry for the hidden psychology.

pbolmstedt, you're not a member of the DSX team are you?

EDIT: Ah, "powerful supplier of IT solutions", I can see why you answered that, but it was just a provocation to elicit a response from the code originator, nothing more. you're not a member of the DSX team are you?

O.K back to serious matters, the latter "[MSG]" part of UPDATE.TXT is simply the info box.

the "[Download]" is obviously just URL's, so that leaves the

[OSVersion]
"DS-Xtreme V1.0.0", 9c ab 31 ab 7a 43 cf 9d 5e 1c 59 95 1a 44 84 ac
"DS-Xtreme V1.0.1", 73 81 be 77 d2 87 ac 05 cd 4f 95 6d b0 44 36 64
"DS-Xtreme V1.0.2", 51 f8 94 9c e3 87 e2 32 1d 82 88 22 da 61 83 5b
"DS-Xtreme V1.1.0", fb d2 7c 30 e9 5d 6e 8f fa 64 f7 76 5c 0b 11 c2
"DS-Xtreme V1.1.2", db 93 c2 fb 58 cf c4 80 f9 f2 df 97 b8 36 d1 7e

As DIB pointed out you can downgrade I.E with Shuny's tool, so I dont see why these values would just be totaly be related to firmware versions (apart from the beginning tag), ofcourse I might be uttely wrong, who knows!

They might be related to how/if the UPADTE.BIN is compressed?
The FPGA can take encryption keys, they could be them?
They might tell the offsets and sizes of the different modules in the update.bin (USB,FPGA,Launcher)?
Or something entirely different?..

A quick exam of the V112 values
hex, decimal, ascii
db = 219 = not ascii
93 = 147 = not ascii
c2 = 194 = not ascii
fb = 251 = not asci
58 = 88 = ascii X
cf = 207 = not ascii
c4 = 196 = not ascii
80 = 128 = not ascii
f9 = 249 = not ascii
f2 = 242 = not ascii
df = 223 = not ascii
97 = 151 = not ascii
b8 = 184 = not ascii
36 = 54 = ascii 6
d1 = 209 = not ascii
7e = 129 = ascii ~

1) So its not any ascii string message.
2) I cant see 1, 1, 2, so it probabily does'nt contain a version number.
3) It seems Ridiculously long for just a checksum (although it might be part of it)

Next examine as 16 bit values (little endian and big endian)
Next examine as 32 bit values (little endian and big endian)
Etc Etc .............................

I'll leave the last two for others to explore..


By the way update.bin does seem to have some sort of header at the beginning of the file.

 

[dib]

Both the AES encryption and a hash use sixteen byte blocks. It's not an md5 hash, I already ran the update.bin through it and it gave a different value.

What happens if you reset v112 to all FFs and then attempt to run the updater?

 

[reveng]

Both the AES encryption and a hash use sixteen byte blocks.  It's not an md5 hash, I already ran the update.bin through it and it gave a different value.

What happens if you reset v112 to all FFs and then attempt to run the updater?

Good point might be an interesting experiment.

Dib, did you notice the .bin file looks like it has a header at the start "ExDS6"
Also because we have two versions of the .bin V110 and V112 comparisons can be made of any potential header.

Also it might throw off your attempts at decrypting if the encrypted data is embedded inside the .bin

A brute force approach would be
offset=0

Decrypt at offset
scan for one of the strings in the launcher
if found decrypted-----------
else
offset = offset + 1
repeat process



There is another potential format MIME, internet message format?

 

[gedly]

It would be a really great gesture, when it is finally admitted officially that the cart is abandoned (I'm assuming that they are waiting for all stocks to run out first before making the announcement so they don't have to be offloaded at a knockdown price) that the DSX team hand over their work to jolly clever people like yourselves.

Without having to waste time reverse engineering what's there already you can begin playing with that superb hardware.
Here's an ironic twist - with further development as an open source project, over the years the DSX could even become a highly prized rarity, capable of so much more than any other cart!

Whaaa....just five more minutes mummy. Oh, I was dreaming

No, but seriously, it is an exciting thought. As has been pointed out, just the things that could be done with the USB port could make it a homebrew developers dream.

 

[reveng]

It would be a really great gesture, when it is finally admitted officially that the cart is abandoned (I'm assuming that they are waiting for all stocks to run out first before making the announcement so they don't have to be offloaded at a knockdown price) that the DSX team hand over their work to jolly clever people like yourselves.

Without having to waste time reverse engineering what's there already you can begin playing with that superb hardware.
Here's an ironic twist - with further development as an open source project, over the years the DSX could even become a highly prized rarity, capable of so much more than any other cart!Â

Whaaa....just five more minutes mummy. Oh, I was dreamingÂ

Â

No, but seriously, it is an exciting thought. As has been pointed out, just the things that could be done with the USB port could make it a homebrew developers dream.

Or an entry level ($100) fpga kit?

 

[MrSpud]

Hey guys, DS-x Guru just posted on ds-x forum, he said a new firmware is coming up. Only thing is, it says ds-x guru joined january 2008 and he has 2 posts? What do you guys think? (sorry, off subject)

 

[reveng]

Hey guys, DS-x Guru just posted on ds-x forum, he said a new firmware is coming up. Only thing is, it says ds-x guru joined january 2008 and he has 2 posts? What do you guys think? (sorry, off subject)

OMG: A WORD FROM THE HOLY ONE
wont stop the project

 

[sylux92]

Its probably an imposter. But the DS-X forums are crap, so maybe DS-X Guru is lying, cause they've been saying for months a new firmware is coming out.

 

[reveng]

Its probably an imposter. But the DS-X forums are crap, so maybe DS-X Guru is lying, cause they've been saying for months a new firmware is coming out.

Hahhahahahhahahahhahahhahah

would be a good joke, classic

sure will miss the DSX company when they liquidate

 

[dib]

I haven't been able to play with it yet, I have alaptop set up for everything like this with all my programs. But it's half way dismantled right now so I don't have it with me during the day.

Isn't the ProASIC3 used in the DS-X arm enabled?

2. AES is not available for ARM-enabled ProASIC3 devices.

 

[cory1492]

If I had to bet, the values in the txt are hashes of the decompressed data or a specific portion of the decompressed data ~ though that is making a very quick assessment/assumption on the 112 header:
"7B A2 18 00" from said header, byterev is 0x0018A27B == 1614459 (actual file size being 1614560/0x18A2E0.)

There seem to be 3 such values (aligned quite nicely to 32bit no less)
"F9 73 48 00" = 0x004873F9 = 4748281 (~4.5MiB) (~decompressed sz?)
"7B A2 18 00" = 0x0018A27B = file size minus 101 bytes (~compressed sz?)
"E0 A2 18 00" = 0x0018A2E0 = actual file size
also, the third is followed by
"01 01 00 00" = 0x00000101 = (edit: looked at 110 and it is identical, just an odd coincidence)

If there is a key, I'd be looking hard at those first 101 bytes... I for one am also presuming the cyphered (aka: not sure if it's compressed, crypted or a combination of both) data contains more than just one firmware/data file.

One thing I would also do is try sniffing the update process via a USB sniffer, see what kind of data blocks are being sent and such (be a huge sniff though if you have to capture the "whole shebang"), perhaps (fingers crossed) there would be some known plaintext code to capture in there somewhere? It might at least give a more viable starting point.

Don't mind me though, I have no DSX so the interest is kind of pointless on my part - just tossing some thoughts into the mix if they haven't been thought of already.

edit:/ in case you missed it reveng: I have messed with stream compression using zlib and similar stubs before and this definitely looks like such a beast (quite likely with the first two bytes 00'd so it's not easily identifiable), mainly because of the 2 sizes presented in what appears to be a fairly long header. Not saying the compression will be standard, though it may also be possible to gain the decompressed data from the PC's memory using one of the PC game cheat tools or something similar. Oh, and keep an eye on the temp folders (or open file handles for the app) when running such software as well, I have come across some interesting mid work data that way before (they didn't think people will be looking at temp while their app is running)

 

[dib]

By the way, where the DS-X forums are concerned please to be noting that "DS-X Guru" != "DSX Guru". Come on, people. Next you'll be entering your Myspace passwords into some site called Myspace.cx

 

[reveng]

Round of applause, for Cory very, very cool....

In theory the .bin file is made up of 3 parts:

1) the ez-usb controller firmware.
2) the actel fpga configuration.
3) the ARM NDS launcher.

We know it has a ARM NDS launcher cause thats been dumped using a wifi rom dumper. But that might be buried in the fpga config..

So that ties in nicely with what your seeing with the 3 lots of settings in the header of the .bin file.

The DSX PC updater has verbatim a copy of some of the zlib source, ive compared it partially on a disassembly. I belive the bit I was comparing was the source to ZLIB inflate.

The sniffers a good idea, though I dont have the hardware...but I think the dsx updater PC application will give the whole game away. I.E
its gotta send the usb firmware - hey presto you have the usb 8051 firmware and the comms protocol.
its gotta send the fpga config - hey presto you have the config (not sure how you decompile veriolg, VHL or whater its called)

As you mentioned you could just step thru the PC app and grab the data.
But at the end of the day you want to be able to alter the firmware as I'm sure others would, so we will need to either, make our own updater or use the dsx updater but repack our own firmware.

Funny: The temp folders was my first attemps with the updater, zapped my pc clean with crapcleaner open up the temp then ran the updater.. Nothing to show, then it was VS2005 binary editor...on the updater.exe that pointed at the URL's of the server it was downloading from... Then it was a simple matter to grab the binary and the txt

I was thinking of maybe just calling the DSX PC updater from a shell coded in VS2005 then I could just use VS2005 debugger to step thru it. Decompiling wise there are some good ones that specifically geard towards Borland Delphi which the application was coded with.


Slightly off topic:
I was looking at the chinese manufactuers site for the R4DS and looking at the other "clone" mod boards they do. The idea being it might point at what sort of chips they have been using for the R4DS. But its slow going... They seem to like Actel, lattice, and UBI Com (parallax), When I get some time I'll compile a proper list. It might help the detective work.

Not really had much time to work on both projects, making a living getting in the way of fun :'(

If I had to bet, the values in the txt are hashes of the decompressed data or a specific portion of the decompressed data ~ though that is making a very quick assessment/assumption on the 112 header:
"7B A2 18 00" from said header, byterev is 0x0018A27B == 1614459 (actual file size being 1614560/0x18A2E0.)

There seem to be 3 such values (aligned quite nicely to 32bit no less)
"F9 73 48 00" = 0x004873F9 = 4748281 (~4.5MiB) (~decompressed sz?)
"7B A2 18 00" =  0x0018A27B = file size minus 101 bytes (~compressed sz?)
"E0 A2 18 00" = 0x0018A2E0 = actual file size
also, the third is followed by
"01 01 00 00" = 0x00000101 = which maybe only by odd coincidence is the decimal equivalent of the difference between the two above (realizing the hex winds up as 257 decimal and as such it could simply be a frame size or similar).

If there is a key, I'd be looking hard at those first 101 bytes... I for one am also presuming the cyphered (aka: not sure if it's compressed, crypted or a combination of both) data contains more than just one firmware/data file.

One thing I would also do is try sniffing the update process via a USB sniffer, see what kind of data blocks are being sent and such (be a huge sniff though if you have to capture the "whole shebang"), perhaps (fingers crossed) there would be some known plaintext code to capture in there somewhere? It might at least give a more viable starting point.

Don't mind me though, I have no DSX so the interest is kind of pointless on my part - just tossing some thoughts into the mix if they haven't been thought of already.

edit:/ in case you missed it reveng: I have messed with stream compression using zlib and similar stubs before and this definitely looks like such a beast, mainly because of the 2 sizes presented in what appears to be a fairly long header. Not saying the compression will be standard, though it may also be possible to gain the decompressed data from the PC's memory using one of the PC game cheat tools or something similar. Oh, and keep an eye on the temp folders when running such software as well, I have come across some interesting mid work data that way before (they didn't think people will be looking at temp while their app is running)

 

[reveng]

By the way, where the DS-X forums are concerned please to be noting that "DS-X Guru" != "DSX Guru".  Come on, people.  Next you'll be entering your Myspace passwords into some site called Myspace.cx


But it was a very funny joke, whoever was responcible?
and whats wrong with Myspace.cx I gave them my bank acc # and Social Security #

No probs dib, my pc's are usually in bits all over the place, glad to have you putting some contributions in.

Cory had some interesting muses on the .bin file and they do correlate with what we know.

Like mentioned in both out posts the .bin has a header and the data embedded (three parts to it probibaly), and Cory's findings sorta point to that way.

I'll spend tomorrow looking at the PC updater, and I should start a WiKi thread with information on the .bin and .txt files thats been gleemed so far.

QUOTEIsn't the ProASIC3 used in the DS-X arm enabled?

Well it can have ARMcore emulation or anyother CPUemulation you can think of. FPGA need a slightly different mindset then thinking of standard CPU's. What happens is, yes you code them, but that code is translated into silicone circuitry, in effect you are making a hard coded cpu based on your program.. Its a bit of of mind fuck at first

when thinking about it

Oh and because its hard coded, your program/circuitry can have many parts all running in parallel. Not the instruction by instruction of standard cpu's. BTW I've never coded one of these devices, so I'm no guru, but dont they sound wicked

 

[cory1492]

The DSX PC updater has verbatim a copy of some of the zlib source, ive compared it partially on a disassembly. I belive the bit I was comparing was the source to ZLIB inflate.
There you go, fiddle with deflate and I'm sure 2 of those values from the header will be useful - deflated and inflated size, the third is likely to calculate the data offset. May well reveal a whole new header with individual file offsets.

The sniffers a good idea, though I dont have the hardware...but I think the dsx updater PC application will give the whole game away. I.E
its gotta send the usb firmware - hey presto you have the usb 8051 firmware and the comms protocol.
its gotta send the fpga config - hey presto you have the config (not sure how you decompile veriolg, VHL or whater its called)
Do you have USB ports, the device in question, and windows XP? (or linux, IIRC snoop runs under linux somewhere along the way as well though the DSX PC soft probably runs only under win)
http://www.pcausa.com/Utilities/UsbSnoop/default.htm
Installs a libusb based intercept driver on the specified installed USB device and creates a decent log (parsing usually required to make it more sensible.) usbSnoop was used while making the if2a project go (reversing the flashing software for the flash2advanced cards, those folks turned me onto that software - though it took me quite a while before I decided to actually learn the USB stuff.) In any event, having a good sniff of what is going on at the bus level is quite helpful when trying to implement libusb based/open source solutions that generally work well cross platform. It also generally saves from having to learn more than how to install the drivers for the original hardware when coding for your type of app, as you rely on your own command interface rather than whatever the manufacturer provides libs for.

1) the ez-usb controller firmware.

and on that note, I point you at the if2a project again as the f2a linkers were based on EZ-USB/cypress devices.
http://if2a.free.fr/
QUOTE

As you mentioned you could just step thru the PC app and grab the data.
But at the end of the day you want to be able to alter the firmware as I'm sure others would, so we will need to either, make our own updater or use the dsx updater but repack our own firmware.

I'm not talking about debugging the PC app at all. I'm talking about getting a memory dump of the PC app's footprint to grab the already sorted and deflated data from memory if it is not cached in a temp file - just like one would do when manipulating in memory data to extract cheat code information for older PC games which didn't use memory encryption.

 

[sylux92]

By the way, where the DS-X forums are concerned please to be noting that "DS-X Guru" != "DSX Guru".  Come on, people.  Next you'll be entering your Myspace passwords into some site called Myspace.cx


But it was a very funny joke, whoever was responcible?

You say that like someone here on gbatemp is responsible...

 

[reveng]

Installs a libusb based intercept driver on the specified installed USB device and creates a decent log (parsing usually required to make it more sensible.)

AH O.K there's me thinking of a hardware kit you attached to the +D -D lines.
Yup the device shows up under windows XP and the sniffer could be pointed at it.. Nice

I point you at the if2a project again as the f2a linkers were based on EZ-USB/cypress devices.
http://if2a.free.fr/

Cheers just had the briefest look thru the site, looks very interesting.
Spent this Xmas free time brushing up on USB tech in preparation used this tutorial.

QUOTE

I'm not talking about debugging the PC app at all. I'm talking about getting a memory dump of the PC app's footprint

AH yes, I get what you mean now dump all the process memory, I was talking about using a debugger to semi run it then dump whats its using, Yours is a far more elegant solution.

On LZIP does deflate unzip or inflate?
Edit: ignore the stupid question, just being lazy

 

[reveng]

You say that like someone here on gbatemp is responsible...

No idea?

Most people here are utterly satifisfied with the DSX! so if its a hoax surely it cant be from here

 

[reveng]