Executing code on the 8163B / 8164B / 3120L

[MacDennis]

Hi all,

I'm currently experimenting with running custom code on any of these drives. Running custom code could in theory be used to 'unlock' a disc without performing a hotswap trick or modifying the firmware.

I have analysed the routines used by the 8163B software flasher to upload the mn103 flasher code to the drive where it executes it. This was done by analysing the ATAPI traffic between PC and drive. The command to execute code is the same as the one used in this thread: http://www.xboxhacker.net/index.php?option=com_smf&Itemid=33&topic=386.msg3800#msg3800

It is actually possible to execute code on the 8050L / 8163B / 8164B drive. BUT, only when a disc has not been inserted. If a disc has been inserted the drive seems to hang completely and disappears from the system. So my question is, has anyone been able to execute code on any of the mentioned drives when a disc was present?

Look in the original thread for details on how to execute code: http://www.xboxhacker.net/index.php?option=com_smf&Itemid=33&topic=386.msg3800#msg3800

Yes, it's possible to upload code in bulk but you will have to specifiy the total length and a correct checksum also has to be present. More on this later.

[SeventhSon]

Yes, it's possible to upload code in bulk but you will have to specifiy the total length and a correct checksum also has to be present. More on this later.

FTR: In my experience, the code must also be padded to a 4-byte boundary.

(Edit: on the 3020L at least).

[SpenZerX]

Hi,

I think its not possible to execute code when a disc is in the drive because every ram-byte is used/cache.

The bulk upload with checksum is still not working on my 3020L, and i dont know why.

I tried to flash my 3020L with a modified firmware, but it didnt work. Has somebody successfully flashed the 3020L with a modified firmware yet(without removing the tsop)?


 
SpenZer

[SeventhSon]

The bulk upload with checksum is still not working on my 3020L, and i dont know why.

Are you still trying with the 0xE7 HIT command? Various mode select commands can achieve a lot of the same things as the 0xE7 commands. I disassembled An LG flasher .exe recently and it uses mode select commands to upload and execute code, no troublesome 0xE7 commands required. One mode select sets the total upload size and sets some bits required by subsequent commands, a following series of mode select commands upload the code (including checksum) 0x7F8 bytes at a time and performs the final checksum, finally another mode select command executes the uploaded code. If you replicate those mode select commands (changing the checksum and total length), then it works nicely. Wait until MacDennis posts more, you'll see what I mean. Much better than the byte at a time method

(edit: This process requires modeB on the 3020L)

I tried to flash my 3020L with a modified firmware, but it didnt work. Has somebody successfully flashed the 3020L with a modified firmware yet(without removing the tsop)?

Yes. And I nailed my drive, big time. I hacked together a flasher that will flash a single sector by uploading the new sector, the 3020L flash erase/program routines and some hand assembled control code to RAM and then executing the control code, which then uses the erase/program routines to write the new sector to flash. I wanted to use this to make small modifications to help me develop a full software flasher. It worked, in the sense that the flash was written to, but it killed my drive. I can't even get a recovery mode on it

I now think I know why. If you look at the flash erase code in the 3020L (starts at 0x2F8B7 in the 0047 firmware), then for some unfathomable reason it erases two sectors for the price of one!

Code:

