przekonwertować plik wykonywalny z powrotem na kod źródłowy C.

Niestety zgubiłem kod źródłowy i po prostu mam plik wyjściowy utworzony za pomocą gcc w systemie Linux i nie mam teraz dostępu do komputera. Czy istnieje sposób na konwersję pliku wyjściowego do pliku źródłowego (in c w systemie Linux)?

Więc miałeś krowę, ale przypadkowo zamieniłeś ją w hamburgera, a teraz chcesz odzyskać swoją krowę.

Przepraszamy, to po prostu nie działa w ten sposób.

Wystarczy przywrócić plik źródłowy z kopii zapasowych.

Ach, nie miałeś kopii zapasowych. Niestety wszechświat nie daje ci za to przerwy.

Możesz dekompilować plik binarny. To nie da ci kodu źródłowego, ale da ci trochę kodu źródłowego o takim samym zachowaniu. Nie otrzymasz nazw zmiennych, chyba że był to plik binarny debugowania. Nie dostaniesz takiej samej logiki, chyba że skompilujesz bez optymalizacji. Oczywiście nie dostaniesz komentarzy.

Użyłem Boomeranga do dekompilacji niektórych programów, a wynik był bardziej czytelny niż kod maszynowy. Nie wiem, czy to najlepsze narzędzie na rynku. W każdym razie nie oczekuj cudów.

Kilka narzędzi jest powszechnych w inżynierii odwrotnej pliku wykonywalnego.

1. Polecenie „plik”, które przyjmuje ścieżkę do pliku jako pierwszy parametr, abyś mógł (w większości przypadków) określić, jaki typ pliku wykonywalnego masz.
2. Dezasemblery, które dokładnie pokazują, co robi plik wykonywalny, ale są trudne do odczytania dla tych, którzy nie piszą kodu asemblera na tej konkretnej architekturze lub mają doświadczenie w dezasemblacji.
3. Dekompilatory, takie jak Boomerang, Hex-ray i Snowman, mogą zapewnić lepszą czytelność, ale nie odzyskują rzeczywistych nazw zmiennych lub składni oryginalnego programu i nie są w 100% niezawodne, szczególnie w przypadkach, gdy inżynierowie, którzy stworzyli plik wykonywalny, testowali z te pakiety i próbowały dodatkowo zaciemnić zabezpieczenia.
4. Diagramy lub tabele przepływu danych. Nie znam żadnego darmowego narzędzia do automatycznego wykonywania tego zadania, ale pomocny może być skrypt Python lub Bash na wierzchu parsera tekstowego danych wyjściowych zestawu (który można zapisać w wersji sed lub Perl).
5. Ołówek i papier, wierzcie lub nie, do notowania przepływów i pomysłów.

W większości przypadków, które widziałem, kod musiał zostać przepisany od nowa, utrzymany jako program w asemblerze lub odtworzony przez ponowne zastosowanie żądań zmiany do starszej wersji.

To, co chcesz zrobić, nazywa się „dekompilacją”. Istnieje wiele dekompilatorów i omawianie ich wszystkich tutaj nie jest praktyczne.

Jednak jako ogólna uwaga: Konwersja ze źródła C na wykonywalny kod maszynowy jest stratna. Na przykład:

• Komentarze są nieodwracalnie utracone
• Zmienne nazwy zniknęły
• Czasami pętle są rozwijane w celu zwiększenia wydajności
• Funkcje mogą zostać zmienione

Kod kompiluje się tak, jak napisano. Obecnie większość kompilatorów radykalnie zmieni kod, aby go zoptymalizować. Więc kiedy dekompilować, kompilator może się tylko domyślać, co kod źródłowy musi wyglądało, że nie ma możliwości dowiedzenia się, co twój kod był, bo to nie ma. Jeśli dekompilator jest dobry, otrzymany kod będzie przynajmniej mógł zostać skompilowany z powrotem do równoważnego pliku wykonywalnego, a następnie możesz zacząć powoli refaktoryzować go do odczytu. Ale najprawdopodobniej dekompilator wytworzy absolutnie nieczytelny kod spaghetti i rozszyfrowanie go będzie ogromnym bólem głowy. Czasami może być mniej pracy, aby napisać program od nowa.