Archive for August 30, 2023

Wednesday, August 30, 2023

Analysis of Obfuscation Techniques Found in FairPlay

nicolodev (via Hacker News):

FairPlay comprises a set of algorithms created by Apple for digital rights management (also called DRM, digital rights management). FairPlay is currently used to manage the decryption of iOS applications during their installation on Apple devices. In fact, we know that Apple distributes all applications in the Apple Store through the IPA file format. The IPA file format contains encrypted information that will then be used by the operating system to install an application. All of the encrypted information is handled through FairPlay, which takes care of keeping the decryption key and the whole process secure to avoid the possibility of decrypting the contents of.ipa files to share the contents of an app (perhaps paid for) in the wrong hands.


If during processing, such as during decryption, a cryptographic algorithm performs a simple addition, it is possible to make the arithmetic expression more complex. […] I have already written in a previous post how to be able to create these expressions by applying transformation rules. The process Apple used is the same: take a constant from the code, rewrite the constant using arithmetic operators, and then apply the transformations. Do we already have an expression? We continue to apply the rules of transformations. Note that only some transformations can be applied since they do not change the semantics of the original expression. At the end of the process, the expression is translated back into machine language so that it can be reinserted within the binary.


Opaque predicates are another very “cheap” technique for introducing obfuscation within instructions. This technique consists of introducing some always true or always false conditions that cause the decompiler to explore blocks of instructions with zero utility. The always true or always false conditions include a direct or indirect jump to basic blocks that will never be executed: they do not present additional functionality, they only add complexity to the functions being analyzed.


Very subtly the stack is moved up (or down, depending on how you want to build the stack).


We can then see how the basic blocks have all been brought to the same de facto level by horizontally extending the graph of basic blocks. The case of control flow flattening taken to the extreme drives the analyst crazy[…]


If you are wondering how Apple obfuscate its software, the answer is simple: they built some extensions for LLVM that applies code transformation directly to LLVM IR.


I’m gonna go out on a limb and suggest that this obfuscation scheme is legacy, and they keep it merely as defense in depth and because it’s tested so why not.

Modern Macs can do remote attestations from a trusted boot chain all the way up to specific apps, which obviates the need for this sort of obfuscation. The memory spaces will be protected by the operating system as long as SIP is enabled, and if it’s not enabled or has been disabled / the root partition has been modified, then that will be detectable by Apple remotely. Although code obfuscation is fun (I’ve built a virtualization based obfuscation in the past), a properly implemented remote attestation and security architecture does obsolete it. It’s therefore mostly useful on Windows/Linux PCs where these schemes don’t really hang together.


Premature Optimization: Universally Misunderstood

Milen Dzhumerov (Mastodon):

It has been commonly interpreted as “don’t think about performance in the beginning, you can fix any performance problem later”. This interpretation is completely and categorically wrong.


With the additional context, the quote takes on a significantly different meaning: it’s making a statement only about micro-optimisations ("small efficiencies"), not about performance in general.

Hoare was simply advising against micro-optimisations without finding the hotspots first: the “premature” part refers to lacking measurements.


As tech stack fundamentals, access patterns, data dependencies and data structures are baked into a design, it’s not possible to hotspot your way out of a slow architecture.


No App, No Entry

Andrew Anthony (via Hacker News):

Leaving aside the “sorry, not sorry” expression of regret, the presumption is that the elderly remain vigilant to every missive from the online world, when in fact many find it a jungle of scams, junk mail, endless passwords and security risks into which they venture as little as possible.


Citing the Jaffes, the historian and TV presenter Amanda Vickery noted in a series of outraged tweets last week that “most car parks now don’t take cash, ticket offices are disappearing. If you are not tech-savvy you are toast. It is so exclusionary.”

The real cause of Vickery’s ire, however, was a breast cancer clinic she attended that, in her words, turned away “some old ladies … because they did not have an SMS message from an app.


