Frage:
Wie kann man eine iPhone / Android-App härten, damit es schwierig ist, sie zurückzuentwickeln?
kumar
2012-02-02 03:56:34 UTC
view on stackexchange narkive permalink

Dies sind die folgenden Ziele, die ich im Auge habe:

  1. Machen Sie die App schwer zu knacken, da die Binärdatei einige geheime Token enthält.
  2. Wenn dies noch möglich ist Kann die App jemandem oder sich selbst mitteilen, dass sie geknackt wurde (z. B. anhand einer Prüfsumme oder eines Zertifikats oder des Betriebssystems, das dies für die App ausführt), und Maßnahmen ergreifen? Die App-Binärdatei kann infiziert werden oder fehlerhafter Code kann injiziert werden, während sich das Programm im Speicher befindet. Daher sollten vorgeschlagene Methoden in der Lage sein, beide Fälle zu behandeln.
  3. ol>

    Ich verwende diese Plattformen:

  • iPhone [Betriebssystem: iOS, Sprache: Ziel-C]
  • Android [Betriebssystem: Android, Sprache: Java]

Bitte berücksichtigen Sie nicht die Kosten und Entwicklungszeiten, da dies eine wichtige App für das Publikum ist. Es ist großartig, wenn ich die Fragen für beide Plattformen beantworten kann. Vielen Dank für Ihre Zeit und Aufmerksamkeit.

Bearbeiten 1 : Sind diese Schutzklassen nicht dokumentiert? Ich sehe keine Dokumentation unter den Apple-Dokumenten. Hat jemand eine Idee, ob diese von Nutzen sind?

Bearbeiten 2 : Codesign für Mac OS X wurde mit der Option -o kill zum Signieren geliefert Binärdateien, sodass das Betriebssystem sie immer dann beendet, wenn eine Binärdatei nicht mit der Prüfsumme im Zertifikat übereinstimmt. Hier detailliert [Strg-F 'Optionsflags']. Gibt es so etwas für iOS?

Bearbeiten 3 : Ich denke darüber nach, eine Kombination dieser Ideen zu verwenden. Falls also jemand hierher kommt, könnte dies helfen. Einwegfunktion & Oblivious Transfer.

Wenn diese App für das Publikum von entscheidender Bedeutung ist und sie bereit ist, viel Geld und Zeit zu investieren, sind Ihre Gegner wahrscheinlich bereit, viel dafür auszugeben, sie auch zu brechen. Alles, was auf einer Plattform außerhalb Ihrer Kontrolle ausgeführt wird, kann so analysiert und geändert werden, dass die App es selbst nicht erkennen kann. Es mag Möglichkeiten geben, dies zu erschweren, aber es ist nur eine Frage der Ressourcen / des Aufwands.
Was Sie erwähnen, ist ein echtes Problem und daher der Wahnsinn. Trotzdem wollte ich selbst herausfinden, ob es überhaupt etwas gibt, um dies zu verhindern. Ich habe erfahren, dass iOS eine Funktion hat, mit der eine App ihre Zertifikate oder ähnliches überprüfen kann und die sich selbst zerstören kann, wenn sie sich positiv auf ihre Infektion auswirkt. Ich recherchiere darüber.
Vier antworten:
Tom Leek
2012-02-02 04:48:55 UTC
view on stackexchange narkive permalink

Grundsätzlich funktioniert das Ziel '1' nicht. Reverse Engineering funktioniert einfach zu gut. Mit der Android-Version wird es besonders einfach, da Java sehr einfach zu dekompilieren ist (unter Android wird ein bestimmtes Bytecode-Format verwendet, da die Java-Implementierung Dalvik ist, nicht das "wahre" Java, sondern das Prinzip bleibt). Mit der iPhone-Version wird es jedoch auch nicht so schwer sein (Objective-C wurde in ARM-Code kompiliert, nicht das Schwierigste, das jemals zerlegt und herausgefunden werden konnte).

Ziel '2' funktioniert auch nicht. Erstens sind Reverse Engineering und Datenextraktion nur passiv, sodass die Anwendung unverändert bleibt. Daher kann die Anwendung nichts tun, um festzustellen, dass ein solches Reverse Engineering stattgefunden hat. Es ist auch einfach, Anwendungscode zu ändern, um interne Tests zu umgehen. Dies ist die Cracking-Technik Nummer 1, mit der der Kopierschutz von Spielen seit den frühen 1980er Jahren (zumindest) umgangen wird.

