GHIDRA vs. IDA Pro


Salam


Saya pikir waktunya telah tiba. Kembung / mendidih / punya pendapat. Dengan rilis Hydra, situasi dengan alat-alat untuk insinyur terbalik telah banyak berubah. Jika sebelumnya tidak ada pilihan khusus apa yang harus digunakan ( Binary Ninja , Hopper , JEB atau Radare2 tidak akan disebutkan di sini , karena di perusahaan keamanan informasi dan komunitas saya tahu mereka menggunakan sejumlah kecil orang, atau ambang batas untuk bergabung dengan beberapa (hi, Radar) sangat tinggi, atau cakupan arsitektur hanya terbatas pada x86 / x64 / ARM / ARM64 / MIPS ), sekarang kami memiliki pesaing yang sangat kuat, Hex-Rays diwakili oleh NSA dengan GHIDRA mereka.


Tetapi apakah Hydra begitu baik? Apakah IDA buruk (atau sebaliknya)? Mari kita perbaiki. Dalam "artikel" ini saya mencoba mengurangi semua pro dan kontra dari kedua alat. Saya tidak memiliki tujuan untuk mengatakan bahwa alat ini atau itu lebih baik - menarik kesimpulan Anda sendiri. Selain itu, satu dan instrumen kedua sedang berkembang. Dan artikel tersebut hanya akan berisi hasil perbandingan pada saat penulisan. Perbandingan akan dilakukan dalam kategori berikut:


  1. Arsitektur yang Didukung
    Jika Anda adalah insinyur balik yang hanya bekerja dengan platform Intel (x86 / x64), maka kehadiran semua yang lain tidak terlalu penting bagi Anda. Tapi, jika harus bekerja dengan banyak berbeda hosting file arsitektur, semakin banyak akan ada dalam pengiriman default, semakin baik.
  2. Format yang didukung
    Sama seperti pada paragraf sebelumnya, hanya berkaitan dengan format data.
  3. Kualitas Dekompilasi
    Komponen yang paling penting dan paling penting adalah dekompiler. Tidak ada banyak arti dari disassembler sendiri, jadi di sini adalah ikhtisar tentang apa yang dapat / menghasilkan Ghidra / IDA .
  4. Ekstensibilitas, SDK / API
    Penting bagi para insinyur balik yang bekerja dengan berbagai arsitektur, format, dan melakukan banyak tugas serupa secara teratur untuk dapat dengan cepat dan mudah menulis modul / loader / skrip tambahan. Akan menyenangkan juga bisa
    debug mereka. Mari kita lihat bagaimana kinerja setiap produk.
  5. Dokumentasi
    Tampaknya, mengapa itu dibutuhkan? Kita semua sudah lama terbiasa dengan hotkey, menemukan mana untuk menulis plugin, dll., Kita juga menemukan antarmuka. Tetapi berapa lama waktu yang dibutuhkan? Dengan dokumentasi, terutama yang berkualitas tinggi, ini akan lebih cepat dan lebih tenang.
  6. Debugger (untuk file yang diselidiki)
    Komponen penting dan perlu untuk lingkungan rekayasa terbalik. Dalam statika juga dimungkinkan, tetapi dalam dinamika lebih mudah.
  7. Kecepatan Analisis File
    Jika datang ke file yang sangat besar (dari 10 MB atau lebih), penting bahwa lingkungan rekayasa balik tidak memaksa Anda untuk pergi minum teh, tidur ketika file sedang dianalisis.
  8. Kenyamanan kerja (antarmuka, tombol pintas, fokus pada input keyboard)
    Terlepas dari kenyataan bahwa hal utama adalah fungsionalitas, cara itu disajikan kepada pengguna, bagaimana penampilannya, memainkan peran penting. Jika antarmuka memungkinkan untuk tidak menggunakan mouse untuk formulir dan perintah yang sering digunakan, ini merupakan nilai tambah. Jika Anda perlu melewati banyak jendela untuk menambahkan argumen input ke suatu fungsi, ini sudah minus. Bandingkan.
  9. Rilis versi baru
    Seberapa cepat bug diperbaiki, fitur baru ditambahkan, dan, dengan demikian, versi baru dilepaskan, merupakan indikator tim pengembangan yang baik dan pendekatan yang serius.
  10. Kesulitan mendapatkan kit distribusi
    Beli, unduh, bangun distribusi - itu saja di sini.
  11. Dukungan
    Apakah Anda ingin melaporkan kesalahan kepada penulis, menyarankan fitur baru, atau hanya bertanya tentang sesuatu - semua ini tentang dukungan. Kami akan mencari tahu siapa yang lebih baik - produk berbayar atau gratis.
  12. Komunitas
    Kehadiran komunitas, dan kesempatan untuk berkomunikasi dengannya, mendiskusikan masalah pengembangan, pertanyaan tentang fungsi, atau hanya mendapatkan saran yang baik dari orang-orang berpengetahuan (bukan pengembang) - ini adalah komunitas.
  13. Kolaborasi Proyek
    Pekerjaan beberapa orang dalam satu proyek cukup penting untuk diabaikan.

Perbandingan


1. Arsitektur yang Didukung (IDA)


Di luar kotak, IDA Pro mendukung sejumlah besar prosesor dan modifikasinya. Daftar ini terhormat: https://hex-rays.com/products/ida/processors.shtml
Daftar prosesor berbeda untuk Professional Edition Starter dan Professional Edition , 64-bit hanya didukung dalam versi Pro (dan juga dalam versi demo , terima kasih slinkinone ). Platform di yang terakhir cukup langka, namun demikian.


Jika pekerjaan tidak berfokus pada IoT, maka Starter cukup, jika tidak, Anda harus membeli versi Pro .
Dekompilasi hanya tersedia untuk x86 / x64 / arm / arm64 / PowerPC , pada paruh pertama tahun depan mereka berjanji untuk meluncurkan dekompiler MIPS .


1. Arsitektur yang didukung (GHIDRA)


Tidak ada versi online dari daftar, jadi saya membawanya ke sini:



Di sini daftar disajikan dalam bentuk prosesor inti (tanpa modifikasi), tetapi ini tidak berarti bahwa mereka tidak didukung. Dekompiler tersedia untuk masing-masing modul prosesor.


2. Format yang Didukung (IDA)


Daftar format di sini: https://hex-rays.com/products/ida/file_formats.shtml


Daftarnya cukup besar. Plus ada plugin dari komunitas yang tidak akan pernah ditambahkan ke kotak, seperti Untuk melakukan ini, Anda perlu mendiskusikan momen tersebut dengan Ilfak Gilfanov (pengembang utama).


2. Format yang didukung (GHIDRA)


Daftar format 1
  • android
    1. apk
    2. bootimg
    3. dex
    4. kernel
    5. odex
    6. xml
  • bplist
  • kopi
  • puas
  • cpio
  • ext4
  • gzip
  • ios
    1. apple8900
    2. btree
    3. decmpfs
    4. dmg
    5. dyldcache
    6. generik
    7. ibootim
    8. img2
    9. img3
    10. img4
    11. ipsw
    12. png
    13. prelink
    14. xattr
  • iso9660
  • java
  • lzss
  • OMF
  • sevenzip
  • sparseimage
  • tar
  • ubi
  • xar
  • yaffs2
  • zip
  • zlib

Daftar format 2
  • kopi
  • katai
  • katai4
  • peri
  • lx
  • macho
  • makro
  • mz
  • ne
  • objc2
  • objektifC
  • OMF
  • pdb
  • pe
  • pef
  • ubi
  • xcoff

Daftar di atas hanyalah daftar direktori di https://github.com/NationalSecurityAgency/ghidra/tree/master/Ghidra/Features/FileFormats/src/main/java/ghidra/file/formats
Daftar file lain di sini: https://github.com/NationalSecurityAgency/ghidra/tree/master/Ghidra/Features/Base/src/main/java/ghidra/app/util/bin/format


3. Quality decompilation (IDA)


