Czy Twój plik binarny VPN jest zbudowany dla tego procesora? Przeczytaj nagłówek ELF

Oba pliki są 32-bitowe i tylko jeden z nich działa na Twojej płytce. Kompilacja ELF32 dla Intela i kompilacja ELF32 dla ARM zgadzają się co do pola klasy i nie zgadzają się co do wszystkiego, co ważne. Strona pobierania oferująca opcję 32-bitową nie powiedziała Ci prawie nic, dopóki nie przeczytasz nagłówka pliku, który faktycznie pobrałeś. Zmiana nazwy nie zmienia ani jednej instrukcji.

Klasa i maszyna odpowiadają na różne pytania

Pole klasy mówi, czy plik używa struktur 32- czy 64-bitowych. Pole maszyny nazywa zestaw instrukcji, dla którego plik został skompilowany. Czytanie tylko pierwszego to sposób, w jaki kompilacja x86 trafia na płytkę ARM z nazwą pliku, która wygląda całkowicie wiarygodnie. Obie wartości pochodzą z tego samego polecenia, dlatego tak łatwo pominąć jedną.

To samo zamieszanie dotyczy etykiet 64-bitowych, gdzie aarch64 i x86-64 dzielą rozmiar słowa i ani jednej instrukcji. Strona dostawcy, która wymienia jedno pobranie 64-bitowe, opisuje własną kompilację, a nie Twoją maszynę. Sprawdź nagłówek pliku, a nie nagłówek kolumny na stronie.

readelf -h ./vendor-vpn
readelf -l ./vendor-vpn | head -20
file ./vendor-vpn

Pierwsze polecenie wypisuje nagłówek, w tym klasę i maszynę. Drugie pokazuje nagłówki programu, w których znajduje się żądanie interpretera. Trzecie daje jedną linię, gdy tabela jest większa niż potrzebujesz.

Dodanie prawa wykonania lub załatanie sprawdzenia dystrybucji niczego nie tłumaczy. Emulacja, tam gdzie platforma ją obsługuje, jest decyzją wdrożeniową z własnym kosztem wydajności i zależności.

Przeczytaj nagłówek, zanim uruchomisz instalator

Sprawdź zaufany artefakt, zanim cokolwiek z niego uruchomisz. Instalator, który zawodzi w połowie, może pozostawić podmienione biblioteki i nic działającego, co jest gorszym punktem wyjścia niż archiwum, od którego zacząłeś. Sprawdzenie nagłówka jest tylko do odczytu i odwracalne w tym sensie, że nic w systemie się nie zmienia.

Porównaj pole maszyny z architekturą pakietów działającego systemu, a nie z nazwą marketingową płytki. Procesor 64-bitowy uruchamiający 32-bitową przestrzeń użytkownika potrzebuje kompilacji 32-bitowej, i ten szczegół decyduje, które pobranie jest natywne. Ograniczeniem nie jest możliwość płytki; jest nim zainstalowana przestrzeń użytkownika.

dpkg --print-architecture
uname -m
getconf LONG_BIT

Pierwsze polecenie zgłasza architekturę, dla której system instaluje pakiety, i to jest wartość, która musi się zgadzać. Pozostałe dwa opisują jądro i rozmiar słowa, i mogą się różnić od przestrzeni użytkownika przy instalacji wieloarchitekturowej.

Gdy te odpowiedzi się różnią, zdecyduj, którą obsługuje dostawca, zanim pobierzesz kolejne archiwum. Zgadywanie tworzy pętlę instalacji, z których każda zawodzi w innym miejscu, a każde niepowodzenie wygląda jak nowy problem.

Sprawdź interpreter, nie tylko architekturę

Dynamiczny plik wykonywalny zapisuje w nagłówku programu program ładujący, którego oczekuje. W systemie z inną ścieżką programu ładującego jądro odmawia uruchomienia pliku, nawet gdy pole maszyny zgadza się dokładnie. To właśnie to niepowodzenie wysyła ludzi na poszukiwanie brakujących bibliotek.

Komunikat o błędzie mówi, w którym przypadku jesteś, a oba przypadki łatwo pomylić. Odrzucenie formatu lub architektury różni się od brakującego pliku lub interpretera, i tylko jeden z nich naprawia się przez zainstalowanie innego pakietu.

readelf -l ./vendor-vpn | grep -A1 INTERP
ls -l /lib64/ld-linux-x86-64.so.2

Pierwsze polecenie pokazuje ścieżkę interpretera, której żąda plik binarny. Drugie sprawdza, czy ta ścieżka istnieje, co oddziela złą kompilację od brakującego programu ładującego.

Nie uruchamiaj listy zależności na niezaufanym pliku binarnym, ponieważ niektóre implementacje mogą wykonać plik, który sprawdzają. Utrzymuj sprawdzanie tylko do odczytu i oprzyj się pokusie dodania dowiązań symbolicznych programu ładującego, aby uruchomić nieobsługiwaną kompilację.

Poproś o kompilację z faktami w ręku

Wyślij dostawcy wersję systemu operacyjnego, architekturę pakietów, wartości klasy i maszyny oraz pierwszy komunikat o błędzie. Taka kombinacja zasługuje na użyteczną odpowiedź, podczas gdy zrzut ekranu ogólnego niepowodzenia zasługuje na szablon pomocy.

Trzymaj pytanie o plik binarny oddzielnie od pytania o konfigurację. Gdy poprawna kompilacja ruszy, profile, dane logowania i trasy nadal są ich własnymi problemami, a żadna ilość edycji profilu nie uruchomi pliku binarnego o złej architekturze.