Apples A10-Chip ist anfällig für den checkra1n-Jailbreak. Damit können Hacker noch heute das iPhone X oder ältere Geräte „entsperren“, selbst wenn Apple das Betriebssystem aktualisiert.

Da Apple allerdings in modernen Macs einen T2-Chip integrierte, der vor allem sicherheitsrelevante Aufgaben übernimmt, sind auch alle Macs von der Sicherheitslücke betroffen.

Hack mit modifiziertem USB-C-Kabel

Nun haben dieselben Personen, die die Lücke aufspürten und nachstellten, ein spezielles USB-C-Kabel angefertigt. Sie kauften dazu vom Schrott ein spezielles Kabel, mit dem Apple selbst seine Macs auf andere Weise anspricht. Solche Debug-Kabel haben bei Apple intern Codenamen wie „Kong“, „Kanzi“ oder „Chimp“. Nun sollte das gekaufte Kabel aller Wahrscheinlichkeit nach verschrottet werden, gelangte aber irgendwie doch in fremde Hände. Die Spezialisten nutzten Reverse-Engineering als Technik, um die Funktion nachzuempfinden und bauten das Kabel nach.

Nun haben sie ein eigenes Kabel, mit dem sie in der Lage sind, Apples Macs – einfach ausgedrückt – auf besondere Weise anzusprechen. Sie können nun aber die Sicherheitslücke ausnutzen und zeigen in einem Video, wie das in der Praxis aussehen kann. In einem weiteren Video treten Ramtin Amin und seine Kollegen sogar den Beweis an, die Booteinstellungen des Macs überschrieben zu haben. Sie änderten dazu das Boot-Logo des Computers.

Modifiziertes Kabel soll in Serie gehen

Vermutlich nicht für jedermann zu kaufen, sehr wohl aber in bekannten Kreisen, wollen die Hacker das Kabel in Zukunft auch in größeren Stückzahlen anfertigen und verkaufen. Während es für die „Szene“ interessant ist, den Mac auf diese Weise zu entsperren, können dunkle Gestalten hingegen auch Schadsoftware auf dem Mac installieren, zum Beispiel einen Keylogger. Das ist möglich, da der T2-Chip auch die Aufgabe hat, die Tastatureingaben zu steuern. Was eigentlich von Apple gut gedacht war, entpuppt sich nun als Sackgasse. Das Unternehmen muss die Lücke vermutlich mit einer neuen Version des Chips schließen, wahrscheinlich einem T3-Chip.

Einzig positiv ist, dass die hier gezeigte Methodik eben erfordert, dass Angreifer sich Zugriff zum Computer verschaffen, und zwar physikalisch und nicht nur übers Netzwerk.

[mn-youtube id="uDSPlpEP"]-T0

Am Ende kann man sich Szene vorstellen wie in Kinofilmen, in denen Hacker einen USB-Stick an einen Computer anstecken, um Daten zu entwenden.

Es ist möglich, dass Apple durch Software-Updates den Hackern das Leben schwerer machen wird. Doch ohne Änderungen am Chipdesign läuft man Gefahr, ein Hase- und Igel-Spiel daraus zu machen, bei dem man immer einen Schritt hinterher ist.

Der Beitrag Wegen T2-Chip: Modifiziertes USB-C-Kabel kann MacBook Pro gefährden erschien zuerst auf Macnotes.de.

Laut eines neuen Berichts des Boy Genius Report (BGR), in der Vergangenheit meist eine sehr zuverlässige Quelle, will Apple die medizinischen Anwendungsmöglichkeiten der Apple Watch weiter verstärken und Diabetikern durch neue Sensoren zur Messung des Blutzuckers eine Möglichkeit zur einfachen Behandlung bieten.

Kommt jetzt der große Auftritt des Debug-Ports?

Sowohl Berichte über einen Sensor zur Messung des Blutzuckers als auch die Gerüchte rund um intelligente Armbänder mit eigenen Sensoren sind nicht neu, BGR berichtet nun jedoch, dass diese neuen Features sehr bald schon kommen könnten, entweder auf der WWDC oder mit Vorstellung der neuen Generation der Watch im Herbst wäre das bereits möglich. Während vorherige Berichte zur Blutzuckermessung noch vermuteten, dass Apple dafür ein zusätzliches Gerät benötige, hat BGR dazu andere Informationen.

