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.

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.

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.

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

It is result of decompilation/disassembling Apple's binaries. I have done this in past. Apple uses some sort of thirdparty whitebox crypto and code obfuscation tool, that hides underlying algorithm into a mess. Underlying algorithm is typically very simple, and standard crypto.

That file is intense… seems like half of it is a declaration of a list with a BUNCH of hex addresses. I don’t know anything about crypto so no idea if that’s fairly typical or not.

This file is also interesting: https://github.com/openairplay/airplay2-receiver/blob/master...

In particular:

AIRPORT_PRIVATE_KEY = ( "-----BEGIN RSA PRIVATE KEY-----\n" "MIIEpQIBAAKCAQEA5..."

Is that intentional? Surely it is, being a public repo, etc.

Looks like that same key is found elsewhere on the web, so I assume it's intentional:

[1] https://www.theiphonewiki.com/wiki/AirPlay

[2] https://www.google.com/search?q=MIIEpQIBAAKCAQEA59dE8qLieIts...

That is a key that someone extracted from an Apple Airport Express back in 2011: https://mafipulation.org/blagoblig/reversing/index.html#shai...

The iTunes key was found by DVD Jon. The Airport Express key was found by James Laird. https://en.wikipedia.org/wiki/Remote_Audio_Output_Protocol

I wonder if the intentionally obtuse and custom cryptography is a form of DRM.

With DRM, since the data itself isn't secret (in fact you want to decode it at the end so you can play the media), the strength of the cryptography itself doesn't matter and the objective is to frustrate and slow down any reverse-engineering attempts, so homebrew cryptography may actually make sense here as to prevent usage of any common cryptographic libraries and force the reverse-engineers to implement it from scratch.

There are two lists buffer1 and buffer4. So these two lines assign a value to the 16th item in buffer1 and prints it with its hex value. The value is determined by arithmetic and bitwise operations.

For example, if buffer1[72]=107343, buffer1[190] = 25, and buffer[4]=18 (buffer1[72] >> (buffer4[buffer1[190] % 21] & 7)) (buffer1[72] >> (buffer4[25 % 21] & 7)) (buffer1[72] >> (buffer4[4] & 7)) (buffer1[72] >> (18 & 7)) (107343 >> 10) 104

https://docs.python.org/3/reference/expressions.html#shiftin...

  >> and << operators accept integers as arguments. They shift the first argument to the left or right by the number of bits given by the second argument 
  i = 14; // Bit pattern 00001110
  j = i >> 1; // here we have the bit pattern shifted by 1 thus we get 00000111 = 7 which is 14/2

https://docs.python.org/3/reference/expressions.html#binary-...

  & operator yields the bitwise AND of its arguments (*If both bits are 1, the corresponding result bit is set to 1. Otherwise, the corresponding result bit is set to 0. so 1100 & 1010 is 1000*)
  ^ operator yields the bitwise XOR (exclusive OR) of its arguments (*so 0101 ^ 1111 is 1010*)

https://docs.python.org/3/tutorial/inputoutput.html#fancier-...

  To use formatted string literals, begin a string with f or F before the opening quotation mark or triple quotation mark. Inside this string, you can write a Python expression between { and } characters that can refer to variables or literal values.

Bitwise examples from:

https://en.wikipedia.org/wiki/Bitwise_operations_in_C

https://docs.microsoft.com/en-us/cpp/cpp/bitwise-exclusive-o...