Decompiler Ida bekerja sangat baik dengan kode x86 / x64 / arm / arm64 (saya tidak bisa mengatakan apa-apa tentang PowerPC , karena saya belum melihatnya), yang dihasilkan oleh beberapa kompiler standar, yang sebagian besar menghasilkan daftar-C yang rapi.


Awalnya, pengembang fokus pada kode MS-DOS, sehingga artefak dari kompiler yang bahkan sudah sangat lama diperhitungkan (karenanya, dalam antarmuka di banyak jendela terdapat , , es / ds / ss / fs / gs ( ds - bahkan pada MIPS!)), Hingga cukup baru. Benar, optimisasi kompiler IDA dihidupkan tidak berfungsi dengan baik, dan knalpotnya berubah menjadi neraka.


Dengan kode yang ditulis dalam kompiler yang tidak diketahui oleh Ida (atau dalam assembler), hasilnya menjadi sangat buruk: menggunakan calling convention standar mengubah daftar yang didekompilasi menjadi serangkaian garis yang hampir tidak dapat dibaca.


Kebutuhan untuk mengatur register yang diperlukan secara manual di jalur input dari prototipe fungsi melalui __usercall dengan @ dan <> , di satu sisi, adalah minus besar, terutama ketika ada banyak register, dan di sisi lain, Hydra tidak memiliki ini, dan hanya ada melalui GUI, yang tidak Itu selalu nyaman jika jumlah register yang digunakan kecil.


3. Kualitas dekompilasi (GHIDRA)


Saya tidak tahu orang-orang yang akan mengatakan bahwa Hydra decompiler itu keren. Di sini, untuk kegembiraan, kemungkinan besar itu ada secara umum, dan ada untuk setiap prosesor yang didukung!


Hydra decompiler memiliki banyak sampah dalam kode yang dikeluarkan, yang tidak biasa bagi pengguna Ida, yang sering mengalihkan perhatian dari memahami esensi dari apa yang terjadi di dalamnya.


Tetapi dekompiler Hydra memiliki satu fitur luar biasa - ia memiliki emulator instruksi, yang memungkinkannya membuang sampah yang tidak digunakan dan tidak akan pernah dipanggil, sembari menyederhanakan beberapa poin.


Juga, dekompiler Hydra tidak peduli di mana register argumen datang - jika mereka diakses, mereka akan digunakan.


Di sini saya ingin mencatat mengapa Hydra atau Ida memiliki masalah khusus mereka dengan dekompilasi. Intinya adalah orientasi masing-masing produk. IDA , seperti yang saya catat di atas, dibuat dengan orientasi pada MS-DOS dan, secara umum, pada x86, kemudian secara bertahap mencakup x64 dan ARM. Karenanya, kualitas knalpot yang luar biasa untuk platform ini, tetapi sama sekali tidak ada cakupan untuk yang lain.
Untuk Hydra, sebaliknya, itu dibuat dengan tujuan membalikkan perangkat IOT. Karenanya sejumlah besar prosesor yang didukung, deskripsi yang jelas dari masing-masing, dan kemampuan sederhana untuk membuat yang baru. Tetapi, karena fakta bahwa pengembang mencoba untuk menutupi banyak arsitektur, meningkatkan knalpot dekompiler tidak menjadi prioritas.

4. Extensibility Fungsionalitas (IDA)


Ida memungkinkan Anda untuk menulis modul loader, plugin, debugger dan prosesor, serta skrip langsung di antarmuka. Beberapa dapat ditulis dengan python, yang sedikit lebih nyaman (melalui plugin IDAPython , ditulis bukan oleh pengembang IDA , oleh Elias Bachaalany ).


