The Firmware Page

Hi,

I'm starting this thread to see if there would be interest is volunteering samples of the standard firmware revisions found on Matshita UJ-8xx drives in Macs.

There are several reasons why having a copy of the firmware available might be useful. For example as a base for region free patches or other patches such as autoreset, bitsetting, or to restore an earlier standard revision.

I've written a very basic utility that I hope can extract a relevant region of the drive's address space. It's not user friendly, needs you to use the terminal and have development tools such as 'gcc' and 'make' installed. Familiarity with some basic unix shell commands is also useful. If you don't know what these things are I don't think it is worth finding out just to try this out.

My idea is that a couple of people with each firmware revision take a sample from their drive - the file will be about 4MB. Upload it to a file hosting site and either post the link here or PM it to me, adding a public comment here to say you've sent it and quoting the firmware revision. Once a couple of people have sent a given revision there's no need for more.

One reason why you might not want to publicly post the link (or do this at all) is that the image taken from the drive is not exactly a firmware image. The 'firmware' would be the same for everybody with a given revision. However the image that the utility would extract is hopefully the firmware plus some other things. That might include information such as your drive's serial number and the history of region changes that have been made to the drive. Although that information does not interest me I ask that the contents of the dump not be changed - to allow for checking of internal checksums.

Assuming that there are some responses I'd make the resulting firmware public (only the firmware parts, no personal information of course). Somebody, myself or somebody else, may then be able a utility available to flash the firmware or make changes for things like region free. However there is no guarantee that me or anybody else will do that - this is just an attempt to get the original firmware available.

Along with the utility to dump the firmware I've also included an example program to (de)obfuscate the firmware as it is supplied to the drive during a flash.

I have been meaning to make more information about the Matshitas available since I made some RPC1 firmwares - but I haven't really been able to make time for that. The example should give the minimal information needed, although it isn't a wonderful example program. However I think somebody experienced in patching drive firmwares and wanting to start to work with these drives would find it helpful. I may be able to add some more description to this thread later.

The archive link:

http://rapidshare.com/files/52925201/ma ... y.zip.html

Example of how the firmware dump should work:

ben11s-computer:~ ben11$ cd Desktop
ben11s-computer:~/Desktop ben11$ unzip matshita_memory.zip
ben11s-computer:~/Desktop ben11$ cd matshita_memory
ben11s-computer:~/Desktop/matshita_memory ben11$ make
gcc -g -Wall -W -o dump mscsi.c dump.c \
-framework IOKit -framework CoreFoundation
ben11s-computer:~/Desktop/matshita_memory ben11$ ./dump
compiled at Sep 1 2007 12:00:00
Appear to have a matshita at device index 0: MATSHITADVD-R UJ-857 HAEA
Reading a portion of the memory of the drive, assuming 32 bit address space
Finished reading drive memory
read memory from device 0, saved in matshita-dump-0.dat

In this case the dump file is 'matshita-dump-0.dat'. You could compress that if you like, before uploading.

An example of the obfuscation scheme used to send the firmware for flash can be
found by looking at the source file 'example_obfuscate.c' in the archive above. It is not part of the dump utility.

The following firmware are already available: DAM5, GAND, GEND, GFND, GGND,
HAEA, HBEA, KBVB, KCVB so there is no need to try to extract those.

The dump utility may or may not work for your drive - if you find it does not then thank you for trying it.

I do not think there is any particular danger in using the dump utility. Any conceivable problem should be fixed by restarting the machine - there is no flash involved. But use is at your own risk.

Thanks!

Simply "congrats"!

EDIT: might be useful for further analysis of the dumps:
http://rapidshare.com/files/52997709/mn103.zip.html

Sent you a dump of this drive
Model: MATSHITADVD-R UJ-857E
Revision: ZA0E

Hi,

Thanks Hiroyuki, and also the person who sent me the DBN7. That's much appreciated!

In fact I have several PMs - I haven't been checking them regularly; it might make me seem a little slow in getting back to you. Sorry about that.

