[Feature Request] Emulate Initial Provisioning Handshake for Factory-Reset Speakers (Missing margeAccountUUID)

[TJGigs]

The Problem:
With the impending Bose Cloud shutdown in May 2026, the current local Soundcork/Uberbose emulation methods (like the BMX registry handshake) work perfectly for speakers that already have a margeAccountUUID stored in memory.

However, if a speaker is factory-reset or completely unregistered, its is blank. In this state, the speaker refuses to request its Account Profile (/streaming/account/{id}/full) and therefore cannot be provisioned with local sources. Currently, the only way to get this ID onto a blank speaker is to use the official Bose app to connect it to the live Bose Cloud.

The Request:
We need a way to reverse-engineer and emulate the exact local network handshake that the official Bose mobile app uses to stamp a new margeAccountUUID onto a blank speaker. Without this, any speaker factory-reset after May 2026 will be permanently bricked, as the cloud will not be there to issue the ID.

I have started a deeper dive into this exact scenario in the Discussions tab here: #223

Has anyone started capturing packet traces of the official app's initial setup process to see what endpoint it hits to inject this ID?

[gmuth]

Soundcork implements the add-device endpoint already. So as long as the Bose App works you should be able to add a factory reset speaker to soundcork AFTER you've changed the marge url on the device. The documentation might not be up to date. Maybe you need to setup empty Recents.xml and Presets.xml files for soundcork. Just try to setup-after-factory-reset and report issues here. (see also #206)

[TJGigs]

Thanks for clarifying. I read through the discussion thread, and while I understand how Soundcork handles the add-device endpoint on the server side, I'm still confused about this specific assumption:

"So as long as the Bose App works you should be able to add a factory reset speaker to soundcork..."

I've tested my existing speakers with Soundcork (using presets, info, providers, recents) and that all works perfectly!