Proses mengembangkan plugin selama versi 6.x cukup rumit, seperti dokumentasi waras tidak ada. Sekarang zaman telah berubah, menulis karya Anda sendiri menjadi lebih mudah. Ada kontes yang diadakan setiap tahun, di mana pengembang memilih plugin terbaik menurut pendapat mereka (dan pandangannya agak kontroversial). Misalnya, dalam kontes terakhir yang dimenangkan, jangan pernah menebak yang mana kontraktor fungsional expander ... Ternyata menjadi plugin yang MEMBUNUH Undo dukungan di IDA ! Tidak ada kata-kata. Pengembang telah meminta fitur ini begitu lama, tetapi sampai GHIDRA , tidak ada yang mau menggerakkan jari. Dan sekarang - tolong hapus fitur keren dengan plugin - Anda menang, selamat!


Plugin debugging mudah, terutama jika ditulis dalam C ++. Debugging python atau skrip IDC lebih sulit, dan tidak ada cara resmi.


Rasa sakit yang sangat parah pada anus dimulai ketika API sepenuhnya ditulis ulang di versi 7.0 , membuatnya tidak kompatibel dengan versi yang lebih lama. Di satu sisi, nama-nama fungsi dibuat lebih jelas, argumen tambahan dihapus, pengembangannya menjadi lebih mudah. Tetapi, jika Anda, seperti saya, mengembangkan plugin untuk versi 6.x , dan Anda perlu mentransfer gagasan Anda ke SDK baru, maka Anda sakit kepala.


Dan kemudian di versi 7.1 , perubahan kembali terjadi, dan semuanya harus diperbaiki dengan cara yang baru.


4. Extensibility Fungsionalitas (GHIDRA)


Ghidra ditulis dalam Java (dengan dekompiler dalam C++ ), dengan dukungan untuk skrip Python (via Jython ). Plugin GhidraDev untuk Eclipse termasuk dalam paket standar, memungkinkan Anda untuk membuat template proyek (yang dapat diimpor nanti ke IntelliJ IDEA ). Pengisian otomatis dalam IDE dan dokumentasi berfungsi dengan baik dan dibutuhkan setengah jam untuk mengetahui cara menulis plug-in pertama Anda.


Selain itu, dalam pengiriman dasar ada banyak skrip yang ditulis untuk hampir semua aplikasi yang mungkin. Mereka juga dapat diperbaiki, jika perlu.


Menggunakan Eclipse nyaman untuk debug proyek Anda tepat selama pengembangan.


5. Dokumentasi (IDA)


Dokumentasi IDA adalah titik lemahnya, dan memang sudah lama. Seperti kebanyakan pengembang, bias masuk ke fungsionalitas daripada dalam dokumentasinya. Oleh karena itu file HLP sedikit datang dalam pengiriman.


Buku " IDA Pro Book " tidak ditulis oleh pengembang, dan dirilis hanya untuk versi ke-6. Sejak itu, tidak ada buku baru yang diterbitkan, tidak ada manual untuk mengembangkan plugin dari pengembang.


Di suatu tempat dari versi 7.0 dokumentasi mulai tumbuh menjadi versi web, dan deskripsi yang buruk tentang fungsi API dari SDK.




5. Dokumentasi (GHIDRA)


Dokumentasi untuk Hydra, tidak seperti Ida, ditulis bersamaan dengan pengembangan. Dari sini, kami memiliki komentar di hampir setiap fungsi API yang disebut, elemen enumerasi, dan kelas. File bantuan yang datang dengan pengiriman dan menggambarkan antarmuka dan pengaturan Hydra juga dibuat dengan baik, dengan screenshot dan contoh untuk, pada kenyataannya, setiap tombol atau item menu.




6. Debugger (IDA)


Ya, dia. Dan itu berhasil. Windows, Linux, MacOS, ditambah kemampuan untuk terhubung melalui gdb . Mengenai yang terakhir: untuk sebagian besar platform non-standar saya harus menulis modul debugger saya sendiri, sekarang ada kesempatan untuk debug melalui gdb untuk platform seperti: x86 / x64 , ARM / AArch64 , PowerPC , MIPS , Motorola 68k , Infineon TriCore , Renesas RH850 . Daftar lengkap di sini: https://hex-rays.com/products/ida/debugger/index.shtml#details


6. Debugger (GHIDRA)


