Recently I rewrote it in Dart/Flutter and finally implemented RaptorQ codes (way more efficient than Luby used in original Txqr). Testing it internally now, prepareing Appstores/GooglePlay/Web deployment and new article.
Single page file transfer using QR Codes and a browser. Sending device loads a file into the page, gets chunked. Receiver gets all the chunks through a camera, tosses lightly and reassembles, CRC to garnish. Designed to push data from an old phone that had broken comms after it took a swimming lesson in a coffee mug, it's been quite handy.
I've wanted to use this for an air-gapped communication device.
I have a device with a camera and a touch-screen that only uses capacitive charging. I type a message. Bytes are encrypted. I hit send. QR codes flash on my screen. I use my PC or my normal phone to receive the encrypted bytes, and transmit them to you. You have the same device. You have your PC or phone flash encrypted QR codes. You use your device to receive, and then decrypt.
I've daydreamed about also buying several different hardware random noise generators. XOR all of their bits together. Save a huge one time pad to each of our devices. And then also use public key crypto on top of it.
I'm not really sure why I want this. But, it's my answer for how to reduce attack surface as much as possible, and have truly secret messages.
> I have a device with a camera and a touch-screen that only uses capacitive charging. I type a message. Bytes are encrypted. I hit send. QR codes flash on my screen. I use my PC or my normal phone to receive the encrypted bytes, and transmit them to you. You have the same device.
Why do you need a separate device for this and not just an airgapped computer?
Me, in my life, I have a PC that's connected to the internet. I have a phone that's connected to the internet.
I want another device, which I imagine to be a Pi or Esp32 or something with a camera and a touchscreen display, and capacitive charging. After I program it and give it the public/private keypair and the OTP, I imagine physically breaking off a USB port, or sealing one with some hardening resin.
I don't want an entire airgapped computer. Maybe you do, that's fine. For me, I'd love it to be a credit-card sized doodad.
I have a device with a camera and a touch-screen that only uses capacitive charging. I type a message. Bytes are encrypted. I hit send. QR codes flash on my screen. I use my PC or my normal phone to receive the encrypted bytes, and transmit them to you. You have the same device. You have your PC or phone flash encrypted QR codes. You use your device to receive, and then decrypt.
I love this type of stuff. Some years ago I did something similar, but instead of QR Codes it used a convoluted mess of audio frequency modulation to send data through sound between devices. This is much more practical if you have two cameras.
I guess lmao, but much more rudimentary, less reliable and with loads of issues, as it had to blast piercing sounds through a speaker and then capture those with a microphone. But it was pretty cool when it worked!
Did you explore using frequencies outside the range of human hearing?
Amazon had modems very much like this in its little buttons that you could stick to your refrigerator and automatically order different items. When setting up the device, you could only hear the little clicks as it turned on and off.
I loved the technology. Hated that the prices changed all the time and you never knew what price you were going to pay ahead of time.
Cool! Out of curiosity, since qr-codes can contain binary data -- rather than base64, have you tried inserting the file as-is? That way you could do away with the ASCII separator and have a binary header as well. This would spend less frames for the same amount of data, but I'm not sure if it would be computationally cheaper. The other alternative would be the alphanumeric mode of qr-codes, but then you lose lowercase.
I once heard someone create a QR code scanner to retrieve gigabytes of data, but the biggest problem is that cameras aren't powerful enough to handle it all. Essentially, the QR code needs to be downloaded to the device for loading; relying on the camera to retrieve it is very difficult. Am I wrong about this project? What's your solution?
I've done a POC with the native QR reading code on iOS. The short answer is: it's not a problem at all, and you can drive very large QR codes for more efficient transfer.
I've done this exact approach before. It's a good way to exfiltrate data. Post the software on GitHub pages, or a popular CDN that co-hosts other shared libraries and you've got a very difficult to block method.
Really goes to show that it's very difficult to stop a motivated and informed actor.
I'm likely being overly specific, but blocking npm downloads, installation on corporate devices, etc is trivial in a restrictive corporate environment.
What would make this truly portable is being able to generate this consistently with a short prompt and generate with a local LLM. That way no network calls or file hash can prevent this
I created a file optimizer, one single file. I was wondering if i could work with you to integrate that into your project. Lmk!!
This method of animated QR data transfer is quite efficient with fountain codes. I had PoC implementation back in the day - Txqr [1] [2]
[1] https://divan.dev/posts/animatedqr/
[2] https://divan.dev/posts/fountaincodes/
Recently I rewrote it in Dart/Flutter and finally implemented RaptorQ codes (way more efficient than Luby used in original Txqr). Testing it internally now, prepareing Appstores/GooglePlay/Web deployment and new article.
Single page file transfer using QR Codes and a browser. Sending device loads a file into the page, gets chunked. Receiver gets all the chunks through a camera, tosses lightly and reassembles, CRC to garnish. Designed to push data from an old phone that had broken comms after it took a swimming lesson in a coffee mug, it's been quite handy.
If the phone had broken comms, how did you get the code onto the phone to run?
In ye olden days we used cables to sync all of our apps and data to our phones.
But why not move the data over that cable? Some kind of iOS thing that made that more complicated than pushing an app to the phone?
Interesting idea! A demo video would be great :)
You should turn on github pages so we can see it live. Seems cool but I’m not at my pc rn
I also implemented a static web with that idea: https://github.com/anhldbk/get-beam
https://gist.github.com/SMUsamaShah/fd6e275e44009b72f64d0570...
very nice list! Can I suggest adding my https://phntm.sh as well? itis a zero-knowledge file transmission system.
I've wanted to use this for an air-gapped communication device.
I have a device with a camera and a touch-screen that only uses capacitive charging. I type a message. Bytes are encrypted. I hit send. QR codes flash on my screen. I use my PC or my normal phone to receive the encrypted bytes, and transmit them to you. You have the same device. You have your PC or phone flash encrypted QR codes. You use your device to receive, and then decrypt.
I've daydreamed about also buying several different hardware random noise generators. XOR all of their bits together. Save a huge one time pad to each of our devices. And then also use public key crypto on top of it.
I'm not really sure why I want this. But, it's my answer for how to reduce attack surface as much as possible, and have truly secret messages.
> I have a device with a camera and a touch-screen that only uses capacitive charging. I type a message. Bytes are encrypted. I hit send. QR codes flash on my screen. I use my PC or my normal phone to receive the encrypted bytes, and transmit them to you. You have the same device.
Why do you need a separate device for this and not just an airgapped computer?
Me, in my life, I have a PC that's connected to the internet. I have a phone that's connected to the internet.
I want another device, which I imagine to be a Pi or Esp32 or something with a camera and a touchscreen display, and capacitive charging. After I program it and give it the public/private keypair and the OTP, I imagine physically breaking off a USB port, or sealing one with some hardening resin.
I don't want an entire airgapped computer. Maybe you do, that's fine. For me, I'd love it to be a credit-card sized doodad.
I have a device with a camera and a touch-screen that only uses capacitive charging. I type a message. Bytes are encrypted. I hit send. QR codes flash on my screen. I use my PC or my normal phone to receive the encrypted bytes, and transmit them to you. You have the same device. You have your PC or phone flash encrypted QR codes. You use your device to receive, and then decrypt.
Congratulations. You just invented IrDA: https://en.wikipedia.org/wiki/IrDA
I love this type of stuff. Some years ago I did something similar, but instead of QR Codes it used a convoluted mess of audio frequency modulation to send data through sound between devices. This is much more practical if you have two cameras.
> a convoluted mess of audio frequency modulation
Like a modem
I guess lmao, but much more rudimentary, less reliable and with loads of issues, as it had to blast piercing sounds through a speaker and then capture those with a microphone. But it was pretty cool when it worked!
Did you explore using frequencies outside the range of human hearing?
No, but that's a cool idea. I think the main problem is that consumer hardware usually gets kinda inconsistent outside our hearing range.
Apple uses this approach when pairing some devices for verification e.g. setting up HomePods using an iPhone
Did you explore using frequencies outside the range of human hearing?
Amazon had modems very much like this in its little buttons that you could stick to your refrigerator and automatically order different items. When setting up the device, you could only hear the little clicks as it turned on and off.
I loved the technology. Hated that the prices changed all the time and you never knew what price you were going to pay ahead of time.
Cool! Out of curiosity, since qr-codes can contain binary data -- rather than base64, have you tried inserting the file as-is? That way you could do away with the ASCII separator and have a binary header as well. This would spend less frames for the same amount of data, but I'm not sure if it would be computationally cheaper. The other alternative would be the alphanumeric mode of qr-codes, but then you lose lowercase.
What's the length limit? I tried pasting some text and got this message: code length overflow. (85700>18672)
I once heard someone create a QR code scanner to retrieve gigabytes of data, but the biggest problem is that cameras aren't powerful enough to handle it all. Essentially, the QR code needs to be downloaded to the device for loading; relying on the camera to retrieve it is very difficult. Am I wrong about this project? What's your solution?
Why not record with a standard high quality webcam and do the QR processing later? That’s how I would exfiltrate a large volume of data.
You could also do it the menial way; create multiple QR codes that can connect together. Not very practical for everyone except the very-motivated.
I've done a POC with the native QR reading code on iOS. The short answer is: it's not a problem at all, and you can drive very large QR codes for more efficient transfer.
I've done this exact approach before. It's a good way to exfiltrate data. Post the software on GitHub pages, or a popular CDN that co-hosts other shared libraries and you've got a very difficult to block method.
Really goes to show that it's very difficult to stop a motivated and informed actor.
If you can connect to Github pages couldn't you exfil that way? This takes 2 mins for 100KB.
Not quietly. Uploads are commonly monitored by data loss prevention (DLP) solutions, especially when MITM is being used for corporate proxy.
Downloading a tiny JS from a CDN, or accessing a GitHub page is mostly noise, especially if obfuscated well.
Npm install qr-made-up-name Can show qr in console. How do you stop that?
I'm likely being overly specific, but blocking npm downloads, installation on corporate devices, etc is trivial in a restrictive corporate environment.
Cool stuff. I’m fond of the “single HTML file” deployment option.
Let Ai help you research not write keeps the content human and original
What would make this truly portable is being able to generate this consistently with a short prompt and generate with a local LLM. That way no network calls or file hash can prevent this