Decompile aber richtig?!

[Haeretik]

Hi,
ich will ne App decompilieren, schauen wie sie aufgebaut ist, evt auch 1-2 ändern und dann wieder als .apk ausschmeissen.
Folgendermaßen bin ich vorgegangen.

Mit apktool decopiled
Projekt in eclipse geladen
ohne irgendwas zu ändern direkt wieder auf meinnexus 4 gestartet

dann kommt die Fehlermeldung

"App" wurde beendet.

Hab schon diverse sachen probiert, unter anderem den META-INF ordner der originalen app in meine neue gepackt usw. Nix hilft, dann kann ich die app erst gar nicht installieren ^^
Man muss doch ne app dekompilieren können, in eclipse laden und danach wieder komilieren.

Hoffe jemand kann mir helfen

PS. hab sie auch schon versuch neu zu signen...

 

[NMMAA]

Die App ist das geistige Eigentum des Entwicklers.
Du hast kein Recht Änderungen an ihr vorzunehmen.

 

[mike_galaxy_s]

Kann man Apps irgendwie gegen decompilen schützen? Denn ich will nicht, dass später mal irgendwer meine App decompiliert und den Source-Code kopiert, usw..

 

[Haeretik]

Warum denkt bei solchen Fragen jeder dass man geistiges Eigentum stehlen will?
Die App könnte von mir sein, ich hab lediglich meine Eclipse Workspaces verloren.
Oder die App könnte Open Source sein, oder ich habe mir das Einverständniss des Entwicklers geholt oder oder oder....
Warum gleich Diebstahl? Oder hattet ihr bisher nur mit solchen Fällen zutun und denkt deshalb Vorurteilig?

Zurück zum Thema...

PS. Ersteres trifft wohl am ehesten zu

 

[DagobertDokate]

Jaja oder der Hund hat sie gefressen

Also was lernst du daraus?
Backup ist dein freund Versionsverwaltung sowieso.
Wenn es open Source ist ist auch der Code verfügbar -> FAIL
Wenn du die Einverständniss hast kann er dir auch den Code geben -> FAIL

Wenn erstes wirklich zutrifft.. dann weißte ja jetzt wie es geht und passt nächste mal am besten besser auf und backups oder Cloudsicherung oder oder oder...

lg. Dagobert

 

[reneph]

Kann man Apps irgendwie gegen decompilen schützen?

Nein kannst du nicht. Man kann es versuchen, indem man (z.B. mit ProGuard) den Code verschleiert, aber i.d.R. sieht es eher schlecht aus.

@Dagobert: Wenn es seine Apps wären, dann hätte er im Ausgangspost nicht geschrieben "decompilieren, schauen wie sie aufgebaut ist" - er wüsste wie seine eigenen Apps aufgebaut sind...

 

[MaxRink]

Obwohl wir Decompilierung verhindern können, ist es noch immer nicht möglich, das bloße Disassemblieren des Bytecodes zu stören. Es gibt allerdings einige einfache Tipps, die dem motivierten Angreifer schnell die Lust am Bytecode verderben. Wir beschreiben einige Regeln, die das Entschlüsseln von Bytecode oder das Umgehen einer Seriennummerneingabe erschweren. Dazu gehört:

Verwendung von Methodennamen und Klassennamen aus Nullen, dem Buchstaben O, Einsen und dem Buchstaben l. Einige freie Obfuscatoren lassen sich leicht anpassen, sodass sie solche Bezeichner erstellen.

Im Quellcode sollten keine lesbaren Zeichenketten vorkommen. Füge jeder Klasse eine individuelle Entschlüsselungsfunktion zu. Bessere Obfuscate-Programme machen das automatisch.

Konstanten sollten über mathematische Funktionen errechnet werden. Erwartet das Programm zum Beispiel die Taste KeyEvent.VK_F1, wird der Compiler automatisch für die Konstante den Wert 0x70 einsetzen. Natürlich können wir diesen Wert auch dynamisch berechnen.

Verwendung vieler bedingter Sprünge, die aber unnütz sind.

Wenn die Möglichkeit besteht, den Bytecode direkt zu manipulieren, können legale, doch unsinnige Bytecode-Sequenzen eingefügt werden. Dynamischer Java-Bytecode hat sich (noch) nicht durchgesetzt, wäre aber möglich. Denkbar ist, an bestimmten Stellen einer Klassendatei Zeichen zu schreiben, dann diese Datei über den Klassenlader zu laden und die Information anschließend wieder zurückzuschreiben. An der »bestimmten Position« könnte etwa eine Variable stehen.

Teile des Programmcodes sollten auf Tabellen zurückgreifen, die dynamisch berechnet werden.

Ein Startbildschirm mit Grafik und Text (Splash-Screen beziehungsweise Nag-Screen) kann leicht zurückverfolgt werden. Daher sollte besser darauf verzichtet werden.

Bei einer Seriennummer und einem Ablaufdatum lässt sich die Systemzeit natürlich zurücksetzen. Wir können kontinuierlich in eine Datei verschlüsselt ein Datum schreiben und dies ständig erhöhen. Ist das Datum des Rechners kleiner als das Datum in der Datei, hat der Benutzer zu schummeln versucht. Ein alternativer Weg ist plattformabhängig: Einige Systemdateien weisen das Datum vor dem Zurückstellen auf, wie etwa SYSTEM.DAT.

