Any luck with the audio files?

[tux3]

Hi!

I just found your repo after trying to google a bunch of sony URLs and other things.
I'm also trying to change the voice files on my headset, because I really wish I could just quiet them or disable them!

I was starting to think of giving up, because I've stumped by the voice guidance encryption. But apparently the VG and encrypted firmware have been annoying a lot more people than just me, so I thought I'd reach out, as a last attempt =)

I peeked at your notes and I see you've also decrypted the info.xml and gotten the voice guidance files and firmware files.
I agree they're definitely encrypted, just looking at the entropy in binwalk makes that certain =)
I've actually poked around in the APK, but after following the code I don't see anything that decrypts those files. It seems to me it only checks the size and "MAC" of the downloaded file (really the unkeyed sha1 hash, so not really a MAC), and then directly starts transmitting it unmodified to the headset.

Another thing, I think you wrote something about not finding the same byte patterns of the VG binaries in the bluetooth dump. I've seen in the code that there's some extra metadata interleaved, i.e. it splits up the binary in <250 byte messages with a 1 byte header (stop byte). Maybe that's why you couldn't match all the patterns?
(Otherwise maybe the app really does decrypt the files before sending, and that'd be very interesting!)

Did you have any luck decrypting the voice guidance files in the end?
I saw your code, so I tried decrypting them with the same info.xml key, but for me that gives garbage (binwalk still shows sky high entropy). And also, I'm pretty sure thye're not encrypted with ECB, because there are no repeating 64B blocks in any of the files.
(I suspect the decryption key must be in a firmware file, and not in the app.)

Right now I'm blocked, because I think the only way to get that key might be to try looking in older firmware files, or directly dumping the headset's flash. And that might be a whole other wild-goose-chase...

I'm not sure there's much more that can be done, but I thought I'd ask anyways. Thanks for taking the time to read all of that =)

[egaebel]

Hiya! Sorry for the long radio silence, glad to see someone else thinking about this.

You have pretty much perfectly described my progress on this project and I agree, I think the encryption key is actually in the firmware, which is rather annoying. I did a lot of poking around the APK too and wasn't able to find any additional decryption (besides the decryption done on info.xml).

There are two ideas I have about how to approach this, but I have been directing my efforts onto other projects lately and these two ideas are somewhat involved.

1. If the files are somehow decrypted by the app after all, then dumping the bluetooth traffic between the headset and the phone could confirm this. It sounds like you've already somewhat gone down this path, so maybe you're part of the way there? Did you try combining the bluetooth messages and running binwalk on them to see if they contain anything unencrypted?

2. Taking apart the headphones themselves and seeing if there is anywhere to connect hardware debugging equipment. I'm not too well versed in hardware details or electrical engineering myself, so I don't know the specifics of how to do this. My understanding is that there are some common hardware debug port standards like JTAG that might be present/accessible on the headphones if they are disassembled. I'm a bit of a headphone nut and I'm planning to buy the Sony XM5s when they come out, so maybe I'll spend some time disassembling the XM4s when I have a replacement set in hand.

I'd be interested to hear if you have or do make any progress on this!

[toomyzoom]

Hi egaebel,

I saw this link show up in your mitm proxy log:
https://info.update.sony.net/HP002/MDRID294300/info/info.xml
Do you still have that info.xml cached somewhere locally?
I'm trying to find the link for old XM4 firmware because the new firmware just botched the ANC.
Using MDR_Proxy, I found the link for the current fimware version:
https://info.update.sony.net/HP002/MDRID294300/contents/0007/UPG_2.5.0_20210413_enc.bin
But it's not the one I want. I want something like 2.0.6 or 2.0.7 but sony remove old bin link from the info.xml when they roll out update so I'm stuck now.

Seriously trying to dump the fimware from the can directly because I'm at my wit end. $300 headphone now has worse noise cancelling than 3M earmuff.

[egaebel]

I don't have it saved off anywhere unfortunately. Looking at the MDR_Proxy link though, I'd bet that you can just brute-force the old firmware's download link, if it's still valid that is.

Just write a script that tries all combinations from:

2.0.0 -> 2.5.0
and
20190101 -> 20210413

and then try a network request at each step. Once you get a request that returns 200 instead of 404 you should be good!

[sdandroid]

Hi,i am use xposed hook SpLog can see lots of detail,I think will help you.

         try {
                final Class hookedClass = lpparam.classLoader.loadClass("com.sony.songpal.util.SpLog");

                String className = "com.sony.songpal.util.SpLog$Level";
                XposedHelpers.findAndHookMethod(hookedClass, "f", className, new XC_MethodHook() {
                    @Override
                    protected void beforeHookedMethod(MethodHookParam param) throws Throwable {
                        Class classIfExists = XposedHelpers.findClassIfExists(className, lpparam.classLoader);
                        Enum verbose = Enum.valueOf(classIfExists, "VERBOSE");
                        param.args[0] = verbose;
                        XposedBridge.log("before param: " + ToStringBuilder.reflectionToString(param.args));
                    }

                    @Override
                    protected void afterHookedMethod(MethodHookParam param) throws Throwable {

                    }
                });


            } catch (ClassNotFoundException e) {
                XposedBridge.log("SpLog class hasn't found");
            }


            try {
                final Class hookedClass = lpparam.classLoader.loadClass("jp.p240co.sony.eulapp.framework.core.util.DevLog");
                XposedHelpers.findAndHookMethod(hookedClass, "setEnable", boolean.class, new XC_MethodHook() {
                    @Override
                    protected void beforeHookedMethod(MethodHookParam param) throws Throwable {
                        param.args[0] = true;
                        XposedBridge.log("before param: " + ToStringBuilder.reflectionToString(param.args));
                    }

                    @Override
                    protected void afterHookedMethod(MethodHookParam param) throws Throwable {

                    }
                });


            } catch (ClassNotFoundException e) {
                XposedBridge.log("SpLog class hasn't found");
            }

[maxisvest]

I don't have it saved off anywhere unfortunately. Looking at the MDR_Proxy link though, I'd bet that you can just brute-force the old firmware's download link, if it's still valid that is.

Just write a script that tries all combinations from:

2.0.0 -> 2.5.0 and 20190101 -> 20210413

and then try a network request at each step. Once you get a request that returns 200 instead of 404 you should be good!

I tried, but unfortunately, sony seems remove the firmware. All the possible link are invalid.

[tux3]

So, my XM4 started malfunctioning recently. It's out of warranty and I had to buy a new one.
Which means I finally had an excuse to look inside without fear of breaking it further:

It's using a 128Mbit QSPI from Winbond. And it's in this extra small WLCSP package, of course.
I assume the firmware is sitting unencrypted in flash (and maybe even the AES decryption keys for OTA updates is in there, who knows?).

Currently contemplating trying to solder those 0.2mm probe wires to this row of four SMDs left of it that look like they might be on the QSPI data lines. And see if a logic analyzer spies anything interesting flying through when I turn the headset on.

Unfortunately I don't know much about electronics, I am not particularly good at soldering, I don't have any appropriate equipment for BGA/SMD work, and I don't currently own any hardware that can drive 1.8V required to talk to the flash chip directly, so... no one hold their breath.

If that fails (likely), my plan B is to wait for my Glasgow to ship, it definitely supports 1.8V and it's more than capable of dumping a SPI flash, if I don't mess up the soldering too badly
... which I probably will, but I figure it should be fun to try anyways =)