ROM:0002FC44                 mov     0xAA, D0 ! '¬'  ! sector erase sequence (for Manufacturer ID 0xBF)
ROM:0002FC47                 movbu   D0, (A0)
ROM:0002FC49                 mov     0x55, D0 ! 'U'
ROM:0002FC4B                 movbu   D0, (A1)
ROM:0002FC4D                 mov     0x80, D0 ! 'Ç'
ROM:0002FC50                 movbu   D0, (A0)
ROM:0002FC52                 mov     0xAA, D0 ! '¬'
ROM:0002FC55                 movbu   D0, (A0)
ROM:0002FC57                 mov     0x55, D0 ! 'U'
ROM:0002FC59                 movbu   D0, (A1)
ROM:0002FC5B                 mov     (word_934), A2
ROM:0002FC5F                 mov     0x30, D0 ! '0'
ROM:0002FC61                 movbu   D0, (A2)
ROM:0002FC63                 add     0xFC, SP ! '³'
ROM:0002FC66                 calls   sub_2FCC7       ! wait for sector erase to complete
ROM:0002FC6C                 add     4, SP
ROM:0002FC6F                 mov     0xAA, D0 ! '¬'  ! another sector erase sequence
ROM:0002FC72                 movbu   D0, (A0)
ROM:0002FC74                 mov     0x55, D0 ! 'U'
ROM:0002FC76                 movbu   D0, (A1)
ROM:0002FC78                 mov     0x80, D0 ! 'Ç'
ROM:0002FC7B                 movbu   D0, (A0)
ROM:0002FC7D                 mov     0xAA, D0 ! '¬'
ROM:0002FC80                 movbu   D0, (A0)
ROM:0002FC82                 mov     0x55, D0 ! 'U'
ROM:0002FC84                 movbu   D0, (A1)
ROM:0002FC86                 mov     (word_934), A2
ROM:0002FC8A                 add     0x1000, A2      ! erase sector input sector + 0x1000
ROM:0002FC8E                 mov     0x30, D0 ! '0'
ROM:0002FC90                 movbu   D0, (A2)
ROM:0002FC92                 add     0xFC, SP ! '³'
ROM:0002FC95                 calls   sub_2FCC7       ! wait for erase to complete
ROM:0002FC9B                 add     4, SP
ROM:0002FC9E                 bra     locret_2FCA0

Guess which sector I chose to test on? 0x9003F000. Unfortunately 0x9003F000 + 0x1000 = 0x90040000 (the start of flash!) I think I erased my flash entry point. Bah. Be warned. Still, all part of the fun

-Kev

[SeventhSon]

My drive has returned from the other side. Ready to be used and abused once more.

But before I set about ruining my firmware again, I tested out an idea that I had today on the issue of executing code with a disc in the drive. I doubted that the official LG flasher .exe would crash upon executing code with a disc in the drive, so I did some digging. Here's an ATAPI transfer 'log' that I derived from reverse engineering the LG flasher .exe. (note: this isn't an actual log, so there may be mistakes in it).

Code:

12 00 00 00 3A 00 00 00 00 00 00 00

E7 48 49 54 30 90 90 E0 00 00 00 00

1B 00 00 00 00 00 00 00 00 00 00 00

5A 00 0E 00 00 00 00 00 18 00 00 00
    00 16 70 00 00 00 00 00
    02 29 DF DE 80 04 F8 E0
    01 F8 92 04 00 F8 92 05

00 00 00 00 00 00 00 00 00 00 00 00

55 10 00 00 00 00 00 00 10 00 00 01
    00 00 00 00 00 00 00 00
    00 06 48 4C 00 00 1B E8

55 10 00 00 00 00 00 08 00 00 00 01
    00 00 00 00 48 4C 00 00
    a chunk of the flasher

55 10 00 00 00 00 00 08 00 00 00 01
    00 00 00 00 48 4C 00 00
    a chunk of the flasher

55 10 00 00 00 00 00 08 00 00 00 01
    00 00 00 00 48 4C 00 00
    a chunk of the flasher

55 10 00 00 00 00 00 04 08 00 00 01
    00 00 00 00 48 4C 00 00
    final chunk of the flasher

55 10 00 48 4C 00 01 00 00 00 00 01

3B 04 7F 48 4C 07 01 08 00 00 00 01
    a chunk of firmware

5A 10 00 48 4C 08 00 00 12 00 00 01
    ?? ?? ?? ?? ?? ?? ?? ??
    ?? ?? ?? ?? ?? ?? ?? ??
    ?? ??

... *snip* the above two commands sent 0x80 times in total

3B 04 00 48 4C 07 01 08 00 00 00 00
    a chunk of the firmware

5A 10 00 48 4C 08 00 00 12 00 00 00
    ?? ?? ?? ?? ?? ?? ?? ??
    ?? ?? ?? ?? ?? ?? ?? ??
    ?? ??

... *snip* above two commands sent 0x80 times in total

