Hacker News Reader

Comment by justapassenger | Hacker News Reader

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).

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

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.

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.

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.)

> 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".

But the resulting output is automatically produced by an obfuscator. There's no creative human involvement in the process itself of how the obfuscated code came to be. Hell, the Copyright Office wrote extensive articles on why AI art can't be copyrighted.

Would you thereby claim (fwiw, you might, and you might even be right about it: I'm just trying to understand if you have a boundary) that extracting the underlying binary code and embedding it in this program with an emulator--instead of laundering it through rewriting the assembly instruction-by-instruction in Python--would be fair game?

If the binary code involved was only the machine code which dealt with the encryption algorithm itself and not any sort of functionality or sequence, then yes. Courts have placed the burden on the program's "structure, sequence and organization".

If one were to take a small sample out of a copyrighted binary which only implemented functionality and had no remains of the creative process behind it, I'd wager they would be in the clear.

That said, I feel like machine code copyrightability is questionable on its face. A packaged binary with resources and assets such as text would be, but the machine code itself is a more complicated issue. Admittedly this would jeopardize libraries, since they don't contain any expressive elements like interactive programs do.

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

If it was decompiled, that's not really reverse engineering though. So I'm not confident that the DMCA carve out would apply here.

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.

That's clearly "hacker true". I wonder if it's "lawyer true" as well? It could very well not be.

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

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)

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

Reply on news.ycombinator.com