[13x1]

@tux3 Any updates on this? Would be very interested in dumping and maybe modifying the firmware :)

[tux3]

Well, my plan A started okay, I had somehow managed to convince two out of four wires to stick (with liberal use of Kapton tape and a slathering of flux). Not the prettiest job, and not making a very solid connection at all, but it surprisingly was sort of working at first:

... and then reality reasserted itself, and I burned the hell out of that third SMD! I don't know if the pic really shows the scale, but these things are 200 microns wide, maybe 50 microns apart, so coming at them with my clumsy inexperienced software person hands and a soldering tip that's bigger than the whole component was maybe a little too much hubris to have it work on the first try =)

On the positive side, the chip is still fine (I only damaged an SMD resistor), and my Glasgow has shipped. A more reasonable way to dump the flash might be to desolder it with a hot air gun or SMD reflow equipment and plop it on a little PCB with proper access pins.

But I don't have an SMD reflow station (let alone a reflow oven), so I wouldn't hold your breath! (and the problem remains that I've never done any SMD work, there are a million people more qualified than me to be attempt this..!).
I'm thinking I might try looking into local hackerspaces to ask about equipment, but I really can't promise anything. To be continued? =)

[mirh]

lzghzr/MDR_Proxy#31

[BoKKeR]

Important, headphone connect has been reborn as sound connect!

I had to initially run the app without the proxy, otherwise it behaves the same.

About the flash/micro controller, I have some equipment for micro soldering but not tooling for chip reballing/reflowing. Some repair shops might be up to the task of extracting the chip to a breakout board. I am yet to order a main board. My headphones are still working

@tux3 Any test pads found? I would assume the easiest route in would be using a bus.

[tux3]

@BoKKeR There's this very good teardown from 52audio with high quality pictures: https://www.52audio.com/archives/54160.html

Nothing screams debug port to me, but I could easily be missing the obvious =)
We do have these two groups of 4 pads (the one on the left has nothing on the other side of the PCB). And there's also many of these pads floating around all over, but I can't tell what signal might be on these pads, could be completely random. Can you see something interesting in there?