Hallo allerseits,

bekanntlich gibt es im Wesentlichen zwei Möglichkeiten, dafür zu sorgen, dass Programme beim Start des Macs oder beim Login des Nutzers automatisch starten: die Anmeldeobjekte in den Systemeinstellungen und programmspezifische .plist-Dateien in (~)/Library/LaunchAgents bzw. (~)/Library/LaunchDaemons.

Nun hatte ich testweise auf Mojave eine Cocoa-App installiert, die ebenfalls von selbst startete, aber zu meinem Erstaunen dafür keine der beiden oben angegebenen Mechanismen nutzte.

Nach einigem Suchen fand ich heraus, dass folgender Eintrag in der Datei MyApp/Contents/Info.plist, die jede macOS-Applikation enthalten muss und die von macOS gescannt wird, ebenfalls ausreicht:

Ich meine mich dunkel zu erinnern, in der Entwicklerdokumentation von Apple mal von einem solchen 3. Autostart-Weg gelesen zu haben, habe das damals aber leider nicht weiter verfolgt, da ich anderes im Kopf hatte.

Ich bringe das hier hauptsächlich aus Sicherheitserwägungen zur Sprache: Bekanntlich muss jede Schadsoftware, sofern sie nicht bei ihrem ersten Start gleich den Rechner in die Luft jagt, sich erst einmal persistent machen, d.h, dafür sorgen, dass sie fortan beim Einschalten des Macs/Login des Nutzers stets automatisch neu gestartet wird.

Deshalb überprüft z.B. die Sicherheitssoftware KnockKnock von Patrick Wardle die beiden oben gelisteten Autostart-Mechanismen und zeigt alle Böslinge an, die sich so persistent verankern wollen.

Die von mir getestete, von selbst startende Software ging KnockKnock aber prompt durch die Lappen.

Kann hier jemand was Erhellendes dazu sagen? Wann/warum diese 3. Autostartmöglichkeit eingeführt wurde, wie man sie erkennen kann, warum KnockKnock das nicht tut usw.

Danke im Voraus für alle Tipps und Infos!

Moin,
ohne es genauer zu wissen, würde ich denken das sich dies mit "launchctl" und "launchd" steuern lässt, und sich der Eintrag mit dem Befehlen auch setzen lässt. Eigentlich eine sehr schöne Sache da es den umstand des Manuellen löschen bestimmter Dateien aus den LaunchAgents und Daemons Verzeichnissen erspart.
Wie gesagt, keine Ahnung, nur ein verdacht.

launchctl list | grep -i "yourAppName"

schau mal ob dieser Befehl deine App auflisten kann, die den Eintrag in der plist hat. Dann würde sich zumindest meine Theorie bestätigen .

Es gibt noch viel mehr Autostart-Möglichkeiten.

Da Apps aus dem App Store keine Befugnis zum Zugriff auf das Launch-Subsystem haben, hatte Apple ab Mac OS X 10.6.7 für Apps eine weitere Anmeldung von Autostart-Objekten eingeführt, und zwar über die Funktion "SMLoginItemSetEnabled()". Das legt ein verstecktes Anmeldeobjekt an, wobei der Eintrag sowohl auf der grafischen Oberfläche als auch in vom Finder standardmäßig angezeigten Ordnern komplett unsichtbar bleibt. Eigentlich kann nur die App, die diesen Eintrag angelegt hat, ihn auch wieder entfernen.

Auch das ist schon wieder Geschichte. Ab macOS 13 wurde diese Technik durch ein neues Subsystem namens "SMAppService" ersetzt. Das ist allerdings noch völlig unausgereift und steckt voller Fehler. Hauptidee dabei ist unter anderem, dass die Objekte nicht mehr in zentralen Ordnern eingetragen werden, sondern fest an das jeweilige Programm gebunden werden. Beim Löschen eines Anwenderprogramms werden dann alle zugehörigen Autostart-Mechanismen (egal ob Agent, Daemon, PrivilegedHelper, LoginItem, etc.) mitgelöscht und das System automatisch bereinigt.

