7 ms·

This looks like someone decompiling Apple's code and basically putting output of that into their project. This method can have some legal risk attached to it (

This looks like someone decompiling Apple's code and basically putting output of that into their project. This method can have some legal risk attached to it (INAL).

joshspankit 4y ago
Are you saying that because you have knowledge of Apple’s code?
- sandermvanvliet 4y ago
  This is generally how you’d make this kind of encryption/decryption work for apps that don’t have documented/open interfaces. In fact, it’s what I’ve done to reverse engineer the encryption for Zwift for example (and a ton of other apps)
- baobob 4y ago
  No knowledge of Apple's code here, but looks like they simply gave up trying to reformat decompiler/disassembler output in that Garble class. Humans don't write code like that, optimizers do
marcodiego 4y ago
AFAIK, DMCA allows reverse engineering for compatibility purposes. IANAL, though.
- jhy 4y ago
  If it was decompiled, that's not really reverse engineering though. So I'm not confident that the DMCA carve out would apply here.
  - thamer 4y ago
    Decompilation is very much part of reverse engineering. The two are not the same, but disassembling and decompiling code are extremely common techniques used to reverse engineer a program, algorithm, or protocol.
    - bigiain 4y ago
      That's clearly "hacker true". I wonder if it's "lawyer true" as well? It could very well not be.
EMIRELADERO 4y ago
Algorithms alone don't cross the threshold for copyrightability, and code which only implements those (specially non-creatively as seen here) is not copyrightable.
- nl 4y ago
  It's true that algorithms alone don't cross the threshold for copyrightability, but just decompiling copyright code and using that is extremely risky. The carve-outs for interoperability might be useful here though.
  - ascagnel_ 4y ago
    On other hand, there are no carve-outs for DRM, so this could still run afoul of that if it supports DRM'd playback. Edit: this explicitly does not support FairPlay DRM'd playback, so the lack of DRM carve-outs shouldn't matter, as awful as the lack of carve-outs is.
- saurik 4y ago
  FWIW, on the "non-creatively" angle, this is almost certainly some really simple algorithm that only looks really complicated as this is a direct translation of the obfuscated binary, and so I'm not sure you can analyze it using so simple a framework. (Apple uses an obfuscation technique that converts functions into massive switch loops, threading a control variable through on which math is done to figure out the next block of code to switch-jump through; they then use a duality between the bitwise logic and algebraic rings to turn what might be one instruction into five instructions in a different order, and often broken up by the inverted looping. I believe--but am not sure, as most of my knowledge of this stuff is from trailblazing myself over the years... I wrote the first decompiler for .NET a couple decades ago and have done a lot of work in the iPhone jailbreaking ecosystem on static analysis and runtime modification--that the literature-searchable terms for these are "parameterized control flow flattening" and "mixed-boolean-arithmetic".) So like, in some sense, this is not at all how someone else who understands how the algorithm works would implement it: it isn't like "oh yeah, there's one semi-obvious way to do it, and I did it that way", and one might definitely argue this is "creative". (I've personally avoided ever just copying and redistributing--even in translated form--logic from Apple like this, and that's part of the reason. It might still be OK, due to some fair use -styled exemptions relating to software interoperability, but the only ones I explicitly know about are with relation to reverse engineering to obtain that interop, not the part where you directly copy the resulting logic instruction-by-instruction.)

This looks like someone decompiling Apple's code and basically putting output of that into their project. This method can have some legal risk attached to it (INAL).

joshspankit 4y ago

Are you saying that because you have knowledge of Apple’s code?

sandermvanvliet 4y ago
This is generally how you’d make this kind of encryption/decryption work for apps that don’t have documented/open interfaces. In fact, it’s what I’ve done to reverse engineer the encryption for Zwift for example (and a ton of other apps)
baobob 4y ago
No knowledge of Apple's code here, but looks like they simply gave up trying to reformat decompiler/disassembler output in that Garble class. Humans don't write code like that, optimizers do

marcodiego 4y ago

AFAIK, DMCA allows reverse engineering for compatibility purposes. IANAL, though.

jhy 4y ago
If it was decompiled, that's not really reverse engineering though. So I'm not confident that the DMCA carve out would apply here.
- thamer 4y ago
  Decompilation is very much part of reverse engineering. The two are not the same, but disassembling and decompiling code are extremely common techniques used to reverse engineer a program, algorithm, or protocol.
  - bigiain 4y ago
    That's clearly "hacker true". I wonder if it's "lawyer true" as well? It could very well not be.

EMIRELADERO 4y ago

Algorithms alone don't cross the threshold for copyrightability, and code which only implements those (specially non-creatively as seen here) is not copyrightable.

nl 4y ago
It's true that algorithms alone don't cross the threshold for copyrightability, but just decompiling copyright code and using that is extremely risky. The carve-outs for interoperability might be useful here though.
- ascagnel_ 4y ago
  On other hand, there are no carve-outs for DRM, so this could still run afoul of that if it supports DRM'd playback. Edit: this explicitly does not support FairPlay DRM'd playback, so the lack of DRM carve-outs shouldn't matter, as awful as the lack of carve-outs is.
saurik 4y ago
FWIW, on the "non-creatively" angle, this is almost certainly some really simple algorithm that only looks really complicated as this is a direct translation of the obfuscated binary, and so I'm not sure you can analyze it using so simple a framework. (Apple uses an obfuscation technique that converts functions into massive switch loops, threading a control variable through on which math is done to figure out the next block of code to switch-jump through; they then use a duality between the bitwise logic and algebraic rings to turn what might be one instruction into five instructions in a different order, and often broken up by the inverted looping. I believe--but am not sure, as most of my knowledge of this stuff is from trailblazing myself over the years... I wrote the first decompiler for .NET a couple decades ago and have done a lot of work in the iPhone jailbreaking ecosystem on static analysis and runtime modification--that the literature-searchable terms for these are "parameterized control flow flattening" and "mixed-boolean-arithmetic".) So like, in some sense, this is not at all how someone else who understands how the algorithm works would implement it: it isn't like "oh yeah, there's one semi-obvious way to do it, and I did it that way", and one might definitely argue this is "creative". (I've personally avoided ever just copying and redistributing--even in translated form--logic from Apple like this, and that's part of the reason. It might still be OK, due to some fair use -styled exemptions relating to software interoperability, but the only ones I explicitly know about are with relation to reverse engineering to obtain that interop, not the part where you directly copy the resulting logic instruction-by-instruction.)