Now it’s all clearer where I already have seen you name, I used your tweaks and I didn’t know ahah 
Great news! Looking forward to purchasing this new version!
1 Like
Just to see what (if any) results would occur if I did that, I re-enabled SIP, rebooted,went into Recover mode and did: csrutil --without fs --without debug and restarted. In terminal, I cleared the boot args using the command line you used. Restarted and re-enabled the boot args and get the following: sudo nvram boot-args=-arm64e_preview_abi
Error setting variable - ‘boot-args’: (iokit/common) not permitted.
So, I think I’ll completely disable SIP and try again.
Hi Karen
Xtrafinder 1.7cut©-and-paste working perfect in intel Mac 13 to 13.2 tested, if this info can help you??!!
really thanks for your hard work you are the best
@Welaxxx XtraFinder is paid software, and even if it wasn’t, I don’t feel comfortable referencing from other people’s work without their explicit consent/permission, anyway.
Progress update (2023/01/07)
I have very good news for everyone — cut-and-paste is now fully working in my development build on macOS 13!
(※ Tested up to macOS 13.2 beta 1 22D5027d on both Apple Silicon [arm64e/AArch64] and Intel/AMD [x86_64].)
This means all TotalFinder features are now fully working on macOS 13!!
I’ll take some time to add some dialogs to improve the initial onboarding user experience for macOS 13, as well as write up some new documentation for the TotalFinder website.
Release should arrive on schedule as stated above!
As always, thank you all for your patience.
※ The issue with TotalFinder not being able to inject into Finder on some old machines patched with OCLP is not something I can really fix on TotalFinder’s side. The root cause lies with OCLP, as their patches on those machines are actually breaking other parts of macOS functionality too, including things like SSH and authentication modules.
Only a select few machines are affected by the issue — not all OCLP-patched machines are affected, especially the more modern ones, as I’ve actually actively been using one for TotalFinder development testing purposes.
Also, this is completely unrelated to OpenCore (the UEFI bootloader).
8 Likes
This is wonderful news, thanks so much Karen. Can’t wait to try it out and finally update to MacOS 13.x.
Quick question though:
I currently run TotalFinder 1.14.3. If I update to MacOS 13.x (from 12.6), can you tell me if I can just run the new version of TotalFinder 1.14.4 that you’ll be releasing and be fine, or will I need to redo that whole process of disabling SIP, due to the OS update possibly putting it back ‘on’?
Thanks!
1 Like
Updating macOS versions will not modify your SIP configuration — this has been the case since SIP’s introduction all the way back in OS X 10.11 (〜2015).
※ If you are using an Intel/AMD (x86_64) machine, the rest of this post does not apply to you, and you are free to ignore it.
Anyway, if you are using an Apple Silicon (arm64e/AArch64) machine and have been using the “partially weakened” SIP configuration mentioned in the documentation, you will have to go back to 1TR (One True recoveryOS) and disable NVRAM protections in addition to the other two (debug and fs).
If you have been using the “fully disabled” SIP configuration (csrutil disable), then you will not have to make any other changes.
The reason for this is because you will need to add a new boot-arg to your NVRAM configuration (-arm64e_preview_abi) to use TotalFinder on macOS 13.
Not to worry though — I’m currently working on the onboarding experience for this to make it as easy as possible for you all.
Basically, TotalFinder will detect and appropriately help walk you through the process of:
- Disabling SIP NVRAM protections if you still have them on
- Adding the
-arm64e_preview_abiboot-arg either automatically using one button press, or instructing you on how to do it manually for those that prefer that, and then prompting for a reboot
… But wait, why is that required now?
The reason for this change is due to Apple introducing a new(-ish) dyld feature in macOS 13 (and iOS 16) called “page-in linking”, which is explained in detail in Apple’s WWDC2022 video “Link fast: Improve build and launch times” at around 25m02s. (※ See also: Ueyama Rui’s analysis of this feature with regards to their excellent “mold” linker.)
In the interest of trying to not go on yet another multi-paragraph lecture, here’s a really over-simplified explanation.
(Hi, Future Karen here! I uh… definitely failed at that goal.)
Traditionally, when loading a dynamically-linked library (or a “dylib”) on Apple OSes, something called dyld handles the entire process of loading the dylib into a random empty space in memory and then “translating” all of the relevant memory addresses so that they’d correctly point to the wherever the dylib is actually located in memory.
(※ I’m sorry to all the developers that are currently yelling at their screens while reading this.)
Apple — in their ever-eternal pursuit of making their OSes as fast and efficient as possible — started using a technique almost a decade ago that they call “page-in linking” for dynamic libraries that are shipped as part of the system — specifically, those that are loaded from something called the dyld_shared_cache (DSC).
By letting the kernel (XNU/Darwin) handle this operation instead of dyld, the “time and memory cost” of loading a dylib is greatly lessened, leading to much faster application launch times, higher system responsiveness, lower memory usage, better security, and of course, greater power efficiency.
Basically, you can say that the full name of “page-in linking” is actually “kernel page-in linking”.
(Again, if you want to know more, I highly recommend watching the video linked above. This explanation is extremely simplified and completely disregards a lot of important aspects. See also: XNU/Darwin source code for map_with_linking_np().)
Okay, but like, you said that was almost a decade ago. What changed now?
The major change that Apple made in macOS 13 / iOS 16 is that now “page-in linking” is used for all dynamic libraries, not just ones shipped with the system (in the DSC).
… Or, well, it tries to. Not every dylib can be loaded this way, as only dylibs that are built with chained fixups enabled (LC_DYLD_CHAINED_FIXUPS) are eligible.
Basically, that means anything targetting macOS 12 / iOS 15 as a minimum version.
“But Karen,” I hear you ask. “TotalFinder currently targets macOS 10.15 as a minimum version! Doesn’t this mean it’s exempt?”
Not quite. The important part thing that is affecting TotalFinder (and other macOS tweaks like it) is the “it tries to” part.
Instead of the traditional behaviour seen in macOS 12 / iOS 15 and below where loading dylibs is pretty much almost solely handled by dyld, macOS 13 / iOS 16 appears to now always get the kernel involved to some extent in this process, regardless of whether or not the dylib works with page-in linking.
Apple’s arm64e ABI
Apple’s platform-binaries shipped as part of their OSes are all compiled using the arm64e architecture (arm64 + pointer authentication). Naturally, this includes Finder.
In order to inject code into another process, the architecture of the code you want to inject must match the architecture of the original process. (※ There are slight exceptions to this regarding minor compatible subtypes such as armv7s vs. armv7, or x86_64h vs. x86_64.)
As a result, the TotalFinder dynamic library is compiled for arm64e (and x86_64), so it can be injected into Finder, an arm64e process.
The problem here is that Apple considers their arm64e ABI to be not yet ready for production use by anyone that isn’t themselves.
In other words, they consider the ABI “unstable” — in that the specifications of the ABI are subject to breaking changes in future OS versions at Apple’s leisure, without any notice or support given.
For this reason, Apple actually prevents you from running arm64e executables by default.
Instead, you have to manually add a boot argument in NVRAM called -arm64e_preview_abi, which you have to disable SIP NVRAM protections in order to do so.
This has been true since macOS 11, the first version of macOS to support Apple Silicon.
… But I don’t need that boot-arg on my Apple Silicon machine running macOS 12 or 11! What changed in macOS 13?
Ah.
So here’s a fun little implementation detail.
The XNU/Darwin kernel is where the “Is this arm64e binary a platform-binary?” check is performed. (※ See below for the actual code excerpt.)
dyld on the other hand, will happily load anything you give it.
Including an non-platform-binary arm64e dynamic library. Such as TotalFinder.
But because macOS 13 now passes all dylib load requests through the kernel, TotalFinder is now suddenly affected by the arm64e restrictions, and thus now requires the -arm64e_preview_abi boot-arg in order to successfully inject.
Aren’t there any workarounds?
Yes, actually!
I read through the source code for the XNU/Darwin kernel to see if I could find out how the arm64e validation is being performed.
After doing that, I managed to find… one potential workaround.
It involves manually modifying the Mach-O header to bypass the arm64e check in the kernel.
If you don’t know what that means, let’s just say it’s a really horrible no good very bad super ultra you should never do this idea.
So… yeah. I’m not doing that.
For the curious: Basically, if you modify your Mach-O header’s cpusubtype in such a way that CPU_SUBTYPE_ARM64_PTR_AUTH_VERSION (which uses CPU_SUBTYPE_ARM64_PTR_AUTH_MASK) would result in some value that isn’t 0, the XNU/Darwin kernel will just… happily allow your binaries to run.
This is because it quite literally only checks to see if the value is exactly 0, and nothing else.
(Please, please never ship software that does this.)
Final notes
- Unlike typical macOS / iOS tweaks, TotalFinder is technically not really a “dynamic library” or a “dylib” in the Apple Mach-O
MH_DYLIBsense. Rather, it is actually a “loadable bundle”, or anMH_BUNDLE.- That being said, it is still, for all intents and purposes, a dynamic library (the generic terminology), and is therefore loaded and treated like one.
- For more information, you can run
otool -hvvvvvv ${PATH_TO_WHATEVER_YOU_WANT_TO_ANALYSE}.
- For some reason, it’s been found that macOS installs from China in particular (and maybe some other Asian countries? Definitely not Japan, though…) have arm64e ABI support enabled by default. No one really seems to know why this is the case, how this mechanism is triggered, or even how to detect it.
- My best guesses for how this is triggered is perhaps a flag in the SMBIOS? Or maybe detection based on regional hardware model IDs like what triggers camera shutter sounds in Japanese and South Korean iPhones? Honestly, it’s anyone’s guess, and Apple sure doesn’t have this behaviour documented anywhere (or even in the XNU/Darwin source code).
I absolutely failed at my original goal of trying not to write a massive essay. I’m sorry. ;P Hopefully this was interesting, at least!
3 Likes
Wow, thanks for the detailed response. Very appreciated. Hopefully won’t be too hard for me. I’m on Apple Silicon, but I think I had fully disabled SIP, so hopefully I should be good. Though , regardless, it sounds like you’ve done a good job having checks run to let the user know what they need to do. Looking forward to getting everything up and running. Good luck finishing things up. Your work is greatly appreciated by us all.
1 Like
Run csrutil status in a Terminal instance, it’ll tell you.
Fully disabled:
System Integrity Protection status: disabled
Partially weakened (※ yours will most likely not match mine):
System Integrity Protection status: unknown (Custom Configuration).
Configuration:
Apple Internal: disabled
Kext Signing: disabled
Filesystem Protections: disabled
Debugging Restrictions: disabled
DTrace Restrictions: enabled
NVRAM Protections: disabled
BaseSystem Verification: enabled
Boot-arg Restrictions: disabled
Kernel Integrity Protections: disabled
Authenticated Root Requirement: enabled
This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.
Thank you!
1 Like
Hi @akemin_dayo!
I have a question about regarding the GL yuri Studio ELAN games development you are working on, especially Please Be Happy with CV Dottovu which I played very recently
It was very good!
Will there be Chinese translation support? The other Studio ELAN games include the support, or have ability to apply Python patch modifications, but Please Be Happy is using Unity engine.
Also, Please be Happy right now requires ROSETTA technology. Is there plans to produce APPLE SILICON application from Unity?
And is there ETA on Console (SONY PlayStation, NINTENDO Switch)?
I hope one day your friend Namirin will also do Character Voice for an ELAN game or maybe ED song like Dottovu’s Someone Someday [Original Song] - YouTube
(My favorite Namirin song is Caesura of Despair - Animation MV - YouTube )
Thank you!!! 
Also I am very happy with TotalFinder, I cannot wait for the new version with compatible support for Apple mOS 13!!!
P.S. Is Links :: Karen's Pineapple the correct place for your donation links?
P.S. 2: Is the correct terminology Yuri or GL or WLW? I see a lot of different words used.
… An unexpected progress update
This will mostly be of interest to @ChrisOSX.
Anyway, I uh…
… accidentally got TotalFinder to work on a macOS install with OCLP Non-Metal Moraea patches applied…!?
I think I’ll focus on finishing and polishing up the NVRAM-related onboarding process and making a release before trying to make this work more reliably, but…
Yeah. That’s uh. A thing that happened.
(Still doesn’t change the fact that something in the OCLP Non-Metal Moraea patches is breaking macOS on a larger scale though — SSH is still severely broken, among other things.)
Thank you for your interest in TotalFinder.
However, I will ask to please direct all Studio Élan-related enquiries to our contact form — this is not really the appropriate place for such enquiries.
The BinaryAge forums are a place to discuss BinaryAge-related content (such as TotalFinder) — it is not really a place to discuss anything that may just so happen to be related to me.
Thank you for your understanding, and for using TotalFinder.
Of interest is an understatement 
Weird it broke in the first place. Granted they have a lot of hardware to track and adapt, and I am patient af when it comes to development esp unsupported development. It still could be to do something with my specific model though. MacbookPro6,2 has been a weird machine since the beginning. With it being noted a couple times about my machine being exempt. The keyboard backlight is not needed for me, and this could be true for other things, maybe just better detection on their part? I don’t want to assume, they have their plates full as it is.
As for TF, I went back through the process of installing Monterey (I broke something unrelated 
) and worked my way backwards again installing versions back to 1.12.3. That is the only version that install process asks for System Events. Anything beyond this version throws the Injection error. It’s still weird that this version installs, granted not full TF capabilities, but functional-ish.
Thank you for your hard efforts and keep up the amazing work! And as always, let me know if you need any info (or a tester 
), I’ll be as prompt as possible.
1 Like
@akemin_dayo Okay, thank you I understand and Sorry, My deepest apologies 申し訳ございません
You are my favorite LGBT lesbian!!!
The smartest and most beautiful too 
Beautiful Japanese Programmer Akemi 明美!!!
I will happily am waiting for APPLE mOS 13 compatible TOTALFINDER!!!
Love from Hong Kong 
Scroll up and read this post: [Update Discussion] TotalFinder 1.14.3 for Apple Silicon and Intel - #224 by akemin_dayo
It’s secret!
The post referenced in that one (you can click that link) says seven days or less and it was written seven days ago. So any time now.
Karen is working hard to get it out, so it would be nice if people let the timeframe xe posted arrive and a little extra before bugging xer about it.
3 Likes
Thx, could not say it better!
2 Likes
Alberto I invite you to read this thread, in short words it won’t fully work you have to wait for TF 1.14.4
eBara, thanks a lot!