Nö, eben nicht. Sonst würde KnockKnock das ja ebenfalls finden.

Das hilft in dieser Vagheit aber auch nicht weiter. Der Abkürzung halber können wir uns ja vielleicht darauf einigen, darunter alle Möglichkeiten zu verstehen, die auch KockKnock kennt.

Die hier diskutierte Variante (er)kennt KnockKnock aber eben nicht. Das ist mein Punkt.
Nämlich wo? /var/folders/?
Die GUI ist in dem Zusammenhang doch egal.
Weil nur sie den genauen Pfad kennt?

Die Variante mit dem Eintrag in Info.plist scheint von all dem, was Du schreibst, aber nicht erfasst zu werden. Nur um die geht es mir aber.

Das Gespenstische ist, dass außer Info.plist keine einzige Datei im Dateisystem verändert zu werden scheint, wenn die Einstellung geändert wird. Mit find als root gescannt, das müsste eigentlich alles erfassen.
Das klingt, wenn es erst einmal bugfrei (🥳) ist, ja höchst sinnvoll. Nur geht es hier ja um Mojave.

BTW: Eine sehr gute Übersicht über die bekannten Autostartmethoden (zu denen die hier diskutierte aber eben nicht gehört) findet sich im Paper Methods of Malware Persistence on OS X vom Autor von KnockKnock, Patrick Wardle.

Weia
Schreib doch ne kurze Nachricht an Patrick Wardle und weise ihn darauf hin Kannst uns ja berichten, was er antwortet; würde mich interessieren.

Dazu will ich aber erst mal selbst verstehen, was das ist.

Ich wäre auch sehr interessiert, wenn du mehr in Erfahrung bringen kannst!

Das Programm ist nicht der Standard für solche Analysen.

Zur ursprünglichen Behauptung: Ich kann nicht erkennen, dass "LaunchAtStartup" irgendeine Funktion in macOS hätte. Das wäre auch untypisch für Apple, da solche Schlüsselworte überlicherweise einen Bibliothekspräfix wie "LS" (Launch Services) oder "CF" (Core Foundation) haben müssen. Jedem Software-Hersteller steht es aber frei, beliebige Schlüssel in die Info.plist eines Programms einzufügen, die dann aber nur für dieses eine Programm selbst irgendeine Bedeutung haben.

Das war von Apple so implementiert, ja.

Nein, die App kennt den Pfad nicht. Die Dienstverwaltung von macOS "weiß" aber, ob eine App mit dem jeweiligen Bundle-Identifier in der Vergangenheit einmal "SMLoginItemSetEnabled" aufgerufen hat und kann das entsprechend auch wieder ausschalten.

Das ist 8 Jahre alt und ziemlich veraltet.

Das habe ich auch nicht behauptet. Mit Deinem vagen Es gibt noch viel mehr Autostart-Möglichkeiten kommen wir aber auch nicht weiter. Daher mein rein pragmatischer Vorschlag, alles, was KnockKnock (das frei zugänglich ist) kennt, als bekannt vorauszusetzen, sodass nur der Rest explizit benannt werden muss.

Und falls Du einen kennst: Was ist denn der Standard für solche Analysen? Dann hätten wir eine bessere Diskussionsgrundlage.
Ich werde den Programmautor mal anschreiben und fragen, was er da implementiert hat.
Erneut: Kennst Du eine bessere?

"Startup" ist doch eher ein Begriff, um den Start eines Programmes und nicht eines Systems ("Launch") zu bezeichnen, z.B. hier und hier (Apple Dokumentationen wg. der Begriffe)

interessant ...
Was ich bis hierher verstanden habe:
- Programme können über einen System Call wie z.B. "SMLoginItemSetEnabled" oder dessen Nachfolger vom Kernel anfordern, beim Reboot /Login wieder gestartet zu werden.
- Der Kernel registriert das irgendwo unterhalb von /var/folders, wo man mit "normalen" root-Rechten nicht rankommt