5A 10 00 48 4Ch 09 00 00 00 00 00 00

... *snip* the above command is possibly send more than once (not sure)

12 00 00 00 3A 00 00 00 00 00 00 00

That 3rd command is a START/STOP unit with power condition, LoEj and Start all set to zero. Which will stop the disc. I coded a simple util to send this command to the drive.

Code:

$ ./execcode /dev/hdc testpoke.bin
(drive dies, I reset it)
$ ./stopdisc /dev/hdc
done

$ ./execcode /devhdc testpoke.bin
done

So that's how to execute code on the 3020L with a disc in the drive. I imagine it would work on all the others. This might not be all that useful to you MacDennis, I'm not sure what you are trying to set to unlock the disc. If it's something originally from the TOC, then this may get re-read once the disc spins up again If it's an unlocked flag within the 3020L, then you might have some luck with this.

(edit: Like everything else useful in the 3020L, stopping the disc fails in modeA, vendor specific check condition)

Code:

root@localhost:/home/test/apps/my_apps/x360dvd# ./stopdisc /dev/hdc
ioctl: Input/output error
failed to stop disc (sense: 05/81/00)

[MacDennis]

So that's how to execute code on the 3020L with a disc in the drive. I imagine it would work on all the others. This might not be all that useful to you MacDennis, I'm not sure what you are trying to set to unlock the disc. If it's something originally from the TOC, then this may get re-read once the disc spins up again If it's an unlocked flag within the 3020L, then you might have some luck with this.

Good info! Well, there's only one way to find out ..  I'll certainly try it soon. When talking about unlocking I mean a way to be able to access/unlock the game partition. Should be possible be either setting a few flags in low RAM or changing the physical format data. This won't work ofcourse if a spin up of the disc overwrites this data again ..

I recently also analysed the 8163B software flasher but from a different angle, I logged all ATA / ATAPI communication. Here's the log of a 8163B drive being flashed in Windows ..

Code:

step 1:
4A 01 00 00 5A 00 00 08 00 00 00
- data: 00 06 01 5E 00 00 00 00
4A 01 00 00 58 00 00 08 00 00 00
- data: 00 06 03 5E 00 00 00 00
4A 01 00 00 50 00 00 08 00 00 00
- data: 00 06 04 5E 00 00 00 00
4A 01 00 00 40 00 00 08 00 00 00
- data: 00 06 06 5E 00 00 00 00

step 2:
4A 01 00 00 5A 00 00 08 00 00 00
- data: 00 06 01 5E 00 00 00 00
4A 01 00 00 58 00 00 08 00 00 00
- data: 00 06 03 5E 00 00 00 00
4A 01 00 00 50 00 00 08 00 00 00
- data: 00 06 04 5E 00 00 00 00
4A 01 00 00 40 00 00 08 00 00 00
- data: 00 06 06 5E 00 00 00 00

step 3:
E7 08 49 54 30 90 90 E0 00 00 00 00
- data write: 1B 00 00 00 00 00 00 00 00 00

step 4:
03 00 00 00 14 00 00 00 00 00 00 00
- data read: 70 00 02 00 00 00 00 0A 00 00 00 00 edit  00 00 00

step 5:
4A 01 00 00 5A 00 00 08 00 00 00
- data: 00 06 01 5E 00 00 00 00
4A 01 00 00 58 00 00 08 00 00 00
- data: 00 06 03 5E 00 00 00 00
4A 01 00 00 50 00 00 08 00 00 00
- data: 00 06 04 5E 00 00 00 00
4A 01 00 00 40 00 00 08 00 00 00
- data: 00 06 06 5E 00 00 00 00

step 6:
4A 01 00 00 5A 00 00 08 00 00 00
- data: 00 06 01 5E 00 00 00 00
4A 01 00 00 58 00 00 08 00 00 00
- data: 00 06 03 5E 00 00 00 00
4A 01 00 00 50 00 00 08 00 00 00
- data: 00 06 04 5E 00 00 00 00
4A 01 00 00 40 00 00 08 00 00 00
- data: 00 06 06 5E 00 00 00 00

