4 ms·
The app is not redistributing it, it just requests a server to get validation data (since anyway the actual library loading involves patching every system funct
by dadoum 3y ago
The app is not redistributing it, it just requests a server to get validation data (since anyway the actual library loading involves patching every system function, making the function independent from the host device, see [0] if you want to see how it's stubbed to run on Linux using a data.plist file), and thus there is no need to emulate it on device.
[0]: https://github.com/Dadoum/imd-apple-services https://github.com/Dadoum/imd-apple-services
- Eriksrocks 3y agoMy (very limited) understanding is that this "validation data" is related to the certificate generation (see [0]). So if the app isn't emulating this on device, and instead calling out to a Beeper server that is hosting the Apple binary, is this a potential security risk? Is it possible to use the data that gets sent off device to derive the client encryption key? If so, that would be a huge security hole in this implementation, completely negating their claim of maintaining secure E2E encryption. [0]: https://www.reddit.com/r/beeper/comments/18duom1/is_beeper_mini_broken/kck3ltu/ https://www.reddit.com/r/beeper/comments/18duom1/is_beeper_m...
- dadoum 3y agoI didn't implement all the IDS stuff, but I am pretty sure the certificate is not used at all to derive keys for anything related to iMessage. I think it is used to attest that the device running it is running Apple software, and it may generate keys to make that an identifier to Apple (probably also because the user may not have any Apple account, so they have to generate another identifier for that purpose).