Gregory's Server@timac How are you detecting Swift in the Secure Enclave binaries? Those are nowadays using Embedded Swift, and there might not be the traditional "obvious" signs of Swift in those Mach-O binaries.
|
5 comments
@timac Aha, so previously you were using the presence of the Swift sections in the Mach-O header to detect Swift? You're right that those are gone with Embedded Swift, which doesn't use type metadata and generally compiles down to something much much closer to what C compilers would produce. Without symbols, it is probably pretty hard to reliably trace back whether the binary is coming from a Swift compiler or C compiler... @timac Though, that said, I can think of one pretty reliable way: If you dump the instructions (otool -xV) of an arm64e binary (SEP uses arm64e), and if you spot PAC sequences using the #0x6ae1 and #0xbbbf constants, then that's a very strong signal about the code being Swift. The constants are coming from this code in the Swift runtime: https://github.com/swiftlang/swift/blob/main/stdlib/public/SwiftShims/swift/shims/EmbeddedShims.h#L49,L60 @kubamracek I was indeed relying on the presence of the Swift sections to detect Swift in the SEP binaries. I just checked on macOS 15, and the sections are indeed missing in the hibernation binary. |
@kubamracek I was unable so far to find any artifacts to detect Embedded Swift. The Secure Enclave binaries are well-stripped, with no typical Mach-O sections. What surprised me, was the SEP app name with the '_swift' suffix.
I assumed that a SEP binary with the '_swift' suffix was built with Embedded Swift, but I could be wrong. It is also possible that the other binaries have been moved to Swift without using the "_swift" suffix.
In any case, I plan to experiment more with Embedded Swift.