wie kann mann den Quellcode von Programm heraus finden?
wie kann man den Quellcode von Programmen herausfinden?
5 Antworten
Bei (vollständig) kompilierten Sprachen ist dies nicht so ganz einfach möglich. Da musst du selber Hand anlegen und Reverse Engineering betreiben.
Mit einem Java-Programm geht das einfacher. Nicht quelloffene Programme sind aber meist obfuscated, du musst die Bedeutung der Klassen, Variablen, Methoden, etc. selbst erraten.
Dasselbe gilt auch für interpretierte Sprachen wie JavaScript oder Python. Auch dort kann der Code obfuscated werden.
Wenn das Programm Open Source ist, geht dies natürlich ganz einfach. Meist gibt es dazu eine Repository auf Github oder anderen Plattformen.
- Bei interpretierten / JIT kompilierten Sprachen liegt dir der Quellcode oder zumindest eine Zwischensprache vor
- Bei anderen gibts decompiler und reverse engineering tools wie ghidra, IDA
Wenn du den Quellcode nicht hast bekommst du in der Regel nicht exakt den Quellcode, aber du hast Möglichkeiten den Code zu analysieren.
Manchmal gibts natürlich auch einfach Source Code Leaks oder auch Open Source Quellcode den man sich einfach anschauen kann.
Kommt auf die Sprache an.
Der Fragesteller könnte ja mit der konkreten Sprache antworten und dann würde ich den konkreten Fall sehr viel präziser beantworten können.
bei compilierten sachen nicht den original code, du kannst halt nur etwas erzeugen was maximal das gleiche verhalten hat. ob dir der dann viel sagt, ist eine ganz andere problematik . den der wird meist ziemlich nichts sagend sein .
lese mal nach bei : Decompiler
Du kannst den Assembler Code sehen und der ist genau dazu kann man zb via den pseudo Code relativ einfach das genaue Verhalten herausfinden
bei c basierten programmen brauchst du reverse-engeneering. sonst kannst du aber auch die files nach sourcen durchsuchen.
*hinzugefügt zu der Antwort wenn das Programm mit einer scripting Sprache gemacht wurde wie zb csharp dann brauchst du ein Programm wie zb dnspy und damit kannst du dann den source sehen ist es aber was compiltes musst du Reverse Engineering da siehst du dann aber nur Assembler Code und wenn dein reverse Programm das unterstützt kannst du dir ein Pseudo Code anzeigen lassen aber so Sachen wie Funktionen /variablen Namen sind nicht mehr lesbar und du musst über Umwege herausfinden was was macht aber manches zb bei il2cpp da kannst du dann die Funktion Namen wieder einfügen da die dort in einer externen Datei gespeichert sind
c# ist strenggenommen eine script sprache da diese nicht compiled wird wodurch du ja auch den source ganz einfach sehen kannst
C# wird compiled.
Es gibt keinen Zwang, dass direkt zur Maschinensprache kompiliert werden muss, es kann auch zu IL kompiliert werden. Das macht eine Sprache nicht weniger kompiliert, es wird einfach nur anders kompiliert.
Stellen wir uns mal vor ich hätte Hardware, die IL nativ ausführen kann, aber dafür das was sonst Maschinencode ist nur mit einer VM ausführen kann. Diese Hardware mag deutlich komplexer sein.
Ist dann plötzlich C eine Scriptsprache? Eher nicht.
wodurch du ja auch den source ganz einfach sehen kannst
Der C# Compiler benutzt einige Konzepte durch lowering. Das heißt er transformiert den Code, bevor er ihn zu IL übersetzt. Diese Sachen können auch decompiler nur schätzen. Während du bei einer interpretierten Sprache den Code so lesen kannst, wie er geschrieben wurde.
Außerdem erwarte ich mehr von einer Programmiersprache, die eine Scriptsprache sein will. Ich möchte mit ihr rapid entwickeln können. Vielleicht duck-typing, vielleicht Variablendeklarationen ohne Typangabe (var in C# gibt den Typ immer noch an), ich möchte Sachen kurz und schnell schreiben.
Das alles trifft eher weniger auf C# zu. Ein besseres Beispiel wäre JS oder Python.
also ich kann c# aber komplett decompilen komisch das dann da 1zu1 der gleiche code ist wie ich den auch compiled habe
Du schreibst also ein Programm selbst, und vergleichst das Dekompilat dann mit deinem Quellcode?
Baust du im Debug-Modus? Befindet sich im Ordner bei deinem Programm eine .pdb Datei? Diese enthalten Informationen über dein Programm, welche du eigentlich nicht brauchst, welche aber bei der Entwicklung praktisch sind.
Mit .pdb-Dateien ist es z.B. auch möglich die Kommentare des Quellcode im Dekompilat zu sehen.
Wenn du deine Software im Release-Modus baust, und keine .pdb-Datei ausgibst, wird auch dein Ergebnis nicht mehr exakt dem Quellcode entsprechen, auch wenn er vielleicht das gleiche tut. Eben weil es Konzepte gibt, die nicht direkt in IL abgebildet werden.
So wird dann schnell aus:
for (int i = 0; i < 10; i++)
{
Console.WriteLine(i);
}
int j = 0;
while (j < 10)
{
Console.WriteLine(j);
j++;
}
foreach (int i in Enumerable.Range(0, 10))
{
Console.WriteLine(i);
}
Durch einen Decompiler das hier:
int num = 0;
while (num < 10)
{
Console.WriteLine(num);
num++;
}
int num2 = 0;
while (num2 < 10)
{
Console.WriteLine(num2);
num2++;
}
IEnumerator<int> enumerator = Enumerable.Range(0, 10).GetEnumerator();
try
{
while (enumerator.MoveNext())
{
int current = enumerator.Current;
Console.WriteLine(current);
}
}
finally
{
if (enumerator != null)
{
enumerator.Dispose();
}
}
Ausprobieren kannst du das ganze selbst z.B. hier:
Vielleicht hast du aber auch einen Decompiler, der die foreach als foreach anzeigt. Das liegt jetzt nur nicht daran, dass im Code wirklich eine foreach steht, es liegt vielmehr daran, dass dein Decompiler einfach rät. Irgendwer hat ihm mal gesagt, dass wenn er ein IEnumerator sieht, er es als foreach darstellen soll. Das heißt aber, dass er auch Code, der keine foreach war, als foreach darstellen wird. Einfach weil er es nicht besser weiß.
compile mal was in c# und pack es dan in dnspy dann siehst du es schon :)
Ich habe dir gerade lang beschrieben, wie der Prozess funktioniert und welche Fehler du wahrscheinlich machst, weswegen das so auf dich wirkt (.pdb, Debug).
Wenn du es nicht liest, ausprobierst oder zumindest nachprüfst, kann ich dir da auch nicht mehr helfen. Es würde dich aber sicher weiterbringen zu verstehen, was du eigentlich tust, anstatt einfach nur ein Programm zu öffnen.
du kannst den kompletten code mit funktionnamen variablennamen nur mit der exe sehen die in release gebuidled wurde und ohne pdb
Es gibt schon antworten hier warum antwortet man dann noch obwohl die schon vorhandenen die Antwort beantworten und deine viel ungenauer ist