Bei dem fraglichen Programm wechselt aber der Wert zu diesem Key zwischen true und false, je nachdem, ob das Programm bei Login von selbst startet oder nicht; das ist ganz eindeutig reproduzierbar.

Kommt man nicht? Ist also durch SIP geschützt? Ich kann das nicht beurteilen, weil SIP bei mir prinzipiell ausgeschaltet ist.

Ist das die Ursache für den Programmstart oder notiert das Programm dort, ob es zum Login gestartet wurde?

Gute Frage! Just das habe ich heute Nacht getestet und herausgefunden, dass es eher Letzteres ist. Genau: Es notiert dort einfach die Nutzereinstellung, wozu auch immer.

Ich schreibe jetzt wie gesagt einfach den Autor an, bevor ich mir weiter den Kopf zerbreche.

Nicht beim Kernel, das wäre viel zu tief im System. Das wird bei der Diensteverwaltung von macOS angefordert. SM heißt Service Management.

Nicht wirklich. Jeder Benutzer hat volles Zugriffsrecht auf seinen persönlichen /var/folders-Unterordner. Dort befindet sich für jeden Benutzer quasi ein zweiter Home-Ordner, nur dass der Finder ihn normalerweise nicht anzeigt. Die Funktionalität von "SMLoginItemSetEnabled" wurde nur deshalb eingeführt, weil Apps (im Sinne von "eingeschränktes und von Apple zensiertes App Store-Programm") keine Sandbox-Befugnis haben, irgendetwas im System zu sehen, was nicht zu dieser App gehört. Eine App darf aber SMLoginItemSetEnabled aufrufen, um anzufordern, dass macOS einen privaten Autostart-Eintrag für diese App anlegt. Wie macOS das macht, kann die App weder sehen noch beeinflussen.

Stellt sich für mich so dar - aber vielleicht wieder eine Fehlinterpretation - kann ja sein, ich lerne noch.

Im Beispiel hast Du hast den verdeckten Benutzerordner des Benutzers "macports" aufgerufen.

Von den Rechten her hat jeder Benutzer auf seinen eigenen Ordner volles Zugriffsrecht. Da der Ordner aber komplett von macOS verwaltet wird, gibt es in der Tat Bereiche, die von SIP geschützt werden und auch geschützt werden sollen, z.B. der Zugriff auf die eigenen "Bildschirmzeit"-Beschränkungen.

Das sind aber Sandbox-Einschränkungen und hat nichts mit Rechten zu tun. Die beiden Konzepte arbeiten völlig getrennt voneinander. Wird Dir ein Recht verweigert, bekommst Du einen "access denied"-Fehler, wirst Du dagegen von SIP oder einem anderen Sandbox-Mechanismus aufgehalten, bekommst Du einen "operation not permitted"-Fehler.

Ja, stimmt. In meinem eigenen Folder sieht es anders aus und ich bin sogar der owner,
"Operation not permitted" gibts dann teilweise auch.

Ich meine nicht den von KnockKnock, sondern von dem autostartenden Programm, das KnockKnock nicht findet …

Mea Culpa!

Der Entwickler hat geantwortet; er verwendet in der Tat einfach SMLoginItemSetEnabled(). Den LaunchAtStartup-Key setzt sein Code in der App-eigenen plist-Datei in ~/Library/Preferences/ wie üblich; wieso der Key auch in Info.plist auftaucht (was ihm nicht bewusst war und wovon er sich selbst erstmal überzeugen musste), sei ihm ein Rätsel.

Umgekehrt ist unklar, wie/wo macOS diese Einstellung mit SMLoginItemSetEnabled() nun eigentlich abspeichert; die von mir verwendete Suchroutine hätte ohne jede Einschränkung alle veränderten Dateien finden müssen, hat aber nach Verändern der Einstellung keine einzige gefunden.

Aber die grundlegende daraus resultierende Frage ist, ob KnockKnock mit SMLoginItemSetEnabled() persistent gemacht Programme prinzipiell nicht erkennt oder überhaupt erkennen könnte. Denn dann wäre die ganze Funktionalität von KnockKnock als Viren-Warnung natürlich Makulatur, zumal SMLoginItemSetEnabled() so ein häufig genutztes Verfahren ist.

