"""
GPLv2
Python implementation by systemcrash 2022
Original C implementation of OmgHax by (credit to original author and Foxsen)
If you want this to work, don't touch anything. It's a steaming hot
rats nest of crypto mess which works. It's quite performant.
Resist the urge to refactor. :)
Avoid +=, -=, ^= etc operators in Garble: they don't account for overflow.
"""
before going into lovely detail, containing lines (e.g. in a method appropriately called Garble) such as
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.
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.
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.
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
>> 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
& 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*)
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.
What I really want is for someone to crack the Sonos S1 protocol — the one that allows for low-latency P2P sharing - and then to use one of these Airplay 2 bridges with it. Right now the best I can do is to pipe an icecast stream to one which adds seconds of latency. That would allow my older S1 Sonos gear (which I spent thousands on) to have basically unlimited life.
Low latency, linkplay, HTTP API, you can join multiple of them together for whole home audio. Integrates into Home Assistant. Can play random URLs, can play spotify, airplay, etc. Wifi, ethernet, bluetooth.
By far the best product I've found. What I like the most is that it plays whatever I throw at it and I can turn any speaker into a smart speaker. It's also all local.
You should check the connections it makes. From the review of a sister product:
“Now for the bad news. In the last 24 hours my network security blocked: 6,936 calls to AMS ("The Cloud"); 9,523 calls to s000.linkplay.com, 6,050 calls to www.yahoo.com; 6,050 calls to www.microsoft.com; 9,650 calls to Amazon Technologies; 6,049 calls to Aliyun Computing - Beijing China;3,468 calls to Google; That was 94% of the attempted connections outside of LAN.”
That makes zero sense to anyone who’s ever worked on hosting things in China.
Their Great Firewall makes it a no-go for practically everything and everyone. At the best of times the latency and packet loss are hideous, with abysmal throughput. And then you get cut off randomly for hours, days, or decades at a time on the whim of random CCP members with no recourse.
Paying them is a giant pain in the arse as well.
It is quite literally never the best option.
Hosting sites in Russian — in the middle the current war — would make more sense!
If you're in the western world, you really should consider avoiding IoT devices that call home to Chinese servers. You could be turning yourself into a potential botnet member if things go geopolitically sideways by keeping these products on your network. If you have access to other networks from home, you're inviting access into those networks from a box that should only be there for streaming music.
Better if things don't call home at all, but second best is choosing western servers under control of western actors.
I hope that one day we no longer have to consider the political origin of servers our devices to call back to, but that's a few years away at least. In the meantime, devices that call back to noone are still the best.
Apparently those requests weren’t necessary for using the device, so arguably it shouldn’t do them without user consent in the first place, and certainly not retrying multi-thousand times per day. It just shows that data economy and privacy wasn’t a design consideration of the software, which should be a red flag.
2.1 systems generally use powered subs, not passive subs.
For use with higher-quality bookshelf speakers, you can send the stereo line level signal to a 2-channel amp and pass the high-level speaker lines through your sub. I do this with Belkin AirPlay 2 receivers and it works well.
> That would allow my older S1 Sonos gear (which I spent thousands on) to have basically unlimited life
2 years ago, I bought some used Yamaha (not "smart") speakers and AVR. They are 8 years old now and work flawlessly. My solution to making them "smart" was to just Cast to my Android TV that's plugged into the AVR.
That entire set up cost me <$200 and has no end in sight with a very clean upgrade path. It's unfortunate that so much modern hardware is paperweight in a few years just because the company can't be bothered to maintain the software.
In my experience AirPlay equipped receivers are also a pretty decent bet for long term support. My receiver is a 7 year old midrange Marantz model and its AirPlay has always worked great. It still gets software updates occasionally too which is nice. If I upgrade it’ll be due to changing HDMI standards (it can’t handle high framerate 4K video), not protocol support.
As I understand Airport Express models from the 2000s still work with AirPlay from modern Apple devices too, though I don’t own any and can’t vouch for them personally.
AirPlay 1 doesn't have the nice multi-room audio support that AirPlay 2 does. It only has a much hackier version that works from iTunes, but not from your iPhone's media controller.
But if you only ever want to play to 1 device, then you're set.
The 3rd generation AirPort Express (A1392; the flat/non-wall wart 2012 version) supports AirPlay 2. All generations of the AirPort Express also have a mini-TOSLINK output allowing for a pure digital audio stream from the source to the receiver/amplifier.
While probably not an ideal solution for the parent poster, who understandably wants to make things work with their existing Sonos gear, the A1392 is an outstanding value at this point because there are absolute truckloads of them on eBay for ~$20.
Assuming you're okay with AirPlay (which, admittedly, rules a lot of HN folks out) this is a $20-per-room device that gives you full lossless multiroom streaming including your choice of analog or optical out. Really great.
I have two Chromecast Audio devices which similarly provide both analogue and optical digital outputs, but they seem to be much more expensive second hand than the Airplay alternative.
Shame there’s nothing similar for video airplay. I needed to add airplay to an old/cheap dumb tv just for apple fitness in my partner’s workout room, and the only cost-sensible thing was an ad-infested roku device.
I had a 3rd gen Apple TV, but it had grown nearly unusably buggy. Still-supported apps would randomly crash or fail to stream, AirPlay would randomly fail entirely or fail to play video, streams/AirPlay would randomly stop, various operations would randomly take minutes to complete or time out.
Not only would that require me to buy an AirPort Express per speaker, many Sonos speakers don’t have an audio in jack. Thus my desire to bridge this purely in software.
It’s a bit janky for what you want do to, but if you have any Sonos S1 device with an input, you should be able to group that device with whatever other speakers you want playing the audio input. (And if that input device is a speaker that you don’t want playing, you can turn the volume all the way down.)
If the receiver is turned off, do you ever have to try multiple times (2-3) to wake and begin playing music via Airplay? I'm sure my slimline Marantz is just misconfigured.
I haven't had that trouble, but I have found that mine (NR1606 model) is more fussy about things like that when it's on WiFi. It definitely "prefers" to be on hardwired ethernet.
FYI my ~9y/o marantz is also hardwired, but I cannot get airplay to work unless I explicitly go to Net/USB and even then it's the same 2-3 attempt (switching inputs) to get the device to appear on the airplay list. After that it's flawless, but the UX pretty much means I'm the only one airplaying to that device. I have since upgraded 3 years ago to a newer slimline model and that has no problem being found regardless of the input used and regardless of wifi/ethernet.
My friend with a ~5 year old denon also has no problem. So possible this is a discontinued firmware issue. YMMV
Yup. Happens a lot with my Denon. It also likes to disconnect a lot, while my TV (right above it) is streaming YouTube at the same time with no problem.
My issue is less that it drops connection (seems pretty solid once I have music playing), but that the initial connection can take several tries.
My guess is that when the receiver is awoken by Airplay, it is then attempting to connect to the “Last Used” input (or something) which disconnects Airplay.
> because the company can't be bothered to maintain the software.
Ironically (considering that you're using Yamaha) their MusicCast system have had a reasonable lifespan (seven years on the third generation, although they no longer support their 2003 stuff).
But yes, I'm looking at dabbling with HifiBerry (https://www.hifiberry.com/) for streaming duties for my older stereo gear.
Sonos has done a pretty decent job at keeping hardware alive. IIRC they still have S1 products alive but created S2 in the last few years because people wanted new features that required more CPU than their old devices could handle.
They still maintain an old S1 app for older devices and I think those devices should still all work. I don’t think there’s a plan to “turn them off”. A lack of new features is something that may or may not be a problem.
Actually, I think audio companies in general have been pretty good about keeping products alive. Even the old Amazon Echo Gen 1 I think still works… and that’s a full-on smart device that exists for the smarts not the audio quality.
The problem here is the wildly different expectations. It's an audio system, and normally audio systems are expected to work for >30 years. But it's a "smart" system controlled through an app, and apps need to be maintained to keep working on new hardware.
Yea I agree. I personally still come to the conclusion that it’s probably worth it assuming the business continues to operate as they have been. But eWaste does suck to generate knowingly.
I have a record player (and DAC) and an amp and passive speakers. I have the full HiFi setup - the record player is setup to avoid vibrations and the speakers are properly distanced from the wall etc. I can tell you without any hesitation that the price-per-minute-listened of my Sonos system is a small fraction of the HiFi (which will last 30 years). If I upgrade the Sonos every decade I’m sure it’ll still “make sense”. That’s excluding the cost of media for which records cost a lot more than streaming. Personally, I think the Sonos sound “more than good enough” to enjoy without missing anything from the record player.
That said, I don’t love the generation of eWaste, and I hope the Sonos lasts for more than a decade. And every day that Amazon/google keep their smart speakers alive is a good day for eWaste. I can only dream they’ll allow you to update the firmware when they finally EOL them. (I know they won’t though).
And that audio URI is then an ice cast with seconds of latency. This is different for the protocol that the speakers use to pipe audio to each other which is near real time.
It might not be as realtime as you think, especially if it's buffered. You just need to sync timestamps and buffer for at least the slack in your system. I wouldn't be surprised if it was using NTP/PTP under the hood to sync up system clock time and then just playing back a buffer that's shared across all speakers (or just the channel for that speaker with a timestamp). The actual audio transfer probably gets buffered and only the relative timestamp and simple instructions like "play from this timestamp in the buffer" is actually being used to sync up between speakers. It's probably a limitation of the hardware or the lower-level wireless protocol (bluetooth or wifi) that causes that delay. I'm just speculating though, all of my realtime experience is in hard-realtime scientific control systems.
If you have a Sonos amp with an input plug, you can play that in near real time. There isn’t much buffering there. It’s low enough latency you can watch video and the lips looks like they match. There’s actually a setting where you can tell it the priority of the audio, which I assume just controls the buffer size.
It's probably a mixture of things. Just tried some of mine with the sonos app and there's always a slight 1-2s delay on play and seeking. But actions like pausing or adjusting the volume are instant. I can pump the volume slider in tempo with the music and there has to be only a few ms of latency.
I'd hope so. One of those things (initiating music playback or seeking outside of the playback buffer) involves realtime sequential data transmission, and the other (modifying local settings or playback state remotely without leaving the buffer) is just a byte or two in a packet, if that.
This is amazing! For many years, I've been a happy customer (no other affiliation) of Rogue Amoeba, whose (closed-source, commercial) Airfoil software: https://rogueamoeba.com/airfoil/mac/ does all this & more (MacOS and iOS only). I've had a multi room audio setup with Airport Expresses and dumb powered M-Audio bookshelf speakers for the past 10 years going strong!
I love this project, but for folks who use MacOS and want something that simply works, I can't recommend Airfoil highly enough.
> Can Airfoil Satellite receive AirPlay 2 audio? Airfoil Satellite receives audio via the AirPlay 1 protocol. Because of this, it can’t currently be part of a multi-speaker group receiving audio from iOS.
Still a great piece of software (that I also can recommend).
Adding on, the AirPlay 2 implementation by Shairport-sync works very well. I have approximately 6 different Rpis/thin clients around the house I use as AirPlay 2 receivers and can vouch for how well the system works. NQPTP is built by the same team.
shairport-sync also has the option to output to FIFO/stdout, which I couldn't see details of in this Open AirPlay 2 implementation. Indispensable for tying in to SnapCast!
I don't know they did it. But one approach I (badly) tried was to use the firmware image for the old AirPort Express that got AirPlay 2 support.
Someone had already extracted the key which was used to encrypt the firmware, so you could download the firmware from Apple and look at the unencrypted firmware blob.
Perhaps even boot it using something like QEMU? But I never got anywhere with that...
That's the point of all these TPM chips/subprocessors Apple and Microsoft are sticking into their computers. The key can stay on the TPM chip which does the decrpytion
I've been using shairport-sync to receive audio from my iPad while working. It has proven a really convenient means to turn my iPad into a 2nd display for watching videos. I've been wanting to use this on Windows as well but had no luck getting sound to work with WSL last time I tried.
This new app looks like a promising cross-platform replacement.
For all the audiophiles out there, M1 Mac Mini is an incredible digital player. You can basically play lossless audio over iTune/Apple Music and it’s well-integrated with the rest of the Apple ecosystem.
I’m having a great time with my Apple TV 4K -> Topping E30 -> Aiyima A07 -> Wharfedale 4.1s. Only thing lacking is more power/bass but I can’t get past 2/10 volume without annoying the neighbours anyway.
This is why I will replace my phone with an iPhone. The chromecast protocols are so locked down, it makes casting really suck, and chromecast audio pucks are no more.
Chromecast works differently. Casting something causes the receiving device to load a web app that then plays whatever you were playing. Yes, that tiny thing actually runs a cut-down version of Chrome OS. In other words, it's not merely an audio/video streaming protocol. Your phone/computer acts as a remote, and it's the Chromecast itself that does the streaming.
That's only for apps that support doing that, though, like Netflix, YouTube, Spotify, Twitch, etc. If you're casting a game or something that's local content, then it will obviously still stream it directly.
Aside from specialty DoD-type phones, iPhones (and Apple devices in general) are the most locked down devices on the market. You can't even install an open source app without going through hoops. On Android you download the APK and click the "accept risk" button.
