5 ms·

I worked on the Xcode team for years and know the lengths Apple goes to make this stuff difficult to figure out. I just wanted to say that you’ve done an excel

I worked on the Xcode team for years and know the lengths Apple goes to make this stuff difficult to figure out. I just wanted to say that you’ve done an excellent job and am looking forward to the 3rd installment.

RetpolineDrama 8mo ago
>I worked on the Xcode team for years Why did you guys remove the ability to detach the console and move it to another window?
- estimator7292 8mo ago
  [flagged]
tiffanyh 8mo ago
Would you mind explaining more. “Difficult” because of lack of documentation? Or difficult because of purposefully obfuscating things?
- LatencyKills 8mo ago
  There's a lot you can do at build time to make reverse engineering harder than just stripping symbol information.
  - bri3d 8mo ago
    This seems odd to me. I have never seen obfuscation techniques in first party Apple software - certainly not in Espresso or ANECompiler and overall nowhere at all except in media DRM components (FairPlay). Apple are really the major OS company _without_ widespread use of a first party obfuscator; Microsoft have WarBird and Google have PairIP.
    - LatencyKills 8mo ago
      > Apple are really the major OS company _without_ widespread use of a first party obfuscator You might want to look into techniques like control-flow flattening, mixed boolean–arithmetic transformations, opaque predicates, and dead code injection — Apple uses all of these. The absence of a publicly named obfuscator doesn’t mean Apple doesn’t apply these methods (at least during my time there). Ever wonder why Apple stopped shipping system frameworks as individual .dylib files? Here’s a hint: early extraction tools couldn’t preserve selector information when pulling libraries from the shared cache, which made the resulting decompiled pseudocode unreadable.
      - bri3d 8mo ago
        I'm very familiar with CFG flattening and other obfuscation techniques, thanks. That's interesting; I suppose I must not have touched the parts of the platform that use them, and I've touched a fair amount of the platform. Again, I _have_ seen plenty of obfuscation techniques in DRM/FairPlay, but otherwise I have not, and again, I am entirely sure the ANE toolchain from CoreML down through Espresso and into AppleNeuralEngine.framework definitely does not employ anything I would call an obfuscation technique. > Ever wonder why Apple stopped shipping system frameworks as individual .dylib files? If the dyld cache was supposed to be an obfuscation tool, shipping the tools for it as open source was certainly... a choice. Also, the reason early tools couldn't preserve selector information was selector uniqueing, which was an obvious and dramatic performance improvement and explained fairly openly, for example - http://www.sealiesoftware.com/blog/archive/2009/09/01/objc_explain_Selector_uniquing_in_the_dyld_shared_cache.html http://www.sealiesoftware.com/blog/archive/2009/09/01/objc_e... . If it was intended to be an obfuscation tool, again it was sort of a baffling one, and I just don't think this is true - everything about the dyld cache looks like a performance optimization and nothing about it looks like an obfuscator.
        LatencyKills 8mo ago
        I’m still relatively new to HN, but I continue to find it fascinating when people share their perspectives on how things work internally. Before joining Apple, I was a senior engineer on the Visual Studio team at Microsoft, and it's amazing how often I bump into people who hold very strong yet incorrect assumptions about how systems are built and maintained. > I suppose I must not have touched the parts of the platform that use them It’s understandable not to have direct exposure to every component, given that a complete macOS build and its associated applications encompass tens of millions of lines of code. /s That said, there’s an important distinction between making systems challenging for casual hackers to analyze and the much harder (if not impossible) goal of preventing skilled researchers from discovering how something works. > Also, the reason early tools couldn't preserve selector information was selector uniqueing That isn't even remotely how we were making things difficult back then. I led the SGX team at Intel for a while, working on in-memory, homomorphic encryption. In that case, the encryption couldn’t be broken through software because the keys were physically fused into the CPU. Yet, a company in China ultimately managed to extract the keys by using lasers to remove layers of the CPU die until they could read the fuses directly. I’ll wrap up by noting that Apple invests extraordinary effort into making the critical components exceptionally difficult to reverse-engineer. As with good obfuscation—much like good design or craftsmanship—the best work often goes unnoticed precisely because it’s done so well. I'm done here - you go on believing whatever it is you believe...
  - saagarjha 8mo ago
    The codenames are cute but don’t really do much
asimovDev 8mo ago
What kind of skillset would one need to work there? I really want to get hired there and stuff to the vim emulation in Xcode
- dostick 8mo ago
  Apply on their website, they’ve been looking and I got interview just being iOS/macOS developer, no tools development exp.
  - asimovDev 8mo ago
    https://jobs.apple.com/en-us/details/200586465-0836/xcode-internals-engineer?team=SFTWR https://jobs.apple.com/en-us/details/200586465-0836/xcode-in... I was mostly joking, I am not from the US and not skilled enough to be considered for bothering with creating a visa for me when there are thousands of developers much more fit for this in the USA. But it is neat to see that the requirements are not as intense as I would've expected