Andererseits hat KnockKnock laut Patrick Wardle bislang jeden bekannten Mac-Virus gefunden. Heißt das nun, dass ausnahmslos alle Virenprogrammierer nur zu blöd sind, SMLoginItemSetEnabled() zu nutzen? Oder dass KnockKnock doch Programme mit SMLoginItemSetEnabled() aufspüren kann, nur dieses eine, von mir getestete nicht? Und warum gerade das nicht? Und wie kommt der LaunchAtStartup-Key in Info.plist?

Fragen über Fragen.

Das ist doch eine App aus dem AppStore, oder? Da SMLoginItemSetEnabled() von Programmen aus dem AppStore genutzt wird, müsste die Malware auch über den AppStore auf den Rechner gelangen.

Nö.
Nö. SMLoginItemSetEnabled() muss von Apps aus dem Appstore, aber kann auch von allen anderen genutzt werden.

hat mir geholfen:
SMLoginItemSetEnabled gehört zum Service Management Framework und können angeblich nur von der Applikation selber gelöscht werden.

Aber natürlich gibt es schon Möglichkeiten die zu finden und zwar in der Datei /var/db/com.apple.xpc.launchd/loginitems.501.plist

Bei mir gibt es dort einen Eintrag zu einer (längst gelöschten) App namens AdGuard (com.adguard.mac.adguard) welche ich mit der aktuellen Version von KnockKnock nicht finden kann wenn ich die App gelöscht habe. Solange sie installiert ist, wird sie auch angezeigt.

