Archive for May 26, 2022

Thursday, May 26, 2022

Code Injection with Dyld Interposing

Noah Martin:

Swizzling handles Objective-C methods, but cannot be used for C/C++ functions. Non-Obj-C lower level calls can be useful for reverse engineering iOS apps, but sometimes you need to intercept them in an app that you don’t have the source code for.

In this post we’ll be looking at a lesser known technique for injecting code at a function call, one that works with C/C++ functions and with unmodified app binaries.

Peter Steinberger:

As of macOS 10.15.4, text input in Mac Catalyst apps sometimes crashes. I’ve noticed this a lot in Twitter for Mac, however, we also saw crash reports for PDF Viewer for Mac. My hope was Apple would fix this in 10.15.5, but now the release is out and things are still crashing, so let’s fix this ourselves.


Swift @_assemblyVision

Karl (via Ron Avitzur):

There is a super-hidden feature in the compiler which gives you insight in to all kinds of optimisation decisions: such as the cost-benefit calculations for inlining, where exclusivity is enforced, where ARC operations happen, which generic specialisations get generated and which calls get devirtualised.


To use it, add the @_assemblyVision attribute to a function, and build in release mode (or @_semantics("optremark") on a pre-5.6 compiler.


The first is called opt remarks. “opt remarks” shows the decisions the optimizer is making (e.x.: did I specialize this, did I inline this/etc).

The second is something that I invented called “Assembly Vision”. This is the thing that is telling you where the ARC/exclusivity checks/runtime casts. Assembly Vision also enables the other form of normal opt-remarks since that information can be useful when determining where/why ARC is there. The idea is to make it so that instead of having to read the assembly, one can have vision on approximately where these calls are so you don’t have to read the assembly yourself.


The concept came from me trying to automate how I optimize Swift code as a compiler engineer so that other engineers who aren’t compiler people can be just as effective.

This looks incredibly useful.


DOJ Will No Longer Charge Security Researchers

Adi Robertson (in June 2021):

The Computer Fraud and Abuse Act (CFAA), a controversial anti-hacking law which bans “exceeding authorized access” on a computer system, was narrowed by the Supreme Court on Thursday in a 6-3 ruling. The court said the law shouldn’t cover people misusing systems they’re allowed to access — and that claiming otherwise would criminalize a “breathtaking amount” of everyday computer use.

Department of Justice (via Bruce Schneier):

The Department of Justice today announced the revision of its policy regarding charging violations of the Computer Fraud and Abuse Act (CFAA).

The policy for the first time directs that good-faith security research should not be charged. Good faith security research means accessing a computer solely for purposes of good-faith testing, investigation, and/or correction of a security flaw or vulnerability, where such activity is carried out in a manner designed to avoid any harm to individuals or the public, and where the information derived from the activity is used primarily to promote the security or safety of the class of devices, machines, or online services to which the accessed computer belongs, or those who use such devices, machines, or online services.


So they’re saying security research actually is A Crime under CFAA, but they just promise they won’t go after you for committing that Crime, right?

Doesn’t give me a warm and fuzzy feeling…


No, that’s not correct. The policy memo is a straightforward, good-faith instruction to USAs not to prosecute certain categories of potential CFAA cases because (a) SCOTUS’s new Van Buren precedent says they do not fit within the CFAA, or (b) they are near enough to Van Buren that, if called upon to resolve such a case, courts would likely say they do not fit within the CFAA, or (c) even if a court could maybe be convinced not to dismiss the case under Van Buren, such a prosecution wouldn’t serve to vindicate the government’s interest in “promot[ing] privacy and cybersecurity by upholding the legal right of individuals, network owners, operators, and other persons to ensure the confidentiality, integrity, and availability of information stored in their information systems.”

Will Disk Utility Ever Work Properly?

Howard Oakley:

When Apple developed APFS, it decided neither to make it open source, nor to document it sufficiently to help third parties develop their own utilities for its maintenance. In doing so, it made a commitment to its users that Apple itself would provide all the tools necessary to work with its new file system. After all, any file system without sufficient tools to check, repair and maintain it isn’t fit for release, is it?

Disk Utility and its command line check and repair tool fsck_apfs are thus among the most important utilities in the whole of macOS. While there are several excellent alternatives which can perform the same tasks on HFS+ volumes, Apple’s policies on APFS have successfully locked all competition out of this market. Yet, over five years after the new file system’s release on 27 March 2017, Disk Utility is still riddled with bugs, and can’t check or repair disks containing Time Machine backups unless the Mac is booted in Recovery Mode, or without resorting to skulduggery with hidden snapshots.

See also: AskDifferent, Should you trust Disk Utility’s First Aid or fsck?.