SACD Ripping using an Oppo or Pioneer? Yes, it's true!

[mindset]

3 minutes ago, Phthalocyanine said:

@mindset Thanks for that tip!  I searched for vermagic in the Oppo sacd_extract and got this

 

vermagic=2.6.35 SMP preempt mod_unload ARMv7

 

So ARMv7! 😀

That is interesting.  I have a way to extract the kernel module from the program.  I can try loading it on my BDP-S6200 which also runs 2.6.35 ARMv7.

[mindset]

29 minutes ago, mindset said:

That is interesting.  I have a way to extract the kernel module from the program.  I can try loading it on my BDP-S6200 which also runs 2.6.35 ARMv7.

 

Tried loading the kernel module I extracted from sacd_extract for oppo and running sacd_extract_160 in server mode on BDP-S6200.  It just worked like a charm.  The process is a little hacky.  I will see if I can make it a little easier for people.

 

[mindset]

14 minutes ago, Phthalocyanine said:

So you ended up using sacd_extract 160 even though it is compiled for Arm 6 on the Sony S6200 which is running Arm 7 but the added kernel module made it work?

 

When you have the time, please try to explain this in simple terms to us simple minds out here.  ☺️

The sacd_extract_160 "program" itself is compatible with both ARMv7 and ARMv6.  It's the kernel module file embedded in the binary that is kernel-dependent.  Therefore, sacd_extract_160 program works fine if the kernel module extracted sacd_extract for Oppo, which carries the kernel module for ARMv7, is loaded before running sacd_extract_160.

 

By the way, I tried running sacd_extract for Oppo with libiconv.so.2 you sent me on S6200.  It worked fine, too.  I think this is less hacky and better approach than playing with kernel modules like I was doing a few minutes ago.  All I had to do was to put it it in the same directory with sacd_extract.  I am doing all this experiments in telnet.  Not sure if we can make this work automatically via Autoscript

 

To summarize:

 

BDP-S5100, S4100, S590, and S490 use ARMv6 and are missing libiconv.so.2

BDP-S6200 and BDP-S790 use ARMv7 and are missing libiconv.so.2

(S790 is not fully confirmed yet, but most likely same as S6200)

 

sacd_extract_160 doesn't have libiconv.so.2 problem, and carries sacd_read kernel module for ARMv6

sacd_extract for oppo has the libiconv.so.2 problem on Sony's, and carries sacd_read kernel module for ARMv7

 

 

[mindset]

32 minutes ago, mindset said:

I am doing all this experiments in telnet.  Not sure if we can make this work automatically via Autoscript

I got it working with this in Autoscript (note LD_LIBRARY_PATH.  This is needed to for sacd_extract to find libiconv.so.2).

CLI(CLI_exec cp /mnt/sd*/sacd_extract /3rd_data)
CLI(CLI_exec cp /mnt/sd*/libiconv.so.2 /3rd_data)
CLI(CLI_exec LD_LIBRARY_PATH=/3rd_data /3rd_data/sacd_extract -S &)

 

[mindset]

1 hour ago, Phthalocyanine said:

@mindset how did you indent quote your autoscript stuff to get around that?

I did nothing special.  I think it happened to trigger nothing.    Of course, I have seen the same problem with my older posts.

[mindset]

On 2/11/2019 at 11:14 AM, Knur said:

@mindsetYou mentionned that you have a way to extract the kernel module from the sacd_extract binary, may you enlighten me ?

 

Open the sacd_extract binary with a binary editor, and replace this 

insmod %s minor=201

with

cp  %s /3rd_data/

, and executethe modified  sacd_extract.  Then a file whose name starting with "tmp" will be created under 3rd_data.  That is the kernel module

[mindset]

On 2/12/2019 at 9:52 AM, Phthalocyanine said:

For this new method for the S790 and S5200 to work, both the sacd_extract program and the libiconv library have to be in the same folder.  That folder can either be root or /mnt/3rd_data, but you have to chose one or the other and your scripts have to specify the correct folder.  @mindset had both in /mnt/3rd_data, so that's why his script uses it.  But you, using the stock script had sacd_extract copied to root, so mindset's script referencing libiconv in 3rd data would not work because that's a different directory than root and both have to be in the same directory.

 