Die smarten Armbänder, die BGR zudem schon bald vermutet, sollen es Apple ermöglichen, weitere Sensoren anzubieten, ohne den Preis der eigentlichen Uhr zu erhöhen. Denkbar wäre, dass ein Blutzucker-Sensor nicht direkt in die Watch integriert wird, sondern über ein eigenes Band als Zubehör angeboten wird.

Bereits bei Veröffentlichung der ersten Apple Watch wurde bekannt, dass diese unterhalb des Anschlusses für Armbänder einen sechs-poligen Anschluss bieten, über den die Watch unter anderem aufgeladen werden kann. Aktuell ist dieser Anschluss bei allen Uhren durch eine Kappe verdeckt, möglich wäre jedoch eine Nutzung dieses Anschlusses für die Messung des Blutzuckers, damit könnten auch alte Watch-Generationen mit den neuen Armbändern kompatibel sein.

Der Beitrag Apple Watch: Apple arbeitet an Diabetes-Behandlungshilfe und intelligenten Bändern erschien zuerst auf Macnotes.de.

Lösung: Umtausch

watchOS 3.1.1 sollte, ähnlich wie die anderen Veröffentlichungen, Fehler beheben. Das scheint aber nicht ganz funktioniert zu haben. Nutzer stellten fest, dass die Apple Watch nach dem Update um Hilfe bat. Sie gab eine Webseite an, auf der es hieß, man solle einen Hard-Reset durchführen. Der hat bei den Betroffenen aber auch nichts gebracht und in dem Fall soll die Uhr in einen Apple Store gebracht werden. Dort wurde sie dann umgetauscht.

Was genau die Ursache ist, ist nicht bekannt. Allerdings deuten die Umstände darauf hin, dass es sich um einen Software-Bug handelt, da relativ viele Geräte betroffen sind, die vor dem Update einwandfrei liefen. Betroffen sind anscheinend vor allem Apple Watch Series 2. Sie werden in Apple Stores umgetauscht, da sie nicht mehr weit genug hochfahren, um sie auf dem „normalen“ Weg mit einer anderen Firmware zu versehen. Dafür müsste man vom Debug-Anschluss Gebrauch machen, was aber auch die Techniker im Apple Store nicht können.

In der Folge hat Apple das Update komplett zurückgezogen. Wer jetzt nach der Aktualisierung sucht, dem wird watchOS 3.1 angeboten, falls die Version schon installiert ist, wird sie als aktuell angesehen. Wer watchOS 3.1.1 herunterladen konnte, die Installation aber noch aufschob, kann das Update ebenfalls nicht installieren, da es nicht mehr verifiziert werden kann.

Der Beitrag watchOS 3.1.1 für Apple Watch wieder zurückgezogen erschien zuerst auf Macnotes.de.

Ehemaliger Apple-Entwickler im Interview

Bob Messerschmidt, der vormals bei Apple angestellt war, hat in einem Interview mit Fast Company ein paar Geschichten aus seiner Apple-Zeit erzählt. Er kam 2010 nach Cupertino, als Apple ein anderes Unternehmen gekauft hat. Messerschmidt half bei der Entwicklung des Pulsmessers der Apple Watch mit.

Er erzählte, dass einige Sensoren eigentlich anders aufbauen wollte. Denn seine Vorstellung sah vor, dass die Sensoren nicht in der Uhr selbst, sondern im Armband versteckt werden. Das allerdings wurde vom Industrial Design-Team um Jony Ive abgelehnt. Die Vorgabe war, dass man einfach das Armband wechseln kann. Sensoren im Armband erschweren das hingegen.

Messerschmidt erinnert sich auch an eine zweite Geschichte. Dabei hätten die Sensoren einen Platz in der Uhr gefunden. Jedoch hätte sie eng anliegen müssen. Auch dieser Vorschlag wurde vom Design-Team abgelehnt mit der Begründung, dass das nicht ist, wie der Nutzer die Uhr tragen wird.

