xcodebuild system version check

[07151129]

I have only tested it for Xc7, but it seems like xcodebuild checks DVTMinimumSystemVersion at xcodebuild:10000142c (com.apple.xbs/Sources/IDETools/IDETools-8027/xcodebuild/xcodebuild_main.m:checkMinimumOSVersion). The version itself is stored in info.plist in __TEXT of xcodebuild binary.
If the check fails, then Xcode fails to install developer tools, and so it won't let user in past the license view.
As a workaround, I suggest implementing something like xpf_patch_info_dictionary, but this time for that nasty key :)

(This is, of course, only a peak of the iceberg. I am still working on making it actually run xc7b2 and will report when done...)

[07151129]

Ok, here is a patch. DVTFilePath-related stuff is for fixing the crash when configuring VCS:
DVTAssertions: ASSERTION FAILURE in /Library/Caches/com.apple.xbs/Sources/DVTFrameworks/DVTFrameworks-8114.24/DVTFoundation/FilePaths/DVTFilePath.m:896 Details: url should be an instance inheriting from NSURL, but it is nil Object: <DVTFilePath> Method: +filePathForFileURL: Thread: <NSThread: 0x7fb5e2518430>{name = (null), num = 1} Hints: None
Unfortunately, it does not help (method does not get hooked properly?…), and I am too tired for that.
I had to add libgnu fstatat implementation.
For some reason, installing packages from Resources/Packages failed (performed by Xcode after accepting license); I had to do it manually.

UPD: VCS problem seems to be relevant to lack of necessary symbols (rebound by XPF) in com.apple.dt.Xcode.sourcecontrol.* XPC services.
It seems like that some symbols are not rebound for created subprocesses. For instance, simulator refuses to start because of system version check. This would also explain Xcode not being able to install the packages.
There is another problem with +[DVTFilePath filePathForFileURL:]: assertion [(url) isKindOfClass:[NSURL class]] failed; the URL turned out to be an instance of NSString. I solved it by redirecting the calls to +[DVTFilePath filePathForPathString:] in ideplugin using [[PLPatchMaster master] patchFutureClassWithName:], but there might be a better solution.

UPD: Indeed, dyld ignores DYLD_* envvars for subrpocesses (restriction by private entitlements?). Also, the image name check should be extended against a list of images instead...

[landonf]

Just some notes:

• I did some work on ensuring the environmental variables do get preserved, but it won't resolve the case where dyld considers the subprocess 'restricted' and ignores them: https://github.com/landonf/XcodePostFacto/tree/bugfix/preserve_dyld_envvar_across_exec
• The package installation fails due to the use of a new "pbzx" archive format. I started work on shimming this, but I think we're running into the fact that the actual installation occurs inside of installd: 198d890#diff-9491f7b5cb2bd93e9c1abd4698b9c8c8R36
• XC7 support has been destabilizing enough that I've been working on it in a separate https://github.com/landonf/XcodePostFacto/commits/feature/xcode7-support branch.

Ultimately, I think Xcode 7 support might require graduating from DYLD_* insertion and actually performing runtime code injection from a privileged position.

[07151129]

Thank you for your reply!
Indeed, it seems to be a good option to switch to something more powerful for injection (e.g, comex' Substitute?). We ourselves are using a kernel-space patcher for this.
The patch is actually for xcode7 support branch, it's just that github does not separate issues based on branch. It's not like it is of much use now anyway, since it needs some more fixes. I will submit a PR if/when it's done.
P.S. I am actually surprised by how simple the principle of XPF is; perhaps, one day we could build a generalised backporting framework based on it?…

[landonf]

Indeed, it seems to be a good option to switch to something more powerful for injection (e.g, comex' Substitute?). We ourselves are using a kernel-space patcher for this.

Huh, neat. I've been playing around with kexts to hook exec/spawn* -- I'll have to look at Substitute in more detail.

P.S. I am actually surprised by how simple the principle of XPF is; perhaps, one day we could build a generalised backporting framework based on it?…

I've had similar thoughts. We're not very far away from having a full-fledged dyld replacement, and if we can do arbitrary binary injection/patching:

• We could load all or a subset of dylibs from a future OS, rather than the current host OS.
• We wouldn't need to rewrite symbol references as weak to convince dyld to load the libraries.
• We could easily redirect libSystem's syscall shims for new syscalls to our own userspace handlers.
• We could hook syscalls to present a read-through virtualized view of the file system / mach port namespace, as appropriate.