Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bluetooth Headphone Jacking: A Key to Your Phone [video]

media.ccc.de

Post reply on HN
Print view View original

151–160 of 228 posts

Re: Bluetooth Headphone Jacking: A Key to Your Phone [video]

#151

Post by tialaramex »

p0w3n3d wrote: post #63
ricardobeat wrote: post #61

Earlier quoted context omitted.

The jacks are a physical impediment for slim phones. An adapter costs $3 if you still want it. It’s not a bad trade.

3$ adapter will have low quality DAC

DACs are very cheap. The BOM gap between "This DAC barely works" and "It won't sound any better if we spend more" for a headphone DAC is probably a dollar or so. This isn't some 1980s analogue technology where we need to spring for the best materials to get good results, and the components needed are all readily available from many suppliers today.

Re: Bluetooth Headphone Jacking: A Key to Your Phone [video]

#153

Post by krick »

zaptheimpaler wrote: post #118

I couldn't find anything from Sony confirming that these specific vulnerabilities had been patched, so i tried to reproduce the steps from the whitepaper using nRF Connect [1] with my Sony WH-1000XM4 on the latest firmware version. There was no response to the Get Build Version command, and the Read Flash command returned an error. So tentatively (with false negatives possible), it seems to have been patched on Sony…

WH-1000XM4 isn't on the list of affected devices though, does it have the same chip?

Re: Bluetooth Headphone Jacking: A Key to Your Phone [video]

#154

Post by krick »

chmod775 wrote: post #148
ricardobeat wrote: post #61

Earlier quoted context omitted.

The jacks are a physical impediment for slim phones. An adapter costs $3 if you still want it. It’s not a bad trade.

Phones are already way slimmer than they should be. Now we have top-heavy "slim" phones with huge bulges for cameras*, 50% less battery life, reduced performance because of thermal issues, glued together in favor of screws and rubber seals, wasting weight and space on additional strengthening and internal routing. Just because people think it looks neater than the more practical alternative. The S2 had an amazing for…

I'm not even sure people think that. Apple's marketing department thinks that, and other company marketing departments seem to be implementing some kind of master-slave architecture, where they are slave instances to Apple's master server. Does anybody really check specs and deliberately choose the thinner phone? Or do people just buy new iPhone regardless of whatever decisions they make just because having the last iPhone is cooler? Of course, I don't know, but I somehow really doubt it's the former.

Re: Bluetooth Headphone Jacking: A Key to Your Phone [video]

#155

Post by cetra3 »

krick wrote: post #153
zaptheimpaler wrote: post #118

I couldn't find anything from Sony confirming that these specific vulnerabilities had been patched, so i tried to reproduce the steps from the whitepaper using nRF Connect [1] with my Sony WH-1000XM4 on the latest firmware version. There was no response to the Get Build Version command, and the Read Flash command returned an error. So tentatively (with false negatives possible), it seems to have been patched on Sony…

WH-1000XM4 isn't on the list of affected devices though, does it have the same chip?

Yes it is, page 29 of that PDF lists it:

- Sony WH-1000XM4

Re: Bluetooth Headphone Jacking: A Key to Your Phone [video]

#156

Post by krick »

aziaziazi wrote: post #62
watermelon0 wrote: post #25

Earlier quoted context omitted.

I'd assume that most people wouldn't want to get back to wired headphones. Transition period was definitely rough, but nowadays bluetooth headphones are substantially better than they were in the past, and it's quite freeing to not have to deal with wires. There are definitely benefits to wired headphones, such as better audio quality and no battery life to worry about, but for those cases there are USB-C DACs.

Brand new devices' batteries are awesome but wear off and need to be changed at some point, if A) the device is designed to let you do that and B) the battery is still in production. You don't really own a wireless headphone. You can see it as a rent, or an ownership that loose its capability when in use.