Werden Seriennummern eingegeben, so sucht der Angreifer nach Textfeldern. Besser ist in diesem Fall eine Lowlevel-Event-Verarbeitung. Wir legen einen Listener zum Beispiel auf etwas ganz anderes, beispielsweise ein Label. Die Ereignisse werden abgefangen und bearbeitet. Aus dem AWT-Event holen wir dann die Zeichen heraus. Da der Angreifer aber auch nach Eventhandlern sucht, ließe sich auch die System-Queue abhorchen.

Checksummen von Klassen bilden, die eventuell angezapft werden könnten. In einer anderen Klasse lässt sich dann diese Checksumme testen. Zum Entschlüsseln von Daten können auch weitere Klassendateien verwendet werden. Nun mein Lieblingstipp: Zeitmessungen vornehmen, um zu erkennen, ob jemand versucht, das Programm zu debuggen. Zudem lassen sich Cracker leicht befriedigen, indem ihnen eine offensichtliche Prüfung einer eingegebenen Seriennummer angeboten wird. An weiteren Stellen können aber ein Test auf die Seriennummer und subtile Fehlfunktionen ins Programm eingewoben sein. Das Programm hat kleine Fehler oder Unzulänglichkeiten, falls die Seriennummer diese Tests noch nicht erfüllt.

Lässt sich durchaus erfolgreich machen.

 

[StefMa]

Vielleicht postest du lieber die Quelle statt ein Zitat welches so umformatiert total bescheuert zu lesen ist

 

[mike_galaxy_s]

Das ist auch keine Dauerlösung, denn da kennt man sich Erstens selber nicht mehr aus, Zweitens macht es viel mehr Aufwand und Drittens wird das Programm dann viel komplizierter.

 

[Otandis_Isunos]

Das Decompilieren mit ProGuard erschweren

 

[reneph]

@MaxRink: Das man Code verschleiern kann, das habe ich schon gesagt. Ändert dennoch nichts daran, dass sich Dekompilieren nicht verhindern lässt - und was anderes sagt dein hier rein kopiertes auch nicht aus.

Hat eben auch alles seine Kehrseiten. Wenn man dann Bugreports über die Developer Console bekommt, dann sieht man eben auch nur Stacktrace der zuvor verschleierten Funktionen. Dann fängt man selbst wieder an seine eigene App zu dekompilieren, um heraus zu finden, welche verschleierte Funktion denn eigentlich gemeint ist, wo der Fehler aufgetreten ist... Fazit nach wie vor: verschleiern ja, verhindern nein.

 

[rihntrha]

Angesehen davon ist es eh egal. Bisher wurden alle Programme gecrackt (egal welcher Kopierschutz), egal wie viel Mühe sich der Hersteller gab.

Und geht es um andere Gründe (z.B. vermeintliche Sicherheit durch ein geheimes Übertragungsprotokoll) dann ist das Konzept eh fehlerhaft.

Und Code klauen... selber schreiben dürfte einfacher sein als irgendwelche Funktionen auf diese Weise zu klauen.

cu

 

[amfa]

Zum Ursprungsthema:
Du müsstest doch ne Fehlermeldung bekommen.
Da sollte drinstehen warum die App sich einfach beendet.

Und dann musste mal schauen warum es nicht funktioniert.


@Alle anderen
Warum so einen Aufwand treiben?
Ganz ehrlich habt ihr wirklich Angst das euch jemand Code klaut?
Wenn ja, wie viel Code habt ihr "geklaut" (Damit meine ich auch OpenSource verwendet oder im Prinzip schon überhaupt auf das Android Framework zugegriffen).

Ich muss meinen Code ja nicht zwingend in die Welt pusten (OpenSource etc.)
Aber diese Verschleierung finde ich immer irgendwie affig.
Funktional kann man eine App immer nachprogrammieren.
Und selbst wenn jemand Code klaut, so what?
Soll er doch. Sollte er damit eine Konkurenzapp bauen, die am Ende besser ist als eure, liegt das garantiert nicht daran, dass bei euch Code geklaut wurde

 

[Haeretik]

Leider kommt keine Fehlermeldung bis auf "Appname" wurde beendet beim starten der app
In Eclipse bekomm ich auch keine Meldung, installiert wird sie ja von Eclispe, nur das öffnen am Smartphone geht nicht.

Damit das geblubber hier mal ein Ende hat:
Ich hab in der Tat Code von einem Kerl genommen der ein Template zur verfügung gestellt hat (zur freien Verwendung möchte ich anmerken). Ich habe das Template also meinen Wünschen nach angepast, ne .apk kompiliert, PC neu gemacht, kein Workspace gesichert und nu steh ich da mit ner .apk die wieder in Eclipse rein will und danach natürlich auch wieder raus Denn ich möchte ja wieder daran arbeiten und einige Dinge eben nachschauen die ich vll für was anderes verwenden kann.

 

[Greenstar]

Hast du schon versucht alle Dateien neu zu erstellen und den Code rein zu kopieren; nicht gerade praktisch, vielleicht hilft es aber.