Archive for Jun. 2013

Android RE - Pool Master Pro

In diesem Post wird es um ein die Basics von Android Reverse Engineering gehen. Das Ziel ist eine Billiard-App namens “Pool Master Pro”. Dazu zunächst einmal ein Vorher/Nachher Bild:

Billiard1

Billiard2

Das Ziel ist es also, die relativ kurze “Aim Linie” zu verlängern, dass wir präzise über den ganzen Tisch zielen können.

Android basiert einer Java VM, und dies ist mehr oder wenig gut zu decompilieren. Dabei entpacken wir erst ein mal die APK (im Zip umbenennen) und sehen u.a. eine “.dex” Datei. Dort ist der komprimierte Source drin. Mit Hilfe des Tools Dex2Jar erzeugen wir uns eine einigermaßen lesbare .jar-Datei.

Allerdings gibt es auch ein weiteres Tool für Android De-und Recompiling names apktool. Dieses nette Tool entpackt alle Ressourcen, Decodiert das XML-Manifest und wandelt auch die .dex-Datei in eine Art Java-VM-Assembler (smali) um (wie bei .NET MSIL). Dieses werden wir nachher patchen. Aber zunächst zu der “Java-Analyse” dank JD-gui.

Die “Aim Line” ist im Optionsmenu an oder ausstellbar. Daher hat dort meine Analyse begonnen. Wir durchsuchen also den ganzen smali-Code nach dem String “Aim” und werden in der Main.smali fündig:

Weiterlesen

5 people like this post.

Reversing ist kein Ponyhof - Intercafe 2013 (die letze)

Hallo meine treuen Blogleser ;-)

Auf bitten einer Person hab ich mir Intercafe 2011 bzw 2013 nochmal angeschaut. Über Intercafe habe mir bereits vor 2 Jahren den Kopf zerbrochen, die damals entstanden Artikel sind in der Serie unten verlinkt. Mit mehr Lebensweisheit und vorallem Erfahrung habe ich also einen weiteren Versuch gestartet, das tückische System zu überlisten.

Wie immer geht es zunächst um die Registrierung des Programms. Dabei ist der Mechanismus bei 2013 genau der selbe wie der bei 2011. Wie in den vorherigen Posts nach zu lesen ist, wird ein Name, ein Softwarecode und ein Softwarekey verlangt. Diese Daten werden nach durchlaufen eines Offline-Checks über eine verschlüsselte Verbindung zum Server übertragen. Wenn diese Daten passen, so ist man registriert. Wenn nicht, so sendet der Server die Anzahl der Tage, die die Testversion schon abgelaufen ist. Da ich auf dem selben PC vor 2 Jahren gearbeitet hab, ist auch das Testdatum das vor 2 Jahren. Somit ist meine Software bereits seid 684 Tagen abgelaufen.

Im letzten Post habe ich von einem Base64-String erzählt, der wohl die Lizenzdaten bereitstellt. Mit dieser Erkenntnis bewaffnet, schaute ich mir diese Lizenzklasse weiter an. Da diese inzwischen in eine ziemlich lesbare, exterene Lib ausgelagert wurde, konnte man sie auch dementsprechend gut analysieren. Aber zunächst etwas Code, der die Server-Response auf eine Login/Registrationsmessage darstellt.

public static void A(string DKSStateString, string st, string string_0, string DKSStateString, string st, string st, string st, string st, string DKSStateString, string st)
{
	try
	{
		e9.C = Convert.ToBoolean(st);
	}
	catch
	{
		e9.C = false;
	}
	e9.E = CLConvertFunctions.ConvertObjectToBool(st);
	e9.A = (E.A(DKSStateString) as CLRegistrationEntry);
	if (string.IsNullOrEmpty(e9.A.RegistrationCode))
	{
		e9.f = "DEMOVERSION";
	}
	e9.G = string_0;

Ziemlich unleserlicher Salat, nicht? Diese Funktion schaltet das Programm frei, oder auch nicht. Denn in dem ersten Parameter wird eine Base64-Serilisierte Klasse übergeben, die im Anschluss als “CLRegistrationEntry” (9te Zeile) gelesen/deserialisiert wird. Wenn nun der Registrations-Code in dieser Struktur “NullOrEmpty” ist, so handelt es sich um eine Demoversion. Weiterlesen

12 people like this post.