jjtech

Joined 2 years ago

Karma
78
Submissions
15
Member since
Dec 5
https://github.com/JJTech0130
View on Hacker News

Recent submissions

Comment · 6 months ago
Comment · 9 months ago
> Assuming your carrier bothers to run RCS, the protocol works just like MMS and SMS do. If your operator doesn't peer with other operators then you'll have the same issues getting any kind of multimedia delivered from phone to phone.

Except, SMS/MMS can be implemented by any standard IMS stack and it will function on any carrier (in theory, ignoring implementation bugs/incompatibility);

RCS has an explicit provision in the standard for "client authenticity" checks which in practice means App Attest/Play Integrity signatures.

(see also: my comment above)

Comment · 9 months ago
As an aside, the IMS stack used to implement SMS/MMS/RCS on Android is super cursed. A lot of the heavy lifting is handed off to the OEM, for example, Pixel devices hand it off to the Qualcomm modem. (Meaning Android the OS doesn't even have any control over how the raw SIP messages are sent: they're inside an IPSec tunnel set up by the modem that it can't see inside)

iirc Samsung devices do it differently and they implement it in userspace using StrongSwan?

That's why it's super annoying to handle SMS/MMS using the standard/legacy APIs, because depending on what device the user has, the implementation may behave radically differently with regards to PDU parsing and such.

RCS makes the whole situation worse because it sets up an entire secondary IMS stack inside the Google Messages app, and then uses weird APIs to try to tie it back into the main stack, even though obviously the modem implementation doesn't understand RCS... it's a mess.

Comment · 9 months ago
Comment · 11 months ago
All of these errors have now been stealth-corrected.

New strategy discovered: Ask LLM to write article, nerdsnipe HN into correcting it, feed corrections back into LLM until people stop complaining

Comment · 11 months ago
Comment · 11 months ago
Jibe actually will ask iOS for App Attest attestation (this is actually spec, unfortunately: see section 2.11 Client Authenticity in RCC.14)

So it is entirely plausible that they banned the device, I guess. (Or they could have banned the IMEI, as mentioned)

Comment · 1 year ago
Comment · 1 year ago
Comment · 1 year ago
Comment · 2 years ago
To clarify some points, though I'm sure all will become clear when this releases:

+ This is NOT hardware attestation. It's simply using a combination of things such as serial number and other device identifiers to prove to Apple you own the device

+ Because it is not hardware attestation, in the future this process might be improved, if someone reverses/emulates the (purely software) algorithm "proving" you have that device. Then it would only be a matter of asking the user to input a serial number, once.

+ Hardware attestation is implemented in the protocol. However, the 2019 iMac does not have a T2, so this cannot be enforced for a while yet.

+ Beeper Mini still implements the rest of the iMessage stack on-device

Comment · 2 years ago
…I wonder if this could be used to implement AWDL (Apple Wireless Direct Link) for use with AirDrop… if I recall correctly, the blocker on normal WiFi chipsets is being unable to send the ACK frames, which this should enable?
Comment · 2 years ago
Comment · 2 years ago
I was thinking of finding a way to extract it directly from old Mac OS X updates downloaded directly from Apple... anyway, Beeper's app doesn't use it, that's purely a hack I came up with to make the proof-of-concept easier to use.
Comment · 2 years ago
While I will definitely agree that Signal is more secure:

There is a newer version of the iMessage encryption (sometimes called "pair-ec") which uses ECIES. Beeper implements it, I never got around to backporting it to pypush proper.

Also, the new Contact Key Verification (I believe it is the same thing as "key transparency" internally) should prevent the man-in-the-middle.

A lot of the things you mentioned can actually be solved on the pypush side: there's nothing preventing pypush from alerting you when a new key is inserted, or providing you with the fingerprints of each of the keys.

I'm not an expert on these things, but I do think it is time that another analysis by a proper cryptographer was done: the one you linked was from 2015, and a lot has changed since then.

Anyway, the point of iMessage is convenience, if we're being honest here. It provides a reasonable level of security that will keep out all but the most entrenched and determined attackers, and that's really all most people care about.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton