Apple Mac OS X

iPhone Software 2.0: Jailbreak und Unlock mit pwnage 2.0

Dirk Eisenberg — Sun, 20 Jul 2008 18:35:31 GMT

Schon ganz ungeduldig habe ich den Blog des iphone Dev Teams beobachtet und auf das Release von pwnage 2.0 gewartet. Dieses Tool soll in der Lage sein bei meinem iPhone 2G den jailbreak und unlock durchzuführen. Um die Spannung zu nehmen, es hat geklappt und für alle die keinen MAC daheim haben, gibt es einen Möglichkeit den unlock auch durchzuführen.

Ein kurz Anleitung wie der Prozess durchzuführen ist findet man hier. Im weiteren Verlauf der Kommentare finden sich auch Links zu den Bootloader. Ich wollte eigenlich nur eine Hürde beschreiben. Wie bekommt man sein iPhone in den DFU mode?

1. iPhone über USB andocken
2. iPhone über die Tastekombination Power + Home ausschalten (ca 7s)
3. Power + Home Taste ca zwei weitere Sekunden gedrückt halten
4. Danach die Power-Taste loslassen und Home gedrückt halten bis iTunes das Geräte im Recovery erkennt. Der Monitor des iPhones muss schwarz sein.

Danach befindet sich das iPhone im DFU Mode und kann beliebige Images verdauen. Um ein Image (wie das von pwnage erzeugte) einzuspielen, einfach die alt-Taste (auf MAC) oder die CTRL-Taste gedrückt halten und dann auf Restore in iTunes drücken. Jetzt kann ein beliebiges .ipsw ausgewählt werden. So können auch Windows nutzer ihr iPhone unlocken wenn sie ein passendes .ipsw haben.

SMBIOS Daten unter Mac OS X lesen

Dirk Eisenberg — Sun, 24 Feb 2008 19:36:27 GMT

Die Daten aus dem System Management Bios geben Aufschluss über die vorliegende Hardware und können nutzbringend in der eigenen Software verwendet werden. Ich selbst wollte SMBIOS-Daten auch in einer Applikation auf einem Mac Book Pro verwenden. Um diese auslesen zu können habe ich ein wenig suchen müssen. Aus diesem Grund möchte ich hier eine Step-By-Step-Beschreibung zu diesem Thema weitergeben:

Wo findet man die SMBIOS Daten:

In der Dokumentation des Standards findet man einen Hinweis das sich zwischen zwei bestimmten Speicheradressen der Anchor-String "SMBIOS" verbirgt. Konnte dieser String gefunden werden, hat man die Offset-Tabelle für die SMBIOS-Daten im Speicher gefunden.

Wie kommt man an diese Daten:

Für diese einfache Frage ist die Antwort eigentlich auch sehr einfach. Man muss nur den Hauptspeicher des Rechner an der entsprechenden Stelle durchsuchen. Das ist auf alten Betriebssystemen wie DOS einfach möglich, auf modernen Betriebssystemen wie Windows, Linux oder Mac OS X nicht. Hier verwaltet der Kernel den Speicher und somit hat auch nur der Kernel Zugriff auf diesen. User-Space-Prozesse erhalten immer nur virtuelle Speicherseiten, also niemals den zu durchsuchenden Speicherbereich. Um doch an diesen Speicher zu kommen gibt es unter vielen Unix-System, sowie Linux und teilweise Mac des (k)mem-Device /dev/kmem. Auf dieses kann jedes User-Space-Programm zugreifen und somit auch die SMBIOS-Tabelle lesen. Windows bietet eine enstprechende Raw-Data-Tabelle die über WMI erreichbar ist. Ab Mac OS X 10.4 wurde dieses Device entfernt.

AppleSMBIOS.kext:

Statt sich jetzt eine eigene Kernel-Extension schreiben zu müssen, hat das Apple erledigt. Die AppleSMBIOS-Kernel-Extension bietet als IOService die Möglichkeit auf die SMBIOS-Daten zuzugreifen. Was ist also zu tun:

Wir müssen erstmal einen Komnuikationspunkt zum Darwin-Kernel aufbauen. Hierzu nutzen wir einen Mach-Port (es ist erstmal nicht weiter wichtig mehr darüber zu wissen)

mach_port_t myMasterPort;
IOMasterPort(MACH_PORT_NULL, &myMasterPort);
Also nächstes muss der AppleSMBIOS-IOService erstmal im System gefunden werden. Dabei werden Services in MAC OS X über eine Service-Identity identifiziert. Folgender Code sucht den SMBIOS-IO-Service:

CFMutableDictionaryRef myMatchingDictionary;
io_object_t foundService;

myMatchingDictionary = IOServiceMatching("AppleSMBIOS");
foundService = IOServiceGetMatchingService( myMasterPort, myMatchingDictionary );
Wurde der Service gefunden kann man mit dem Lesen der SMBIOS-Daten beginnen.

CFMutableDictionaryRef    properties    = NULL;
CFDataRef                 smbiosdata    = NULL;

IORegistryEntryCreateCFProperties( foundService,
                                   &properties,
                                   kCFAllocatorDefault,
                                   kNilOptions );

CFDictionaryGetValueIfPresent( properties,
                               CFSTR( "SMBIOS" ),
                               (const void **)&smbiosdata );
Jetzt stehen die SMBIOS-Daten zur Verfügung und müsse dem Standard entsprechend verarbeitet werden.

Abschluss:

Scheinbar gibt es hier und da ein kleines Problem mit der Abfrage von SMBIOS-Daten. Besonders wenn man in Verbindung mit netkas versucht Mac OS X auf einer anderen Hardware zu nutzen. Auch gibt es eine spezielle Anpassung um Probleme in Verbindung mit Adobe CS zu vermeiden.