step 7:
5A 00 0E 00 00 00 00 00 18 00 00 00
00 16 70 00 00 00 00 00 0E 0E 04 00 00 00 00 4B 01 FF 02 FF 00 00 00 00

step 8:
00 00 00 00 00 00 00 00 00 00 00 00

step 9:
03 00 00 00 14 00 00 00 00 00 00 00
- data: 70 00 02 00 00 00 00 0A 00 00 00 00 3A 00 00 00

step 10:
4A 01 00 00 5A 00 00 08 00 00 00
- data: 00 06 01 5E 00 00 00 00
4A 01 00 00 58 00 00 08 00 00 00
- data: 00 06 03 5E 00 00 00 00
4A 01 00 00 50 00 00 08 00 00 00
- data: 00 06 04 5E 00 00 00 00
4A 01 00 00 40 00 00 08 00 00 00
- data: 00 06 06 5E 00 00 00 00

step 11:
55 10 00 00 00 00 00 00 10 00 00 01
- data write: 00 00 00 00 00 00 00 00 00 06 48 4C 00 00 1B E8

step 12:
55 10 00 00 00 00 00 08 00 00 00 01
- data: 00 00 00 00 48 4C 00 00 flasher code (0xE0 bytes)

step 13:
55 10 00 00 00 00 00 08 00 00 00 01
- data: 00 00 00 00 48 4C 00 00 flasher code (0xF10 bytes)

step 14:
55 10 00 00 00 00 00 08 00 00 00 01
- data: 00 00 00 00 48 4C 00 00 flasher code (0x800 bytes)

step 15:
55 10 00 00 00 00 00 08 00 00 00 01
- data: 00 00 00 00 48 4C 00 00 flasher code (0x408 bytes)

excute flasher:
55 10 00 48 4C 00 01 00 00 00 00 01

poll:
4A 01 00 00 5A 00 00 08 00 00 00
- data: 00 06 01 5E 00 00 00 00

test firmware upload:
3B 04 7F 4C 07 01 08 00 00 00 01
- data: firmware upload (0x100 bytes * 4 + 100)
5A 10 00 48 4C 08 00 00 12 00 00 01
- data: 00 10 00 7F 00 00 00 00 00 00 00 00 00 00 00 00
3B 04 7E 4C 07 01 08 00 00 00 01
- data: firmware upload (0x100 bytes * 4 + 100)
5A 10 00 48 4C 08 00 00 12 00 00 01
- data: 00 10 00 7E 00 00 00 00 00 00 00 00 00 00 00 00
3B 04 7D 4C 07 01 08 00 00 00 01
- data: firmware upload (0x100 bytes * 4 + 100)
5A 10 00 48 4C 08 00 00 12 00 00 01
- data: 00 10 00 7D 00 00 00 00 00 00 00 00 00 00 00 00
...
...
3B 04 01 48 4C 00 08 00 00 00 01
- data: firmware upload (0x100 bytes * 4 + 100)
5A 10 00 48 4C 08 00 00 12 00 00 01
- data: 00 10 00 01 00 00 00 00 00 00 00 00 00 00 00 00
3B 04 00 48 4C 00 08 00 00 00 01
- data: firmware upload (0x100 bytes * 4 + 100)
5A 10 00 48 4C 08 00 00 12 00 00 01
- data: 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00

poll:
4A 01 00 00 5A 00 00 00 08 00
- data: 00 06 01 5E 00 00
4A 01 00 00 5A 00 00 00 08 00
- data: 00 06 01 5E 00 00
4A 01 00 00 5A 00 00 00 08 00
- data: 00 06 01 5E 00 00

real upload:
3B 04 7F 48 4C 07 00 08 00 00 00 01
- data: firmware upload (0x100 bytes * 4 + 100)
4A 01 00 00 5A 00 00 08 00 00 00
- data: 00 06 01 5E 00 00
5A 10 00 48 4C 08 00 00 12 00 00 01
- data: 00 10 00 7F 00 00 00 00 00 00 00 00 00 00 00 00
3B 04 7E 4C 07 01 08 00 00 00 01
- data: firmware upload (0x100 bytes * 4 + 100)

