Eine ausführbare .NET Framework v4.5-Datei dekompilieren "keine .net-Assembly-Datei" in dotPeek, aber die ausführbare Datei läuft einwandfrei

Question

Ein Client hat Brücken mit seinem vorherigen Entwickler gebrannt und ich versuche, Quellcode von dem, was von ihrer Payroll ausführbaren Datei übrig ist, zu extrahieren Leider habe ich als Web-Entwickler wenig Erfahrung mit dem .NET-Framework.

EDIT: Unser Kunde besitzt rechtlich die Software, hat aber nicht nach Quellcode gefragt, die Entwickler reagieren nicht auf unsere Kommunikation. Meine Absicht, diese Frage auf SO zu stellen, war nicht für Rechtsberatung (wir haben Leute, die damit umgehen), sondern für alle Optionen, die für die Dekompilierung zur Verfügung stehen.

Ich habe ausführbare Dateien mit JetBrains dotPeek erfolgreich zuvor dekompiliert, aber sie alle lief die .Net Framework v2.0/v4.5 Frameworks. Die ausführbare Payroll-Datei des Clients, mit der ich gerade arbeite, läuft unter .Net Core v4.5, was von dotPeek, ILSpy oder anderer C# -Dekompilierungssoftware, die ich als .NET-Assemblierungsdatei ausgeführt habe, nicht erkannt wird.

Nach ein wenig Forschung, glaube ich, .Net Core wurde vor kurzem Open Source ... aber ich bin mir nicht sicher, wie ich durch den Dekompilierungsprozess fortfahren kann, oder wenn es zu diesem Zeitpunkt sogar möglich ist. Irgendwelche Empfehlungen?

Hinweis: Ich werde eine Antwort nach dem Motto "es ist unmöglich zu dekompilieren, aber haben Sie X, Y, Z zuerst?" Akzeptieren. Ich muss den Kunden wissen lassen, ob es möglich ist oder nicht, da wir einen engen Zeitplan haben.

eine Klarstellung dessen, was ich tat: program.exe in dotPeek rechten Maustaste auf Eigenschaften Eröffnet gibt mir dies:

Sie behauptet, „Nicht .NET Assembly-Datei“, aber ich kann die ausführbare Datei ausführen fein.

EDIT: Ist es möglich, mehr Informationen aus der ausführbaren Datei zu extrahieren, so dass ich eine andere Methode zum Dekompilieren eingrenzen kann?

Ich vermute, dass .NET-Decompiler hier nicht helfen werden.

Answer 1

.net Kern eine Open-Source-Version von .net derzeit eine Arbeit in Arbeit. Sie können corefx

den Fortschritt von Tag zu Tag auf microsoft public Github-Seite Ich bin ein wenig verwirrt durch das, was .net Kern Mittel in Frage, aber aus meinem Verständnis gibt es keine endgültige .net Kern 4.5 noch, und obwohl es durchaus brauchbar, aber unvollständig ist, warum sollte jemand es im Produktionscode verwenden?

Für weitere Informationen lesen this blog post

Answer 2

Es ist nichts Besonderes über eine .NET-Assembly, die .NET-Core Runtime zum Ziel hat. Es verwendet nur verschiedene Referenzbaugruppen. Sie müssen Ihren Decompiler darüber informieren, damit er die korrekte Version von mscorlib et al. Verwendet. Was auch immer das Programmziel ist, Silverlight wäre angesichts des wahrscheinlichen Alters das einzig vernünftige. .NETCore ist zu neu.

Aber das wahrscheinlichste Problem, das Sie in einem Szenario wie diesem haben, ist, dass der Programmierer seine IP durch das Verschleiern seiner Assemblys geschützt hat. Payroll-Programme werden fast immer auf Vertragsbasis erstellt, der Kunde zahlt nur für die Anpassungsarbeit und hat keinen gesetzlichen Titel auf den Kern oder den Quellcode.

Answer 3

Der Entwickler stellte eine legitime Programmierfrage auf einer Entwicklungswebseite und verdient eine fundierte Antwort. Keine unerwünschte Rechtsberatung.Es gibt viele legitime Gründe für das Dekompilieren einer DLL.

Wenn dotnetpeak darauf hinweist, dass eine Datei mit ".Net Core v4.5" entwickelt wurde und keine MVID hat, würde dies bedeuten, dass in der Datei ein CLR-Header fehlt.

Wenn Sie die Datei zurück in Assembly dekompilieren, werden Sie wahrscheinlich identifizierende Markierungen finden, dass die Datei in VB6 entwickelt wurde.

Finden Sie einen guten VB6 De-Compiler und Sie werden wahrscheinlich in der Lage sein, das Programm ohne viel Problem zu dekompilieren. Leider können Sie vb6 nicht vollständig in Quellcode dekompilieren, aber Sie können ziemlich gut verstehen, wie die Anwendung aufgebaut wurde.