Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Software>Toast Titanium 20 frisch installiert, macOS verweigert den Start weil Malware drin enthalten?!

Toast Titanium 20 frisch installiert, macOS verweigert den Start weil Malware drin enthalten?!

LittleBOFH05.03.2517:52
Moin,

ich hab mir heute nach einigem Hin und Her ein Upgrade auf Toast Titanium 20 gekauft. Über den Installer die Software installiert, gewartet, dann versucht Toast zu starten => ging nicht:

Laut Support sei die Software x-mal überprüft worden und es sei definitiv keine Malware darin enthalten (was ich mir ehrlich gesagt auch nicht wirklich vorstellen kann). Ich sollte mal die Firewall deaktivieren, das Programm starten und danach die Firewall wieder reaktivieren. Hat aber erwartungsgemäß nichts gebracht.

Hat jemand eine Idee, woran das liegt? Oder wie man weitere Infos bekommt, _was_ genau macOS daran gefährlich findet?

macOS 15.3.1 auf einem MacBook Pro M2
Toast Titanium 20.3 (7890)
+3

Kommentare

Nebula
Nebula05.03.2519:28
Also bereits beim Installer bekomme ich eine Warnung. Laut Hilfe passt die Datei nicht zur Signatur und wurde offenbar manipuliert.



Ich habe die App mal mit Suspicious Package extrahiert und Apparency meint auch, da stimmt was nicht. Es fehlt auch eine Notarisierung, wobei ich nicht weiß, ob Suspicious Package die Ursache dafür ist.



Vermutlich wurde beim Deployment irgendwas vergessen. Evtl. kannst du ältere Versionen laden und installieren? Ich habe die bei Macupdate.com verlinkte Version genommen, die vom Roxio-Server stammt.

Hier mal die SHA-256-Checksummen von Installer und App.

sha256sum Toast\ 20\ Titanium.pkg  
bc4086b5166a8a635f10b24233106a67738b13edf7c50c69bc62753b0f82b52f  Toast 20 Titanium.pkg

ditto -c Toast\ 20\ Titanium.app - | sha256sum
987997935e2c51b2ecbeefbb45e34226e1f7822312bf35ab76926b80ce45147d  -

Und hier noch der Codesign-Hash, den der Support bestätigen müsste:

codesign -d --verbose=4 Toast\ 20\ Titanium.app 2>&1 | grep "CDHash="
CDHash=0e2834008521e604a2983157311594e323a009a1
„»Wir waren schon immer schamlos darin, großartige Ideen zu stehlen.« – Steve Jobs“
+5
Nebula
Nebula05.03.2519:42
Wenn ich vor dem Entpacken das Quarantäne-Bit löschen, bricht der Installer nicht mehr ab. Das Programm hat jetzt zwar einen anderen Hashwert, ist aber weiterhin fehlerhaft.

ditto -c Toast\ 20\ Titanium.app - | sha256sum
30df6d74c5343ba4a83de753fe59ef72859bb2465d962d2e94ec50a6b60ffb8a  -
„»Wir waren schon immer schamlos darin, großartige Ideen zu stehlen.« – Steve Jobs“
+3
Deichkind05.03.2520:26
Die in Nebulas Beitrag dargestellte Fehlermeldung kommt, wenn das Etikett mit der Notarisierung fehlt oder fehlerhaft angebracht ist. Gatekeeper geht dann davon aus, dass das Paket nicht bei Apple zur Notarisierung eingereicht und somit nicht auf anwesende Malware geprüft worden ist. Dass anscheinend selbst mit der Signatur des Entwicklers etwas nicht stimmt, kommt noch hinzu. Notarisierung und Signatur sind unterschiedliche Sicherheitsschichten.