Sayangnya, belum ada debugger di domain publik. Dok di WikiLeaks menyebutkan beberapa modul debugging. Namun demikian, diketahui bahwa NSA sedang mengerjakan ini, dan akan ada debugger!


Sementara itu, melalui plugin yang memperluas kemampuan antarmuka, dimungkinkan untuk menulis debugger Anda sendiri. Namun ternyata, tidak ada yang melakukan ini.


7. Kecepatan kerja (IDA)


Lebih dari file besar, Ida engah Hydra lebih sedikit, tetapi tidak selalu. Alat analisis Ida berjalan dalam mode single-threaded, dan pada file besar satu core terisi penuh sementara sisanya idle. Dalam waktu dekat, penulis tidak akan mengubah ini (dari kata-kata pengembang).


7. Kecepatan kerja (GHIDRA)


Ketika percakapan antara kedua pembalik datang untuk membahas kecepatan Ida dan Hydra ini, semua orang sampai pada kesimpulan bahwa Hydra membutuhkan banyak waktu untuk memproses file besar. Meskipun ditulis dengan mempertimbangkan multithreading. Dan Java disalahkan: plus untuk cross-platform, minus untuk kecepatan. Namun, jika Anda mengkonfigurasi jumlah memori, tumpukan dan tumpukan untuk JVM , serta jumlah utas, pekerjaan sedikit dipercepat.


8. Kegunaan (IDA)


Tidak diragukan lagi, banyak orang yang tahu hotkey Ida. Mereka sederhana dan mudah, seringkali intuitif. Banyak item menu dan fitur Ida dapat dipanggil dari keyboard, yang cukup nyaman.


Mengenai penampilan, hingga beberapa versi 6.x antarmuka grafis yang ditulis sendiri digunakan. Selanjutnya, pengembang sepenuhnya beralih ke Qt . Antarmukanya sudah pasti lebih bagus. Lokasi tab, tombol, dan elemen antarmuka tidak berubah untuk waktu yang lama.


Dari sini baik pro dan kontra mengikuti. Pro - antarmuka sudah biasa, Anda tidak perlu mencari di mana itu dan melawan kebiasaan. Kontra - beberapa elemen tetap belum sempurna (editor struktur terlihat seperti warisan versi lama Ida) atau tidak digunakan 90% dari waktu ..



8. Kenyamanan kerja (GHIDRA)


Semuanya justru sebaliknya. Sebuah produk baru di pasar, perbedaan hotkey dibandingkan dengan Ida, sedang melakukan tugasnya. Kecepatan kerja, yang sejak lama bekerja dengan Ida telah mencapai kecepatan luar biasa, mulai merosot di Hydra. Tetapi, tentu saja, dengan kerja yang berkepanjangan dalam kebiasaan terakhir juga muncul, dan itu menjadi tidak terlalu sulit.


Hydra memiliki banyak menu, jumlah elemen yang terkadang cukup besar, dan tidak semua item memiliki tombol pintas. Tetapi pada saat yang sama, konfigurator pengaturan hotkey memungkinkan Anda untuk menggantung hotkey Anda sendiri di hampir setiap perintah.


Karena Ghidra ditulis dalam Java , para pengembang menggunakan fungsionalitas dasar dari JDK , yaitu Swing . Karena ini, kita memiliki apa yang kita miliki. Tapi ini tidak bisa disebut minus Hydra.


9. Pelepasan versi baru (IDA)


Pernahkah Anda memperhatikan bahwa dengan rilis Hydra, versi baru Ida mulai keluar lebih sering? Tapi saya sudah mencermati. Apakah kamu tahu mengapa? Tentu saja intinya adalah kompetisi. Akhirnya dia muncul!

Sebelumnya, versi baru Ida jarang dirilis, Ida sangat enggan untuk mendapatkan fungsionalitas baru. Setelah melaporkan bug, Anda seharusnya tidak mengharapkan bahwa koreksi yang dikirim pengembang kepada Anda akan segera muncul di kolega Anda. Tidak ada patch sistem, seperti pengembang menambal file utama untuk setiap pelanggan (tanda air).


Tampaknya kecepatan rilis versi baru Ida akan meningkat karena persaingan produk.


