W trakcie przygotowywania warsztatów wprowadzających do inżynierii wstecznej i asemblera, zadaliśmy sobie oczywiste pytanie: od których z setek instrukcji asemblera x86-64 powinno się zacząć?

Zwyczajowo instrukcji assemblera uczy się tematycznie – najpierw podstawowe kopiowanie danych, operacje arytmetyczne i bitowe. Następnie skoki bezwarunkowe, a po nich testy i porównania sparowane ze skokami warunkowymi. Potem przychodzą zazwyczaj instrukcje operujące na stosie, a zaraz za nimi CALL/RET. A po tym "oczywista" do tej pory kolejność zaczyna się nieco rozmywać. Ale czy to faktycznie jest właściwa kolejność? Czy naprawdę ważniejszym jest dowiedzenie się co robi instrukcja JS od wszędobylskiego CALL, szczególnie jeśli ostatecznym celem nauki asemblera jest inżynieria wsteczna?

Te pytania powinny być rozważone z różnych stron, ale jedna rzecz jaka może pomóc w znalezieniu odpowiedzi to zawsze dane!

Biorąc pod uwagę powyższe, Dan oskryptował Ghidrę w Pythonie i policzył ile razy dana instrukcja pojawiła się w plikach wykonywalnych – w tym w bibliotekach dynamicznych – znalezionych pod Windowsem oraz Ubuntu (Linux). Dla doprecyzowania dodamy, że pisząc instrukcja mamy konkretnie na myśli unikatowe mnemoniki, takie jak generuje je disassembler Ghidry.

Wyniki prezentują się następująco:

Zobacz całe top 100 pod tekstem posta...

Bazując na tych danych można przyjąć, że jeśli nauczysz się dziesięciu najpopularniejszych instrukcji asemblera z tej listy, to będziesz w stanie zrozumieć 75% kodu programu. Ucząc się kolejnych dziesięciu instrukcji dochodzimy do 90% pokrycia. Oczywiście potem pozostaje nam bardzo długi ogon innych instrukcji – zaobserwowaliśmy ich ponad 800, a wiemy, że jest ich więcej. Trzeba też zaznaczyć, że rozumienie instrukcji, które składają się na kod programu, to jeszcze nie to samo co rozumienie algorytmu, ale jest to zdecydowanie dobry pierwszy krok.

Kilka informacji o tej tabeli:

• Rozważanie popularności instrukcji jest interesujące i może się przysłużyć podczas projektowania szkoleń, ale inne zastosowania mogą wymagać nieco bardziej dokładnego podejścia (np. podczas projektowania procesorów – przy próbach ustalenia gdzie poświęcić więcej czasu na optymalizację).
• Kolumna "Odsetek" mówi o tym ile razy daną instrukcje zaobserwowaliśmy w całym badanym zbiorze. Procent ten jest obarczony błędem, o czym zresztą piszemy dalej na tej liście. Co za tym idzie, lepiej nie sugerować się za bardzo konkretną wartością procentową. Bardziej istotne jest to, czy instrukcja jest czy nie jest często spotykana, a mniej istotne to czy powinna być na np. 55. czy 57. miejscu.
• Zgodnie z tym, należy pamiętać, że to jest lista najczęściej występujących unikatowych instrukcji, zaobserwowanych w kodzie (w tzw. deadlistingach). W szczególności nie jest to lista najczęściej wykonywanych instrukcji.
• Wszelkie instrukcje, które pojawiają się dynamicznie w pamięci, np. jako rezultat rozpakowywania kodu albo kompilacji JIT, również nie zostały wzięte pod uwagę przy tworzeniu tej listy.
• Ponieważ źródłem instrukcji był output Ghidry, pewne idiosynkrazje specyficzne dla Ghidry również mają tutaj zastosowanie. Na przykład, prefiks LOCK w Ghidrze pojawia się jako sufiks w nazwie instrukcji. W związku z tym, np. INC i INC.LOCK pojawiają się jako osobne wpisy w tabeli, odpowiednio na pozycji 29. i 78. Jeśli by założyć, że jest to jednak ta sama instrukcja, wtedy znalazłaby się na miejscu 28.
• Trzeba też zwrócić uwagę na inne różnice w wynikach działania różnych dezasemblerów. Przykładowo, niektóre dezasemblery używają sufiksów oznaczających wielkość danych na jakich instrukcja operuje (np. MOVL albo MOV.L). Inne mogą używać reprezentacji NOPn (np. NOP3) do oznaczenia "nic nie robiących" wielobajtowych instrukcji w miejscu faktycznych instrukcji wynikających z kodowania.
• Biorąc pod uwagę problem z rozróżnieniem co jest a co nie jest kodem w programie (zwykle rozwiązywany za pomocą dużej ilości heurystyki), zapewne wdarł się tutaj niewielki błąd również na tym froncie. Podobnie w przypadku błędów, gdy przebieg dezasemblera został rozpoczęty na złym offsecie (tj. wewnątrz faktycznie wygenerowanej instrukcji) – na szczęście to ma tendencje się bardzo szybko synchronizować.
• Są pewne różnice w kolejności i instrukcjach, które pojawiają się w top 100 pomiędzy Windowsem a Ubuntu. Wynika to z tego, że na różnych platformach używane są różne kompilatory, które różnie generują kod wynikowy.
• Podobnie, rezultaty będą inne np. na Gentoo, zwłaszcza jeśli używa się niestandardowych ustawień kompilatora w swoim make.conf.
• I na koniec, lista popularności instrukcji będzie się również różnić pomiędzy kodem trybu użytkownika a kodem jądra. Stwierdzając to co oczywiste, uprzywilejowane instrukcje nie pojawiają się w programach w trybie użytkownika, poza ewentualnymi błędami i oczywiście lokalnymi exploitami.

Top 100 najpopularniejszych instrukcji x86-64