Zwar fühlte sich Messerschmidt nach eigenen Angaben durch die vielen Vorgaben ein bisschen eingeengt, aber er nimmt aus der Apple-Zeit dennoch Positives mit. Denn es seien gerade die Grenzen, die ihm gesetzt wurden, die ihn zum Ausprobieren neuer Wege motiviert haben. Dass man so viel Wert auf den Nutzfaktor lege, sei zudem nur bei Apple der Fall – in anderen Unternehmen würde man derartige Kompromisse eingehen. Bei Apple hingegen wird eine Idee solange abgelehnt, bis sie gut funktioniert, so Messerschmidt.

Der Beitrag Apple Watch sollte Sensoren im Armband bekommen erschien zuerst auf Macnotes.de.

Es läuft

Die französische Webseite Nowhereelse.fr hat abermals ein paar Bilder zugespielt bekommen, die einen Prototyp des iPhone 7 zeigen sollen. Der Unterschied ist diesmal, dass der Prototyp komplett ist. Und zwar so komplett, dass er sogar funktioniert. Denn darauf läuft ein iOS mit der Build-Nummer „14A92340t“. Die aktuelle Build-Nummer von iOS 10 (Beta 4) lautet 14A5322e – es handelt sich also um eine Version von iOS 10.

Jedoch ist das kein iOS, das Apple zu veröffentlichen gedenkt. Es handelt sich um eine Debug-Version, wie sie schon öfter auf Prototypen gesehen wurde. Sie kommt mit einer Reihe von Tools, die eigentlich nur für Apple sind. Weitestgehend soll damit getestet werden können, ob alle Komponenten und Sensoren ordnungsgemäß funktionieren.

Wo die Fotos sind, ist auch ein Video nicht weit, das dasselbe Gerät zeigt mit der angepassten Firmware in Aktion. Wir haben es für euch an den Artikel angehängt.

Der Beitrag iPhone 7: Funktionierender Prototyp im Video gezeigt erschien zuerst auf Macnotes.de.

Anhand einer Zeitleiste auf der WebKit-Homepage kann man den Werdegang des Web Inspector nachverfolgen.¹ Im Januar 2003 wurde Apples Browser Safari der Öffentlichkeit vorgestellt, im Sommer desselben Jahres in Version 1.0 veröffentlicht. WebKit ist die Render-Engine in Safari und mittlerweile einer Vielzahl anderer Browser.²

Web Inspector aus 2006

Im April 2005 erschien erschien Safari 2.0 und im Juni desselben Jahres wurde Safari zu WebKit zu Open-Source-Software. Es dauerte von da an nur gut ein halbes Jahr bis der Web Inspector das Licht der Welt erblickte. Am 15. Januar 2006 wurde die erste Version des Web Inspectors veröffentlicht. Das Debugging-Tool konnte damals allerdings nicht viel mehr als den DOM in einer Baumansicht anzeigen und die zugehörigen CSS-Regeln zu den Elementen.

In der Zwischenzeit wurde der Web Inspector in WebKit optisch vollkommen überholt und um viele Funktionen erweitert, kann die Geschwindigkeit vom Laden von Ressourcen bestimmen, Scripte auf Webseiten bei der Ausführung unterbrechen, um sie auf etwaige Fehler hin zu untersuchen, und vieles mehr.

Der Beitrag WebKit: Web Inspector 10 Jahre alt erschien zuerst auf Macnotes.de.

WordPress 4.3 grillt den Server

Vor Kurzem ist WordPress 4.3 erschienen, das einige eher unspektakuläre Änderungen an der Oberfläche hat, dafür einige unter der Haube. Beispielsweise wollte man ein Problem mit den Schlagworten angehen, wenn es zufällig genauso heißt wie eine Kategorie. Schön! Weniger schön ist ein kleiner Bug, der sich eingeschlichen hat. Der Bug sorgt dafür, dass die Server-Last ins Unermessliche steigt. Schuld daran ist ein Cronjob, der Tags bereinigen soll. Leider gibt es bei der Entwicklung einen Fehler; der Cronjob wurde mit vertauschten Parametern aufgerufen. Das wirft keinen Fehler, sorgt aber dafür, dass die Abbruchbedingung niemals erfüllt wird – die Datenbank wird „vollgemüllt“ und der Server immer langsamer. Das Problem ließ sich eingrenzen, wenn der „Load“ stieg und stieg, obwohl man temporär sämtliche Plugins deaktivierte und ein Standard-Theme keine Fehler behobt. Der lang diskutierte Fix von Samuel Wood (Otto) im Forum brachte die Lösung. Vielen Dank dafür!

