Sandisk Clip Sport

[wzdd]

Okay, I've decrypted the 1.22 firmware. It is here: http://wikisend.com/download/409764/upgrade-1.22.raw.gz

It is missing its BREC, which seems to be the first code to run which can be changed. I'll look into dumping that as well later. (The BREC seems do to flash initialisation, or at least contain flash initialisation parameters, which may mean that it is stored on the atj2127 instead of the flash?)

I did this by running the ucos firmware upgrade routine on a MIPS emulator. Next step will be to rewrite it in C to figure out how it works. I'll upload the code tomorrow (it's late here).

The missing key data is part of FWDec.al -- I had just converted it wrong the first time. It's 32 bytes starting at file offset 0x282c and beginning 0xa2, 0x6e, 0x14, 0x42. These seem to form an initial state for the decryption, which I don't recognise (the function starts at file offset 0x268c). The state is combined with the ciphertext using xor, but there is some (very small amount) of mixing involved so the blocks must be decrypted in order.

This is largely academic at this point because it is much easier to figure out the adfu protocol and send unencrypted data, but it's interesting to see what is going on -- and it will make reflashing the device as simple as copying a file across, which is quite nice.

[wzdd]

I also discovered that the Philips GoGear Muse firmware contains the same firmware upgrade module, but apparently compiled with debugging symbols enabled. Also, the file is in ELF format rather than ucos format, and appears to be compiled with a different (and much worse) compiler. I got this firmware by following pmaury's firmware finding formula on the wiki -- the filename is sa4mus08kf_12_hf1_eng.zip.

[wodz]

I bet compiler is the same i.e some flavor of gcc. The files for atj213x I've studied use different optimization level hovewer. With -O0 gcc produce terrible code while higher levels are rather well optimized (and considerably harder to follow in disassembly).

BTW. Which mips simulator did you use?

[wzdd]

Just qemu. You're probably right about the optimisation levels.

This is the code: https://github.com/nfd/atj2127decrypt

Next step will be to convert the mips32 asm to C, so it doesn't require a MIPS system to run!

[wodz]

On github you state that MBREC is not correctly decoded. It well may be that MBREC is additionally scrambled/crypted. Have you tried to sniff usb traffic during recovery with PC tool? It should be fairly easy to map usb payload to the unpacked files. On atj213x the first stage image needs to be scrambled (descrambling is handled by code in boot rom). AFAIK MBREC sits at the very beginning of NAND.

[wzdd]

Wodz, interesting about the mbrec. I'll have a look at what's going on. I can also definitely dump the usb transactions using VMWare, so I'll try to see how the adfu mode works (is there anything on this already?)

I updated the github code to remove the assembly language portion, so it now compiles on non-mips systems. But it's all (semi-)auto-decompiled and pretty horrible at the moment -- cleaning it up is the next step. Fortunately most of it is already implemented in rockbox's atj tools, so only the new stuff needs to be merged.

edit: sm - will do! Or at least try

[wzdd]

