|
Top-level
@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. 4 comments
@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. |
Gregory's Server
@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...