Notepad-Entwickler am Werk?

„Der beste Code-Editor ist immer noch Notepad“ – viele sogenannte Programmierer vertreten scherzhaft diese Meinung, weil Notepad dermaßen einfach gestrickt ist, dass man sich selbst um Luxus wie Code-Einrückungen und korrekte Parameter kümmern darf. Wenn der Code dennoch funktioniert, ist man ein bemitleidenswerter Nerd, aber der eigene „Skill“ ist dann offenbar „Over 9000„. Hätte der verantwortliche WordPress-Entwickler eine richtige IDE genutzt, wäre das nicht passiert, denn dank Code-Hinting hätte man nur mal auf den Bildschirm schauen müssen und die Reihenfolge der Parameter wäre klar gewesen. Bam!

Niemand hat große Projekte

In mir macht sich langsam der Verdacht breit, dass niemand von den Entwicklern seinen Code mal auf gut besuchten (und entsprechend großen) Projekten testet, sondern immer nur in der Theorie mit irgendwelchen Scripten auf nicht-reale Weise abklopft. Denn bei kleineren Seiten merkt man so etwas freilich nicht. Doch gerade bei Scripten wie WordPress, das Abermillionen Installationen zählt, ist es von oberster Dringlichkeit, dass so etwas nicht passiert, wenn man die Software für stabil erklärt. Andernfalls schadet das dem Ruf und kostet den Anwendern im schlimmsten Fall jede Menge Geld. Debuggen, langsame Seiten (die Google überhaupt nicht mag) und Benutzer, die das Weite suchen, weil die Seite nicht laden mag, sind die Folge.

WordPress kann nicht mit Performance umgehen

Dieses Problem zieht sich leider durch WordPress wie ein roter Faden. WordPress hat einen schlechten Quellcode (dafür eine herausragende Usability, immerhin) und die Software ist langsamer als sie sein müsste. Das fängt bereits bei der Datenbankklasse an. Auf Macnotes beispielsweise wurde testweise ein selbst entwickeltes Plugin integriert. Prinzip-bedingt gibt es den Fall, dass alle vorhandenen Beiträge bearbeitet werden müssen – SELECT ID, post_content FROM wp_posts WHERE post_type = 'post' AND post_status = 'publish'. In einer Schleife werden alle post_content-Zeilen angepasst und per UPDATE-Anweisung wieder gespeichert. Mit der WordPress-Datenbank-Klasse dauert das 31 Minuten. Eine halbe Stunde! Die exakt selben SQL-Abfragen hat PDO in 11 Sekunden abgefrühstückt. Aber bei WordPress diskutiert man lieber jahrelang über Sinn oder Unsinn von MySQLi und wenn PHP 5.5 dann eine Deprecated-Meldung für MySQL-Funktionen wirft, wird – aber nur dann, wenn PHP 5.5 oder neuer installiert ist! – MySQLi verwendet.

Suchfunktion – für die Tonne

Das war ein schönes Beispiel für Missmanagement bei WordPress, aber wenn man auf der Startseite 10 Beiträge abfragt und in der Beitragsansicht nur einen, merkt man das fast nicht. Aber es gibt ja noch die Suche, die ist ebenfalls hoch ineffizient. Sucht man beispielsweise in der Frontend-Suche bei Macnotes nach „iPhone„, generiert WordPress daraus folgende Suchabfrage:

SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts WHERE 1=1 AND (
((wp_posts.post_title LIKE '%iphone%') OR (wp_posts.post_content LIKE '%iphone%')))
AND (wp_posts.post_password = '')
AND wp_posts.post_type IN ('post', 'page', 'attachment', 'tablet', 'entwickler', 'event', 'game', 'plattform', 'publisher', 'cheats')
AND (wp_posts.post_status = 'publish' OR wp_posts.post_status = 'closed')
ORDER BY wp_posts.post_date DESC LIMIT 0, 10

Laut phpMyAdmin dauert es 0,7 Sekunden, bis allein der Query fertig ist. Das Problem ist gleich die erste (nicht sinnlose) WHERE-Bedingung: Weder die Spalte post_title noch post_content sind mit einem Index versehen. Jetzt könnte man argumentieren, dass post_content vom Typ longtext ist und deshalb ein Index nicht möglich ist – stimmt. Aber ein FULLTEXT wäre möglich. Dafür müssen nur folgende Änderungen gemacht werden:

ALTER TABLE wp_posts ENABLE KEYS;
ALTER TABLE wp_posts ADD FULLTEXT(post_content);
ALTER TABLE wp_posts ADD FULLTEXT(post_title);

Und die Suchabfrage muss leicht geändert werden:

SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts WHERE 1=1 AND (
((MATCH(wp_posts.post_title) AGAINST ('iphone')) OR (MATCH(wp_posts.post_content) AGAINST ('iphone'))))
AND (wp_posts.post_password = '')
AND wp_posts.post_type IN ('post', 'page', 'attachment', 'tablet', 'entwickler', 'event', 'game', 'plattform', 'publisher', 'cheats')
AND (wp_posts.post_status = 'publish' OR wp_posts.post_status = 'closed')
ORDER BY wp_posts.post_date DESC LIMIT 0, 10

Das Ergebnis: Die SQL-Abfrage dauerte nur noch 0,1 Sekunden, ist also siebenmal so schnell, das Ergebnis ist identisch. Herausragend.

Problem ist weit verbreitet

Leider sind derartige Probleme in der Open-Source-Gemeinde extrem weit verbreitet und nicht nur auf WordPress beschränkt. Es ist nur so, dass WordPress am Ende immer noch der beste Kompromiss aus Ressourcen bei Google und Benutzbarkeit ist.

Beispielsweise scheint ModX an manchen Stellen ebenfalls mit Notepad entwickelt worden zu sein. Dass man sich den Problemen nur bedingt annimmt, liegt mit Sicherheit auch an der geringeren Verbreitung. Bei ModX hat man, zumindest in den früheren Versionen, offenbar noch nicht allzu viel von Indexen in der Datenbank gehört. Jeder Fliegenschiss wurde in der Datenbank protokolliert und wenn man bei Google News einen schönen Treffer hatte, über mehrere Tage hinweg, wurde der Server-Load irgendwann dreistellig. Und dann ist da die Sache mit den großen Seiten – das Admin-Menü von ModX lädt alle verfügbaren Seiten per JavaScript in eine Navigation. Das mag ja ganz praktisch sein, wenn man nur 10 statische Seiten hat, aber bei mehreren Tausend Newsartikeln, kann man sich schon mal einen Kaffee aufkochen, während das Backend lädt.

„Dann verbessere doch den Code, es ist Open Source!“

Ja, das würde man gerne. Das Problem ist, dass die meisten der anderen Entwickler das Problem nicht sehen, weil sie anscheinend nicht mit gut besuchten Seiten zu tun haben. Diese haben nämlich eigene Programmierer, die dann entweder neue Hardware kaufen dürfen oder den Code bis zur Unkenntlichkeit verändern, damit die Software läuft. Versucht man dann, wie oben beim Vorschlag, PDO zu verwenden, einen validen Punkt anzusprechen, stößt man auf taube Ohren. Es könnte ja 1-2 Plugins geben, die sich nicht an die Coding-Richtlinien halten und davon kaputt gehen. Das ist wichtiger, als dass man selbst mit gutem Beispiel vorangeht und einen sauberen, performanten Code verbreitet. My Ass!

„Dann mach halt einen Fork, es ist immer noch Open Source!“