However, If I have a factory reset speaker and can't use the original Bose SoundTouch App because I assume after May 2026 it's margeAccountUUID assignment function will no longer work. How does Soundcork handle this scenario?
Specifically, how does Soundcork assign and push a new margeAccountUUID to the speaker to replicate what the original Bose App does during initial provisioning? Does Soundcork have a mechanism to do this?, or does the project currently rely entirely on the native Bose App to inject that ID?
Thanks you for any insight on this. (I'm amazed at how much you guys have already figured out and implemented!)

[gmuth]

By blacklisting the Bose servers in your network you can test everything today. Let us know if you find any limitations using the SoundTouch App. If the May 2026 App update removes the ability to pair speakers with soundcork accounts we have to stick with the current Version 27.0.1.

There is another ticket where we investigate how to make the core HTML5 app work with soundcork: #125
Manual setup is still an option. When using soundcork instead of bose marge you can setup any accountID you like.
See also #223

[TJGigs]

Thanks! So from your reply then it means you guys haven’t implemented this is soundcork? (correct?) So folks could be completely independent of the native Bose SoundTouch app when reconnecting a factory reset speaker even after May 2026?

I assume the speaker/native app on setup get its initial margeid from the bose cloud marge server.
I'm going to test this by using the native App on a factory reset speaker (no soundcork redirect) with the internet turned off to see if the native Bose App (runing on desktop) tries to do a handshake to the bose cloud on initial speaker setup... Somewhere in the initial setup proocess the speaker gets its initial margeID...whether the speaker gens it itself, gets it directly from the app, or the app passes it to the speaker after getting it from the marge server, or the app triggers an event to tell the speaker to go get it by itself from the marge server... (those are the scenarios i can think of) .

I wasnt going to update the soundtouch app either in may.. But if the current version is calling the bose cloud even just for speaker setup (ie get the margeId) then it's still going to break...Hence my assumption a factory reset speaker after may 2026 is bricked (so much then for the idea of buying them dirt cheap off of ebay after may... lol!)

[TJGigs]

  RE:  **_"Let us know if you find any limitations using the SoundTouch App"_**

Im done testing for today byt this is what i captured in wireshark when doing soundtouch speaker setup on a factory reset speaker using the native soundtouch app.
My summary is that wireshark capture shows the SoundTouch app (v27 latest) does not push the Marge ID to the speaker during setup (I was hoping). Instead, the speaker independently look up to streaming.bose.com, establishes HTTPS connection on Port 443, and gets the ID directly from the Bose Cloud over an encrypted TLSv1.2 tunnel. So when the streaming.bose.com servers shut down in May a factory reset speaker will permanently fail the setup process because it will be unable to retrieve this required margeID.
So it becomes a brick unless we figure out how to spoof this TLS response locally before the servers die. Maybe some others can also try running this as well to confirm my theory and results.?? ..But regardless it is doing a call to the server that is going to die in May.

Action	No.	Time	Source	Destination	Protocol	Length	Info
Speaker asks for Bose Server (DNS Lookup)	447	94.626970600	192.168.137.81	192.168.137.1	DNS	78	Standard query 0x8691 A streaming.bose.com
Speaker gets IP Address (DNS Response)	448	94.627480000	192.168.137.1	192.168.137.81	DNS	224	Standard query response 0x8691 A streaming.bose.com CNAME streaming.fortis.bose.com A 3.168.132.75 A 3.168.132.11 A 3.168.132.26 A 3.168.132.79
Speaker initiates Secure Connection (TCP Port 443)	450	94.643795900	192.168.137.81	3.168.132.75	TCP	74	47480 → 443 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM TSval=261728 TSecr=0 WS=16
The TLS Handshake (Client Hello)	458	95.105108100	192.168.137.81	3.168.132.75	TLSv1.2	583	Client Hello (SNI=streaming.bose.com)

[gmuth]

We should separate concerns here.

1. Make the SoundTouch App work after Server EOL

The App currently requires the Bose Server to work. How do we configure the App to connect to soundcork?
See also #125 where findings are documented concerning the configured URLs.

2. Add App support to soundcork

The App uses various backend services. There are a few use cases where Bose endpoints are involved. After they are discovered and documented they can be implemented. @deborahgu, do you consider App support in scope for this project?

3. Understand and document app to device communication

The App uses websockets to communicate with the device. For async requests (wrapped in messages) it gets async responses (wrapped in messages) additionally to event notifications (also wrapped in messages). See also #123 (I closed this ticket because no one seemed to be interested in)

4. Document other App use cases

Other use cases involve

• TuneIn Services
• Device Discovery
• Spotify
• Amazon Music
• etc.

I did start documenting those use cases - see #64.

5. Setup use case

Soundcork's original setup workflow (copy DeviceInfo.xml) also works with fresh devices. You can configure any numeric accountID in SystemConfigurationDB.xml that fits your setup. Sure we can improve this. In other discussions I suggested an empty default or fallback config for fresh devices.

[TJGigs]

To Clarify.  I captured the factory reset speaker’s independent traffic to Bose server when it was being rediscovered and setup by the sound touch app’s  initial add new speaker process.  I have another trace that I did not include that shows the SoundTouch app itself does not talk to the Bose servers on initial speaker setup.  The connection and conversation to the Bose servers is all coming from the factory reset speaker itself that is being set up. (That's the trace I did include. )  But it would be great if someone can validate my findings and conclusions. I want to find someway to assign a maregeid to a factory reset speaker that does not have it so then the daily speaker handshake to the cloud emulation (soundcork ) can work . I couldnt find that already implemented anywhere. I'm probably repeating stuff others have already figured out?. It wasn't until a week ago or so that I even knew about soundcork/uberbose and needing power up handshake source/presets issues. i thought it was just streaming source bypass that had to be addressed.

[TJGigs]

Ok i just got an end-to-end process working for a factory reset speaker's new config setup with no native soundtouch/app or speaker hotspot needed I never did get the wifi hotspot process to work. Thanks for pointing me in the right direction based on your comments and digging through everything souncork here (and uberbose) 🙏

So still have to code the front end (and test switching wifi config without wiping everything) The approach replicates the Soundtouch App USB cable setup to get speaker on network. And then from there add the required margeid into a config file directly (no post etc) ... Once I hit the correct file on my search I remembered reading somewhere something (there is so much to dig through...lol!) about that file but didnt really understand then . But I found it after running this huge text string search on my margeid from 1 of my speakers (grep -rnw '/' -e "6261590") It took forever!!...lol ... Anyway after that then the normal soundcork/Uberbose approach i baked in my app work fine and started to play my presets.

Ill write up the details and code when i get back after a few days .. Im trying to make all the setup turn key (pic below) ... no vi etc . And no native soundtouch app needed

BTW I also tested with this file intead /var/lib/Bose/PersistenceDataRoot/OverrideSdkPrivateCfg.xml and the redirect works without changing the main PrivateCfg file .. The cool thing for testing u can delete it and the speaker points back to real bose (again no vi... so many typos...aurgh!)... I toggle back and forth a bunch trying to figure stuff out...Lol.

below the log from my app after the wifi/marge update on a factory reset speaker (55) the missing marge was stopping everything before .. but now. [Admin] Speaker already has valid ID: 6261590. Proceeding

BOSE SOUNDTOUCH HYBRID 2026 V1 (MUSIC ASSISTANT EDITION)
[OK] Bose Living Room | Type: SoundTouch 20 | IP: 192.168.4.46
[OK] Bose Kitchen | Type: SoundTouch 20 | IP: 192.168.4.47
[DeviceState] State Change 192.168.4.47: INIT -> STOP_STATE (Power: OFF, Track: None)
[DeviceState] State Change 192.168.4.46: INIT -> STOP_STATE (Power: OFF, Track: None)
[DeviceState] State Change 192.168.4.48: INIT -> STOP_STATE (Power: OFF, Track: None)
[!!] Bose Family Room | IP: 192.168.4.55 | OFFLINE
[OK] Bose Den | Type: SoundTouch 10 | IP: 192.168.4.48
[!!] Bose Studio | IP: 192.168.4.57 | OFFLINE

Server running at http://0.0.0.0:3000
[Admin] Sending Telnet 'sys reboot' to 192.168.4.48 on port 17000...
[Bridge] Action: POST /streaming/support/power_on from 192.168.4.48
[Bose Cloud] Power On Signal Handled for 192.168.4.48
[Bridge] Action: GET /bmx/registry/v1/services from 192.168.4.48
[Bose Cloud] Delivered BMX Registry to 192.168.4.48
[Admin] Smart Inject Sequence started for 192.168.4.55...
[Admin] Checking Speaker Identity...
[Admin] Speaker already has valid ID: 6261590. Proceeding...
[Admin] Connected to Telnet. Sending override...
[Bridge] Action: POST /streaming/support/power_on from 192.168.4.55
[Bose Cloud] Power On Signal Handled for 192.168.4.55
[Bridge] Action: GET /bmx/registry/v1/services from 192.168.4.55
[Bose Cloud] Delivered BMX Registry to 192.168.4.55
[Bridge] Action: GET / from 192.168.4.55
[Bridge] Action: GET /streaming/sourceproviders from 192.168.4.55
[Bose Cloud] Delivered SourceProviders to 192.168.4.55
[Bridge] Action: GET /streaming/account/6261590/full from 192.168.4.55
[Bose Cloud] Account Profile requested by 192.168.4.55. Fetching identity...
[Bose Cloud] Delivered Account Profile to 192.168.4.55 (Bose SoundTouch 99F3E4 - ID: 44EAD899F3E4)
[Bridge] Action: GET /streaming/account/6261590/provider_settings from 192.168.4.55
[Bridge] Action: GET /preset/1.mp3 from 192.168.4.55
🔘 PHYSICAL PRESS: P1 from 192.168.4.55
✅ Triggering via MASS: Diana Krall Radio
[MASS] Play Request: Diana Krall Radio on Bose SoundTouch 99F3E4
[MASS] Clearing Queue for Bose SoundTouch 99F3E4...

[akpdw]

Wow a lot of info here. :) Anyway I did a quick run through with factory resetting my speaker. This speaker has an ethernet connection so I didn't have to go through the wifi setup (might need some research/documentation there). But the basic procedure I used was:

• Flash the usb stick with remote_services
• reboot the speaker with the usb stick and find it on the network
• telnet into the speaker and create a correctly-configured OverrideSdkPrivateCfg.xml file to point to soundcork
• reboot
• set the language by POSTing to http://(ip address):8090/language the following payload: <sysLanguage>2</sysLanguage>
• associated with an existing soundcork account by POSTing to http://(ip address):8090/setMargeAccount and payload

<PairDeviceWithAccount>
 <accountId>1234567</accountId>
 <userAuthToken>soundcorkdoesntcare</userAuthToken>
</PairDeviceWithAccount>

Then rebooted and it was set up on my existing account. The name wasn't correct -- it's possible that you can include a <name> in the setMargeAccount call but I didn't try. You should also be able to set the name with a POST to http://(ip address):8090/name with the payload <name>New Speaker Name</name>, but the endpoint isn't implemented in soundcork yet. I'll probably have a PR for that tomorrow.

It might also be a good idea to have a 'set up a new account` endpoint for soundcork that would create an empty account with no presets or recents and a skeleton of sources, but our first priority is to keep functionality for existing users who already have accounts/configurations.