note: data is uploaded in a 13x loop (only first time)

3B 04 72 48 4C 07 00 08 00 00 00 01
- data: firmware upload (0x100 bytes * 4 + 100)

...
4A 01 00 00 5A 00 00 08 00 00 00
- data: 00 06 01 5E 00 00
5A 10 00 48 4C 08 00 00 12 00 00 01
- data: 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00

The '4A' commands aren't really interesting, just some internal polling mechanism.
I was able to upload the bulk mn103 flasher code (which is present in the dld footer) to the 8163B drive using the following plscsi commands ..

Code:

rem step 1
plscsi -p -v -x "4A 01 00 00 5A 00 00 08 00 00 00" -i x8
plscsi -p -v -x "4A 01 00 00 58 00 00 08 00 00 00" -i x8
plscsi -p -v -x "4A 01 00 00 50 00 00 08 00 00 00" -i x8
plscsi -p -v -x "4A 01 00 00 40 00 00 08 00 00 00" -i x8

rem step 2
plscsi -p -v -x "4A 01 00 00 5A 00 00 08 00 00 00" -i x8
plscsi -p -v -x "4A 01 00 00 58 00 00 08 00 00 00" -i x8
plscsi -p -v -x "4A 01 00 00 50 00 00 08 00 00 00" -i x8
plscsi -p -v -x "4A 01 00 00 40 00 00 08 00 00 00" -i x8

rem step 3
plscsi -p -v -x "E7 08 49 54 30 90 90 E0 00 00 00 00" -o x0a -f step3.bin

rem step 4
plscsi -p -v -x "03 00 00 00 14 00 00 00 00 00 00 00" -i x14

rem step 5
plscsi -p -v -x "4A 01 00 00 5A 00 00 08 00 00 00" -i x8
plscsi -p -v -x "4A 01 00 00 58 00 00 08 00 00 00" -i x8
plscsi -p -v -x "4A 01 00 00 50 00 00 08 00 00 00" -i x8
plscsi -p -v -x "4A 01 00 00 40 00 00 08 00 00 00" -i x8

rem step 6
plscsi -p -v -x "4A 01 00 00 5A 00 00 08 00 00 00" -i x8
plscsi -p -v -x "4A 01 00 00 58 00 00 08 00 00 00" -i x8
plscsi -p -v -x "4A 01 00 00 50 00 00 08 00 00 00" -i x8
plscsi -p -v -x "4A 01 00 00 40 00 00 08 00 00 00" -i x8

rem step 7
plscsi -p -v -x "5A 00 0E 00 00 00 00 00 18 00 00 00" -i x18

rem step 8
plscsi -p -v -x "00 00 00 00 00 00 00 00 00 00 00 00"

rem step 9
plscsi -p -v -x "03 00 00 00 14 00 00 00 00 00 00 00" -i x14

rem step 10
plscsi -p -v -x "4A 01 00 00 5A 00 00 08 00 00 00" -i x8
plscsi -p -v -x "4A 01 00 00 58 00 00 08 00 00 00" -i x8
plscsi -p -v -x "4A 01 00 00 50 00 00 08 00 00 00" -i x8
plscsi -p -v -x "4A 01 00 00 40 00 00 08 00 00 00" -i x8

rem step 11
plscsi -p -v -x "55 10 00 00 00 00 00 00 10 00 00 01" -o 0x10 -f step11.bin

rem step 12
plscsi -p -v -x "55 10 00 00 00 00 00 08 00 00 00 01" -o 0x800 -f flash1.bin

rem step 13
plscsi -p -v -x "55 10 00 00 00 00 00 08 00 00 00 01" -o 0x800 -f flash2.bin

rem step 14
plscsi -p -v -x "55 10 00 00 00 00 00 08 00 00 00 01" -o 0x800 -f flash3.bin

rem step 15
plscsi -p -v -x "55 10 00 00 00 00 00 08 00 00 00 01" -o 0x408 -f flash4.bin