Das ist aber anscheinend nichts Neues. Berichte "Roxio Toast Titanium 20 installation fails" gab es schon im Frühjahr 2023.
+7
LittleBOFH05.03.2521:10
Nebula
Ich habe die App mal mit Suspicious Package extrahiert und Apparency meint auch, da stimmt was nicht. Es fehlt auch eine Notarisierung, wobei ich nicht weiß, ob Suspicious Package die Ursache dafür ist.
Die beiden Programme kannte ich noch gar nicht. Vielen Dank für den Hinweis.
Nebula
Vermutlich wurde beim Deployment irgendwas vergessen. Evtl. kannst du ältere Versionen laden und installieren? Ich habe die bei Macupdate.com verlinkte Version genommen, die vom Roxio-Server stammt.
Habe ich auch mal, aber das lief genauso wenig. Soweit ich auf die Schnelle beurteilen kann unterscheiden sich die .pkg-Files dadurch, dass in dem, was der Roxio Installer geladen hat, ein paar Tools mehr enthalten sind, die installiert werden.
Nebula
Und hier noch der Codesign-Hash, den der Support bestätigen müsste:

codesign -d --verbose=4 Toast\ 20\ Titanium.app 2>&1 | grep "CDHash="
CDHash=0e2834008521e604a2983157311594e323a009a1
Das nützt nur wenig, wenn der Hash an sich zwar richtig ist, macOS aber dennoch das Programm nicht starten mag

Ich nerve einfach den Support weiter, und wenn das partout nichts bringt (wovon ich erstmal ausgehe ), probier ich mal, ob ich das Geld wieder zurückbekomme...
+3
Nebula
Nebula05.03.2522:05
Ich weiß nicht, wie Codesign arbeitet. Wenn's der erwartete und nicht der tatsächliche Hash ist, hilft das natürlich nichts. Wenn der Support Zugriff auf eine fehlerfreie Version hat, müssten sie auch einen andere SHA256-Hash haben als du. Bei Sequoia hat Apple ja nochmal was verschärft. Vermutlich haben sie ihre Software noch nie auf macOS 15 frisch installiert.
„»Wir waren schon immer schamlos darin, großartige Ideen zu stehlen.« – Steve Jobs“
+2
Marcel Bresink06.03.2508:34
Zu den Hash-Werten: Die Ermittlung der Prüfsumme über codesign ist völlig richtig, aber man darf in der Praxis nicht mit sha256sum eine Prüfsumme über das ausgepackte Programm berechnen, da das nicht aussagekräftig ist.

Es kann in Programmen Teile geben, die nicht konstant sind, sondern von macOS für das laufende System optimiert werden. Dazu zählt zum Beispiel das Prebinding von Code, oder die Lizenzquittung in App Store-Programmen, die Anpassung des Icons, früher auch das Abschalten von Sprachpaketen über den Finder. Codesign "weiß", welche Teile eines Programms konstant sein müssen und welche sich ändern dürfen.
+4
ssb
ssb06.03.2510:41
Mal abgesehen davon, dass ich Toast bzw. den jetzigen Eigentümer nicht mehr für vertrauenswürdig halte und daher eine andere Anwendung zum Brennen verwende (BURN)…

codesign nutzt die Entwicklerzertifikate zum signieren und keinen allgemeinen Hash, der vom Zertifikat unabhängig ist. Dann weiß - wie bereits erwähnt - codesign, was im Speicher landet und signiert nur das. Für jede VirtualMemory Page, die von dyld beim Start in den Speicher geladen wird, wird ein Hash-Wert in das Link-Edit-Segment geschrieben. Am Ende wird diese Hash-Tabelle erneut gehasht - das ist das, was im codesign-Block gespeichert wird. Wird die Anwendung also geladen, dann wird Speicherseite für Speicherseite mit dem Hash im Link-Edit-Segment verglichen - stimmt da etwas nicht, dann bricht dyld das Laden ab. Das betrifft aber nur Speicherseiten, die nicht per-se beim Laden dynamisch verändert werden, sondern oft erst später (zB Relocations, Initialized Data).

Soweit mal zum Verständnis von codesign - ich habe mich damit eine Weile intensiver auseinander gesetzt (Mach-O Binary Structures zerlegt, um diese zu verändern).

Notarization hingegen erstellt einen Hash eines „Deliverables“ - was ein DMG, ein ZIP oder entsprechendes sein kann. Das Package wird erst einmal inhaltlich geprüft und dann wird ein Hash erstellt, der dann auf Servern von Apple hinterlegt wird. Bei ein paar Dateiformaten kann man das „Ticket“ auch in das Binary „stapeln“, also einbetten. Dann muss bei gesetztem Quarantine-Flag Gatekeeper nicht mit dem AppleServer das Ticket prüfen sondern verwendet das eingebettete.