Forken ist, besonders wegen kleinerer Änderungen, ziemlich albern. Beispielsweise macht es nicht allzu viel Sinn, die Usability des Backends von WordPress neu zu erfinden, weil die recht gut ist. Wenn es nur wenige Änderungen sind, die man selbst gerne im Core-Paket hätte, ist es einfach sinnlos, einen Fork anzufertigen, weil man dann bis ans Ende aller Tage dem Original hinterherläuft, um die Änderungen in den eigenen Fork zurückzuportieren. Und außerdem ist Meckern ohnehin attraktiver als selbst Hand anzulegen, das wissen wir ja alle.

Der Beitrag Gastartikel: Arbeiten an WordPress nur Notepad-Entwickler? erschien zuerst auf Macnotes.de.

Bundles sind eine gute Gelegenheit, sich neue Programme anzuschaffen und dabei kräftig zu sparen. Momentan hat Bundle Hunt ein attraktives Paket im Angebot, bei dem man 9 Programme zu einem Preis von 39,99 Dollar (37,15 Euro) abstauben kann – einzeln würden die Programme zusammen 460 Dollar kosten (427,33 Euro) kosten; es lassen sich also 91% sparen.

Web-Design, Spotlight-Ersatz, Datenrettung

Mit RapidWeaver 6 (normalerweise knapp $90) lassen sich Webseiten gestalten, erstellen und veröffentlichen, ohne dass man besondere HTML-Kenntnisse benötigt. Das Tool LaunchBar (normalerweise 30 Dollar) ist ein Ersatz für die Spotlight-Suche in OS X und findet alle Arten von Informationen, entweder auf dem Mac oder im Internet. Typed kostet normalerweise 20 Dollar und stellt einen Text-Editor für den Mac dar, der einfach zu bedienen ist und damit eine Menge Zeit spart. Ein weiteres, eher teures Programm, ist Mac Data Recovery Guru, das für sich genommen 79 Dollar wert ist und versehentlich gelöschte Dateien wiederherstellt oder zerstörte Daten wieder lesbar macht. CandyApple richtet sich an Vektor-Designer und ermöglicht das Erstellen und Bearbeiten von Vektor-Grafiken.

Spaces, Vorlesefunktion und WLAN-Debugging

Apple hat im Laufe der OS-X-Updates immer wieder die in Mac OS X 10.5 Leopard erstmals vorhandenen Spaces umgebaut – wem die ursprüngliche Version noch am ehesten zusagt, der sollte einen Blick auf TotalSpaces2 (normal 18 Dollar) riskieren, denn das Tool bringt die altbewährte Funktion wieder zurück, während ein Icon in der Menüzeile darüber informiert, auf welchem Space man sich momentan befindet. Der Narrator (allein $30) ist in der Lage, digitalen Text vorzulesen. An Fotografen richtet sich Intensify, das einzeln knapp 15 Dollar kostet und in der Lage ist, Rauschen aus Fotos zu entfernen und weitere Effekte zu generieren. Die teuerste App im Bundle ist mit 149 Dollar NetSpot Pro, mit der sich drahtlose Netzwerke mit MacBooks anzeigen, optimieren und untersuchen lassen, falls es Probleme gibt.

1-Klick-Import in 1Password

Wer sich für das Bundle entscheidet und das Tool 1Password bereits besitzt, kann außerdem von einem neuen Feature Gebrauch machen, das alle Lizenz-Codes mit einem Klick in den eigenen Tresor überträgt – auf diese Weise sind die Lizenzschlüssel immer verfügbar und müssen bei Bedarf nicht lange gesucht werden.

Der Beitrag Bundle Hunt: 9 Mac-Apps mit 91% Rabatt erschien zuerst auf Macnotes.de.

Die französische Expertin Axelle Apvrille hat ein ausführliches Paper (PDF) mit einer Analyse zur AdThief-Malware veröffentlicht, die erstmals im März 2014 bekannt wurde.

AdThief manipuliert Adcodes unter iOS

Anders als die Malware „unfold“ nimmt AdThief nicht die Apple-Login-Daten von Nutzern ins Visier, sondern manipuliert Adcodes. AdThief (auch „spad“ genannt), ersetzt vorhandene Entwickler-API-Keys für Werbenetzwerke mit fremden. Im Ergebnis werden so mögliche Werbeeinnahmen von Entwicklern, die auf Werbung innerhalb ihrer Apps vertrauten, auf das Konto der Hacker umgeleitet.