The length of the actual mn103 flasher code which is uploaded (not the firmware) is specified in step 11.
Contents of step11.bin : 00 00 00 00 00 00 00 00 00 06 48 4C 00 00 1B E8
Notice 1B E8, this is the length of the flasher, which is equal to 3 * 0x7F8 + 0x400

Each flashing binary contains the following header: 00 00 00 00 48 4C 00 00
It is then followed by 0x7F8 bytes of actual flasher data.

Using these commands you should be able to bulk upload any mn103 code and execute it ..

*edit*
The bulk code upload should be a multiply of 4 bytes. So, only upload code which is 4, 8, 12, 16 etc bytes in length. SeventhSon mentioned that previously.

At the end of the flasher code you will find a simple checksum. I'm not sure yet who checks this checksum, the original software flasher or the code in the firmware which handles the upload ..

[SeventhSon]

So that's how to execute code on the 3020L with a disc in the drive. I imagine it would work on all the others. This might not be all that useful to you MacDennis, I'm not sure what you are trying to set to unlock the disc. If it's something originally from the TOC, then this may get re-read once the disc spins up again If it's an unlocked flag within the 3020L, then you might have some luck with this.

Good info! Well, there's only one way to find out ..  I'll certainly try it soon.

Good luck,

Using these commands you should be able to bulk upload any mn103 code and execute it ..

For users of my execcode app (if any ), I'm currently rewriting it to use the upload process that MacDennis just described. It will be *a lot* faster this way. I know some hackers were using it to create a flasher and it was taking several minutes to upload the code a byte at a time

[MacDennis]

A small update regarding the bulk-upload of mn103 code. Some corrections and some additions ..

The following method has been tested on the 8163B / 8050L / 8164B / 3120L drive successfully.

Code:

rem step 1
plscsi -p -v -x "E7 08 49 54 30 90 90 E0 00 00 00 00"

rem step 2
plscsi -p -v -x "1B 00 00 00 00 00 00 00 00 00"

rem step 3
plscsi -p -v -x "03 00 00 00 14 00 00 00 00 00 00 00" -i x14

rem step 4
plscsi -p -v -x "5A 00 0E 00 00 00 00 00 18 00 00 00" -i x18

rem step 5
plscsi -p -v -x "00 00 00 00 00 00 00 00 00 00 00 00"

rem step 6
plscsi -p -v -x "03 00 00 00 14 00 00 00 00 00 00 00" -i x14

rem step 7
plscsi -p -v -x "55 10 00 00 00 00 00 00 10 00 00 01" -o 0x10 -f upload_prepare.bin

rem step 8
plscsi -p -v -x "55 10 00 00 00 00 00 08 00 00 00 01" -o 0x800 -f upload_flash1.bin

rem step 9
plscsi -p -v -x "55 10 00 00 00 00 00 08 00 00 00 01" -o 0x800 -f upload_flash2.bin

rem step 10
plscsi -p -v -x "55 10 00 00 00 00 00 08 00 00 00 01" -o 0x800 -f upload_flash3.bin

rem step 11
plscsi -p -v -x "55 10 00 00 00 00 00 04 08 00 00 01" -o 0x408 -f upload_flash4.bin

rem step 12, execute code, not fully tested yet ..
rem plscsi -p -v -x "55 10 00 48 4C 00 01 00 00 00 00 01"

Contents of upload_prepare.bin: 00000000000000000006484C00001BE8
The last 4 bytes is the total length of the data to upload including the checksum.
Notice 1B E8, this is the length of the flasher, which is equal to 3 * 0x7F8 + 0x400

Each flashing binary contains the following header: 00 00 00 00 48 4C 00 00
It is then followed by 0x7F8 bytes of actual flasher data. The total length of the data being uploaded by a mode select (0x55) command need to be specified in the CDB, LL specifies the length: plscsi -p -v -x "55 10 00 00 00 00 00 LL LL 00 00 01" -o 0x408 -f upload_flash4.bin

The bulk code upload should be a multiply of 4 bytes. So, only upload code which is 4, 8, 12, 16 etc bytes in length.