Is that correct, @mindset?

 

Well, the AutoScript I posted copies both sacd_extract and libiconv.so.2 to the same directory, but they don't necessarily have to be in the same directory.  What is important is libiconv.so.2 resides in the directory specified by LD_LIBRARY_PATH in the AutoScript.

 

For the server method with BDP-S6200, it is important that the USB stick is inserted after the disc is inserted and the player is put in sleep (of course with quick start mode enabled).  After AutoScript is loaded from the USB stick, it can be removed and discs can be sequentially processed as long as the player is put in sleep.  Note that sacd_extract is the one for Oppo (md5sum = 14b531b622c92dfe159cf36cff954e5a).  AutoScript.TSS is not needed.  I don't have it in my AutoScript directory.

 

By the way, BDP-S6500 and BDP-S6700 carry kernel 3.10.26.  This is a real challenge.

Linux sony-player 3.10.26 #1 SMP PREEMPT Tue Oct 3 13:25:52 JST 2017 armv7l GNU/Linux

 

[mindset]

35 minutes ago, mindset said:

, and executethe modified  sacd_extract.  Then a file whose name starting with "tmp" will be created under 3rd_data.  That is the kernel module

Correction: tmp -> file

[mindset]

27 minutes ago, Phthalocyanine said:

This seems to say that one should insert the USB stick after the player is put to sleep (in quick start mode).

 

I thought that once it was in sleep mode, the player could not access the USB ports.

Correct.  For BDP-S6200, I see that sacd_extract needs to start "after" the player is put to sleep. USB stick is accessible during sleep on this player (which was not the case for older players). 

 

sacd_extract won't start properly if I insert the USB stick before the player is put to sleep.

 

[mindset]

To avoid the extra libiconv.so.2 business for BDP-S6200 (and probably BDP-S790), I tried kernel module transplantation from sacd_extract for Oppo to sacd_extract_160.  It seems to work fine.  The following script for Linux extracts the kernel module for ARMv7 from sacd_extract and overwrite the one for ARMv6 in sacd_extract_160 with the extracted kernel module.  The new binary (sacd_extract_6200) can be used in the same way as sacd_extract_160 on BDP-S6200 (and possibly BDP-S790).  As I mentioned earlier, sacd_extract_6200 has to be launched in sleep mode for the server method at least on BDP-S6200.  Note that arm-linux-gnueabi-strip has to be installed for this to work.  For Ubuntu, it's in this package: binutils-arm-linux-gnueabi

 

#!/bin/sh
dd if=sacd_extract of=sacd_read.ko bs=1 skip=192524 count=99505
arm-linux-gnueabi-strip -S -o sacd_read_strip.ko sacd_read.ko 
cp sacd_extract_160 sacd_extract_6200
cat sacd_read_strip.ko | dd of=sacd_extract_6200 bs=1 seek=192476 conv=notrunc

md5sum of the inputs:

sacd_extract:     14b531b622c92dfe159cf36cff954e5a
sacd_extract_160: 49107e9625e8cd27232e395787c46fe2

 

[mindset]

2 minutes ago, Phthalocyanine said:

So this refers to using command line SACD extract on a Linux machine? (Your usual method.)

Yes, the script is intended to run on a Linux machine (not Blu-Ray players) to just to create a sacd_extract binary that works on BDP-S6200.

 

3 minutes ago, Phthalocyanine said:

One would also need to come up with methods for people who will be using Windows or Mac with SACD extract command line  or ISO2DSD. 

Cannot think of a way for Windows other than using WSL (windows subsystem for Linux).  No idea about Mac.

[mindset]

9 minutes ago, Phthalocyanine said:

Could you explain more?  Where does one install this?

Do this:

sudo apt install binutils-arm-linux-gnueabi

 

[mindset]

On 2/21/2019 at 12:09 PM, Nexus3 said:

@mindset Can you shed some light on the script files you have used on your S6200?

