-
teardown photos
11/15/2018 at 01:16 • 0 comments
-
Let the hacking begin!
11/15/2018 at 21:41 • 0 commentsYay! First hack!
How-to:
* download and install CSR BlueSuite
* connect Flip4 with micro-usb
* press and hold Vol.Down + Play for 12 seconds or so. Flip4 detects as a usb device.
* launch PSTool.exe
* in popup, select USB, OK.
If no message pops up, you're in!
* In main menu, File->Dump, save current config to a file. This is a backup for a case you change something and can't change it back.
* in Filter box, type "local", and pick an entry that says something like "local user-friendly name".
The value should read "JBL Flip 4".
* change value to your liking, click Set.
done. Now, disconnect usb, and … I don't know how to wake it up, the advertised combo Vol.Up + Vol.Down + Play didn't help. I had to unplug the battery.
UPDATE: hold power button for 14 seconds, it switches off. Then powers up as usual.
-
Trying to play with dsp. No success...
11/16/2018 at 00:57 • 0 commentsInstalled Universal Parameter Manager.
CSR8600 Release, v 2.3.137, Dec 11 2012 13:37:59
People say it only connects when running on windows 7 32-bits. It runs fine on Win10, but for me it doesn't connect to the speaker.
"The transport remote cannot be opened.
Ensure that the device is connected and enabled."
It has a feature to load up a .csr file. I tried it, but the program crashes.
I tried generating .csr files with this tool. It creates files with data like this:
// PSKEY_DSP30 = CVC Configuration &2276 = 2276 0000 0001 0000
And if I try to dump this binary data into PSKEY_DSP30 field in PSTool, the tool warns me that the data length is unexpected, and offers to write it anyway. I didn't try forcing it, I feel like there is serious chance to brick the chip. I'm afraid that dsp will crash, and I won't be able to enable DFU mode on the speaker with button combination.
It just seems that the manager and the chip speak different languages. And it's unsurprising, since the manager is soooo ancient. So far, I had no luck getting something more recent.
Any hints? -
Glorious progress... and EPIC FAIL
11/17/2018 at 00:00 • 0 commentsInitially, I was trying to connect to the chip via SPI, using FT232RL, as described here:
https://github.com/lorf/csr-spi-ftdi
And I couldn't. it just kept saying "no chip".
USB connection was great, but there was a problem: if I change something that would make the firmware crash on startup, I wouldn't be able to recover it, as entering DFU mode requires a button combination to work. So I didn't want to dive into hacking the settings too much.
Connecting via SPI would solve that problem. So I kept pushing. I whipped out a scope, and quickly figured out that the pinout explained in the readme wasn't right. Eventually I reverse-engineered the correct pinout. And filed an issue to the tracker:
https://github.com/lorf/csr-spi-ftdi/issues/39
But now I have a working SPI connection, that doesn't require magic button combination. It just works.
And I dived in.
I started exploring, if the config of the chip changes while it's playing music. Yes, it does, a little bit.
And I connected the keyboard to switch the DSP off. Then started poking at keys, DSP didn't want to switch off, then it suddenly just powered down (and made its typical power-off sound). And that was the end of it.
Now, it won't power on anymore. The chip supply turns on for a split second when I press power button, and that's it.
I tried bypassing the mosfet to force the power to the chip. Unfortunately, it still doesn't boot, and worst of all, PSTool fails to communicate with the chip. It says "no chip".
I have a bad feeling, that the firmware might have detected hacking, and decided to nuke itself, together with the chip itself. Or maybe I just blew it, as the connector for the keyboard was slightly damaged.
Anyway, RIP CSR8675. You are a horribly obscure masterpiece of super-proprietary engineering, I won't miss you.
-
DOH! It's alive!
11/17/2018 at 15:15 • 0 commentsToday I got to investigating, what really happened. Found out that despite me forcing the main power to the chip, core voltage (1.8 V) was still coming on for a brief moment after pressing power button. So I tried forcing that core voltage, externally. That didn't change anything, the chip still won't SPI. Then, I continued probing around, and there were quite a lot of signals coming on and off during that brief moment. It was clear that the chip is not quite dead yet, maybe just sleeping.
I tried SPI-ing the chip during that brief power-on period, and got something. That made it clear the chip WAS WORKING, it was just immediately powering off.
Then, after a bit more probing, I came across the pin that detects if charger is connected... Aha! I recalled, there is that demo mode, where it wouldn't power on if charger is not connected. So I plugged it in, and EUREKA! it works!
So, now it became clear, that my semi-broken flex connector caused it to misinterpret the key combo I was doing, and I enabled demo mode instead.
How embarrassing!
OK, back to hacking!
There remains a question. How does one force the chip on, to re-flash it for example, if the firmware powers it off immediately.
-
DSP not configurable?
11/17/2018 at 17:24 • 0 commentsI have progressively erased all data in User DSP Configuration Data XX fields. The DSP still functions as before. So either, as I erase stuff, DSP reverts to built-in defaults, which match the stored values, or it simply ignores them altogether.
-
Extracting firmware
11/17/2018 at 17:56 • 0 commentsAfter no luck on changing DSP, I began trying other tools from bluesuite. BlueFlash came up.
It has buttons that supposedly do what I need. But greyed out, it says "processor running". As soon as I clicked Stop Processor, it spew out an error, because the chip immediately loses power.
Using same trick to force the power to the chip again, now I got lucky. I stopped the processor and dumped the firmware, and even verified it. You can find it in project files.
-
Analyzing the firmware... using Audacity =0
11/17/2018 at 22:04 • 1 commentI looked at the files I extracted from the chip - there are two files, one small and one large. It's a simple text file with hex numbers. So I glued then together with a quick py script to have a look:
file_name = r"S:\somethingsomething\jbl flip 4.xpv" with open(file_name, 'r') as x_file: with open(file_name + '.bin', 'wb') as b_file: for line in x_file: if len(line)<4: continue addr, str_hex_val = line.split(' ') b_file.write(bytearray([ int(str_hex_val[2:4], 16), int(str_hex_val[0:2], 16) ]))
First, I opened them in text editor, to see if there are some interesting strings. Not that I looked very thoroughly, but I only found "JBL Flip 4" string once, and nothing else. I was hoping for some debugging strings, to give me clues.
Then, I decided to see, if the sounds are in that firmware, And yes they are:
(WARNING: VIDEO IS VERY LOUD!)
I loaded the binary file into audacity, and after some precision guesswork, picked the parameters: signed 16-bit pcm, big-endian, 1 channel, 16k sample rate.
-
Sound table
11/20/2018 at 19:19 • 2 comments"User configuration data 30" (PSKEY_USR30)
Contains this:
476d 0000 3fff 476e 0001 3fff 476f 0002 3fff 4770 0003 3fff 4771 0004 3fff 4772 0005 3fff 4773 0006 3fff 4774 0007 3fff 4775 0008 3fff 4776 0009 3fff 4001 000a bfff 4002 000b bfff 4003 000c bfff 4742 000d bfff 4744 000e bfff 4116 000f bfff 4101 0010 bfff 411b 0011 bffe
... and appears to have this meaning:
// event id sound number flags 476d 0000 3fff // "one" 476e 0001 3fff // ... 476f 0002 3fff // 4770 0003 3fff // 4771 0004 3fff // 4772 0005 3fff // 4773 0006 3fff // 4774 0007 3fff // 4775 0008 3fff // 4776 0009 3fff // "nine" 4001 000a bfff // power-on sound 4002 000b bfff // power-off sound 4003 000c bfff // pairing sound 4742 000d bfff // bluetooth connected 4744 000e bfff // volume limit bump 4116 000f bfff // some chord, dunno what 4101 0010 bfff // connect+ activate 411b 0011 bffe // connect+ deactivate
By editing this table, I can reassign and disable sounds.
To disable a sound, set flags to zero. In particular, I've found that bitmask 0x0002 affects if the sound is played or not, the remaining bits don't seem to do anything.
If you want to swap power-up and shut-down sounds, for example, change 000a into 000b and 000b into 000a.
I'd consider it to be FIRST ACTUAL HACK! Yuppeeeee!
-
More setting hacks
11/30/2018 at 11:50 • 0 commentsSo, I have essentially scanned through just about all "User configuration data" keys of csr chip. I have not found anything that affects dsp. But I did find quite a bit of something. Here it goes.
"user0" = "User configuration data 0" aka PSKEY_USR0
"word0" = the index of word (16-bit value) of data in the key.
"0400" = bitmask in hexadecimal notation. If followed by "->" means I tested that precise value.
user0: word0: == 0010 bit -> startup sound == ffff -> boot-loop, self-resets to BEDF 0400 bit set-> crash word3: startup volume word4: if >1aac -> boot loop (halfway through startup sound) data6: word0: 0001: always BT-pairing? data7: word1: change to 0011 -> no startup sound word6: crashy 2000 -> crash 1000 -> crash 0100 -> crash 0010 -> ok 0040 -> ok 00ff -> crash word9: dbd0 -> crash d000 -> crash 0b00 -> crash 00df -> crash 0080 -> ok 000f -> ok data8: word9: >8bcf -> no sound data13: word0: crashy 0070->crash fb70->crash user16: word9: 6070 -> crash 5070 -> ok logic unclear word10: similar to 9 word11: other channel than word12? word12: A060 if any of these set, boot loop with startup sound playing 4000 : boosts volume 001f : boosts volume, the more the value the more the boost user20: word0: 0001: exhibition mode 0002: ?? maybe exhibition mode too? user21: see user26 user26: similar to user21 word0: crash if zero, otherwise no effect word2: if zero, next values are filled with what looks like random numbers user30: sounds table, 3 words per entry word0: event number. 4001 = startup, 4002 = shutdown word1: sound number. 0000-0009 = digits; 000a = startup, 000b = shutdown, 000c = pairing, 000d = connected, e = bump, 000f = chord, 0010 = connect+, 0011 = cancel connect+ word2: bit 0002 is enable/disable, the rest seem irrelevant user37: word0: 0x0080 - clearing this bit inhibits aux input user43: word2: changing value causes either boot loop, no sound, or nothing. Hard to understand word4: signed word, adjusts startup sound loudness (negative for less loud) (0100 is noticeable amount) user49: word0, word1 always restore themselves user51:(thanks @karl.potratz) device color 0001 = Black 0002 = Red 0003 = Blue 0004 = Turquoise 0005 = Grey 0006 = 0007 = Red Base with Blue chequer crosses 0008 = Camouflage 0009 = Blue with Orange chequer stripes 000a = Grey with Turquoise chequer triangles 000b = Turquoise with Blue concentric square pattern 000c = Black 000d = Black 000d = Black user53: change to any value -> crash (tested word0 bit 0001, word2 bit 0001) user61: (thanks @karl.potratz) Custom Device Name. 16 Chars max. (this can also be set via the JBL app) 004a 0042 004c 0020 0046 006c 0069 0070 0034 0020 0031 0032 0033 0034 0035 0036 J B L F l i p 4 1 2 3 4 5 6
Of course, this is still very far from complete. I didn't test all bit combinations for the values listed here, so the conclusion might be wrong.
I've written random values to all unknown data, while looking for clues. Dsp was never seriously affected. Even after isolating a lot of things that cause crashes, I was still observing crashes, boot loops, and overall strange behavior. At least one crash was an unlucky combination of at least two settings in different keys; hunting that stuff down is too time-consuming.
As for "DSP configuration data" - I replaced it all with random values, three times, and it had no effect whatsoever. I'm afraid, it is simply not used at all. Other possibility might be that it checks some checksum on these settings, and reverts to default if checksum is not matched. But I doubt it, it's pointless... So my chances of disabling dsp are really slim at this point.