Was aber oft völlig falsch angegangen wird, gerade von Firmen, die traditionell nicht auf macOS zuhause sind (und Toast gehört jetzt dazu), ist die korrekte und umfängliche Notarisierung. So muss man erst einmal die App-Bundles notarisieren (und dann Stapeln), dann packt man das in das Package und muss dieses erneut notarisieren. Dabei ist wichtig, dass man das Package danach nicht mehr verändert. Daher würde ich DMG empfehlen, machen aber wenige. Gerne nehmen sie dafür ein ZIP und irgendjemand manipuliert das dann noch - oft auf einem Windows-Rechner, der zB mit einem AV-Tool irgendwas im ZIP hinterlässt - womit das Ticket gebrochen ist.

Glaubt mir - ich habe da mit dem Package aus eigenem Hause, welches an Mac-Kunden ausgeliefert wird, sehr lange basteln müssen. Ich habe zwar alles richtig gemacht, aber irgendwer hat dann wieder daran rumgepfuscht (oft unabsichtlich) und wir hatten immer wieder die Quarantine-Fehler mit der App-Translocation. Und warum? Meist weil irgendwer einfach nicht eingesehen hat, das auf einem Mac zu machen und es unberührt online zu stellen. Obwohl mittlerweile ein signiertes und notarisiertes DMG vom Build-Server erstellt und geteilt wird, kursiert immer noch ein ZIP, welches unter Linux erstellt wird und daher genau diese Merkmale nicht hat - nicht haben kann.

Es ist ein Drama, Windows-Menschen zu erklären, was Apple da macht und warum es gut ist, dass macOS da so streng ist.
+7
LittleBOFH06.03.2512:18
ssb
Mal abgesehen davon, dass ich Toast bzw. den jetzigen Eigentümer nicht mehr für vertrauenswürdig halte und daher eine andere Anwendung zum Brennen verwende (BURN)…
Danke für den Hinweis zu BURN, schaue ich mir gerne mal an.

ssb
codesign nutzt die Entwicklerzertifikate zum signieren und keinen allgemeinen Hash, der vom Zertifikat unabhängig ist.
(...)
Es ist ein Drama, Windows-Menschen zu erklären, was Apple da macht und warum es gut ist, dass macOS da so streng ist.
Schöne Erklärung eines offenbar Leidgeplagten , danke dir!
0
Nebula
Nebula06.03.2514:59
Marcel Bresink
Zu den Hash-Werten: Die Ermittlung der Prüfsumme über codesign ist völlig richtig, aber man darf in der Praxis nicht mit sha256sum eine Prüfsumme über das ausgepackte Programm berechnen, da das nicht aussagekräftig ist.
Deshalb habe ich ja ditto verwendet.
„»Wir waren schon immer schamlos darin, großartige Ideen zu stehlen.« – Steve Jobs“
-1
Marcel Bresink06.03.2515:21
Nebula
Deshalb habe ich ja ditto verwendet.

Das ändert nichts am Problem. Das Programm ist bereits aus dem pkg ausgepackt und irgendwohin kopiert, also kann es von macOS verändert worden sein.
0
giorgino06.03.2520:16
Ich habe noch einen Lizenzkey von Toast Titanium 20, das Programm jedoch aktuell nicht installiert, da momentan kein wirklicher Bedarf besteht. Kann man davon ausgehen, dass die aktuelle Version grundsätzlich auf allen Macs die vom TE geschilderten Probleme macht? Sonst könnte ich es mal auf meinem Mac mini M4 versuchen. macOS ist Sequoia 15.3.1
0
LittleBOFH06.03.2522:41
giorgino
Ich habe noch einen Lizenzkey von Toast Titanium 20, das Programm jedoch aktuell nicht installiert, da momentan kein wirklicher Bedarf besteht. Kann man davon ausgehen, dass die aktuelle Version grundsätzlich auf allen Macs die vom TE geschilderten Probleme macht? Sonst könnte ich es mal auf meinem Mac mini M4 versuchen. macOS ist Sequoia 15.3.1
Ob das auf allen Macs der Fall ist, kann ich natürlich nicht beurteilen. Da ich Toast früher auf meinem alten Intel-MacBook Pro (2012) laufen hatte, gehe ich davon aus, dass die Probleme auf neueren Geräten und/oder macOS-Versionen auftreten. Nebula hatte weiter oben ja erwähnt, dass Apple bei Sequoia wohl ein bissel was verschärft hat an Prüfungen, und Roxio hat das vermutlich (noch?) nicht auf einem frisch installierten System getestet.

