Quiet for Android – TCP over sound | Hacker News Reader

Quiet for Android – TCP over sound

github.com

301 pointsadulau74 comments

Today I learned that you can actually abuse the system bus on some macbooks to actually send audio over AM radio[0]. Even scarier, you can do it from the browser[1]. And now this library[2] will let you open a TCP connection over the radio to download off that data machine. This is shaping up to be a pretty cool attack PoC!

[0]: https://github.com/fulldecent/system-bus-radio

[1]: https://fulldecent.github.io/system-bus-radio

[2]: https://github.com/quiet/quiet-js

Code running in your browser gaining a TCP connection seems like the least scary use case of this possible- presumably it already has a TCP connection in the first place.

Could you possibly use the radio transmission to triangulate someone's location?

The range is quite low. If you can hear the radio you already know where it is.

what's the transmission speed?

How is the system bus radio machine going to receive its ACKs?

Yeah I realized this shortly after posting, too. UDP it is.

That reminds me of the programs you could run on a TI-83 calculator that used a similar approach for playing sound on headphones or a nearby AM radio: http://www.pacmeb.com/calc/features.php

System Bus Radio

https://news.ycombinator.com/item?id=16167594 (Jan 2018)

https://news.ycombinator.com/item?id=11203951 (Mar 2016)

For those of you interested, there was an app called Chirp by Animal Systems that allowed you to transfer messages and shortcodes of hosted media content over audible frequencies. Despite being rather ear-piercing each time a Chirp was sent, it was still a very interesting principal. I remember reverse engineering the protocol and error correction mechanisms (it was a varient of the Reed-Solomon algorithm iirc) with a friend for a little household "internet of things" that communicated over sound. I still have a few temperature monitoring devices around the house that sing a little tune based on the RE'd code every few hours to report back to my RasPi on home temperature data.

Judging by the fact that this was in my GitHub stars list from about a year ago, it looks like I was considering transitioning to something more open. With the right encryption and error correction mechanisms I think this type of technology could be really useful for short-range home iot communication.

I remember that app! It sounded so cool but was only available for iOS at the time and when I saw the Android app a few years later by change it was only a weird proof-of-concept where you can transmit folder-icons from within the app to another phone with the app.

Mh, looks like they're still around: https://www.chirp.io/

I really like the concept, would be really nice to have a functional app one day.

It's already becoming common. Chromecast has used it since 2014, and I just bought a $30 Wifi camera on Aliexpress that also uses ultrasounds for the initial configuration.

It's definitely an interesting concept. I've been playing around myself recently with implementing a simple data-over-sound protocol (nowhere near as advanced as Quiet). If anyone is interested, here is a quick 1 min showcase: https://www.youtube.com/watch?v=HrMQjFGD_MU

Using something that sounds like bird calls - or something else that's pleasant - to transmit data sounds like a pretty neat idea for a smart home. It would expose the otherwise-invisible artificial ecosystem you're living in.

Imagine your smart home ecosystem that sounds like the Amazon ecosystem. That sounds like the kind of thing that would actually push me the extra edge to wire my home up.

Until 3am, when auto-installed updates roll out :)

Back in the mainframe days I spent many late nights in the machine room doing systems janitor work. I could easily identify which workload was running, and what phase, by the ambient noise of disk and tape drives.

I can imagine your house chirping and tweeting about, when suddenly you wake from a deep sleep saying "what was that!" when some unusual pattern of sound happens.

The pattern matching and decoding portions of our brain never, ever, stop their efforts and are wired deeply in to the survival mechanisms we have.

Back when I built robots I could tell when they needed lube or bearings replaced by the pitch change in the motors on full power. I find it interesting that you figured out the same for a mainframe

I once read that Brian Eno did an experiment about this. He recorded something like 30min of outside noise in order to see if he could learn "how it goes," just like you learn how a piece of music goes. "Wind rustle, dog barks, more wind, a horn honk, then the garbage truck goes by and a bottle falls out and breaks," etc. It was a successful experiment.