Sure, but I am totally willing to make that tradeoff, and when my earbuds die, I buy new wireless earbuds, not permanently switch to some wired headphones I have lying around (mostly just in case, to not be left hanging if my earbuds suddenly die). I didn't know that before I started using wireless stuff, but now I do. Because, you know, I can change my T-shirt, maybe even take a shower, and start cooking something in the kitchen without pausing that audiobook, all while my phone is charging in another room.

I am even cautiously aware that people have lost their hearing, because damn LiOH exploded in their ear. That's much scarier than knowing I will have to buy new earbuds in a couple of years. Didn't stop me using them either.

Re: Bluetooth Headphone Jacking: A Key to Your Phone [video]

#158

Post by kalleboo »

simpaticoder wrote: post #57
makeitdouble wrote: post #35

Earlier quoted context omitted.

The most frustrating part is when Apple dropped the jack we laughed at the "courage" bit, Apple's given reasons where already seen as bullshit, Samsung had their finger pointing moment. And it just went on, Apple weathered the critics, the other makers also dropped it, and at some point there was just nowhere to go for anyone still wanted a 3.5 jack with a decent phone.

I agree the loss of the 3.5mm jack is a short-sighted and poor decision. There is at least one mitigation, which is the ability to recover the jack through a USB-C DAC. Apple sells them for USD10. I have several, in the car and in my backpack. It's not a good solution though. In particular I find the USB-C port gets worn out pretty quickly. Its also easy to lose the dongle and of course it's more complicated to setup…

Can't you just leave a dongle on any wired headphones you have? Assuming you only use them with your phone and computer and don't have a CD player or something.

Re: Bluetooth Headphone Jacking: A Key to Your Phone [video]

#159

Post by throw0101a »

miduil wrote: post #13

Glad this submission is finally receiving upvotes. This was just shown at the 39C3 in Hamburg, few days back. Common (unpached) Bluetooth headsets using Airoha's SoCs can be completely taken over by any unauthenticated bystander with a Linux laptop. (CVE-2025-20700, CVE-2025-20701, CVE-2025-20702) This includes firmware dumps, user preferences, Bluetooth Classic session keys, current playing track, ... > Examples of…

> WH1000-XM6

These (and others?) actually have a wired option (even provide the cable) for listening. Sadly the built-in microphone doesn't work in 'wired mode' (though ANC does).

You could get at at "cable boom microphone", e.g.:

* https://www.amazon.com/dp/B07W3GGRF2

* https://www.amazon.com/dp/B00BJ17WKK

Maybe the XM7 will have it (along with wired audio controls) via a CTIA/AHJ TRRS plug:

* https://en.wikipedia.org/wiki/Phone_connector_(audio)#TRRS_s...

or via USB audio.

Re: Bluetooth Headphone Jacking: A Key to Your Phone [video]

#160

Post by abeyer »

IshKebab wrote: post #32
miduil wrote: post #13

Glad this submission is finally receiving upvotes. This was just shown at the 39C3 in Hamburg, few days back. Common (unpached) Bluetooth headsets using Airoha's SoCs can be completely taken over by any unauthenticated bystander with a Linux laptop. (CVE-2025-20700, CVE-2025-20701, CVE-2025-20702) This includes firmware dumps, user preferences, Bluetooth Classic session keys, current playing track, ... > Examples of…

Is this an unintentional vulnerability or is it one of those "we left it open because it's easier and we hoped nobody would notice" kind of things. I mean can you just send a "update to this firmware" command completely unauthenticated and it's like "yep sure"? No signing or anything?

According to the details in their whitepaper, firmware is signed, but the management protocol allows reading arbitrary memory, so you can read out the keys and sign your own payload.

I'm not sure anyone intentionally did this, but there were several poor decisions involved. It sounds like the upstream vendor shipped sample code without auth, assuming implementers would know they needed to secure a privileged device management interface, and said implementers just copied the sample and shipped it.

Post reply on HN