DEC 5.2 String hashen?

[Rollo62]

Exakt, das wäre mein Vorschlag.

Wenn es zeitlich und räumlich nicht so nah ist, und an zig verschiedenen Stellen,
wird es zumindest nicht so leicht zu hacken sein.

Der Hacker braucht ja events um zu checken wann geprüft wird und wann wans entschieden wird.
Ich würde die Prüfung daher niemals direkt bei Start machen.

Lass das Programm doch eine Weile laufen, und überleg dir mittendrin ein paar Scherze, oder speichere erst bei Programmende die neue Situation.

Ist natürlich witzlos wenn die App nach einer Minute Ihren Zweck erfüllt hat, aber für Daueranwendungen
kann man Hacker schon etwas beschäftigen.

Rollo

[a.def]

Zitat:

Lass das Programm doch eine Weile laufen, und überleg dir mittendrin ein paar Scherze, oder speichere erst bei Programmende die neue Situation.

Das ginge bei meinem Programm leider nicht. Es ist zwar eine Anwendung die dauernd läuft, aber sie erledigt zeitkritische Dinge. U.a. direkt bei Programmstart und Programmende.

Bin mit meiner aktuellen Lösung zufrieden. Werde die aber noch weiter ausbauen.

[nahpets]

Zitat:

Zitat von a.def (Beitrag 1370178)

Zitat:

Lass das Programm doch eine Weile laufen, und überleg dir mittendrin ein paar Scherze, oder speichere erst bei Programmende die neue Situation.

Das ginge bei meinem Programm leider nicht. Es ist zwar eine Anwendung die dauernd läuft, aber sie erledigt zeitkritische Dinge. U.a. direkt bei Programmstart und Programmende.

Ist das relevant, wenn es darum geht herauszufinden, ob da jemand was manipuliert hat?

Klar, bei 'ner zeitkritischen Anwendung darf die "Zwischendurchprüfung" das Programm nicht ins Stolpern bringen, aber wenn dann festgestellt wurde, dass da was manipuliert wurde, würd' ich mal sagen:

Korrekte Funktionalität ist nicht zwingend erforderlich, da das Programm ja sowieso per entsprechender Meldung beendet werden soll.

Beim Start prüfen, aber per Timer "verspätet" reagieren?

[a.def]

Zitat:

Beim Start prüfen, aber per Timer "verspätet" reagieren?

Wäre eventuell eine Möglichkeit.
Nur das würde dann meine schöne Unit wieder auseinanderreißen (ich suche einen weinenden Smiley. Gibt es wohl nicht) *Stell dir hier einen weinenden Smiley vor!*

Aktuell ist meine Unit umfangreich mit ein paar Einstellungsmöglichkeiten und ich brauche nur an einer einzigen Stelle etwas hinschreiben, damit der Selbsttest ausgeführt wird.
Mit dem Timer wären das dann ja schon 2 Stellen.

Quatsch! Wäre ja trotzdem nur eine Stelle! Einfach eine Timer-Instanz in der Unit selber erzeugen, starten und warten!

Ich sehe gerade, meine Unit hat Potential :hello:

[Zacherl]

Zitat:

Zitat von nahpets (Beitrag 1370142)

Exe erstellen.
Mit UPX packen.
MD5-Checksumme (oder auch beliebige andere) hinten dran hängen.

Zitat:

Zitat von nahpets (Beitrag 1370142)

Frage: Kann man die Prüfung dann auch "mal eben" wegpatchen?

UPX bietet - wie du ja selbst erwähnst - von Haus aus eine Funktion an, mit der man Dateien wieder entpacken kann. Bietet also auch keinen größeren Schutz. Man patcht nicht den Hash, sondern die Prüfung ansich.

Zitat:

Zitat von nahpets (Beitrag 1370142)

Die Änderung müsste dann wohl eher zur Laufzeit im Arbeitsspeicher passieren.

Diese Möglichkeit gibt es natürlich auch noch jederzeit. Entweder per Loader, oder man modifiziert die IAT, um dem Programm eine extra DLL unterzumogeln. Lohnt sich bei Tools, welche auch erst zur Laufzeit (partiell) unpacked werden und so gute Hash-Checks besitzen, dass es vom Zeitaufwand schnell in die Stunden/Tage gehen könnte sie auszubauen.