I had a similar personal experience. For years growing up I slept to a white noise machine that played a 3-second recording of a mountain stream. I became intimately familiar with the clip and could anticipate every trickle, the changing pitches of different water droplets, and the length of the loop. I can still conjure it from memory in great detail.

Intriguingly, on a single night I experienced some sort of hypnogogic auditory hallucination that caused the sound to lose all familiarity. Instead, I perceived the sound of a male singer arpeggiating rapidly. I found it highly disturbing.

never knew how to phrase it, but I've had that a couple of times in the past few years. I've had to get really picky abouth the white noise sounds I listen to. Eventually, almost all the loops become identifiable - I can tell when the loop restarts, etc. I had two different loops (both of water sounds - waterfalls, maybe? - iirc) that, at some point, started to register as human voices, and it freaked me out more than a bit.

fwiw, the only thing that works well for me is masking any other sounds with a mix of grey and brown noise on top. i use 'white noise app' to achieve this, and it helps me get to sleep, masking out many other ambient disturbances (road/car noises, mostly).

For everything about noises, I highly recommend mynoise.net. It has a ton of high quality sound generator which does not loop. If it is too monotonous, you can automatically "animate" the sounds which modify continuously the sounds at different frequencies.

You mean Amazon as the Amazon river..?

You know, if I worked at Amazon, I would be very tempted to build something that plays river-and-rainforest sounds to indicate the health status of things.

Smoothly running stream? Everything is green. Rapids? Yellow-status; something needs looking into. Waterfall? Something's gone terribly awry.

Happily chirping birds? Successful health checkins. Monkeys screeching? Unhealthy result. Jaguar growl? Datacenter is on fire.

> I remember reverse engineering the protocol and error correction mechanisms (it was a varient of the Reed-Solomon algorithm iirc)

Wow! Do you have a write up, or code? I tried to do the same [1], but got stuck on the error correction [2]. I'd love to get closure.

1. https://github.com/moreati/chirppy 2. https://math.stackexchange.com/questions/663643/discover-par...

I'll see if I can't send something over in a PR or Issue :) I'll have to make sure it's a clean-room implementation, however, to get around legal issues.

Thank you

I've been hearing weird short "chirps" on youtube re-broadcasts of my shows on non-licensed accounts. I was wondering if they were weird leaking ultrasond signals (leaking under 22khz) used for advertisement tracking on mobile devices. I turn off my mobile at night now before I watch the shows.

Hey everyone, author of the library here.

There's a live JS demo of this you can try for yourself at https://quiet.github.io/quiet-js which demonstrates the audible and ultrasonic modes.

The JS version is compatible with the Android version. There's also iOS ( https://github.com/quiet/QuietModemKit ) and C ( https://github.com/quiet/quiet ) which interop as well.

The throughput you can get changes depending on conditions. Across a cable, you can achieve about 64kbps. Across a short air gap, about 3-4 kbps. Across a room, you can maintain 5 bps or so. There's no capacity negotiation/detection, instead you preconfigure using a modem profile.

A good demonstration of Quiet's flexibility can be seen here https://quiet.github.io/quiet-profile-lab

Do you have any recommendations for microphones suitable for desktop use?

Our team worked on a similar idea and the test phone speakers died pretty fast, probably 2 out of 3 within a month. The cause may be (1) we over-stressed them too much (2) they were cheap Samsung phones and (3) we used frequency around 20kHz to avoid annoying human users (this library seems to operate at 17+kHz at most). Our conclusion at the time was consumer speakers and microphones are not good enough. Would love to hear whether Quiet has the same issue.

Funny, I say my cheap, 2 year old, $60 huawei phone die a couple of months ago. At the end it was emitting weird sounds from its speaker. It would not boot properly anymore.

I was always thinking that broadcasting high pitched audio signals would be an awesome way to drive a companion website in a theater or museum. As you follow the play subtitles advance or text for a painting comes up on your phone.