At the end of the flasher code you will find a simple checksum. This checksum is checked by the last CDB command responsible for the upload of code. It will throw an error if the checksum is incorrect. The checksum should be placed in the last 2 bytes of the data to upload.

A piece of c# code which I use to calculate the checksum:

Code:

            for (int index = 0x00; index lessthan 0x1BE6; index++)
            {
                checksum += footerBuffer[index];
            }

            checksum = 0x10000 - (checksum & 0xFFFF);

            checksum3 = (checksum >> 8) | ((checksum  lessthan lessthan 8) & 0xFF00);
            checksum3String = String.Format("{0:X4}", checksum3);

            footerBuffer[0x1BE6] = (byte)(checksum & 0xFF);
            footerBuffer[0x1BE7] = (byte)(checksum >> 8);

Replace 'lessthan' which the corresponding operator.

As mentioned, this method works fine on various drives to upload code in bulk. It would be nice if someone could write a small program which could upload any piece of bulk code automatically, correcting the checksum and stuff like that.

[SeventhSon]

It would be nice if someone could write a small program which could upload any piece of bulk code automatically, correcting the checksum and stuff like that.

I have written one. It works perfectly in Windows, but for some unknown reason it's crashing Linux (not the drive) when uploading more than about 0x400 bytes As soon as I figure out why, I'll upload it.

[anita999]

the bilk code upload shall be no problem with all HL-DT DVD drives. the problem is that the  total transmition size is very small, not enough to transmit the flash code together with the flash data. So in regular HL-DT flashers, there is a smaller header to be loaded into the ram, then after executing the header code, the header will use DMA to receive the FW data. in 3120L, the DMA accessing code is not fully identified, so we need to upload the code include the FW data byte by byte.

[SeventhSon]

so we need to upload the code include the FW data byte by byte.

At least now we can upload the code and FW data  ~2KB by ~2KB Plus we now have a built in checksum on the data. So it's ever so slightly safer. But still risky.

[MacDennis]

so we need to upload the code include the FW data byte by byte.

At least now we can upload the code and FW data  ~2KB by ~2KB Plus we now have a built in checksum on the data. So it's ever so slightly safer.

Anyone know how much data we can transfer using the bulk upload method? It's not safe to upload the FW in several pieces and then executing it. Why? The running firmware code and/or the command responsible for upload and execute might need/modify the higher RAM region. Then your FW will get corrupted..

Only safe way is to flash one sector at a time. This code should also auto-correct the FW checksum in the flash. So it basically flashes 2 sectors. Another option is to flash the correct checksum after all sectors have been flashed.

[SeventhSon]

so we need to upload the code include the FW data byte by byte.

At least now we can upload the code and FW data  ~2KB by ~2KB Plus we now have a built in checksum on the data. So it's ever so slightly safer.

Anyone know how much data we can transfer using the bulk upload method? It's not safe to upload the FW in several pieces and then executing it. Why? The running firmware code and/or the command responsible for upload and execute might need/modify the higher RAM region. Then your FW will get corrupted..

Only safe way is to flash one sector at a time. This code should also auto-correct the FW checksum in the flash. So it basically flashes 2 sectors. Another option is to flash the correct checksum after all sectors have been flashed.

There doesn't appear to be any failsafe upload limit in the mode select handler code (on the 3020L). The most obvious RAM location that will cause us problems is (0x8003CC00). This is where our data block ends up before being copied to (0x80000000 + current_block_index * 0x7F8). So at most we can transfer 0x3CC00 bytes, quite alot! (assuming that there are no problem locations before this one, which there might well be).

This code should also auto-correct the FW checksum in the flash. So it basically flashes 2 sectors. Another option is to flash the correct checksum after all sectors have been flashed.

I'd be tempted to correct it at the end. Better to end up in recovery mode than in a potentionally broken firmware. I had a quick look at the upload and execute handlers in the recovery code a week or so ago, shouldn't be too hard to make any flasher work in recovery mode too.

[SeventhSon]

Immediately prior to executing our uploaded code, the mode select handler writes the ATAPI packet to RAM at 0x80010010