Zitat:

Zitat von Rollo62 (Beitrag 1370164)

Wenn es zeitlich und räumlich nicht so nah ist, und an zig verschiedenen Stellen,
wird es zumindest nicht so leicht zu hacken sein.

Das ist in der Tat schonmal eine Stufe aufwändiger - besonders, wenn man eine dynamische Analyse per Debugger vornimmt.

Zitat:

Zitat von Rollo62 (Beitrag 1370164)

Der Hacker braucht ja events um zu checken wann geprüft wird und wann wans entschieden wird.

Exakt. Wobei viele Leute auch statische Analysen mit IDA vornehmen und dabei nicht auf irgendwelche Events angewiesen sind. Hierfür muss man allerdings in der Regel schon direkt mehr Zeit einplanen, um relevante Codestellen zu finden.

Zitat:

Zitat von a.def (Beitrag 1370184)

Aktuell ist meine Unit umfangreich mit ein paar Einstellungsmöglichkeiten und ich brauche nur an einer einzigen Stelle etwas hinschreiben, damit der Selbsttest ausgeführt wird.

Genau das ist aber leider absolut kein Vorteil. Hast du eine inline Funktion, welche du an mehreren Stellen - z.b. wie von Rollo beschrieben beim Auftreten "zufälliger" Events - einsetzt, dann muss ich auch diverse Stellen patchen und kann mir außerdem erstmal nie sicher sein, wirklich alle Vorkommen gefunden zu haben. Nagut, habe ich eine Stelle, kann ich nach der entsprechenden Code-Signatur im ganzen Programm suchen, aber im Optimalfall verwendest du mehrere komplett individuelle Funktionen.

Edit:
Ich habe mal noch ein paar Bilder angehangen, die die Vorgehensweise demonstrieren. Den String zu verschleiern würde in diesem Falle keinen Mehrwert erzeugen, da man stattdessen auch einen Breakpoint auf MessageBoxW setzen könnte. Und selbst komplett ohne MessageBox kann man die Routine finden, welche den hinterlegten Hash aus der Datei ausliest, indem man einen BP auf CreateFileW platziert.

[a.def]

Zitat:

aber im Optimalfall verwendest du mehrere komplett individuelle Funktionen.

Habe ich zum Glück schon. Mein Programm prüft einmal diese Hash-Sache und dann aber noch etwas komplett anderes.

Zitat:

indem man einen BP auf CreateFileW platziert.

Um CreateFileW kommt man vermutlich nicht herum richtig? (Datei anderweitig laden)

Allgemeine Frage an dich nahpets:
wirst du deine Methode weiterhin benutzen und einen Selbsttest durchführen?

[Zacherl]

Zitat:

Zitat von a.def (Beitrag 1370197)

Zitat:

indem man einen BP auf CreateFileW platziert.

Um CreateFileW kommt man vermutlich nicht herum richtig? (Datei anderweitig laden)

Würde mir zumindest auf Anhieb jetzt keine Möglichkeit einfallen, die nicht genauso einfach zu erkennen ist.

[a.def]

Zitat:

Würde mir zumindest auf Anhieb jetzt keine Möglichkeit einfallen, die nicht genauso einfach zu erkennen ist.

Ok. Zeugenvernehmung beendet. Urteil gesprochen: Zacherl hat das Zepter und kommt eh um alles rum :stupid:

[himitsu]

Die wichtigen Teile der EXE sind in den RAM gemappt, also kann man das auch im RAM hashen, anstatt die Datei.
Nur muß man hier erstmal alle Teile finden, da erstens die PE-Sektionen einzeln geladen werden, die Reallocationstabellen übershrieben werden und auch überall die Sprung-/Speicheradressen werden vom Windows gepatcht, wenn das Image im RAM verschoben wurde.

[a.def]

Klingt kompliziert und resultiert bestimmt wieder in keinerlei Mehrwert. Denn CreateFile muss man ja nicht suchen denke ich.