9. Rilis versi baru (GHIDRA)


Keteraturan rilis versi baru Hydra cukup besar: sekitar enam versi telah dirilis sejak sumbernya diterbitkan.


Jika Anda menunggu lama untuk rilis distribusi baru, Anda bisa membangun cabang master dengan github . Pertama kali akan membutuhkan lebih dari satu jam, tetapi itu sangat berharga.


10. Kesulitan mendapatkan kit distribusi (IDA)


Semua orang tahu cerita ini: " Ilfak Gilfanov - lawan pembajakan! ". Karena itu, akses ke versi Pro dan Starter dari kit distribusi untuk pembelian menjadi sangat sulit dan suram. Untuk manusia biasa yang tidak memiliki akses ke uang gila kotak surat tidak pada server surat publik seperti gmail , mail.ru , dll. distribusi tidak dimungkinkan. Dan, bahkan jika Anda memiliki IP Anda sendiri, situs web Anda, Anda harus melalui banyak pemeriksaan, mengirim scan, konfirmasi, dll. Dan semuanya agar distribusinya tidak diposting di Internet. Ini tidak selalu membantu.


Versi yang gembira muncul, tetapi jarang. Oleh karena itu, sebagian besar penggemar teknik terbalik menggunakan distribusi ESET lama, yang dulu digabungkan, dan antivirus Cina.


Belum lama ini, versi resmi, tetapi terpotong untuk siswa mulai muncul, tanpa dekompiler, dan banyak pembatasan lainnya (lebih detail di sini ).


10. Kesulitan mendapatkan distribusi (GHIDRA)


Tampaknya tidak ada yang bisa ditulis sama sekali, tetapi. Padahal, akses ke situs utama Hydra dilarang dari Rusia, Israel dan Cina. Perlu VPN , atau Tor (kecepatan unduh yang sesuai). Tidak ada rilis di github , hanya kode sumber.


11. Dukungan (IDA)


Betapa saya harus berkomunikasi dengan dukungan Hex-Rays , selalu ada pengalaman berbeda: beberapa orang yang bekerja dalam dukungan sangat sopan dan selalu siap membantu. Bagian: Pengembang utama, dan komunikasi menjadi kasar. Apalagi jika pendapat itu tidak sesuai. Tapi, mungkin ini sifatnya. Hal yang sama dalam komunikasi dengan pengguna di Internet.


Baru-baru ini ternyata hanya saya yang berkomunikasi dengan dukungan dari teman saya. Bug yang sangat lama terkait dengan hilangnya pilihan selama pengguliran, yang muncul dalam versi 6.6, yang diketahui semua orang, tidak pernah didebitkan oleh pengembang. Dia bertanya ada apa. Dan jawabannya ada dalam gaya: "Saya tidak ingin berkomunikasi dengan orang yang memperlakukan pengguna dengan cara ini ." Sayangnya, reputasi bekerja seperti itu.


Namun demikian, bug dan saran yang saya laporkan kepada pengembang diperbaiki dan diperhitungkan (tidak semua).


11. Dukungan (GHIDRA)


Hydra memiliki repositori di github . Ada issues , dan di sinilah Anda harus melaporkan bug. Kecepatan respons terhadap beberapa bisa sangat panjang atau sangat cepat. Tapi, bug tidak menutup begitu saja, kata mereka, kami tidak ingin mengimplementasikan ini. Semuanya dipertimbangkan, diperhitungkan. .


PR . .


12. (IDA)


, . , -, . , , , .


12. (GHIDRA)


: ghidra.re , -, @GHIDRA , github. , .


13. (IDA)


. , , , -, .


13. (GHIDRA)


. -, .


Kesimpulan


. , - . , Linux β€” // , , .


/ IDA . , . .


, , Ghidra . IDA β€” .


β€” . . , Ghidra , IDA β€” . , , IoT β€” . .


, , . Terima kasih


PS .
PPS 2 - .
PPPS . . netch80 .

Source: https://habr.com/ru/post/id480824/


All Articles