AdThief nutzt Cydia Substrate

Nachgewiesen wurde, dass die iOS-Malware Cydia Substrate als Schnittstelle verwendet, um Ersetzungen auf Dateiebene durchzuführen. Entsprechend sind einzig Nutzer von jailbroken iPhones, iPads oder iPod touch überhaupt betroffen.

Die Liste der betroffenen Werbenetzwerke wirkt umfangreich. Sie umfasst 15 Anbieter beziehungsweise deren SDK oder andere Softwareschnittstellen:

• Youmi
• Sina Weibo
• Vpon
• Umeng MobClick
• Umeng App Union
• AdSaga
• MdotM
• InMobi
• MIX SDK
• Domob
• AdWhirl
• AdsMogo
• Google Mobile Ads SDK
• AderMob
• PolySDK
• GuoHe
• Komli Mobile

Demgegenüber fällt die Zahl der verseuchten Geräte relativ gering aus. Diese Einschätzung ist vor dem Hintergrund zu sehen, dass die AdThief-Malware für iOS vor allem den chinesischen Markt im Blick hat. Denn das Gros der betroffenen Adkits (8 von 15) betrifft ausschließlich chinesische Werbung. Vier Netzwerke aus den USA und zwei aus Indien sind ebenfalls nicht von der Manipulation verschont geblieben.

Die Malware soll ungefähr 22 Millionen Bannereinblendungen zu eigenen Gunsten manipuliert haben. Der mögliche Umsatz ist entsprechend kein Pappenstiel.

Entwickler der iOS-Malware bekannt

Die Spezialistin aus Frankreich konnte anhand von ein paar Debugging-Kommentaren, die im Quellcode der Malware hinterlassen wurden, den vermeintlichen Entwickler ausfindig machen. Es handelt sich um einen chinesischen Hacker mit dem Nickname „Rover12421“ (alias „zerofile“). Dieser hat bereits bestätigt, Teile des Codes geschrieben zu haben, streitet aber ab, mit der Verbreitung von AdThief zu tun haben. Entsprechend ist die iOS-Malware offenbar als Auftragsarbeit zu sehen.

„Rover12421“ betreibt ein eigenes Blog und arbeitet hauptsächlich an Android-Hacks, die man über sein Github-Repository herunterladen kann. Nach dem Bekanntwerden seiner Mitarbeit an der iOS-Malware AdThief sollte man jedoch Abstand davon nehmen, sie zu nutzen.

Der Beitrag Paper zu iOS-Malware AdThief veröffentlicht erschien zuerst auf Macnotes.de.

MAMP ist eine Entwicklungsumgebung für OS X, die einen Apache-Server, PHP mit vielen Modulen und MySQL bereitstellt. Enthalten ist beispielsweise die GDLib, die die Manipulation von Grafiken mit PHP ermöglicht. Leider stößt GD an seine Grenzen, wenn man beispielsweise TIFF-Dateien verarbeiten möchte. Imagick schließt diese Lücke. Außerdem wird Imagick nachgesagt, bessere Resultate zu erzielen als GD. Leider ist Imagick trotz entsprechender Ankündigung bislang nicht in MAMP enthalten. Wir haben MAMP Pro verwendet und möchten es mit PHP 5.5 nutzen, da diese Version auch auf dem Server installiert ist.

Installation von Homebrew

Da wir mithilfe von Homebrew noch mehr Pakete installiert haben, ist dieser Paket-Manager unser Mittel der Wahl. Homebrew kann, ähnlich wie Mac Ports, für Linux entwickelte Tools und Programme auf OS X installieren. Wer es noch nicht installiert hat, kann es sich auf der Webseite herunterladen. Im Terminal sollte dann der Befehl brew zur Verfügung stehen.

Abhängigkeiten auflösen