RetpolineDrama 8mo ago

>I worked on the Xcode team for years Why did you guys remove the ability to detach the console and move it to another window?

estimator7292 8mo ago
[flagged]

tiffanyh 8mo ago

Would you mind explaining more. “Difficult” because of lack of documentation? Or difficult because of purposefully obfuscating things?

LatencyKills 8mo ago
There's a lot you can do at build time to make reverse engineering harder than just stripping symbol information.
- bri3d 8mo ago
  This seems odd to me. I have never seen obfuscation techniques in first party Apple software - certainly not in Espresso or ANECompiler and overall nowhere at all except in media DRM components (FairPlay). Apple are really the major OS company _without_ widespread use of a first party obfuscator; Microsoft have WarBird and Google have PairIP.
  - LatencyKills 8mo ago
    > Apple are really the major OS company _without_ widespread use of a first party obfuscator You might want to look into techniques like control-flow flattening, mixed boolean–arithmetic transformations, opaque predicates, and dead code injection — Apple uses all of these. The absence of a publicly named obfuscator doesn’t mean Apple doesn’t apply these methods (at least during my time there). Ever wonder why Apple stopped shipping system frameworks as individual .dylib files? Here’s a hint: early extraction tools couldn’t preserve selector information when pulling libraries from the shared cache, which made the resulting decompiled pseudocode unreadable.
    - bri3d 8mo ago
      I'm very familiar with CFG flattening and other obfuscation techniques, thanks. That's interesting; I suppose I must not have touched the parts of the platform that use them, and I've touched a fair amount of the platform. Again, I _have_ seen plenty of obfuscation techniques in DRM/FairPlay, but otherwise I have not, and again, I am entirely sure the ANE toolchain from CoreML down through Espresso and into AppleNeuralEngine.framework definitely does not employ anything I would call an obfuscation technique. > Ever wonder why Apple stopped shipping system frameworks as individual .dylib files? If the dyld cache was supposed to be an obfuscation tool, shipping the tools for it as open source was certainly... a choice. Also, the reason early tools couldn't preserve selector information was selector uniqueing, which was an obvious and dramatic performance improvement and explained fairly openly, for example - http://www.sealiesoftware.com/blog/archive/2009/09/01/objc_explain_Selector_uniquing_in_the_dyld_shared_cache.html http://www.sealiesoftware.com/blog/archive/2009/09/01/objc_e... . If it was intended to be an obfuscation tool, again it was sort of a baffling one, and I just don't think this is true - everything about the dyld cache looks like a performance optimization and nothing about it looks like an obfuscator.
      - LatencyKills 8mo ago
        I’m still relatively new to HN, but I continue to find it fascinating when people share their perspectives on how things work internally. Before joining Apple, I was a senior engineer on the Visual Studio team at Microsoft, and it's amazing how often I bump into people who hold very strong yet incorrect assumptions about how systems are built and maintained. > I suppose I must not have touched the parts of the platform that use them It’s understandable not to have direct exposure to every component, given that a complete macOS build and its associated applications encompass tens of millions of lines of code. /s That said, there’s an important distinction between making systems challenging for casual hackers to analyze and the much harder (if not impossible) goal of preventing skilled researchers from discovering how something works. > Also, the reason early tools couldn't preserve selector information was selector uniqueing That isn't even remotely how we were making things difficult back then. I led the SGX team at Intel for a while, working on in-memory, homomorphic encryption. In that case, the encryption couldn’t be broken through software because the keys were physically fused into the CPU. Yet, a company in China ultimately managed to extract the keys by using lasers to remove layers of the CPU die until they could read the fuses directly. I’ll wrap up by noting that Apple invests extraordinary effort into making the critical components exceptionally difficult to reverse-engineer. As with good obfuscation—much like good design or craftsmanship—the best work often goes unnoticed precisely because it’s done so well. I'm done here - you go on believing whatever it is you believe...
- saagarjha 8mo ago
  The codenames are cute but don’t really do much

asimovDev 8mo ago

What kind of skillset would one need to work there? I really want to get hired there and stuff to the vim emulation in Xcode

dostick 8mo ago
Apply on their website, they’ve been looking and I got interview just being iOS/macOS developer, no tools development exp.
- asimovDev 8mo ago
  https://jobs.apple.com/en-us/details/200586465-0836/xcode-internals-engineer?team=SFTWR https://jobs.apple.com/en-us/details/200586465-0836/xcode-in... I was mostly joking, I am not from the US and not skilled enough to be considered for bothering with creating a visa for me when there are thousands of developers much more fit for this in the USA. But it is neat to see that the requirements are not as intense as I would've expected