Just a couple of updates ... it turns out that you can run arbitrary code from ADFU mode, which should make hacking this thing somewhat easier. I've pushed a demo to https://github.com/nfd/atj2127decrypt in the dfu directory, but you'll need an ADFUS.BIN file (available from that PD196_ATJ2127 repo) to initialise the hardware. (This probably isn't absolutely required, but the demo is pretty hacked-up and follows the standard ADFU flow, which is: upload ADFUS.BIN (raw mips32r2) which provides a basic OS for the rest, then upload some code to discover hardware information (nandhwsc.bin, also raw mips32r2), which then returns a block of data to the flashing tool -- I've managed to get nandhwsc to return different data to demonstrate that it's actually being run).

You can also issue a vendor-specific SCSI command to go from UDISK (standard block device) mode to ADFU mode, so the demo includes an example to do that as well (you should be able to reboot to UDISK mode from ADFU mode also, but this isn't working yet).

I also fixed mbrec decoding -- I was re-using some of the pd196 code for decrypting firmware blobs and didn't notice that it wouldn't work if the size of the target file was under 32k -- the mbrec now looks like mips32r2 code, so if there is scrambling it happens elsewhere -- wodz if you have some time to look at a decrypted firmware I'd be interested in your thoughts on this)

[wodz]

I did a quick look at ADFUS.BIN file. It looks fairly similar to atj213x adfu handler. One thing I found unusuall is that  mem mapped registers are accessed through KSEG2 which means that something must have setup MMU earlier. PD196_ATJ2127 register description seems to be accurate. I'll dig up which commands are supported and will report back.

edit: I compared usb core registers with what I know about atj213x usb core and both are the same (or at least very close). Porting hwstub to this platform should be trivial. One would need to write some header file with atj2127 registers addresses and tweak startup code. Interrupt controller (with obvious difference in interrupt source mapping), timer module, WDT are the same as in 213x as well.

edit2: here we go. in [] there are byte numbers as read from usb fifo

Code: [Select]

adfu_cmd_handler()
  read 32bit, check for 'USBC' 0x43425355 flag   [0,1,2,3]
  read 12 bytes, store only last                 [4,5,6,7,8,9,10,11,12,13,14,15]
    check stored byte for CMD selector 0xB0, 0xCC or 0xCD
    B0 - force reset by entering infinte loop which catches watchdog reset
    CC - seems to be NOP

description of CD:
  read byte, treate it as subcmd               [16]
  strip top bit and compare with available subcmds 0x21, 0x13, 0x20, 0x10, 0x22, 0x23, 0x60
  bit7 serves as transfer direction indicator 1 - usb IN transfer, 0 - usb OUT transfer

0x20:
  read 7 bytes, discard                        [17,18,19,20,21,22,23]
  read 32bit, store in exec_address            [24,25,26,27]
  execute code from exec_address (jalr)
  after exec return to adfus main()

0x21:
  read 7 bytes, discard                        [17,18,19,20,21,22,23]
  read 32bit, store as jump address            [24, 25, 26, 27]
  jalr to received address, the returned value in v0 is stored in cmd22_src_addr
  replay with all zeros packet

0x22:
  read 3 bytes, discard                        [17,18,19]
  read 32bit, store as transfer len            [20,21,22,23]
  transfer (IN) memory content as pointed in cmd22_src_addr+4, len
  reply with all zeros packet

0x23:
  read 3 bytes, discard                        [17,18,19]
  read 32bit, store as transfer len            [20,21,22,23]
  transfer (IN) memory content as pointed in cmd22_src_addr, len
  reply with all zeros packet

0x13:
  read 3 bytes, discard                        [17,18,19]
  read 32bit, arg1 (address)                   [20,21,22,23]
  read 32bit, arg0 (len)                       [24,25,26,27]
  transfer 'len' bytes data in direction indicated in dir bit starting at 'address'
  reply with all zeros packet

This two do some more fancy stuff. Basically they do some transfers interleaved with calls to 0xbfc1e400 with 4 arguments
where last is buffer address and first some sort of subcommand. At first glance this look like some crypt/scramble stuff with
some repetitive blocks of 0x20, 0x200 and 0x4000 bytes
0x10:
0x60:

0xcd 0x13 is interesting as it looks like one can read arbitrary memory. It would be interesting to check if dumping memory starting  at 0xbfc00000 is possible (ROM)

Cheers

[wzdd]

Cool, glad it's similar! I was actually impressed by it -- HW companies aren't known for their software...

I've uploaded the Wireshark-readable packet captures from a DFU session here: http://nyloncactus.com/random/atj2127dfu.tar.gz

For command 0x23, it seems like it actually causes the device to dump memory to the host? What seems to happen is (examining the pcap):

- host writes a binary with command 0x13

- host executes the binary on the device with command 0x21

- host reads a block of memory from the device (length specified in packet)

- device replies with a block of data

This data is from a memory area which is written by the host-uploaded binary. It seems that the flash tool runs something which queries the NAND controller for the NAND ID and some other information, and writes a packet of length 0x9c beginning 'HW' which contains that ID and some other stuff. The host then decides what flash driver to upload based on what comes back. This seems quite nice to me.

[wodz]

Thanks for pcap dumps. This seem to match my understanding of ADFUS.BIN disassm.
BTW. The sequence you described in your previous post is not accurate.

The interesting thing to explore is issuing cd93 cmd (cd 0x80|0x13 address len) to get ROM dumpstarting at 0bfc00000
I extracted payload from pcap file to trace this magic 0xbfc1e400 function. I'll report when find something.

edit: I did quick look at this 0xbfc1e400 function and it is rather complicated. What can be said for sure it is some nontrivial wrapper around ROM? functions starting at ~0xbfc20000. All this functions seems to use MIPS16 coding as calls are made through jalx instruction. atj2127 brief mentions about subset of libc provided in ROM. Referenced functions are:
0xbfc205b8, 0xbfc21470, 0xbfc21960, 0xbfc21b88, 0xbfc20740, 0xbfc21920, 0xbfc21308, 0xbfc204c4 and one data ref: 0xbfc24cd0 (with offsets 12, 14, 24)

Maybe you could pop up on IRC so we could have live discussion?

[InGearX]

question 1. hmmm how could one help with this?

old version of Sansa Zip are discontinued by manufacturer :/

so this is the future..

question 2: would getting hold of some developer in Sandisk help? what could he/she provide?

question 3: as a quick has is it possible to say keep default OS - but disable it indexing / building database on each change? (if it is a big 64GB or 128GB card it takes a while)

thank you ...

[wodz]

According to my knowledge all this discussions are pure academic as is seems hardware is not capable to run rockbox. I'd love to be proven wrong though.