This is the only thing I have in AutoScript (I do not even have AutoScript.TSS).

CLI(CLI_exec cp /mnt/sd*/sacd_extract_6200 /3rd_data)
CLI(CLI_exec /3rd_data/sacd_extract_6200 -S &)

 

The following is a working sequence.  Inserting the USB stick before putting the player in sleep doesn't work.  (debugging via telnet shows sacd_extract_6200 won't even start)

• Insert the power plug
• Open the tray & insert a disc
• Press the power button to put the player in sleep (with the quick start mode enabled)
• Insert the USB stick
• Run sacd_extract from a PC

[mindset]

2 hours ago, Nexus3 said:

Is this the only working way to do it - or the rephrase it, is the conventional script failing on the S6200?

I am just trying to make sure that we are not riding two different trains heading for the same destination.

No.  The one you posted for BDP-S790 works, too.  I am a minimalist, so try not to include unnecessary lines.

 

I suggest replacing this:

CLI(CLI_exec cp /mnt/sda1/AutoScript/sacd_extract_6200 /)

with this:

CLI(CLI_exec cp /mnt/sd*/AutoScript/sacd_extract_6200 /)

Hard-coding a USB stick mount point as sda1 is not a very good idea.  Each time a USB stick is inserted to the player, the mount point changes as sda1-> sdb1->sdc1... In addition, USB sticks without a partition will not have a number in the mount point. I think this thread wouldn't have grown this much if the original AutoScript  had had this in consideration.

 

[mindset]

12 hours ago, Nexus3 said:

 

@mindset, do you still own the BDP-6500 & BDP-6700 models and able to re-check their SACD ripping abilities? 🤞

No luck there due to kernel version mismatch.

[mindset]

4 hours ago, MikeyFresh said:

 

I stand corrected, on examination of the LX58 service manual, that unit does not use the MT8580 despite being a high-end competitor to the Oppo and it's derivatives. So the Oppo script likely won't work, though it never hurts anything to try.

 

It is definitely worth a try. There have been earlier posts that associate SoC type with ripping capability, but that is just based on limited observation.

 

By the way, I recently found a way to obtain more details about the SoC on the player.

 

Here is what I got from players I have:

 

BDP-S390: MT8551KAAG

BDP-S590: MT8560EAAG

BDP-S1100: MT8552DAAU

BDP-S5100: MT8560EAAG

BDP-S6200: MT8580DJAG

BDP-S6500: MT8580DJAG

BDP-S6700: MT8580DJAG

 

Method to obtain the SoC type:

1. telnet to the player.
2. cliprog
3. Enter drv.bonding.g
4. CTRL+C
5. dmesg
6. SoC type is displayed with other interesting info

Some players are missing the dmesg command. In that case you need to get it from somewhere.

[mindset]

3 hours ago, Phthalocyanine said:

As I recall, it read the redbook CD layer of SACD hybrids and would shown "unknown disc" for non-hybrids.

This is a problem.  Unless the disc is mouted as SACD, you cannot read anything (encrypted or decrypted) from the SACD layer.

 

3 hours ago, Phthalocyanine said:

But when it came to running sacd_extract_160 this is what I always got:

 

sh: mknod: not found
[0]: install_modules: mknod/insmod filed
[0]: Can not install modules

This means the essential command for sacd_read kernel module called mknod is missing on the player or is at a non-standard location.  You need to get it from somewhere or find it on the player.  

[mindset]

30 minutes ago, Phthalocyanine said:

Concerning this and what @Nexus3 has been pursuing by comparing the common Sony BD drive units  -- the question (in my non-programmer way of saying it) is where does the "secret sauce" for reading SACDs reside in these optical units?  If you disassemble a computer optical drive you see it is a combination of (1) the optical drive pick-up (laser and sled assembly) and (2) some motors and (3) a circuit board. 

 

Where does the special ability to read SACD reside in the Sony models -- in a special laser assembly or in some special chip or instructions in the circuit board.  If the special sauce is in a chip or a circuit board independent of the basic Sony BD optical unit (which appears common to both SACD and non-SACD models) then this could explain why the same basic Sony BD optical unit can be used in both SACD and non-SACD models).

 