There are also an estimated to be 1.3 million adults in this country who are “unbanked” – ie do not have a bank account. For them, something as mundane as parking a car is increasingly fraught – a quarter of London councils have removed pay and display parking machines in favour of smartphone-centred apps.

Even if you do have a smartphone, it’s not great to have it be a single point of failure. It could be lost, stolen, away from cell service, or have a low battery. Most electronic tickets and admission passes don’t seem to work with the Wallet app, and who knows whether an e-mail, app, or Web link will fail when you need it, even if it was cached. A common pattern is to take a screenshot of the barcode or QR code, but that requires more tech-savvy.


What frustrates me is how fragile this can quickly become.

I recently was traveling with my 7 year old daughter on public transit, and her card was denied… something was wrong with the ‘kids free travel’ product loaded on her card. Since her card is actually issued by a train company, I had to login to their website. Since I hadn’t logged into their site (as her) in a while, I had to verify my account with a password reset link. The site then sends a create password link to HER email (they would not let me use my email since I was already a user), which I had also not used in a while, so I needed to answer some security questions. The email was severely delayed so cue lots of refreshing.


Thankfully it was a long bus ride but the driver was clear I would need to pay if I couldn’t arrange it. This is all totally insane as kids ride free and you don’t need an RFID card to see that at 7 year old is under 14. And the worst part is that since it’s a bus pass loaded on a train card linked to an email address you need to access on your mobile phone… there is just no accountability.

A similar event happened when my bank just decided I couldn’t login since I accidentally used a VPN once, with no error message. Congrats, you won the lottery, you get to play the 3 hour call support game.

Update (2023-08-31): John Gordon:

I last wrote about “mass disability” and the Left Behind in a 2021 post. The concept has sometimes seemed on the edge of going mainstream but it’s never quite made it. Maybe we’re getting closer; a recent Michael Tsai post (No App, No entry) reminded me of my Mastodon thread from a few weeks ago[…]

Update (2023-09-04): Naveen Arunachalam (via Hacker News):

One day, I was so insistent on doing my laundry without a smartphone that I even considered doing my laundry off-campus so that I could avoid having to deal with Washlava. So imagine my surprise when I learned that Washlava indeed does provide an option for users without a phone. You can actually check out an iPod Touch, generously provided by Washlava and SidPac, to open the Washlava app and perform your laundry.


As it turns out, I was the first person in SidPac history to request the procurement of this device. When Andrea finally found the abandoned relic, she dreadfully noted that the Laundry Pod was out of battery.


When the Laundry Pod finally gained consciousness, little did I expect to encounter yet another challenge: a password screen. After a couple failed attempts to guess the password, I admitted defeat and dejectedly retreated to the front desk to request the password.


My next hurdle was logging into Washlava. When I first made my Washlava account, I had used my personal gmail and a temporary password that I intended to change later. My Android had always logged me in automatically after that, so I never got around to changing my password and never had to log in after the first time. Thus, lacking practice in the art of presenting my credentials to Washlava, I found that I was unable to log in.


As I made one last-ditch attempt to guess my password, I decided it was time to press the sacred button of last resort. Unfortunately, this turned out to be futile: on the iPod Touch, the keyboard cannot be retracted to uncover the “Forgot Password” text, meaning that it is effectively impossible to click it.


One significant problem with making your hardware dependent on an app is that if you are a washing machine company, you probably don’t make mobile apps. So, you hire a contractor. They design an app without any expertise in the product or the domain, and program it on the cheap. It is trash. Later, the contractor goes out of business and you give the code to another contractor. They notice that the code is garbage, and not even garbage that somebody there made. Feature work is impossible, the app languishes. 1.5 stars in the app store. Every time there’s an iOS update, people can’t do their laundry for a couple weeks, until the one programmer working half time on the app can push an update. Later, you (the washing machine company) decide to sunset that product line, which means there’s no updates to the app. iOS changes, the app stops working altogether, everybody has to buy a new washing machine.

I’ve been that contractor, which is why I will never be the owner of an appliance that requires an app to function.