tchebb / bose-dfu Goto Github PK

If that's of any help, here is the URL called by the Bose USB Link Firmware Updater application : https://assets.bose.com/content/dam/Bose_DAM/Web/pro/software/bose_work/700uc/1_0_0/fileInfo.json

I just bought a used Bose qc35II and the prev owner did somethign with the FW so it now show that it is a Bose SoundSport. Official BTU says it has the latest FW (For that product) so I cannot replace the FW with the official tool...
I just downloading and installing your tool but I wonder if there is any way to skip or disable the check which is for the connected device and for the FW which will be loaded. I know its a safety feature but in my case it would be a help I think...

Error: this file is not for the selected device: file for 05a7:4020, device is 05a7:4012

BTW the device enter and leave DFU as I see from the messages.

Thanks,
Gabor

I ran the binary on my Windows 11 build 22616.1 for my Bose 700.
I could execute bose-dfu.exe list, which return:

05a7:40fc X935501CG10809171J40020 Bose Noise Cancelling Headphones 700 [UNTESTED device in unknown mode]

But whenever I tried other commands (bose-dfu.exe enter-dfu -f or bose-dfu.exe info -f), here's what I got back:

[WARN  bose_dfu] Device has not been tested with bose-dfu; by proceeding, you risk damaging it
[WARN  bose_dfu] Cannot determine device's mode; command may damage devices not in normal mode
USB serial: X935501CG10809171J40020
Error: USB transaction error while requesting info field

Caused by:
    hidapi error: The parameter is incorrect.

Hello!
I tried to downgrade Bose QC35 but it seems to me that it can't go into DFU mode. Can you give an advice? Thanks

C:\Users\user\Downloads>bose-dfu-v1.1.0-win-x86_64.exe info
USB serial: 072546Z62705849AE
HW serial: 072546Z62705849AE
Device model: Wolfcastle
Current firmware: Main 2.5.5.828

C:\Users\user\Downloads>bose-dfu-v1.1.0-win-x86_64.exe enter-dfu -f
[INFO  bose_dfu] Note that device may take a few seconds to change mode

C:\Users\user\Downloads>bose-dfu-v1.1.0-win-x86_64.exe info -f
[WARN  bose_dfu] Device has not been tested with bose-dfu; by proceeding, you risk damaging it
[WARN  bose_dfu] Cannot determine device's mode; command may damage devices not in normal mode
USB serial: 072546Z62705849AE
Error: USB transaction error while requesting info field

Caused by:
    hidapi error: A device attached to the system is not functioning.

C:\Users\user\Downloads>

Currently, we query three different fields from the device, each of which has a two-digit identifier:

Those three identifiers (plus lc, which I couldn't get working as per the comment) were the only ones I was able to learn from USB captures. But by searching firmware binaries for known strings that get returned from info requests, I've found indications of other identifiers that might return different data. I haven't disassembled the source—this is purely based on strings that occur near each other—so there's no guarantee they're what I think they are. But it's worth trying them out anyway to see if they return anything interesting.

So far, I've looked at the SoundLink Color II (Foreman) and SoundLink Mini II (KCup) firmware images.

Both

• vr (known)
• v2
• v4
• pl (known)
• sn (known)
• lc (known, not working)
• la
• bt
• sr
• sh
• fd
• pw
• uq

SoundLink Color II only

• db
• mq
• ep
• ua
• aa

SoundLink Mini II only

• rs
• list (unsure why not 2 characters like the others)
• hr
• vo

As @gaborrell pointed out in #4, the index.xml for QuietComfort 35 II (BayWolf) from downloads.bose.com contains not just a stack_plus_app.dfu but also two .xuv files, ext_signed.xuv, and acorn_coeffs_signed.xuv. Upon further investigation of the archives in bosefirmware/ced, it seems like my device, Foreman, is coincidentally the only one that doesn't have updates with at least one .xuv file.

These .xuv files contain binary data in a rudimentary address+data ASCII hex encoding. The "ext" files are particularly interesting: once decoded back to binary, they begin with fsr_dfu1 magic, which also occurs at various points inside the .dfu files. However, the data following that magic in a given ext_signed.xuv file does not also occur in the corresponding stack_plus_app.dfu file, and in at least one case the former file is larger than the latter, indicating it's an independent piece of the firmware that also needs to be flashed.

Reports indicate that flashing the .dfu file alone seems to work and change the indicated firmware version even for devices that also have .xuv files, but if the two are truly multiple pieces of one firmware image, there could easily be functional issues that occur when they don't match.

To investigate these files further (and hopefully support them properly in bose-dfu), I'll need USB captures of the official updater updating any device that uses them (i.e. any device except the SoundLink Color II). You can gather this with Wireshark (make sure to install USBPcap during installation). If anyone could gather these and share them privately, I'd be grateful! If you filter your capture before sharing it, ensure you don't inadvertently filter out any packets going to your Bose device. The capture should have packets going both to and from the device in both DFU and non-DFU mode.

All of the bose-dfu info output from #3 exhibits this issue. For example, from @Gigzy:

$ bose-dfu info
USB serial: 00000000000000000000000
HW serial: 72476P62100100A2
Device model: Cup
Current firmware: .1.4.3558

That ought to say "1.1.4.3558", I think. I've pushed commit db3c349 to add new logging when BOSE_DFU_LOG=trace to help debug the issue. If folks with the SoundLink Mini II can clone this repository, run BOSE_DFU_LOG=trace cargo run -- info in normal mode, and post the output (feel free to redact the serial number), that'd be useful!

I was about to give up on my quest to resurrect my Sound link Mini II which has been showing flashing red when I power it and thats when I found this great repo. Let me first say hats off to your effort Mr. Developer :)
I had tried the regular bose updater and it shows "no dice" error when it tries to update

Tried this method of firmware update, added a new entry for sound link mini II in the 70-bose-dfu.rules

# SoundLink Mini II, normal and DFU modes respectively
SUBSYSTEM=="hidraw", ATTRS{idVendor}=="05a7", ATTRS{idProduct}=="40fe|4009", TAG+="uaccess"

Below are outputs from different commands
bose-dfu info
USB serial: 00000000000000000000000
HW serial: 68617963564514A4
Device model: Cup
Current firmware: .1.4.3558

bose-dfu list
05a7:40fe 00000000000000000000000 Bose SoundLink Mini II [compatible device in normal mode]

bose-dfu file-info KCup_1.1.4_stack_plus_app.dfu
For USB ID: 05a7:4009
CRC: valid (0xe14c9cbb)

When I try to start the process I get below responses
bose-dfu enter-dfu
[INFO bose_dfu] Note that device may take a few seconds to change mode

bose-dfu download KCup_1.1.4_stack_plus_app.dfu
Error: no devices match specification

bose-dfu leave-dfu
Error: no devices match specification

The fact that bose-dfu leave-dfu gives the same error gets me thinking maybe the device is not entering dfu mode?
Any pointers/suggestions appreciated. I even tried with 1.1.3 firmware trying to repeat above steps but same error.