This slashes our limit to 0x10010

Edit: I believe there are execution vectors available that do not write the packet to RAM first, these might help to get around this limit.

[SeventhSon]

I've finished the new version of execcode and well as my sector flasher.

The sector flasher is not for n00bs (you really do need a very good low level understanding of the Hitachi-LG firmware to use it safely). Please read all the warnings/instructions carefully if you are going to use it. Even then, there is no guarantee that it will not break your drive. Use at your own risk.

http://www.kev.nu/360/dvdshort.html#7

I also got around to uploading my notes on the new upload/execution procedure and the 3020L firmware routines. So if you're interested in details rather than just the tools, check them out here.

http://www.kev.nu/360/dvd.html#update_04_04_06

There appears to be a bug in the 3020L upload code. I explain it at the end of my 4th April 2006 update. I do *not* check/correct for this problem in execcode, so keep it in mind. I'll paste the bug info here too for those who hate reading.

Interestingly, there appears to be a bug in the 3020L firmware. When the handler code for the Mode Select command that prepares the transfer calculates the total number of blocks to be transfered, it divides by 0x800 (a right shift of 0x0B is the same as division by 0x800).

ROM:00026C54                 mov     D0, D1          ; D1 = transfer length
ROM:00026C55                 lsr     0xB, D1         ; D1 length / 0x800
ROM:00026C58                 movbu   D1, (word_8CE)  ; (8CE) = D1

However, the handler code for the Mode Select commands that transfer the data increments the block counter every 0x7F8 bytes. This means that a small number of transfer lengths will fail when they shouldn't. For example: Imagine you want to transfer 0x1000 bytes of data. The drive calculates the total number of blocks as 0x1000 / 0x800 = 2. You send the first 0x7F8 byte block, which works. Then you send the next 0x7F8 byte block. Now, you still have 0x10 bytes to send (including your checksum), but the drive sees that two blocks have been uploaded and so assumes that you've finished. It then tries to match the checksum to whatever 16-bit value happends to be in RAM at 0x80000000 + (0x1000 - 2) = 0x80000FFD. The sum will almost certainly fail and, even if it doesn't, you still have an incomplete code upload. I haven't tested this bug, but I'm sure it exists.

With a working (allbeit very unsafe) software flasher, I can now finally attempt to reproduce the firmware hack

-Kev

[SeventhSon]

oops, double post

[Mjrweed]

Nice work seventhson, hope a more userfriendly version can be made in the future, it seems abit to risky for me to try the flasher software yet

[SeventhSon]

Nice work seventhson, hope a more userfriendly version can be made in the future, it seems abit to risky for me to try the flasher software yet

Very very sensible. I don't think a safer one will be too long.

[TheSpecialist]

There appears to be a bug in the 3020L upload code.

Funny I also found a bug in the old VAD6011 FW (however in a routine that only got called in a certain 'exception' and that's probably why they didn't find it). I thought about informing Philips about the bug, but I don't know if they would appreciate it, hehe Besides, I'm quite sure MS wouldn't issue a FW update for it, so informing Phlips about it didn't make any sense at all to me.

Anyway, it was confirmation for me that my assumption was right and the VAD6011 FW was indeed coded in ASM (since the bug was that they simply used a wrong register, I checked it a few times and I'm 100% certain of it )

With a working (allbeit very unsafe) software flasher, I can now finally attempt to reproduce the firmware hack

I have a feeling it is not going to be any problem for you

[SeventhSon]

Funny I also found a bug in the old VAD6011 FW (however in a routine that only got called in a certain 'exception' and that's probably why they didn't find it).

Same with this one. It would only ever present itself during a soft-flash and even then only with a very small set of transfer lengths. No wonder they didn't find it.

I thought about informing Philips about the bug, but I don't know if they would appreciate it, hehe Besides, I'm quite sure MS wouldn't issue a FW update for it, so informing Phlips about it didn't make any sense at all to me.

When Hitachi start sending me cheques, I'll start sending them bug reports Until then, they'll have to read the forums.

I have a feeling it is not going to be any problem for you

Not with all the great info from the original team