zeezide / 5guis Goto Github PK

macOS BS has the "dyld shared cache" which breaks running objdump on the dependencies. E.g. this results in BS Safari not having any features detected.

$ otool -L /Applications/Safari.app/Contents/MacOS/Safari
/Applications/Safari.app/Contents/MacOS/Safari (architecture x86_64):
	/System/Library/PrivateFrameworks/Safari.framework/Versions/A/Safari (compatibility version 528.0.0, current version 610.2.6)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.0.0)
/Applications/Safari.app/Contents/MacOS/Safari (architecture arm64e):
	/System/Library/PrivateFrameworks/Safari.framework/Versions/A/Safari (compatibility version 528.0.0, current version 610.2.6)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.0.0)

W/ the "dyld shared cache", the /System/Library/PrivateFrameworks/Safari.framework doesn't actually exist on disk anymore (hence objdump can't analyse it).

Maybe we can use dlopen to load and open an executable and then somehow traverse the link list (w/o actually executing the binary)?

What seems to break in this case is that 5 GUIs tries and fails to detect AppKit (“No 👨🏽‍🦳 AppKit usage to be found? 🤔”). That’s probably because of the structure of Chromium. In order to update cleanly, Chromium (and Google Chrome) is separated into an outer bundle and an inner framework, and the only job of the outer bundle is to call into the inner framework. If all that is being analyzed is the outermost binary, you’re not going to find usage of any system framework. All of Chromium’s AppKit usage (it’s an old-school ~2008 AppKit app) is through the inner framework that isn’t ever explicitly linked to any of the .apps.

I’m not sure of an easy, not special-cased way to detect this. The main function uses dlopen to open a hard-coded path to the inner framework, so there are no obvious traces in metadata.

Several apps carry additional apps in their Frameworks folder, e.g.:

Zini18:~ helge$ ls -d /Applications/zoom.us.app/Contents/Frameworks/*.app
/Applications/zoom.us.app/Contents/Frameworks/CptHost.app
/Applications/zoom.us.app/Contents/Frameworks/Transcode.app
/Applications/zoom.us.app/Contents/Frameworks/ZMScreenshot.app
/Applications/zoom.us.app/Contents/Frameworks/ZoomUninstaller.app
/Applications/zoom.us.app/Contents/Frameworks/caphost.app

We should scan those as well and incorporate into the result. The ExecutableFileTechnologyInfo is prepared for that already.

5GUIs incorrectly identifies these Qt apps as AppKit:

Tableau Desktop
VirtualBox
Blackmagic Desktop Video
Blackmagic RAW Player
Blackmagic RAW Speed Test
DaVinci Resolve

(I am horrified by the realization that DaVinci Resolve is a Qt app. It was supposed to save us from Premiere...)

In an app review, someone mentioned that 5 GUIs crashes on macOS 13 betas. I don't have them installed yet, but should check that.

AppKit usage not detected

This should show everything we detect (e.g. all languages etc), and also allow the user to browse the different embedded apps and frameworks individually.

The Info.plist has a JavaX dictionary embedded, which is the trigger

For all intents and purposes, we use "Electron apps" to refer to apps that wrap Chromium.

5GUIs identifies Spotify appears as an AppKit Objective-C app, which it is not.

First: Thanks for the idea and the app. Neat one.

You might also check for Java, like "Arduino.app". Probably detectable via the "Java" directory in the bundle.

https://dangerzone.rocks/
https://github.com/firstlookmedia/dangerzone

Seems like python, tcl/tk etc., and it needs Docker. (But it's a macOS app bundle.)

It has an embedded 'QtGui.framework', which is highly suspicious.

Detect Platypus apps that run scripts e.g. at ./Contents/Resources/script
Right now, 5GUIs thinks they're fine (AppKit Objective-C), but that's just the Platypus wrapper for the script.

Detect Automator apps that run scripts e.g. at ./Contents/Resources/Scripts/main.scpt
Right now 5GUIs doesn't know what to do with them.

Over here, found while stalking @kiliankoe: https://github.com/kwin/macdependency

Not sure whether it makes sense or not.

Tungsten.framework in the "Framework" bundle points to "Tungsten Fabric" as the API

Me – again – next idea: Python wrapper apps like Calibre.app

Assuming it actually is an AppKit app, we might need to tone down the praise :-)

Not 100% sure whether Catalyst and plain UIKit apps (i.e. running iPhone/iPad apps natively on a DTK/Apple silicon Mac) are actually the same thing on macOS BS. I would think not, but who knows.

On Catalina Catalyst apps are detected when they link UIKitMacHelper.framework. Maybe the bug is also just a result of Issue #2? (the b0rked dependency traversal due to the shared cache)

I clicked the App Store link but it says it's not available. Has it been removed?