Kann man hier herunterladen (https://adguard.com/en/adguard-mac/overview.html) und nachvollziehen.

Ah, herzlichen Dank, der Link ist extrem hilfreich!
Das isses! (Wobei die 501 nicht feststeht, sondern die User-ID des jeweiligen Nutzers ist. macOS beginnt mit 501 zu zählen, das ist also der erste Nutzer, der in macOS angelegt wurde. Danach folgen 502, 503 usw. Seine eigene User-ID kann man ggf. mit folgendem Befehl herausfinden:
(weia muss man natürlich durch den eigenen Nutzernamen ersetzen. )
Das ergibt ja auch Sinn. Wo (d.h. unter welcher Kategorie) wird die App denn dann in KnockKnock angezeigt?

Damit kann meine Frage/das Problem wohl generell als gelöst gelten. Warum es in meinem spezifischen Fall mehrere spezielle Probleme zu geben schien, kann ich ja dann noch für mich untersuchen. Am Ende war das Problem einfach wieder nur der, der vor dem Computer saß … 🙄

Steht ja im verlinkten Artikel, sorry!

großes Merci für diesen wertvollen Thread!

Das verstehe ich nicht. Also Du findest einen Eintrag in /var/db/com.apple.xpc.launchd/loginitems.501.plist, der in KnockKnock unter LoginItems angezeigt wird. Aber KnockKnock hat Dir doch nach eigener Aussage im Eröffnungsbeitrag das selbststartende Programm eben nicht angezeigt. Ich gehe mal einen Kaffee holen - vielleicht verstehe ich es dann

Wirklich ein interessanter Thread!
Ich frage mich gerade, ob alle ausführbaren Dateien, die bei KnockKnock unter „Login Items“ aufgeführt werden, auch (unter anderen) in den Systemeinstellungen von Ventura unter Allgemein - Anmeldeobjekte - „Im Hintergrund erlauben“ oder „Bei der Anmeldung öffnen“ aufgeführt werden.
Bei mir ist das nämlich so. Aber das heißt natürlich noch nicht, dass dies allgemein gilt.

Mein Problem bestand ja aus mehreren Teilen:

• Warum diese 3. Autostart-Methode eingeführt wurde und wie sie implementiert ist – beantwortet
• Wie man sie erkennen kann – beantwortet und auch, dass KnockKnock das im allgemeinen auch kann
• Warum in meinem speziellen Fall KnockKnock sie nicht erkannte – noch nicht beantwortet

Den dritten Teil hielt ich für nicht sonderlich interessant für die Allgemeinheit – ist er aber doch. Mittlerweile habe ich mir nämlich meine com.apple.xpc.launchd/loginitems.501.plist angeschaut und festgestellt, dass es beileibe nicht nur dieses eine Programm ist, dass KnockKnock nicht findet, sondern etliche (ich hatte gar nicht vor Augen, was ich alles installiert habe). (Nebenbei bemerkt: Mir ist absolut unverständlich, warum Apple das in der macOS-GUI nicht anzeigt; aber möglicherweise ist das ja in Ventura behoben, siehe Beitrag von McErik.)

Mein augenblicklicher Erkenntnisstand ist der folgende: heubergen hat ja geschildert, dass KnockKnock Einträge in com.apple.xpc.launchd/loginitems.501.plist nur dann auflistet, wenn das zugehörige Programm noch installiert ist. Dazu muss KnockKnock Letzteres natürlich überprüfen und es scheint so zu sein, dass es dabei davon ausgeht, dass all diese Programme direkt in /Applications/ installiert sind.

Das ist bei mir aber so gut wie nie der Fall. Entweder befinden sich die Programme in Unterordnern von /Applications/, in ~/Applications/ oder ganz woanders. Und selbst wenn alle erwünschten Programme in /Applications/ wären, eine Malware wird doch nicht so doof sein und sich selbst ausgerechnet dorthin installieren.

Ich mags das noch nicht glauben, denn das wäre ja eine Lücke so groß wie ein Scheunentor, aber im Augenblick deutet alles darauf hin. Ich wollte mir nur noch sicherer werden, bevor ich das hier poste oder an Patrick Wardle schicke.

Bei mir (MacOS Ventura) sind dort* Programme aufgeführt, die seit langem deinstalliert sind, Programme die nicht automatisch ausgeführt werden und es sind sogar Programme zweimal enthalten (z.B. Hazel).

* dort: com.apple.xpc.launchd/loginitems.501.plist

Was ist dort? KnockKnock oder com.apple.xpc.launchd/loginitems.501.plist?

macOS 13.1 Ventura
Jetzt habe ich bei mir ein Programm (Theine.app), dass sich beim Start öffnen soll, beendet und aus dem Programme-Ordner in den Schreibtischordner verschoben und erneut geöffnet.
Dann KnockKnock das System scannen lassen. Jetzt fand sich die Theine-App nicht mehr unter Login Items.
Wenn die App zurück in den Programme-Ordner kommt, wird sie dort wieder aufgeführt.
Bestätigung von dem, was Weia festgestellt hat! Schwerer Fehler von KnockKnock!




Etwas Neues am Rande:
Man kann eine App zwar wie immer in den Programme-Ordner hineinziehen aber nicht mehr hinaus. An dem Zielort erscheint lediglich ein Alias der App. Mit (cmd)(C) - (cmd)(alt)(V) kann ich die App aber dennoch aus dem Ordner verschieben. ??

Ergänzung:
Die Anzeige in den Systemeinstellungen bleibt von der Verschiebung der App aus dem Programme-Ordner unberührt.

Tausend Dank für die Tests!

KnockKnock ist ja Open Source und die für Login Items zuständige Datei LoginItems.m. Darin findet sich ab Zeile 476 folgender Code, der nach allen Programmen mit LoginItems suchen soll:


directoryContentsAtPath: listet aber den Inhalt von Unterordnern nicht auf und Objekte ausserhalb von Path natürlich sowieso nicht.

Und selbst wenn es das täte, würden andere Apps natürlich durch das Raster des Suchstrings stringWithFormat:@"/Applications/%@/Contents/Library/LoginItems/", application fallen, der ja nur Apps direkt in /Applications findet.

Ich mag das immer noch nicht so recht glauben, aber es ist wohl so. 😳
Auch bei gedrückter Taste? Damit ging es bislang, ohne schon lange nicht mehr.

Nein - auch mit gedrückter Befehlstaste nicht.

Ich habe Patrick Wardle jetzt eine Email geschickt; mal sehen …

Am Rande bemerkt: In der Info.plist Datei im App-Bundle kann man natürlich alle möglichen Keys verwenden, auch solche, die macOS ignoriert. Aber ändern kann man sie dort nicht, da dabei die Signatur der App gebrochen wäre und die App nicht mehr zu starten wäre. Ausnahme: nicht signierte App, bei der man Gatekeeper davon überzeugen muss, sie zu starten.

Ich kann mir vorstellen, dass der Autor, ohne sich darüber genau Gedanken zu machen, den Inhalt der Info.plist als Blaupause für die Datei verwendet, die im Preferences-Verzeichnis seiner App abgelegt wird.

Insgesamt aber ein guter Thread - vielen Dank für die Recherchen hierzu!

Ja, das dachte ich auch immer. Sie wurde aber mit jedem Ein-/Ausschalten der Persistenz der App in ihren Einstellungen verändert.
Ich kann mich nicht entsinnen, dass das der Fall war, will das aber nicht ausschließen. Allerdings habe ich SIP grundsätzlich deaktiviert, aber davon kann der Autor ja nicht ausgehen und ich weiß auch nicht aus dem Stegreif, ob das an dieser Stelle was ändern würde.

Alles sehr rätselhaft. Leider habe ich die App währenddessen wieder entfernt, da ich sie loswerden wollte.

Ich habe jetzt erst Deine Ergänzung bemerkt; sorry.

Dass Einträge von gelöschten Apps zurückbleiben, ist normal; das ändert sich ja eben erst mit dem ganz neuen Verfahren in Ventura, das Marcel Bresink erwähnt hat. Eben deswegen muss auch KnockKnock noch überprüfen, ob die App überhaupt noch existiert, und genau da tritt ja der Fehler auf, dass es alle Apps, die nicht direkt in /Applications/ liegen, für nonexistent hält. Ebensowenig werden die Einträge entfernt, wenn der Nutzer die Persistenz gerade ausgeschaltet hat. Es geht nur darum, zu indizieren, dass das eine App ist, die dieses Verfahren der Persistenz benutzt.

Patrick hat geantwortet und wir haben ein bisschen hin und her gemailt.

Patrick dachte tatsächlich, dass Persistenz mit SMLoginItemSetEnabled() nur in sandboxed Applications implementiert werden kann und dass alle sandboxed Applications in /Applications/ liegen müssen (vermutlich weil App Store Apps per default dort landen – aber jederzeit verschoben werden können). Das hat mich etwas gewundert bei jemandem, der ansonsten in den tiefsten Tiefen von macOS zuhause ist. Aber vielleicht gerade deshalb …

Er meinte, dass er an einer neuen Version von KnockKnock arbeitet, die auf die neuesten APIs von Apple aufsetzt und so sicher alle persistenten Apps in den Blick bekommt. Dagegen habe ich eingewendet, dass diese Version von KnockKnock dann nur mit den neuesten Versionen von macOS funktionieren wird, während das Programm doch gerade für Nutzer älterer macOS-Versionen, die keine Sicherheitsupdates mehr bekommen, wichtig sein könnte.

Ich habe ihm dann eine kleine Demo-App geschickt, die alle mittels SMLoginItemSetEnabled() persistenten Apps auf dem Mac registriert, im Prinzip eine Objective-C-Implementation von
plus Herausfiltern der persistenten Apps, die er nun in einem Update in die im Prinzip jetzige Version, die auch weiterhin auf alten macOS-Versionen laufen wird, einbauen will. Damit dürfte das Problem dann gefixt sein.

Der für mich selbst überraschendste Ort für eine persistente App auf meinem Mac, den mir meine Demo-App anzeigte, war übrigens /Library/Printers/hp/Frameworks/HPDeviceMonitoring.framework/Versions/1.0/Helpers/HP Device Monitor Manager.app

Besten Dank Weia! Im Namen aller KnockKnock-Nutzer