Das Beste, auf das Sie hoffen können, besteht darin, Benutzer in zwei Kategorien aufzuteilen: diejenigen, die einen Jailbreak haben Telefon, und diejenigen, die nicht. Auf einem iPhone ohne Jailbreak können nur von Apple pflichtgemäß genehmigte Apps installiert und ausgeführt werden. Dies verhindert die Installation einer modifizierten, nicht offiziellen App, die Ihre "geheimen Token" auf eine Weise verwendet, die Sie nicht möchten. Jailbreaking ist genau das, was Leute tun, um nicht genehmigte Apps zu installieren, und es scheint relativ einfach zu sein.

Sie können auch versuchen, Angreifern das Leben zu erschweren, indem Sie Ihre geheimen Token sehr oft erneuern und ständig neue Versionen veröffentlichen Ihrer App. Genau das tun Anbieter von Spielekonsolen mit ständig neuen "Firmware-Versionen", die Benutzer herunterladen müssen, um mit den neueren Spielen spielen, die neueren Filme anzeigen oder eine Verbindung zu einem Spielernetzwerk herstellen zu können. Dies ärgert auch die Benutzer, so dass dies nicht gerade billig ist.

Es wäre viel einfacher für Sie, wenn Sie dafür sorgen könnten, dass die "geheimen Token" benutzerspezifisch sind. Wenn ein Token-Wert übermäßig extrahiert wird, können Sie ihn auf diese Weise trotzdem auf Ihrem Server auf die schwarze Liste setzen (ich gehe davon aus) Ihre App verwendet die Token, um irgendwo eine Verbindung zu einem Server herzustellen.

Beachten Sie, dass es der Heilige Gral aller Spiele ist, Daten in einer bereitgestellten Anwendung geheim zu halten oder andernfalls die betrügerische Verwendung dieser Daten zuverlässig zu erkennen Redakteure und Filmverlage auf der ganzen Welt. Zuletzt habe ich gehört, dass die großen Player wie Sony und Warner es noch nicht gefunden haben, und das liegt nicht daran, es nicht zu versuchen.

Wir erwägen aktiv, Telefone mit Jailbreak fernzuhalten. Außerdem verfallen die Token alle eine halbe Stunde oder weniger, aber es ist nicht möglich, dass der aus der Binärdatei geladene Code selbst infiziert wird. Wenn sich eine App das Privileg auf Betriebssystemebene gewähren kann, ist das nicht ein echtes Szenario? Die Token sind ebenfalls benutzerspezifisch, aber der Server würde nicht wissen, ob eingehende Anforderungen Identitätswechsel oder von der realen Client-App stammen, es sei denn, ein Benutzer erkennt und meldet aktiv Verstöße.
@kumar:-Umkehrer können und werden jeden dieser Schutzmaßnahmen umgehen. Lassen Sie dieses Problem am besten in Ruhe und verschieben Sie alles Wertvolle auf die Serverseite
@kumar - Möglicherweise können Sie Personen nicht daran hindern, Ihre Anwendung auf einem Telefon zu verwenden, das einen Jailbreak aufweist oder verwurzelt ist.
@Ramhound Ja, es ist in der Tat sehr schwierig, die Installation ausschließlich auf Geräte ohne Rootberechtigung zu beschränken, aber bisher scheint dies unsere zweitbeste Wahl zu sein.
Der Teil dieser Antwort "Benutzer in zwei Kategorien aufteilen" ist ein schlechter Rat. Ich schlage nicht vor, auf Geräte ohne Jailbreak zu zählen. Benutzer haben Geräte mit Jailbreak, und Sie können sie nicht stoppen, wenn sie geschickt genug sind, um MDM-, EMM-, MAM- oder MCM-Richtlinien zu verhindern, indem Sie diese Apps vor der Installation zurückentwickeln, möglicherweise die Binärdateien patchen oder die Laufzeit mit Methoden-Swizzling oder der patchen mögen.
this.josh
2012-02-02 08:06:20 UTC
view on stackexchange narkive permalink

Wie kann man eine iPhone / Android-App so hart härten, dass es schwierig ist, sie zurückzuentwickeln?

Das Verhindern des Reverse Engineering von Software ist ein schwieriges Problem.

Es ist ein außerordentlich schwieriges Problem, das Reverse Engineering von Anwendungssoftware auf einer allgemeinen Computerplattform mit schwacher Hardwareunterstützung (PC, iPhone oder Android-Telefon) über einen längeren Zeitraum (Monate) zu verhindern.

Anstatt die gesamte Anwendung zu schützen, besteht eine übliche Alternative darin, den Schutz der von der Anwendung verwendeten kritischen Daten zu versuchen und den Schutz der gesamten Anwendung aufzugeben.

[1] Machen Sie die App schwer zu knacken, da die Binärdatei einige geheime Token enthält.