Sent you a dump of the ZB0E revision of the UJ-857E. Same model as Hiroyuki, slightly different firmware.

Sent you the dump of the MATSHITADVD-R UJ-846 (Revision : FB2U)

thks!

Hi,

I've got a MATSHITA DVD-R UJ-85J with a FCQA firmware on a Intel iMac 24"
I can't make the dump

Did I done something wrong ? Is it working only on PPC ?

Hi. I'm looking for the UJ-85J FCQA or forward firmware...
Does someone can send it to ben11 please ?

Also, does somebody tried to upgrade the drive (not this's one articulary) with a most recent firmware revision? it's working ?

Thanks in advance

Hmm... try removing the / and put everything on one line.... (shouldn't make any difference, but did it for me...) what version of gcc/xcode you have?
Worked fine on my intel mbp 2.2GHz

Just type "make" in the command line. It's enough to compile the code.

Thanks for your help Hiroyuki and El Bacho
Unfortunately it's still not working...


I'm using Xcode.app 2.4 and i686-apple-darwin8-gcc-4.0.1

can you give me the output of gcc -v

I'm downloading the latest Xcode (2.5 Developer Preview 8M2540a)
and I'll try again...

ehh... no "make" in front of gcc that should do the trick

Ok with no "make" I obtain a 44 Ko dump file and no further indications in the terminal


Here is the dump file, zipped : http://www.sendspace.com/file/7rgr3x

Thanks again Hiroyuki

That seems correct... then you run just type ./dump and it will give you an appx 4MB file which you can upload to ben11

MATSHITADVD-R UJ-85J FCQA : http://www.sendspace.com/file/2xx9nb

MATSHITA DVD-R UJ-846, Revision FM3J :
http://www.sendspace.com/file/zt6l25 (bzip2 file, use bunzip2 to uncompress)

It would be nice, if you get time, to post some more info on the obfuscation of the firmwares - my C-skills aren't so strong so just looking at the (mostly) uncommented code doesn't provide much for me.

Mod, can you guys make this a sticky thread? I think it is quite important to the future of this sub-forum

A) to compile the program, simply type "make" into the terminal. "make" will read the "makefile", and hence execute "gcc" to produce the "dump" utility.

B) to execute the "dump" utility, it is necessary you type "./dump" into the terminal. otherwise, the OSX-built in "dump" utility will be executed (located in /sbin/dump).

C) if you cannot read the source code about the obfuscation - hell, what do you want more ??? it wont read nicer if he rewrote it in visualbasic.

A: didn't work for the guy i helped, so I just used the contents of the makefile

C: I just wanted it a little more commented, no need to get all worked up about this... and it was a request not a requirement (I know some C, but i don't know basic... so that wouldn't help at all.. your technical docs were kinda interesting reading though hendrix)


end note... Not all people are as competent as you are hendrix, so please don't bash us for not having the knowledge you posess... I personally am here to learn - hopefully i can provide something to the community too.

A) he typed: "make gcc -g -Wall -W -o dump mscsi.c dump.c \
> -framework IOKit -framework CoreFoundation"

while is was supposed to type just "make"

C) there is no "technique", it is just shuffling bits around and xor'ing them. HOW TO GUESS this encryption - that is a miracle. So far only two people on earth were able to do this.

I know that, but he did try just make too..

Anyways, he got it working, so no need to argue over that ^^

And for the XOR and shuffeling bits part... XORing usually leaves quite visible traces; so quite often there is no need to guess - I would recommend Bruce Schneiers books on this topic; bitshifting though, might be a bit more tricky (haven't read up too much on that).

No matter how easy or difficult this may be, I think ben has done us all a great favor!

it is all about guessing how the random number generator works AND how the feedback is implemented. i'm not sure whether mr schneier will help with that (does he tell how to attack an unknown cipher?)
additionally, this is not a known/chosen-plaintext attack, but some kind of unknown-but-similar-plaintext attack (with varying keys).

the encryption itself is (always in stream ciphers) done via XOR. however, using a good RNG will leave you with no "visible traces".

I fear you are left with no real "tools" to break this, but your (own) brain.