In other words, the secret sauce may be in a separate chip or circuit board not the common Sony BD optical unit.

The only special thing about the SONY BD optical unit and associated readout circuit in terms of reading SACD should be the ability to read data inscribed in PSP (pit signal processing).  This is where part of dthe ecryption key, which is unique to the disc, is stored and normal DVD drives cannot read it.   (The other part of the decryption key (fixed) is probably stored somewhere in the main SoC.)  The rest of the stuff on the disc is nothing but DVD.

 

My speculation based on some hacking attempt is that non-SACD models are probably missing the fixed key in the SoC and/or PSP readout capability is disabled.  I managed to make BDP-S1100 to switch to the SACD layer by modifying the bdpprog program, and could read raw encrypted data from the SACD layer.  However, I couldn't get decrypted data using sacd_extract_160 (got gabled data with lots of warnings).

 

[mindset]

11 hours ago, Phthalocyanine said:

But the question is can one get this player to mount the disc as a SACD through the mediatek/Linux commands?

I am not aware of any easy way like that.  The only way I could find was to modify the bdpprog program, which is very tedious.  You need to disassemble the program, analyze it to find the layer selection portion, and modify that part to force the player to select the SACD layer.

 

11 hours ago, Phthalocyanine said:

Very interesting.  But how would one begin to get mknod from somewhere?  Alternatively, could you suggest a Linux search command I could run through telnet on the player to look for mknod on the player?

mknod is a standard Linux command and should be at /bin/mknod

[mindset]

1 hour ago, Nexus3 said:

 

./dmesg: error while loading shared libraries: libncursesw.so.6: cannot open shared object file: No such file or directory

 

This is a common problem of borrowing a program from other machine.  You copied the program but not its dependencies. You can try copying libraries it complains about that it might not go anywhere. 

 

 

Sony refuses on cliprog:

cliprog
 open cli device OK!
Enter drv.bonding.g
Cannot do ioctl to device!

Do not enter "Enter".

 

[mindset]

2 minutes ago, Nexus3 said:

Where does the file 

drv.bonding.g

reside? Surely it can be copied to USB and its content readout on PC.

It's not a file.  It's a command.

 

Please try omitting "Enter" in you command entry.

[mindset]

2 hours ago, MikeyFresh said:

So that right there is actual proof this exploit is not necessarily limited to machines with the MT8560 and 8580 SoC then, no?

I believe so.  MT8560/8580 is neither necessary nor sufficient for compatibility with sacd_extract.  There are non-working ones like BDP-S6700 and S6500 usimg MT8580, and BDP-S390, one the working ones, uses MT8551.  There is a larger set of compatible SoCs than just MT8560/8580, but kernel version matching is a must (2.6.35 ARMv7 or v6).

[mindset]

1 hour ago, Nexus3 said:

Thank you @mindset - sometimes persistency pays out.🤑

If you are interested, try "ls" in the cliprog program.  You will get a list of commands in dmesg.  For a list of subcommands you can just enter the command name like "drv" or "drv.bonding".  There are lots of different commands you can play with including a few related to SACD.

 

 

[mindset]

1 hour ago, Nexus3 said:

Assuming the drv.ir.rx.sq is the command sequence for "fake" internal infra-red code inputs via cliprog and 0xaf000 is the hex-code for the EJECT-button, shouldn't there also be hex-codes for other keys like "options" "directions keys" and the "enter key?

IR codes are associated with player functions in /etc/lircd.conf.  But I don't see 0xaf000.  

[mindset]

Regarding your comment on local ripping in sleep mode on BDP-S7200:

 

2 hours ago, Nexus3 said:

Well the telnet session should still work even within sleep mode, only the USB-ports should be gone. Hence a local ripping is not possible within sleep mode.

At least for BDP-S6200, this is not true.  USB does remain alive in sleep and local ripping to a USB stick during sleep is possible.   I would guess the same is true for BDP-S7200 as well.