Hier wird das Konzept "Daten schützen" vorgestellt. Was die Anwendung wirklich schützen soll, sind einige wichtige Daten: die geheimen Token.

Wie schützen Sie Daten, wenn die Anwendung sich nicht selbst schützen kann?

Sie übergeben die Verantwortung zum Betriebssystem. Es gibt zwei Arten von Schutz, die Betriebssysteme bieten können: Zugriffskontrolle und Kryptografie. Die meisten Schutzmaßnahmen, die wir verwenden, wenn wir das Lesen von Daten zulassen oder verweigern oder eine bestimmte Aktion ausführen, sind Zugriffskontrollen.

Eine Zugriffssteuerung verwendet als Eingabe eine Aktion und eine Kennung, wer die Aktion ausführen möchte. Die Ausgabe ist entweder Genehmigen oder Verweigern der Berechtigung zum Ausführen der Aktion. Eine Zugriffssteuerung verwendet einen Satz oder Regeln oder eine Tabelle, um zu bestimmen, ob ein Bezeichner eine Aktion ausführen darf.

Zum Beispiel: Alice hat ein Spiel FunGame auf einem Computer. Die Zugriffskontrolle des Computers hat die Regel, dass nur Alice FunGame ausführen darf. Bob setzt sich an den Computer und versucht, FunGame auszuführen. Die Zugriffskontrolle des Computers verwendet als Eingabe 'run FunGame' und 'Bob'. Basierend auf der Regel "Nur Alice darf FunGame ausführen" wird die Ausgabe der Zugriffssteuerung verweigert.

Die Zugriffskontrolle bietet eine direkte und allgemeine Möglichkeit, Entscheidungen über das Zulassen oder Verweigern zu treffen, während die Kryptografie eine indirektere Methode zum Zulassen oder Verweigern bietet. Mit Ver- und Entschlüsselung können wir Daten so transformieren, dass die Daten sinnvoll oder nicht sinnvoll sind.

Für die Ver- und Entschlüsselung ist mindestens ein kryptografischer Schlüssel erforderlich. Der Wert des Schlüssels wird zu einer Zugriffskontrolle mit den beiden Regeln "Erlaube jedem, der den Schlüssel hat, verständliche Daten zu nehmen und sie unverständlich zu machen" und "Erlaube jedem, der den Schlüssel hat, unverständliche Daten zu nehmen und sie verständlich zu machen". Wenn Daten unverständlich gemacht werden, werden die Daten nur vor dem Verstehen geschützt. Eine Person kann die Daten möglicherweise noch lesen, sie werden jedoch nicht in der von ihnen verstandenen Form vorliegen.

Beachten Sie, dass der Schlüssel anstelle der Kennung eines Akteurs zur kritischen Komponente wird. Jeder, der den Schlüssel hat, egal wie er ihn erhält, kann auf die Daten zugreifen. Dies macht das Speichern des Schlüssels zu einem Problem. Wenn Sie den Schlüssel auf demselben System wie die Daten speichern, stellen Sie jedem die Möglichkeit zur Verfügung, auf Ihre Daten zuzugreifen. Aus diesem Grund müssen Passphrasen auswendig gelernt werden. Das Speichern einer Passphrase speichert den Schlüssel (Passpharase) in Ihrem Kopf anstatt auf dem System.

Um Ihre Token zu schützen, können Sie die Zugriffskontrollen des Betriebssystems verwenden oder die Token oder beides verschlüsseln. Wenn jemand ein Betriebssystem hat, das seine eigenen Zugriffskontrollen nicht erzwingt (iPhone mit Jailbreak oder gerootetes Android-Telefon), können Sie sich nicht auf die Zugriffskontrollen des Betriebssystems verlassen. Solange sich der zum Verschlüsseln Ihrer Token verwendete Schlüssel nicht auf demselben System befindet wie die verschlüsselten Token, bleiben Ihre Token auch dann geschützt, wenn das Betriebssystem gefährdet ist.

Behalten Sie jedoch den Schlüssel bei Aus dem fraglichen System ist ein weiteres schwieriges Problem, das als Schlüsselverwaltung bezeichnet wird.

[2] Wenn es immer noch geknackt werden kann, kann die App auf irgendeine Weise jemandem oder sich selbst mitteilen, dass es geknackt wurde (z. B. anhand einer Prüfsumme oder eines Zertifikats oder des Betriebssystems, das dies für die App tut) und nehmen etwas Action?

Die App-Binärdatei kann infiziert werden oder fehlerhafter Code kann injiziert werden, während sich das Programm im Speicher befindet. Daher sollten vorgeschlagene Methoden in der Lage sein, beide Fälle zu behandeln.