Bevor sich das PHP-Modul Imagick mittels Homebrew installieren lässt, müssen ein paar Abhängigkeiten geklärt werden. Der Dank für diesen Tipp geht an Daniel Feder von Stack Overflow. Benötigt wird PHP und dupes von Homebrew, das sich mit folgenden Befehlen installieren lässt:
$ sudo brew tap josegonzalez/php
$ sudo brew tap homebrew/dupes

Das ist notwendig, weil wir Imagick in MAMP einbinden wollen, Homebrew aber davon ausgeht, dass wir PHP als System-Dienst benötigen.

Installation von Imagick

Die Installation des PHP-Moduls von Imagick ist dann relativ einfach. Hierfür muss nur folgende Zeile im Terminal nachgeschoben werden:
$ sudo brew install php55-imagick

Wird das Paket für andere PHP-Versionen benötigt (5.3 oder 5.4), kann die „55“ im Paketnamen entsprechend angepasst werden. Die Erweiterung befindet sich im Anschluss unter dem Pfad /usr/local/Cellar/php55/5.5.6/lib/php/extensions/no-debug-non-zts-20121212/imagick.so, bei anderen PHP-Versionen variiert der Pfad entsprechend.

Erweiterung laden

Im Anschluss muss die Erweiterung nach Lehrbuch in die php.ini eingetragen werden, damit PHP diese auch lädt. Dies muss in MAMP Pro aus dem Menü geschehen, da MAMP ansonsten die php.ini wieder auf die alten Werte zurücksetzt. Dafür muss aus Ablage, Vorlage editieren, PHP der Eintrag „PHP 5.5.3 php.ini“ ausgewählt werden. Hier gilt es, die folgende Zeile hinzuzufügen:
extension=/usr/local/Cellar/php55/5.5.6/lib/php/extensions/no-debug-non-zts-20121212/imagick.so

Die Gratis-Version von MAMP bietet diesen Komfort nicht. Hier muss in /Applications/MAMP/conf/php5.5.3 die Datei php.ini mit einem Texteditor bearbeitet und obige Zeile hinzugefügt werden.

Library not loaded: /usr/local/lib/libfreetype.6.dylib

Der Neustart des MAMP-Servers schlug bei uns an dieser Stelle fehl. Aus dem Menü X kann man in MAMP Pro die Logfiles auflisten lassen, beim kostenlosen MAMP muss man im Ordner /Applications/MAMP/logs die Datei php_error.log selbst mit einem Editor öffnen, um an die Fehlermeldung zu kommen. In unserem Fall sah sie so aus:
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/Cellar/php55/5.5.6/lib/php/extensions/no-debug-non-zts-20121212/imagick.so' - dlopen(/usr/local/Cellar/php55/5.5.6/lib/php/extensions/no-debug-non-zts-20121212/imagick.so, 9): Library not loaded: /usr/local/lib/libfreetype.6.dylib
Referenced from: /usr/local/lib/libMagickWand-6.Q16.1.dylib
Reason: Incompatible library version: libMagickWand-6.Q16.1.dylib requires version 17.0.0 or later, but libfreetype.6.dylib provides version 16.0.0 in Unknown on line 0

Tobias Eisenschmidt hat hierfür den entscheidenden Tipp parat gehabt. Das Problem ist, dass Imagick die LibFreeType-Bibliothek in Version 17 oder neuer benötigt, MAMP sie aber in Version 16.0.0 mitbringt. Die Lösung ist, dass OS X die aktuellste Version selbst mitbringt – aber dafür muss man MAMP verbieten, an der eigenen Quelle nach den Bibliotheken zu fahnden. Dafür muss die Datei /Applications/MAMP/Library/bin/envvars mit einem Texteditor geöffnet werden. Die letzte Zeile lautet export DYLD_LIBRARY_PATH und muss auskommentiert werden, indem eine Raute davor gesetzt wird. Das sieht dann so aus: #export DYLD_LIBRARY_PATH. Anschließend lässt sich MAMP wieder aktivieren und ein Blick in die PHPInfo sollte die Verfügbarkeit von Imagick bescheinigen.

Der Beitrag How To: MAMP mit Imagick unter OS X Mavericks ausstatten erschien zuerst auf Macnotes.de.