Xbase Dekompilieren
Moderator: Moderatoren
-
- Rekursionen-Architekt
- Beiträge: 205
- Registriert: Mo, 15. Apr 2019 16:19
- Hat sich bedankt: 13 Mal
- Danksagung erhalten: 4 Mal
Xbase Dekompilieren
Hallöchen zusammen,
Mich würde mal interessieren ob, bzw wie leicht, sich eine Xbase .exe dekomplilieren lässt.
Mir geht es darum, Passwörter oder Hash Saltes im Source aufzubewahren.
Und ja ich kenne die Verschlüsselungklassen von Alaska. Und ja ich verwendete sie auch
Könnte im Forum nichts über dekomplilieren finden.
Mich würde mal interessieren ob, bzw wie leicht, sich eine Xbase .exe dekomplilieren lässt.
Mir geht es darum, Passwörter oder Hash Saltes im Source aufzubewahren.
Und ja ich kenne die Verschlüsselungklassen von Alaska. Und ja ich verwendete sie auch
Könnte im Forum nichts über dekomplilieren finden.
Gruß Dominik
- brandelh
- Foren-Moderator
- Beiträge: 15707
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 71 Mal
- Danksagung erhalten: 38 Mal
- Kontaktdaten:
Re: Xbase Dekompilieren
Wie die Alaska EXE den Code ablegt weiß ich nicht, vermutlich ist es eine Art von P-Code den die Runtime verarbeitet.
Was ich schon gesehen habe (ist ewig her ob es noch immer so ist ,,,), dass man einen Text den man einer Variablen zuordnet wie
cKennwort := "Ich bin so geheim"
in der EXE mit HEX Editor geöffnet als "Ich bin so geheim" finden kann.
Bei Private oder Public Vars, wurde auch der Variablenname irgendwie in der EXE hinterlegt, die LOCAL ist als Name nie in einer EXE.
Der Crypt() Befehl speichert irgendwie veränderte Strings, ich konnte nie erkennen wie die Verschlüsselung funktioniert, aber wer bin ich
Es reicht um normale Entwickler von den Inhalten fern zu halten, ansonsten nicht - steht mein ich auch so in der Doku irgendwo ..
die AES Verschlüsselung soll wirklich sicher sein, aber die Xbase Umsetzung bei den DBFs war mir immer zu kompliziert. Ich brauch das auch nicht.
Wenn man einen String in der EXE verbergen will, kann man den als ASCII Wert in Zahlen in einem Array hinterlegen und zur Laufzeit wieder mit chr() zusammen setzt.
Was ich schon gesehen habe (ist ewig her ob es noch immer so ist ,,,), dass man einen Text den man einer Variablen zuordnet wie
cKennwort := "Ich bin so geheim"
in der EXE mit HEX Editor geöffnet als "Ich bin so geheim" finden kann.
Bei Private oder Public Vars, wurde auch der Variablenname irgendwie in der EXE hinterlegt, die LOCAL ist als Name nie in einer EXE.
Der Crypt() Befehl speichert irgendwie veränderte Strings, ich konnte nie erkennen wie die Verschlüsselung funktioniert, aber wer bin ich
Es reicht um normale Entwickler von den Inhalten fern zu halten, ansonsten nicht - steht mein ich auch so in der Doku irgendwo ..
die AES Verschlüsselung soll wirklich sicher sein, aber die Xbase Umsetzung bei den DBFs war mir immer zu kompliziert. Ich brauch das auch nicht.
Wenn man einen String in der EXE verbergen will, kann man den als ASCII Wert in Zahlen in einem Array hinterlegen und zur Laufzeit wieder mit chr() zusammen setzt.
Gruß
Hubert
Hubert
- Jan
- Marvin
- Beiträge: 14662
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Xbase Dekompilieren
So ähnlich mache ich das an den wenigen Stellen, an denen ich das brauche.
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- nightcrawler
- 1000 working lines a day
- Beiträge: 655
- Registriert: Di, 24. Apr 2012 16:33
- Wohnort: 72184 Weitingen
- Hat sich bedankt: 3 Mal
- Danksagung erhalten: 96 Mal
- Kontaktdaten:
Re: Xbase Dekompilieren
je nachdem, wie sicher die Anwendung sein soll ... aber so eine "Hintertür" im Programm ist sehr oft der Hebel zum Knacken des Programms. Gibt es keine andere Möglichkeit, z.B. indem der Benutzer das Passwort eingeben muss?
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
Re: Xbase Dekompilieren
Zur Ausgangsfrage: Ich gehe nicht davon aus, dass es explizit einen De-Compiler für Xbase++ gibt. Da Xbase++ meines Wissens aber auf C+/++ basiert, gibt es in diesem Bereich möglicherweise Tools, die aber keinen PRG-Code erzeugen dürften, sondern eben (mäßig brauchbaren) C+/++-Code.
Unsere Hintertüren sind nicht statisch.
Unsere Hintertüren sind nicht statisch.
Herzlich,
Tom
Tom
- Jan
- Marvin
- Beiträge: 14662
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Xbase Dekompilieren
Microsoft Visual C++. Lt einer Fehlermeldung, die ich ab und an mal bekomme.
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- azzo
- Rekursionen-Architekt
- Beiträge: 483
- Registriert: So, 28. Mär 2010 19:21
- Danksagung erhalten: 11 Mal
Re: Xbase Dekompilieren
Hallo,
keine Ahnung, ob dieser Decompiler auch für xBase funktioniert.
https://securelist.com/how-we-developed ... ler/95517/
LG
Otto
keine Ahnung, ob dieser Decompiler auch für xBase funktioniert.
https://securelist.com/how-we-developed ... ler/95517/
LG
Otto
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: Xbase Dekompilieren
Hallo DominikDominik Krebs hat geschrieben: ↑Di, 29. Dez 2020 18:28 Mich würde mal interessieren ob, bzw wie leicht, sich eine Xbase .exe dekomplilieren lässt.
alles was du beim Kunden installierst ist mit mehr oder weniger Aufwand auslesbar. Die Frage die du dir stellen musst ist eher die wieviel Aufwand der Betreffende treibt ob er die Fähigkeiten und Tools dazu hat und vorallem was der (finanzielle) Nutzen aus diesem Tun ist.
(Niemand wird eine gehackte App in seinem Geschäft verwenden, ganz einfach weil er damit keinen Support hat. Da ist der Anreiz schon ziemlich klein)
Es gab für Clipper (Valkyrie) und xbase++ Dekompiler die aus der EXE prg Files erstellen konnten. Meist mit den Orignalen Funktions- und Variablennamen. Die prg Files beider Tools liessen sich dann auch wieder in Funktionierende EXE übersetzten.
Auch Packer, Dongels und anderer Mist waren noch nie grosse Hindernisse ...... 100% Sicherheit gibt es nicht.
Die beiden Dekompiller sind vor längerer Zeit vom Markt verschunden. Tools zum entfernen von Dongles Packern und dem ganzen MIst finden sich jedoch noch immer sehr leicht.
Besser sieht es mit der Sicherheit aus wenn du Software als Service aus der Cloud anbietst.....
Valar Morghulis
Gruss Carlo
Gruss Carlo
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2832
- Registriert: Fr, 08. Feb 2008 21:29
- Hat sich bedankt: 98 Mal
- Danksagung erhalten: 13 Mal
Re: Xbase Dekompilieren
Hallo, Dominik -
ich gehe davon aus, dass ein Passwort, dass Du im Sourcecode "versteckst" auch auffindbar ist.
Wenn ich in der Situation wäre, würde ich das Passwort aus mehreren Funktionen zusammensuchen, etwa so:
cPWd := String1() + String2() + String3() + String4()
Die Funktionen würde ich in verschiedenen Quelldateien definieren, eventuell die eine oder andere in einer DLL. Damit ist das Suchen im Quelltext zwar immer noch möglich, aber es ist nicht mehr im Zusammenhang (zumindest für einen Aussenstehenden).
Wer viel Zeit und Lust hat, kann mit einem externen Debugger durch das Programm laufen, um hinter das Geheimnis zu kommen..
Ansonsten vermute ich, dass Xbase++ als Compiler nicht so interessant ist, dass entsprechende Firmen Zeit und Geld in die Entwicklung eines Decompilers stecken würden.
ich gehe davon aus, dass ein Passwort, dass Du im Sourcecode "versteckst" auch auffindbar ist.
Wenn ich in der Situation wäre, würde ich das Passwort aus mehreren Funktionen zusammensuchen, etwa so:
cPWd := String1() + String2() + String3() + String4()
Die Funktionen würde ich in verschiedenen Quelldateien definieren, eventuell die eine oder andere in einer DLL. Damit ist das Suchen im Quelltext zwar immer noch möglich, aber es ist nicht mehr im Zusammenhang (zumindest für einen Aussenstehenden).
Wer viel Zeit und Lust hat, kann mit einem externen Debugger durch das Programm laufen, um hinter das Geheimnis zu kommen..
Ansonsten vermute ich, dass Xbase++ als Compiler nicht so interessant ist, dass entsprechende Firmen Zeit und Geld in die Entwicklung eines Decompilers stecken würden.
Liebe Grüsse aus der Eifel,
Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2518
- Registriert: Mi, 28. Jul 2010 17:16
- Hat sich bedankt: 12 Mal
- Danksagung erhalten: 77 Mal
Re: Xbase Dekompilieren
Hallo Georg
den gab es ja bereits. Nun existieren Dekompiler und die Hersteller Firma nicht mehr.
Ich kann mir vorstellen dass rechtliche Gründe dagegen sprechen und deshalb beides nicht mehr existiert.
Valar Morghulis
Gruss Carlo
Gruss Carlo
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
Re: Xbase Dekompilieren
Es wird sich einfach nicht gelohnt haben. Es würde sich für Xbase++ nicht lohnen.Ich kann mir vorstellen dass rechtliche Gründe dagegen sprechen und deshalb beides nicht mehr existiert.
Das ist rechtlich ein bisschen wie bei den Radarwarnern: Decompiler darf man herstellen, aber man darf sie nicht in jedem Fall einfach so benutzen. Es ist zulässig, ausführbaren Code zu decompilen, wenn es für den weiteren Betrieb der Software unbedingt erforderlich ist, etwa zur Fehlerbehebung, und wenn der Hersteller das Problem, um das es geht, nicht behebt oder beheben will. Ansonsten ist es ein Verstoß nicht nur gegen die Lizenzbedingungen, sondern auch und vor allem gegen Urheber- und Leistungsschutzrechte.
Valkyrie hatte es bei Clipper bis Version 5.2 ziemlich leicht, da ausführbare Clipperprogramme mehr oder weniger ihren gesamten Quellcode mit sich herumgeschleppt haben. Das änderte sich mit Clipper 5.3.
Anyway, die Frage ist außerdem, ob und was man mit fremdem, undokumentierten Code anfangen will. Eine Hintertür oder ein Osterei oder einen krassen, aber unkomplexen Bug würde man möglicherweise finden, aber wer sich je in geerbten, schlecht oder überhaupt nicht dokumentierten Code einarbeiten musste, weiß, dass es fast keine uneffektivere Arbeitsgrundlage gibt als diese.
Herzlich,
Tom
Tom
- brandelh
- Foren-Moderator
- Beiträge: 15707
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 71 Mal
- Danksagung erhalten: 38 Mal
- Kontaktdaten:
Re: Xbase Dekompilieren
Das Dekompilieren von Clipper hatte zumindest einen einfacheren Ansatz, da die Variablennamen von Private und Statics (die damals häufigsten Typen) noch als echter Klarsichtname raus kamen,
konnte man hoffen dass die einen sinnvollen gewählt haben. Der Pseudo Code war eventuell auch noch leichter zu verstehen, als der Maschinen-Code den andere Compiler erstellen (PowerBasic),
bei letzteren hätte man damals immerhin DEBUG (oder wie das hies) nehmen können um die ASM Befehle zu erhalten ... richtig toll
Ich persönlich fand es schon ätzend genug einen fremden undokumentierten PRG oder BAS Code lesen, verstehen und dann weiter pflegen zu sollen.
Da gibt es ja die reinsten ... Zumutungen
Es gibt ja Tüftler, die Treiber zerlegen um Schwachstellen zu nutzen, daher kann man nie sicher sein, dass jemand irgendwas macht, was nicht unmöglich ist. Ob es sinnvoll ist, bleibt eine andere Frage.
konnte man hoffen dass die einen sinnvollen gewählt haben. Der Pseudo Code war eventuell auch noch leichter zu verstehen, als der Maschinen-Code den andere Compiler erstellen (PowerBasic),
bei letzteren hätte man damals immerhin DEBUG (oder wie das hies) nehmen können um die ASM Befehle zu erhalten ... richtig toll
Ich persönlich fand es schon ätzend genug einen fremden undokumentierten PRG oder BAS Code lesen, verstehen und dann weiter pflegen zu sollen.
Da gibt es ja die reinsten ... Zumutungen
Es gibt ja Tüftler, die Treiber zerlegen um Schwachstellen zu nutzen, daher kann man nie sicher sein, dass jemand irgendwas macht, was nicht unmöglich ist. Ob es sinnvoll ist, bleibt eine andere Frage.
Gruß
Hubert
Hubert