Das Konzept, ein Datenelement zu untersuchen, um festzustellen, ob es seit seiner letzten Überprüfung unverändert ist, wird als Integritätsprüfung bezeichnet. Eine effiziente Methode zur Bewertung des Status eines Datenblocks wird als kryptografisches Hashing bezeichnet. Um eine Integritätsprüfung durchzuführen, müssen Sie zuerst den kryptografischen Hash eines Datenelements berechnen und dann den resultierenden Hashwert schützen. Berechnen Sie zu einem späteren Zeitpunkt den kryptografischen Hash für dasselbe Datenelement neu. Vergleichen Sie den neu berechneten Hashwert mit dem geschützten Hashwert. Wenn die beiden Werte identisch sind, bleiben die Daten unverändert. Wenn sich die beiden Hashwerte unterscheiden, wurden die Daten geändert.

Sie können die im Speicher befindliche Anwendungsbinärdatei als Datenelement behandeln und eine Integritätsprüfung durchführen. Sie können die Anwendungsbinärdatei im Speicher auch als Datenelement behandeln und eine Integritätsprüfung durchführen.

Das Konzept, ein laufendes Programm zu untersuchen, um festzustellen, ob es wie geplant verarbeitet wird, wird als Bescheinigung bezeichnet. Das Überprüfen des gesamten vom laufenden Code verwendeten Speichers ist normalerweise nicht möglich, sodass die Bescheinigung normalerweise etwas Einfacheres überprüft, z. B. die Werte bestimmter Datensätze oder den Status des laufenden Programms und dessen Übergang zwischen den Status. Eine Bescheinigung ist schwer zu erreichen, daher wird sie in kommerzieller Software nicht häufig verwendet.

atdre
2012-02-02 08:46:54 UTC
view on stackexchange narkive permalink

Obwohl es sich um einige wirklich intelligente selbstmodifizierende (z. B. Packen) und selbstüberprüfende Codemethoden für Obj-C, Java / Dalvik, IPA, JAR und APK handelt, glaube ich, dass sie alle so einfach sind wie untergraben als ihre ASM-, C-, C ++ -, PE- und ELF-Cousins. Die Fähigkeiten von Reverse Engineers sind im Jahr 2012 weltfremd.

Mein Vorschlag ist, Ihr gesamtes geistiges Eigentum auf der Serverseite zu belassen und jede Aktion oder Untätigkeit sorgfältig zu authentifizieren und zu autorisieren, ähnlich wie bei Nicht-Rootkits MMORPGs fangen Betrüger (z. B. PunkBuster, aber nicht ganz).

Mobile Apps sollten zu einfach sein und dem Benutzer NIEMALS vertrauen - genau wie jede clientseitige App.

Richtig - aber die mobile Kommunikation ist die meiste Zeit nicht so toll - das Problem tritt erneut auf, da der Code gezwungen ist, auf die Clientseite zu migrieren, um Leistungs- und Kommunikationsprobleme zu kompensieren
Claudio Lacayo
2012-10-06 07:16:42 UTC
view on stackexchange narkive permalink

Es mag als erfolgloses Unterfangen erscheinen, Reverse Engineering wirklich zu verhindern, aber ich denke, der Gedanke hier ist, es für Angreifer schwieriger zu machen. Im Folgenden finden Sie einige Vorsichtsmaßnahmen, die Sie als Entwickler treffen können, um sich besser gegen Dekompilierung unter Android zu schützen:

  1. Schreiben Sie einige der Hauptfunktionen in nativem Code (Android NDK).
  2. Verwenden Sie Verschlüsselung
  3. Logik auf serverseitig verschieben
  4. Verschiedene Formen der Verschleierung anwenden (Variablen teilen, Skalare für Objekte heraufstufen, Variablenlebensdauer ändern, Codierung ändern, Instanzvariablen neu anordnen, Verschlüsselungskennungen neu aufteilen, split / Arrays falten / zusammenführen, Vererbungsbeziehungen ändern) Dies sind nur Beispiele für die Verschleierung von Daten. Schauen Sie sich die Kontrollverschleierungen an. Sie werden feststellen, dass diese Methoden schlampigen Code fördern und den Wartungsaufwand erhöhen - Leute, die Ihre App umkehren, werden Sie jedoch hassen.
  5. ol>

    Dies sind nur einige Beispiele, die ich Ihnen sehr empfehlen würde Lesen Sie dieses Dokument zu Java-Verschleierungstechniken. Die Techniken können an jede Sprache angepasst werden. Viel Glück.

      1 '' Eine Taxonomie verschleierter Transformationen '', Computer Science Technical Reports 148 (1997), https://researchspace.auckland.ac.nz/handle/2292/3491 .  


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...