Dynamische Libraries mit dem Applikations-Bundle verteilen

Dirk Eisenberg — Wed, 06 Feb 2008 23:03:02 GMT

auch auf einem Apple Mac nutzt man in der Regel dynamische Bibliotheken um komplexer werdende Software in verschiedene Module aufzuteilen. Wie auch unter Linux ist das aber so ein Sache wenn es dann um die Verteilung des gesamten Produkts geht. Die von Windows bekannte Side-by-Side-Execution greift leider nicht und somit such der Library-Loader eben nicht im lokalen Verzeichnis nach der Datei. Also was tun. Apple hat zu diesem Zweck dsa Konzept der Bundles. Bundles sind eigentlich nur festgesetzte Verzeichnisstrukturen, die sowieso hinter jeder Applikation die mit XCode erzeugt wird, stehen. In diese Struktur wird die Library an eine bestimmte Stelle gelegt und der Build-Prozess angepasst. Hierzu sind folgende Schritte nötig:

1. Library-Settings so anpassen das beim Linken immer relativ vom Verzeichnis des Executables referenziert wird.

Hierfür legt man in den Project-Settings des XCode-Projektes den Install-Path der Library wie folgt fest: @executable_path/../Frameworks/yourlib.dylib.

2. Einfühurng eines Custom-Build-Steps beim Erzeugen der eigentlichen Software einführen um die benötigten Libraries zu kopieren.

Hierfür nehmen wir die Croos-Referenz auf das Library-Projekt aus dem letzen Beitrag wieder her und ziehen die sich darin befindliche .dylib auf den eben erzeugte Custom-Build-Step (sieh Abbildung).

Wird nun das Hauptprojekt erzeugt, entsteht immer ein Applikations-Bundle was via Drag-n-Drop vom Benutzer installiert werden kann ohne das aufwändig Setupskripte Libraries an andere Stellen kopieren müssen. Das ganze ist dann nun nur noch hübsch in ein Disk-Image zu verpacken und fertig für den Rollout.

dylib - Cross Project Dependencies

Dirk Eisenberg — Sun, 27 Jan 2008 02:52:29 GMT

Nachdem ich die ersten Schritte auf meinem Mac erfolgreiche gegangen bin, rückt das erste Mac OS X - Projekt in Objective-C immer näher. Heute habe ich mich dann mit der korrekten Aufteilung meiner Software in verschiedene Libraries beschäftigt. Nun stand ich vor dem Problem wie sagt man XCode das man auf ein anderes Projekt verweisen möchte und erzeugt dabei eine korrekte Abhängigkeit für den Linker. Dieser soll natürlich die dynamische Library in Abhängigkeit der eingestellten Konfiguration nutzen. Die Antwort ist einfach aber nicht offensichtlich.

1. Cross Project Dependencies

Zuerst muss das referenzierte Projekt in den XCode-Baum eingebaut werden. Hierzu muss lediglich über das Kontext-Menu (Add->Existing Files) das entsprechende ausgewählt werden.

2. Referenziertes Projekt in den Linker einbinden

Jetzt kann das referenzierte Projekt im Tree-View über den kleinen Pfeil aufgeklappt werden. Es werde daduch alle Produkte des Projektes sichbar.

Einfach die entsprechende Library auswählen und zum linken durch den Hacken am rechten Zeilenende setzen:

Danach wird XCode wie erwartet im Debug-Build die Debug-Lib und im Release-Build die Release-Lib anziehen.

NSApp delegate

Dirk Eisenberg — Sun, 11 Nov 2007 11:37:37 GMT

Puh, es ist geschafft - Mein erster Computer von Apple ist da. Wie es sich für einen Software-Menschen gehört wurde natürlich gleich XCode installiert um die Fähigkeiten des Cocoa Frameworks und Objective-C auszuloten. In diesem Post möchte ich die Lösung eines Problems beschreiben welches ich erst nach einigem Suchen lösen konnte.

Was ist das Problem?
Jede Applikation im Cocoa Framework arbeitet mit einem NSApplication-Objekt (für die MFC Coder eine Art CWinApp). Jetzt möchte ich als Programmierer während der Initialisierungsphase meiner Applikation Code zur Ausführung bringen. Das ist ganz nützlich um Variable oder ähnliches anzulegen.

Klar wenn man MFC kennt, oder?
Klar dachte ich mir, da ich sowas in MFC-Applikationen schon oft erledigt habe. Einfach das CWinApp-Objekt abgeleitet und in InitInstance meine Sachen erledigt, wäre da nicht die Apple Dokumentation.

Delegates
In der Dokumentation zu NSApplication kann man nachlesen das es sehr gute Gründe geben muss um diese Klasse abzuleiten da hierzu auch einige Funktionen des Frameworks verändert werden müssen. So einfache Dinge wie Variablen initialisieren soll man doch lieber über ein NSApp-Delegate lösen. Gesagt getan und gleich mal etwas über Delegates nachgelesen um auf das nächste Problem zu treffen. Wie bekomme ich die setDelegate-Methode mit meinem Objekt als Parameter so früh ausgeführt?

Die Lösung
Nach langem Suchen und Probieren ist die Lösung doch denkbar einfach. Der Interface-Designer hält eine Objekt mit dem Namen First-Responder. Zusätzlich legt man sich ein Objekt seiner Klasse die als NSApp-Delegate funktionieren soll an. Diese beiden Objekte kann man jetzt in Beziehung setzen (ctrl + Mouse) und erzeugt somit ein Delegate von NSApplication. Über den Aufruf [NSApp->delegate myMessage.....] lässt sich mit dem Objekte auch kommunizieren. Natürlich werden alle Delegate-Nachrichten die Implementiert sind auch vom Framework aus angesprochen.