I’ve been wanting theaters to adapt a protocol like this to control the color of light sources in the theater (row lights, emergency exit sign). Make all those lights with color leds and let the color be controlled by signal embedded in the audio track of the movie — then subtle mood lighting effects would become an option for movie makers... would be fun for some movies — the stars wars scene in the emperor’s thrown room comes to mind as a good example.

Maybe the law is very specific in the color and amount of light that emergency signs and row lights are allowed to have?

I'm just speculating, but I don't remember the last time I saw a non-green exit sign. I think I've seen them red but very seldomly.

Could that be something preveting such innovations?

I do agree however that it would probably be cool. Sometime ago I got a lightpack (I think it was called?) from a kickstart project, that had a similar effect but for your tv of computer monitor and it looked great.

> I'm just speculating, but I don't remember the last time I saw a non-green exit sign. I think I've seen them red but very seldomly.

In North America?

At least here in Canada, I see almost only red exit signs like this: http://www.mulelighting.com/product/E-StarSeries.jpg

Only in new construction have I started seeing these green signs: https://lerablog.org/wp-content/uploads/2013/05/emergency-ex...

In Mexico at least.

Now that I think about it, I do have seen red ones in Canada and the US.

In any case, it seems that it's a color chosen to comply with some law, instead of just an arbitrary choice. In that sense I'm not sure if regulations would let movie theaters (or other businesses) change the color.

I agree that there is probably a regulatory obstacle — i imagine its at least theoretically possible to overcome and would be pretty cool!

Here's another idea: TCP over vibration. Put one phone on top of the other, the bottom one in vibration mode, the other using its accelerometer to receive.

wow! that's brilliant.

accelerometers are way too imprecise for that to work

How? A naive solution would use only "upwards acceleration" and "lack of upwards acceleration"; phone accelerometers should be able to handle that quickly enough to get at least couple dozen bps.

Yeah, you just need put a wide margin between "high" and "low" states. The bitrate will be low, but it would work.

You'd be amazed how much signal you can pull out of the noise given modern processing techniques.

no i wouldn't - i know all about kalman filtering. it's still not enough

Not only are accelerometers precise enough for data transfer, me and my colleagues demonstrated data transfer at ~200 bps (after error correction) through the user’s finger to a wristworn smartwatch. Take a look: https://www.robertxiao.ca/research/viband/

Uh-huh...

Ripple: Communicating through Physical Vibration

https://www.usenix.org/node/188984

This paper investigates the possibility of communicating through vibrations. By modulating the vibration motors available in all mobile phones, and decoding them through accelerometers, we aim to communicate small packets of information. [...] We develop Ripple, a system that achieves up to 200 bits/s of secure transmission using off-the-shelf vibration motor chips, and 80 bits/s on Android smartphones

Interestingly enough, me and that very same friend from my prior comment also joked around with this idea. We never implemented it however, after I vaguely remember reading about a POC in some article from an engineering journal...

Google has a SDK called Nearby which is supported on iOS and Android. In the first version only some sort of address / ID was exchanged using audio and then the actual message was transferred using GCM, which meant an internet connection was required. v2 apparently didn't need an online connection but haven't tested it.

the docs for nearby suggest it uses ble?

Nearby uses both BLE and ultrasound. Before this was exposed in the Nearby APIs, Chromecast, which does not have BLE, used ultrasound to find Android devices in the same room.

Their newest payment app in India, called Tez, also uses sound to secure transactions I believe.

Yep, made by Google

For headless smallish servers (consumer hardware or SoC like Raspberry Pi) the sound interface is awesome because it needs no additional hardware (as with bluetooth + software stack) and almost all mentioned devices have a sound card on board. I think it's not too hard to setup a getty instance in an old modem fashion with this.

Additionally, as a client already a smartphone is suitable. This can be helpful in weird situations (think of non-working network).

