jflattich

That line numbers are in fact the memory addresses in RAM. I was just checking what the debug string "boot-zone" means and this was the result. But now we are sure, that the only hidden information is the disc id. Btw can somebody supply me with his 10****** file from his HiMD-disc? I think if the information after EKB is the same as the information in my file, then the algorithm used is really the same as described in the patents someone found some time ago.

Perhaps we can come to an agreement on which problem we should focus first (data transfer or decrypting the data), so that we can solve this specific problem with maximum force (I hope you understand this sentence - it looks a bit not well-formed to me )

Would someone be so kind to provide me with a 00010012.HMA file or a hex output of it? Before a transfer of the atdata-part, sonicstage checks 64 Bit (!) of this file. Btw. is there any proof that the keys are really in TRKIDX? The software sends commands to the unit to read/write data, so to circumvent this you would have to crack the software. According to the debug-strings I stick to DES. -> .data:6C38966C \tENC FORMAT:\tdes cbc with session key .data:6C389630 \tENC FORMAT:\tdes ebc with session key

You are right: the mentioned boot- & system-zones are entirely for the visible filesystem data. But before the filesystem is mounted, the program makes some checks. Here is a debug snapshot: [ 2005/09/02 20:06:38 ] ROM: 0 [ 2005/09/02 20:06:38 ] MEDIUM TYPE: umd3 [ 2005/09/02 20:06:38 ] FORMAT TYPE: ddt is recorded [ 2005/09/02 20:06:38 ] WP 0 [ 2005/09/02 20:06:38 ] PAGE CODE: md play mode page [ 2005/09/02 20:06:38 ] TABLE NUMBER: 0 [ 2005/09/02 20:06:38 ] SINGLE: 0 [ 2005/09/02 20:06:38 ] SHUFFLE: 0 [ 2005/09/02 20:06:38 ] REPEAT: 0 [ 2005/09/02 20:06:38 ] START TNO: 0 [ 2005/09/02 20:06:38 ] END TNO: 0 [ 2005/09/02 20:06:38 ] get medium unique id [ 2005/09/02 20:06:38 ] OBJECT NUMBER: 0 [ 2005/09/02 20:06:38 ] DISC ID 16 bytes [ 2005/09/02 20:06:38 ] mount file system For me it looks like that the only real hidden information on the disc is the disc id. So it looks like that the disc id or some combination with the disc id is the key for the encryption (disc id == 16 bytes == 128 Bit -> Triple-DES?)

I was able to get the bootzone, but it's somehow disappointing: It looks like there is only information about the name and the filesystem in it: 00D359D4 E9 00 00 4D 53 57 49 4E é..MSWIN 00D359DC 34 2E 31 00 08 10 01 00 4.1..... 00D359E4 02 00 02 00 00 F0 1F 00 .....ð.. 00D359EC 20 00 40 00 00 00 00 00 .@..... 00D359F4 C7 89 07 00 00 00 29 00 Ç.....). 00D359FC 00 00 00 4E 4F 20 4E 41 ...NO NA 00D35A04 4D 45 20 20 20 20 46 41 ME FA 00D35A0C 54 31 36 20 20 20 T16 There is a disc id too, but it doesn't change after formatting the disc. F.e.: 01E3FE4C 02 00 00 00 00 00 04 12 ........ 01E3FE54 03 03 00 00 00 00 11 82 ........ Perhaps I'll have a look at the system-zone today.

Those Sony guys are a bit arrogant - they left all debug-strings in their exes/dlls. Just disassemble himdpacapi.dll and enjoy the strings. To debug just use ollydbg with hidedebugger and Simple Burner or Sonicstage don't detect the debugger. Btw. I just found the ICVs in a OpenMG folder - is there any information about this discovered yet?

Well, I don't know if this helps, but it seems that: a) there is a session key for each communication with the player, encryption is DES with ECB or CBC (but it is somehow possible to use no encryption), c) there are two hidden areas in the recorder which can be read by the software: -boot-zone -system-zone, d) Simple Burner has a debug feature: netmdsb.exe -debug (helps a lot in the debugging process with f.e. ollydbg), e) if you debug, I would rely on Simple Burner, because it's just simpler Greetings jflattich