Was ich mir vorstellen kann ist, wenn man Toast vorher unter einer älteren macOS-Version erfolgreich genutzt und dann einfach das OS aktualisiert hat, dass man Toast anschließend ohne Probleme unter dem neueren OS verwenden kann. Wie auch immer, Roxio müsste dringend etwas tun. Zumal Toast 20(.3) selbst schon ca. 1,5 Jahre alt und nach wie vor komplett Intel-only ist
Lustigerweise steht als Mindestanforderung auf der Homepage macOS 10.14 (64 Bit), aber Toast beinhaltet einige Frameworks, die noch 32-Bit-Intel-Code und manche gar 32-Bit-PPC-Code mitbringen
+1
Nebula
Nebula07.03.2512:13
Alles klar, dass heißt codesign errechnet den Hash und es wird nicht der erwartete Hash ausgegeben?
„»Wir waren schon immer schamlos darin, großartige Ideen zu stehlen.« – Steve Jobs“
0
LittleBOFH18.03.2521:49
LittleBOFH
Ich nerve einfach den Support weiter, und wenn das partout nichts bringt (wovon ich erstmal ausgehe ), probier ich mal, ob ich das Geld wieder zurückbekomme...
Mittlerweile habe ich nach ein paar Mails mit dem Support sogar tatsächlich das Geld zurückerstattet bekommen - die Software war schlicht unbrauchbar weil nicht startbar. Geht also.

Was mich nur wundert ist nach wie vor, dass der Hersteller das bislang offenbar selbst nicht festgestellt hat, geschweige denn einen Fix hierfür parat hat. Na, kann mir mittlerweile egal sein. Gibt es halt in Zukunft kein Toast mehr auf meinem System, sondern Alternativen wie das bereits erwähnte Burn.
+4
Fontelster
Fontelster19.03.2509:32
LittleBOFH
Was mich nur wundert ist nach wie vor, dass der Hersteller das bislang offenbar selbst nicht festgestellt hat, geschweige denn einen Fix hierfür parat hat. Na, kann mir mittlerweile egal sein. Gibt es halt in Zukunft kein Toast mehr auf meinem System, sondern Alternativen wie das bereits erwähnte Burn.

Ich hab Toast so ziemlich vom ersten Tag an benutzt, zuerst von Astarte, dann von Adaptec, (ebenso wie CD-DA und Jam) und schließlich Roxio. Und ich war lange sehr zufrieden.
Seit Corel den ganzen Bums gekauft hat, ist es zur kompletten Katastrophe geworden, mit Bugs ohne Ende. Dabei hab ich faktisch seit Jahren nur noch die Ton-Konvertieren-Funktion benutzt. Wieviele Bugs die anderen Funktionen enthalten weiß ich nicht, vermutlich ebenso viele.

Als ich vor kurzem wegen eines Bugs mit deren Support zu tun hatte, hat die anderen (von mir erwähnten Bugs) niemand interessiert. Geholfen wurde mir sowieso nicht.

Ich denke, das Teil ist Geschichte, sobald Apple Rosetta 2 einstellt. Einerseits verständlich, wer brennt heute noch CDs, aber dass die offensichtlich die Entwicklung schon lange eingestellt haben (32-Bit-Apps/PPC) und das weiterhin zum vollen Preis verkaufen …

Byebye Toast
+3
silversurfer2219.03.2509:38
nette Werbemails verschickt Roxio aber noch immer ... vorgestern sogar noch ... ABER ... es gibt in den Systemanforderungen KEINE Freigabe für macOS 15 !, nur 14.x.x ist freigegeben

+2

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.