Archive for Apr. 2016

RRT - Ein Auto Parken

Besser spät als nie! Hier der abschließende Post zu RRT - Eine Simulationsumgebung. Ich habe mich an einer typischen RRT Aufgabe Versucht: Parke das Auto in eine enge Parklücke und stelle es am Ende möglichst paralell zum Bordstein hin. Dabei nutzen wir genau das Automodell wie es im ersten Post eingeführt und verwendet wurde. Für anspruchsvollere Simulationen kann man z.B ein Auto mit Anhänger nehmen. Hier ist das Fahrverhalten nochmal komplett anders, RRT findet aber meist auch schöne Lösungen.

Das Interface der simplen Parksimulation hat ein paar Einstellmöglichkeiten spendiert bekommen. So können auch User die nicht im Sourcecode Werte manipulieren wollen mit der Simulation rumspielen. Ich freue mich übrigens auf Screenshots von euren schönsten Einparkmanövern in den Kommentaren ;)

rrt_new_interface

Bevor ihr allerdings mit Simulieren loslegen könnt, braucht ihr noch ein paar Informationen zur Simulationsumgebung: Die Umgebung ist 200 x 100 Pixel groß, das Auto startet bei (100,20) und will nach (102, 78). Dabei kann es Lenkwinkel von -50° bis +50° annehmen und dabei eine Stecke von -20 bis 20px pro “Schritt” zurücklegen. Der Lenkwinkel und die Geschwindigkeit kann jeweils mit einem Multiplikator versehen werden, die voreingestellten Werte liefern ganz gute Resultate.

Spannend wird es, wenn man das Verhalten des Autos einschränkt: Wie parkt es, wenn es plötzlich nur noch nach Rechts lenken darf? Oder der Rückwärsgang kaputt ist und nur vorwährtsfahrend einparken muss? Ein paar dieser Fälle sind weiter unten mit Gif und Erklärung zu sehen . Weiterlesen

4 people like this post.

EarthCore - Injecting, Sicherheit und Spieldaten

Earthcore: Shattered Elements ist ein Online Kartenspiel für Android und iOS, programmiert mit dem Unity Framework. Von den vier Handkarten spielt man drei auf das Spielfeld aus, wobei jede Karte eines von 3 Elementen hat: Feuer, Wasser oder Erde. Am Ende der Runde wird das eigene Kartenelement mit dem Element der gegnerischen, gegenüberliegenden Karte verglichen. Nun schlägt Wasser Feuer, Feuer Erde und Erde Wasser. Der Verlierer auf dem jeweiligen Feld bekommt Lebenspunkte abgezogen, die sich aus dem ausgespielten Kartenwert berechnen. Sollten sich gleiche Elemente gegenüberliegen, wird der Angriffswert jeweils für die nächste Runde gespeichert. Im Grunde also ein “Schere-Stein-Papier” auf drei Feldern gleichzeitig. Spannend wird das Spiel, wenn man die Skills der Karten dazunimmt. Man kann Karten auf Feldern tauschen, die Elemente von Karten ändern oder auch Direktschaden am Gegener verursachen. Mehr möchte ich an dieser Stelle garnicht über das Spiel erzählen, hier geht es um die Internals, das Injecten und natürlich das Daten auslesen.

earthcoreNicht ohne Grund habe ich direkt im ersten Satz erwähnt, dass das Spiel mit Unity entwickelt wurde. Für den Programmierer ist das praktisch, da er Plattformunabhängig und sogar mit .NET Programmieren kann. Für uns hat das den Vorteil, dass wir den kompletten Sourcecode unobfuscated vor uns liegen haben! Dabei befinden sich alle interessanten Klassen in der Assembly-CSharp.dll, die wiederrum in den Ressourcen der APK liegt. Zwar hat man alle Daten unverschlüsselt vor sich liegen, nur ohne die Möglichkeit des Auslesens oder Veränderns bringen uns die schönsten Klassenstrukturen nichts. Wir müssen also eigenen Code in die Android Applikation bekommen. Während schon bei dem Hearthstone-Artikel das CLRHosting mit Mono fehlschlägt, haben hier hier nichtmal die Möglichkeit den Mono Kontext zu kapern. Nach einigem hin und herüberlegen fiel mir eine passable Lösung ein: Benötigt ist ein Loader, der wiederrum weitere DLLs zur Laufzeit nachladen kann. Dieser Loader wird mit in die APK gepackt und muss nun irgendwo im Spiel aufgerufen werden um den eigenen Thread zu starten. Was ist da passender, als die Init-Funktion des Hauptmenüs? In Unity erbt jede Klasse die Renderlogik enthält von “MonoBehaviour”. Davon wird die Start()-Methode aufgerufen sobald die Klasse initialisiert wird, und genau hier packen wir einen call auf unsere statische Loader-Klasse rein. Die will ich nun etwas genauer Besprechen:

Weiterlesen

4 people like this post.

Quizduell - Es geht noch immer?!

quizduellZweieinhalb Jahre ist es her, dass auf diesem Blog ein Beitrag über Quizduell verfasst wurde. Damals, wie auch heute, ging es um das farbliche hervorheben der richtigen Antwort bevor man auf eine Antwort drückte. Der Beitrag ist auch der mit den meisten Kommentaren auf dem Blog! Es wurde über die SSL Zertifikate, das Signieren der App und sogar über fertige Bot-Implementationen und APIs diskutiert. Mehr über Zufall fand die aktuelle Quizduell-App wieder ihren Weg auf mein Handy. Während dem Spielen packte mich wieder die Lust, der App unter die Haube zu schauen. Nach ein paar Probleme beim Unpacken mit dem apktool stand ich wieder vor vielen Klassen. Das erste was auffiel: die Obfuscation war geändert worden, es waren garkeine Klassennamen mehr auszumachen. Und auch der Fragen-Klasse fehlte die Methode zum setzen der richtigen Antwort-Attribute, die wiederrum direkt in der UI angezeigt werden. Stattdessen gab es zwei Funktionen “setWrong()” und “setCorrect()”, die im Prinzip das gleiche machten. Nur wie und wo aufrufen? Die Lösung: Über einen Smali-Patch wird nach erstellen der Darstellung per Iterator alle Fragen durchlaufen und die intere Flag vergleichen. Je nachdem wie der Wert dieses Enums war, wurden dann die setWrong/setCorrect Methoden aufgerufen, die praktischerweise direkt die Farbe in der UI ändert. Zwar ein bisschen anderer Ansatz, aber dennoch das selbe Prinzip. Und auch nur 10 Zeilen zusammenkopierter Code.

Weitere technische Infos gibt es in diesem Beitrag auch garnicht. Er er ist mehr Nachruf an den alten Beitrag gemeint. Und vielleicht als Erinnerung an FEO Media dass man die richtige Antwort der Frage besser auf einem Server hinterlegen sollte ;)

4 people like this post.