Dogs' hearing extends to 45 KHz. Cats hear up to 79 KHz. How do all these ultrasonic audio systems affect them? Do they cause pain? Do they damage the animals' hearing?

I won't (knowingly) use ultrasonic audio systems until I see some research on this topic.

Presumably the amplitude is no louder than normal speakers. 120db will be dangerous to humans and dogs. 20db won't.

Listening to white noise isn't painful.

If you want to try out Quiet's audible profile, you can imagine that ultrasonic is the same volume, but pitch shifted up. Making modems louder doesn't help transmission anyway, so it's pointless to do so.

https://quiet.github.io/quiet-js

Can someone with more knowledge expand on the bandwidth limitations here - what are the hard limits for TCP/sound? Are the speeds here technically able to improve marginally, significantly, or not at all?

One would think that you'll start hitting real-world limits real soon - background noise, speaker/microphone characteristics etc. Improving on those usually means more expensive equipment, this would be the most limiting factor IMHO.

Hard limits are set by the strong absorption of ultrasonic frequencies by the air - IIRC the expected range of frequencies > 1MHz is measured in single digit cm & drops very rapidly. This reddit comment ( https://www.reddit.com/r/askscience/comments/3oo5ks/is_there... ) quotes references that suggest a 100dB drop-off / foot @ 10MHz.

Meh, if exfiltrating a couple kB of password data is all you need... the time for a coffee at a Starbucks is probably enough already

Sound can be used as part of a handshake process and then real communication done over the internet: https://en.wikipedia.org/wiki/Interactive_Connectivity_Estab...

That could be nice to setup/connect devices that don't have buttons and a display. E.g. connecting a printer to a tablet, sending wifi passwords to the printer. (At least, as long as nobody else is listening).

Isn't that solved by RSA? Printer broadcasts its public key saying "hey, printer here, send me the wifi password please". Your phone uses the printer's public key to encrypt the wifi password and send it out. The attacker cannot snoop on the key, because it doesn't have the printer's private key necessary to decrypt the message.

An attacker could still man in the middle the initial key handshake.

Printer: "Printer here, my pubkey is A"

Attacker (races phone): "Alright bro, I got it"

Attacker: "Printer here, my pubkey is B"

Phone: "Alright bro, I got it"

Phone: "Here is the WiFi password, encrypted with B"

Attacker: "Thanks!"

This example is pretty simplistic, but the idea still works even if there is some form of authentication (e.g., challenge-response).

The way around this is to pre-share some sort of info to verify the authenticity of any new incoming key.

For example, the user downloads a printer app on their phone that contains a master pubkey. On the other side, the printer would have a device pubkey signed with the master private key. When the phone receives a new printer message, it first veriffies the key signature to ensure that it actually came from a legitimate printer.

If you can't get some sort of key onto the phone, your best bet is to perform key exchange out of band. One common technique for phones is NFC: it requires proximity, making the attack above difficult to execute.

> For example, the user downloads a printer app on their phone that contains a master pubkey. On the other side, the printer would have a device pubkey signed with the master private key. When the phone receives a new printer message, it first veriffies the key signature to ensure that it actually came from a legitimate printer.

To further increase security, the certificate (signed pubkey) presented should also contain some unique per-device identifier (serial number or some PIN code or something). Otherwise attacker could possibly extract keys from a similar device to conduct the attack.

I see the library has both Android and iOS versions.

I have a question. Is this AppStore-safe? (As in "Is there a chance Apple or Google may reject the app because it includes this feature?")

Chromecast is already using it on their SDKs for Android and iOS apps (they call it "audio tokens"): https://developers.google.com/cast/docs/guest_mode

Reminds me of Google's tez payment system (does over ultrasonic tough)

Oh imagine the world of exploit for IOT... the drive-by remote 0wns, beauty

I wonder if this would work over radio such as Ham or Two-Way.

For low power stuff in amateur radio check out WSPR and FT8.

Hammmm. IT Need to disable all audio drivers now?

Reply on news.ycombinator.com