New (probably unsafe) binary digest

[federicotorrielli]

@mahee96

I noticed this was introduced in commit 02b41c2, with defaultODAMetadataURL pointing to https://zzz.haus/oda.json, which distributes libCoreADI.so and libstoreservicescore.so.

I checked the bundled binaries: libCoreADI.so is byte identical to the copy in the Apple signed Apple Music 6.5.2 APK, and libstoreservicescore.so also matches known Apple Music copies.

Could you clarify why these authentication related executable libraries are served from that domain instead of an Apple controlled source? It would also seem safer to verify them against a pinned hash or other trusted signature before use.

[mahee96]

because sidestore doesn't want to be distributor of apple libs...we will be removing these too maybe in future and will ask user to unpack and prepare the libs for which ss team can provide a script or something...

but basically these features are in testing for now. by next release it should have been settled.

also there are lots of things going on, once we have slowed down and stabilized we can better take these things up.

[mahee96]

asking users to follow new procedure rn, when things are in flux is gonna be a long shot to educate all, so stay tuned for updates...once we are near ready, we will be cleaning this up.

[federicotorrielli]

Thank you for the answer! However, keep in mind that I find that to be a shaky argument against safety of a lot of devices :)
The 0.6.4 prerelease has ODA on by default. Therefore the app downloads libCoreADI.so and libstoreservicescore.so from zzz.haus for every user who keeps the default setting.

1. Checking again (more carefully), the s value in oda.json does not match the payload. Also, a hash from the same server as the payload cannot detect a change on that server.
2. The selected anisette server list can also supply the payload through the oda key (https://github.com/SideStore/SideSign/blob/7f818429fec3c8d7b63871b8bfdf063603cd2115/Sources/Anisette/AnisetteDataManager.swift#L556-L589). Therefore the owner of that list can replace the libraries.

By the way, who operates zzz.haus? Is it you? Do you trust them?

I suggest that the app stores the SHA-256 of each .so file as a constant. The app must stop with an error when a file does not match. A hash of an Apple file does not make SideStore a distributor of that file. The same check also works for the future flow, where users prepare the libraries themselves.

[federicotorrielli]

@mahee96

[nythepegasus]

Yes, this is a new system so we needed a quick spot to place it and a simple concept to get it going. I personally own and operate that domain so no worries there. We definitely plan to get it much more fleshed out and appreciate your suggestions!