- #How come someone hasnt hacked imessage for android how to#
- #How come someone hasnt hacked imessage for android code#
Tests only need to cover use cases the limited set of known clients actually need. They can be changed quickly, but clients have to be changed or and/or tested as well, so again the number of clients is limited. Private APIs can have a low, informal communication burden, but it tends to increase exponentially with the number of clients. They require more stringent security review and comprehensive tests, etc. They also have strict compatibility requirements that greatly slow, prevent, or complicate changes. Public APIs have a high communication burden, but "fixed cost" if done right - it shouldn't go up much as the number of users increases. There's a very significant difference between releasing an API publicly, and having a few internal users. Basically, I’m removing the attribution of malice I felt from the article.
#How come someone hasnt hacked imessage for android code#
Thus, at the moment I think Apple is preventing third-party clients of the type described just by virtue of the literal barrier of “this is a compiled blob that I need to interact with and I don’t have source to” rather than “Apple added obfuscation/prevents you from attaching a debugger/encrypts the code at rest with a Blowfish key that is undone when the kernel maps the process into memory” (all of which are things that Apple does actually do in cases where they half-care).
I say this because I know there is actual Apple-proprietary code that the company has actually put effort into obfuscating things like FairPlay (and closer to iMessage, IDS, though I have only heard rumors of the latter not having looked at it personally).
Ok, to distill my point: I think the author is going beyond a complaint that the system is proprietary and claiming that Apple has purposefully made the code difficult to reverse engineer, which I something I dispute based on the level that the author was working with, which were fairly standard (might I say comparatively well-packaged) private APIs.
#How come someone hasnt hacked imessage for android how to#
Some do venture into that realm (such as the author and I) and find meaning, but I disagree with the characterization that Apple is fighting against reverse engineers by making you dig through class-dump output and figure out how to marshal your arguments through the right function to make it do what you want. They're not Apple making it harder for you, they are just a side effect of how Apple writes its applications and the fact that the entire OS is proprietary. They're not meant to be linked against, they're undocumented, they change and disappear between releases…you really cannot complain about them. The rest of the stuff about private frameworks…I mean, I don't really know what to say. The iMessage team for macOS is already kinda eh, and it shows in the app's architecture and lack of new features for years, as well as its fairly strange usage of a web view (actually the long-deprecated one…) for the main content.
Really, it's one of the places where Hanlon's razor actually applies: the AppleScript bridge sucks because AppleScript in general sucks, as Apple has let it decay until it stops working entirely. Ok, so a comment on the actual content of the article rather than iMessage in general: I do the kinds of things that the author describes in the article (digging into private implementations of things) and I while I believe all of iMessage is a bit obfuscatory it's not nearly as bad as the author has described it.
0 kommentar(er)
