Dekompiler rev.ng Beralih ke Open Source

(rev.ng)

3 poin oleh GN⁺ 2024-03-31 | 1 komentar | Bagikan ke WhatsApp

rev.ng merilis backend dekompiler revng-c ke publik, mengalihkan mesin dekompilasinya menjadi open source, sekaligus meluncurkan beta tertutup UI, situs web baru, rev.ng Hub, dan dokumentasi
Secara lokal, setelah mengonfigurasi CLI dengan skrip instalasi, pengguna dapat memakai revng artifact dan revng ptml untuk melihat hasil dekompilasi dalam bentuk kode C yang valid
UI interaktifnya berbasis VSCode, ditargetkan berjalan di browser dan sebagai aplikasi mandiri, serta tersedia dalam beta tertutup yang mengundang pelanggan newsletter dengan sistem FIFO
Pemulihan struktur data otomatis, reversing kolaboratif, dukungan berbagai arsitektur, dan ekstensibilitas adalah tujuan utama, tetapi QA saat ini paling berfokus pada binary Linux x86-64
Framework dan CLI bersifat open source, UI cloud disediakan gratis untuk proyek publik, sementara proyek privat dan UI mandiri offline dipisahkan dalam model berbayar

Peralihan ke open source dan beta tertutup

rev.ng merilis revng-c, backend dekompilernya, sebagai open source
- Dengan rilis ini, seluruh mesin dekompilasi menjadi open source
- Dokumentasi awal juga disediakan
UI akan mulai mengirim undangan beta tertutup kepada pelanggan newsletter
- Undangan dilakukan dengan sistem FIFO
- Untuk ikut beta, perlu mendaftar newsletter
Situs web baru dan rev.ng Hub juga dirilis bersamaan
- rev.ng Hub adalah titik masuk untuk versi cloud
- Pengguna beta dapat membuat proyek, menjalankan UI di browser, dan berkolaborasi dengan pengguna lain
- Meski bukan peserta beta tertutup, pengguna tetap dapat menjelajahi proyek publik
rev.ng juga menyediakan demo privat bagi pengguna yang ingin melihat langsung fiturnya

Mencoba rev.ng dengan CLI

revng dapat dipasang dalam satu direktori tanpa hak akses root, dan dapat dihapus dengan menghapus direktori tersebut

curl -L -s https://rev.ng/downloads/revng-distributable/master/install.sh | bash
cd revng
source ./environment

Contoh example.c adalah program sederhana yang mengembalikan argc * 3

int main(int argc, char *argv[]) {
  return argc * 3;
}

Setelah dikompilasi dengan gcc, menjalankan revng artifact akan menghasilkan output dekompilasi dalam bentuk satu file

gcc example.c -o example -O2
revng artifact \
        --analyze \
        --progress \
        decompile-to-single-file \
        example \
        | revng ptml --color \
        | grep -A2 -B1 '[^_]main\b' \
        > decompiled.c

Contoh output berupa kode bergaya C dengan _ABI(SystemV_x86_64), dan ekspresi return ditampilkan sebagai _argument0 * 3 & 0xFFFFFFFF
Dokumentasi mencakup pengaturan lingkungan kerja, tutorial pembuatan model, dan tutorial analisis

Cakupan beta dan target pengujian

Untuk menggunakan UI, pengguna perlu mendaftar ke newsletter, dan undangan dikirim dalam batch kecil
Rilis ini berfokus pada demo UI dan hasil dekompilasi pada sebagian binary, serta menerima masukan dan laporan bug untuk pekerjaan pada binary nyata
Binary non-sederhana yang digunakan untuk pengujian beserta ukuran .text-nya adalah sebagai berikut
- hostname 2K, ntfscat 4K, umount 8K
- chroot 15K, nc.openbsd 15K, apt-get 18K
- df 45K, parted 38K, gzip 54K
- updatedb.plocate 56K, resolvectl 61K, ps 47K
rev.ng mendukung berbagai ABI dan platform, tetapi QA awal pada tahap ini berfokus pada binary Linux x86-64
Jika terjadi masalah, pengguna dapat memperoleh bantuan di Discourse

Pengalaman dekompilasi yang dituju rev.ng

Fokus utama rev.ng adalah pemulihan struktur data otomatis, UX modern, reversing kolaboratif, dukungan platform luas, dan ekstensibilitas
Pemulihan struktur data otomatis
- Dengan Data Layout Analysis, layout struct dapat dipulihkan secara otomatis melalui analisis antarprosedur
- Contoh node linked list menargetkan struct yang memiliki array int64_t data[5] dan pointer ke node berikutnya
- Output rev.ng menghasilkan struct dan kode fungsi yang secara otomatis mendeteksi ukuran array 5 dan akses pointer ke elemen berikutnya
- Output dekompiler adalah kode C yang valid secara sintaksis
- Fitur ini saat ini sudah tersedia
UI interaktif berbasis VSCode
- Karena UI berbasis VSCode, pengguna VSCode dapat menggunakannya dengan cara yang familier
- UI dapat berjalan baik di tab browser maupun sebagai aplikasi mandiri
- Shortcut utama adalah sebagai berikut
  - Ctrl + Click: pindah ke definisi fungsi atau tipe di bawah kursor
  - N: ganti nama
  - Y: edit tipe
  - X: tampilkan referensi
- rev.ng adalah dekompiler interaktif yang hanya menghitung ulang bagian terdampak saat ada perubahan
- UI saat ini disediakan untuk peserta beta tertutup
Reversing kolaboratif
- UI rev.ng menggunakan arsitektur client-server
- Beberapa pengguna dapat terhubung ke instance daemon yang sama dan bekerja bersamaan pada proyek yang sama
- Pada versi cloud, tersedia rev.ng Hub, aplikasi mirip GitHub untuk manajemen proyek
- Fitur kolaborasi sudah berfungsi, tetapi pengalaman pengguna masih perlu ditingkatkan, dan dilacak di item roadmap #797

Cara dukungan arsitektur dan platform

rev.ng menggunakan bagian awal pipeline QEMU untuk mengangkat kode yang dieksekusi menjadi tiny code, mengubahnya menjadi LLVM IR, lalu melakukan dekompilasi
Berkat struktur ini, rev.ng dapat mendukung arsitektur yang didukung QEMU dengan relatif mudah
Selain dukungan arsitektur, dukungan platform, terutama ABI, juga penting
- rev.ng menggunakan ABI description format untuk mendeskripsikan properti ABI secara deklaratif
- Format ini dirancang cukup umum agar mudah menambahkan dukungan ABI baru
Status dukungan saat ini adalah sebagai berikut
- Arsitektur: x86, x86-64, ARM, AArch64, MIPS, dan s390x didukung dengan tingkat kematangan berbeda
- Format binary: mendukung ELF, PE/COFF, dan Mach-O
- Impor: mendukung .idb, informasi debug DWARF, dan informasi debug PDB
Sebagian besar QA dilakukan pada binary Linux x86-64, dan sisanya masih memerlukan QA tambahan
QA untuk lebih banyak platform dilacak di item roadmap #58

Ekstensibilitas dan scripting

rev.ng bertujuan menjadi framework untuk alat reverse engineering, dan seluruh proyek selain UI interaktif bersifat open source
File proyek, yaitu model, adalah dokumen YAML, sehingga rev.ng dapat di-script selama pengguna dapat mem-parse JSON atau YAML
Model berisi arsitektur binary target dekompilasi, ABI default, segmen, daftar fungsi, daftar tipe, dan lainnya
Model dapat dimodifikasi dengan wrapper untuk Python dan TypeScript
- Saat ini sudah ada wrapper manipulasi model, tetapi belum ada cara yang memudahkan eksekusi analisis dan pengambilan artefak
- Klien Python lengkap dilacak di item roadmap #17
LLVM IR banyak digunakan dalam representasi internal, sehingga alat dari ekosistem LLVM dapat dimanfaatkan
- Eksekusi simbolik menggunakan KLEE
- Fuzzing berbasis cakupan menggunakan SanitizerCoverage dan libFuzzer
- Eksperimen menerapkan clang static analyzer pada output dekompilasi C yang valid untuk menemukan kerentanan umum

Pemisahan antara CLI open source dan UI berbayar

Framework rev.ng sepenuhnya open source, dan pengguna dapat mendekompilasi target apa pun dari CLI
Bentuk penyediaan UI dibagi menjadi tiga
- UI cloud untuk proyek publik dapat digunakan gratis
- UI cloud untuk proyek privat memerlukan langganan
- UI yang sepenuhnya mandiri dan sepenuhnya offline disediakan secara berbayar
Cara penggunaan cloud adalah sebagai berikut
- Buat proyek di rev.ng Hub dan undang kolaborator
- UI berjalan di browser
- Backend berjalan di cloud rev.ng
Jika file proyek boleh dipublikasikan, versi cloud rev.ng termasuk UI dapat digunakan secara gratis
Instalasi layanan private cloud on-premises menggunakan Kubernetes juga dapat didiskusikan

Roadmap 1.0 dan kanal kontak

Roadmap hingga 1.0 dibagi menjadi 4 tier
- Tier 1: versi alfa, demo untuk kenalan, selesai
- Tier 2: versi beta, memberikan akses versi cloud kepada pelanggan newsletter, saat ini dimulai
- Tier 3: beta terbuka, direncanakan
- Tier 4: rilis 1.0, direncanakan
Progres terperinci dapat dilihat di halaman roadmap
Kabar proyek dan kanal dukungan adalah sebagai berikut
- X/Twitter: kabar pengembangan dan pengumuman penting
- Discord: percakapan real-time dengan tim pengembang
- Discourse: dukungan pengguna dan laporan bug
- GitHub: pengembangan open source dan pendaftaran issue
- Monthly newsletter: partisipasi beta tertutup dan kabar bulanan
- E-mail: pertanyaan privat

1 komentar

GN⁺ 2024-03-31

Opini Hacker News

Model harganya adalah framework rev.ng sepenuhnya open source, dan di CLI Anda bisa mendekompilasi apa pun
UI akan tersedia gratis di cloud untuk proyek publik, berlangganan cloud untuk proyek privat, dan aplikasi offline yang sepenuhnya mandiri akan tersedia berbayar
Sebagai perbandingan, Hopper harganya 100 dolar termasuk pembaruan selama 1 tahun https://www.hopperapp.com/index.html, Ghidra dan Radare2 bebas dan open source sehingga sepenuhnya gratis, sedangkan IDA Pro sangat mahal
- Binary Ninja juga pilihan yang bagus
  Dari pengalaman saya, cukup mirip dengan IDA tetapi lebih ramah pengguna, dan punya banyak fitur yang dirancang dengan baik untuk meningkatkan produktivitas
  Saya belum pernah mencoba Hopper, tetapi pengalaman pengembangan dengan Ghidra dan Radare2 kurang bagus, dan kode C yang dihasilkan juga tidak mudah dibaca. Namun itu berdasarkan pengalaman saya beberapa tahun lalu
  Binja harganya 300 dolar, versi komersial 1500 dolar, dan ada diskon pelajar: https://binary.ninja/features
- Dekompilasi sering kali merupakan bagian yang paling kurang penting dan paling kurang dapat diandalkan di IDA/Ghidra, jadi tidak adil jika membandingkan keduanya secara sederhana
  Meski begitu, decompiler C yang bagus selalu kurang, jadi upaya baru selalu menyenangkan untuk dilihat
- Saya sangat menyukai model lisensi pembayaran sekali dan periode pembaruan yang ditentukan
  Namun saya penasaran bagaimana mereka menegakkannya tanpa membuat aplikasi wajib terhubung ke internet
Melihat halaman tim https://rev.ng/about dan kontribusi kode https://github.com/revng/revng/graphs/contributors, terlihat agak unik bahwa CEO (aleclearmind) memiliki commit jauh lebih banyak daripada CTO (pfez)
CEO lain sering mengatakan mereka hampir tidak punya waktu untuk coding, dan CTO biasanya juga lebih banyak mengurus manajemen dan lebih sedikit coding langsung
Tapi kalau cara ini berjalan baik, sepertinya cukup menarik bagi tim. Edit: saya belum memeriksa timeline-nya
- CTO terutama bekerja pada backend decompiler revng-c yang baru saja dirilis: https://github.com/revng/revng-c/commits/develop/
  Pada akhirnya kedua repositori itu rencananya akan digabung
  Dan saya mengembangkan setiap hari, tetapi entah kenapa GitHub tidak mengenali pengguna saya dengan benar
  Memang menyenangkan
- CTO melakukan lebih banyak commit baru-baru ini, dan commit aleclearmind turun menjadi 0 setelah 2020, jadi sepertinya ia juga makin sulit meluangkan waktu untuk coding
- Saya sama sekali tidak bermaksud mengkritik, jadi saya agak penasaran kenapa mendapat downvote
  Justru saya menyukai hal seperti ini, dan menurut saya menarik karena berbeda dari yang saya lihat di tempat lain
  Apakah di-downvote karena tidak menarik atau tidak unik?
Tampaknya perusahaan keren yang mendapatkan energi dari salah satu buku teori bahasa pemrograman terbaik yang ada: https://link.springer.com/book/10.1007/978-3-662-03811-6
“Ia juga bertemu Pietro, yang kelak menjadi kaki tangannya. Cukup romantisnya, ia bertemu dengannya berkat buku yang akan menjadi fondasi perusahaan.”
https://rev.ng/about
- Kisah lengkap di balik buku itu seperti ini. Saya mulai mempelajari compiler, tetapi teorinya terlalu sulit, dan buku-buku terkenal juga tidak cocok untuk saya, jadi saya cukup patah semangat
  Lalu saya menemukan buku ini yang padat tetapi tampak jelas, dan ketika saya bertanya kepada pembimbing apakah saya boleh membelinya, ia berkata, “coba cek perpustakaan universitas dulu”
  Perpustakaan punya salinannya, tetapi sedang dipinjam, dan sebagai seseorang yang berada di satu-satunya grup yang meneliti compiler, saya berpikir, “siapa berani-beraninya mengerjakan compiler di luar grup kami?”
  Saya pergi ke perpustakaan dan bertanya siapa yang meminjamnya, tetapi mereka bilang tidak bisa memberi tahu karena alasan privasi; saya hanya menanyakan huruf ketiga dari nama keluarga dan huruf kedua dari nama depan, lalu mendapatkan Z dan I
  Saya menemukannya di sini: https://www.deib.polimi.it/ita/personale-lista-alfabetica
  Waktu berlalu, kami menjadi teman dan mendirikan perusahaan bersama
  Butuh sangat banyak pekerjaan hingga peluncuran
Akan bagus jika nama variabel dan nama anggota struct bisa diberikan secara otomatis berdasarkan bagaimana kode menangani variabel dan anggota struct tersebut
Misalnya pointer berikutnya pada linked list semestinya mudah diidentifikasi sebagai next
Tampaknya mungkin untuk mengunduh seluruh GitHub, mencari variabel yang layout dan interaksinya paling mirip di kode, lalu memakai nama itu jika tingkat kepercayaannya cukup tinggi
- Dulu saya pernah mencoba melakukan hal seperti ini secara manual
  Misalnya, jika mendeteksi variabel induksi, mengganti namanya menjadi i
  Namun sekarang cara yang benar untuk hal seperti ini tampaknya cukup jelas, yaitu memakai LLM
  Hanya saja pada tahap ini kami lebih seperti orang yang membangun fondasi yang kokoh; setelah fondasinya siap, mengganti nama atau menambahkan komentar dengan model yang sudah tersedia relatif mudah
  Intinya, pekerjaan dekompilasi yang sulit dan membutuhkan akurasi 100% kami tangani, sedangkan untuk bagian seperti nama dan komentar yang boleh berupa perkiraan, LLM bisa diperkenalkan
  Bagaimanapun, membuat skrip untuk mengganti nama cukup mudah, jadi lihat dokumentasinya: https://docs.rev.ng/user-manual/model-tutorial/
- Sepertinya akan sangat keren, terasa seperti http://jsnice.org/
  Makalah yang menjelaskan apa yang dilakukan JSNice secara internal: https://files.sri.inf.ethz.ch/website/papers/jsnice15.pdf
- Kedengarannya mirip sidekick milik Binary Ninja
- Semacam GitHub Copilot untuk reversing?
Tidak berfungsi pada file ELF saya
Saat menjalankan ./revng artifact --analyze --progress decompile-to-single-file ../maytag.ko, muncul Only ELF executables and ELF dynamic libraries are supported, dan file tersebut terdeteksi sebagai ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped
Apakah binari FreeBSD tidak didukung?
Koreksi: saya melewatkan bahwa modul kernel tidak didukung, dan sepertinya ini bukan karena FreeBSD, melainkan karena file itu bukan executable biasa
- Bisakah membuka issue di GitHub dan melampirkan binarinya?
  Sepertinya memuat ini tidak akan terlalu sulit
Saya berharap ada banyak perhatian pada workflow kolaborasi
Saya belum pernah mencoba sesuatu seperti IDA Teams, tetapi kalau pengalaman reverse engineering yang semulus Google Docs memungkinkan, itu akan luar biasa
- Itu memang tujuan kami
  Dulu kami memakai QtCreator berbasis UI, dan itu pilihan yang buruk sekali
  Setelah itu kami beralih ke VSCode, dan kebetulan bisa berjalan juga di browser
  Jadi dengan sedikit Kubernetes, kami membuat decompiler cloud yang memiliki pengalaman pengguna persis sama dengan versi yang sepenuhnya standalone
  Bagian kolaborasinya masih butuh QA lebih lanjut, tetapi pada dasarnya sudah berfungsi
  Strukturnya sangat sederhana: satu daemon dengan banyak client
  Saya rasa inspirasinya berasal dari pengalaman “berkolaborasi” di CTF dulu, dengan beberapa jendela IDA dan beberapa kursor di atas sesi X server. Caranya sangat terkutuk, tetapi berhasil
Apakah ada rencana mendukung inferensi tipe?
Saat ini sepertinya semua variabel terlihat sebagai generic64_t; akan bagus kalau tipe bisa dideteksi otomatis seperti Ghidra. Tentu saja Ghidra pun kadang salah
- Ada
  Item roadmap: https://rev.ng/roadmap#feature-798
  Pad desain: https://pad.rev.ng/s/eDHi2PUoP#
Terlihat menarik
Saya ingin mencoba versi yang sepenuhnya standalone
Apakah ada kabar perkiraan harganya? Semoga masih terjangkau untuk pengguna hobi
Bertambahnya alat peretasan biner selalu menyenangkan
Karena mungkin ada yang ingin mencobanya langsung, saya meninggalkan saran yang sangat mendetail tentang format pemaketan yang dipilih
source ./environment adalah pertanda kurang baik. Saat saya mengunduh tar-nya, ternyata memang mengatur beberapa variabel lingkungan termasuk PATH, dan untungnya bukan LD_LIBRARY_PATH
Sebagian besar memakai prefiks HARD_, yang mungkin unik, tetapi REVNG terlihat lebih jelas, dan bentrok dengan variabel lingkungan yang sudah ada itu buruk
Ia juga mengatur AWS_EC2_METADATA_DISABLED="true"; saya tidak memakai AWS jadi tidak rusak, tetapi secara umum ini mencurigakan
RPATH_PLACEHOLDER, HARD_FLAGS_CXX_CLANG, PATH yang panjang, string mingw32/gentoo/mips, dan sejenisnya terlihat rapuh
Kalau petunjuk menjalankan berisi “sekarang ubah variabel lingkungan”, biasanya saya menyerah; ini sangat berkorelasi dengan program yang tidak berjalan dengan benar di sistem non-Ubuntu
Mengikat alur kontrol aplikasi ke lingkungan eksekusi punya lebih banyak mode kegagalan daripada yang tampak sekilas, dan sangat mirip dengan variabel global
Clang bisa menanamkan nilai default saat build seperti -DCLANG_DEFAULT_CXX_STDLIB=libc++, dan DEFAULT_SYSROOT juga berguna
Walaupun memakai rpath, jika pengguna menjalankannya saat LD_LIBRARY_PATH sudah disetel, DT_RUNPATH pada biner bisa tertimpa
Saat ini -Wl,rpath sebenarnya berarti runpath, bukan rpath, yang kurang berguna; mungkin pemanggilan yang diinginkan adalah -Wl,rpath -Wl,--disable-new-dtags, agar loader mengabaikan LD_LIBRARY_PATH saat mencari library
Dengan mengombinasikan flag build Clang, static linking, menyematkan biner di dalam biner, dan sebagainya, besar kemungkinan manipulasi variabel lingkungan bisa dihilangkan sepenuhnya
Fakta bahwa biner clang-16 ditautkan secara dinamis dan saat runtime mencari sesuatu seperti libLLVMAArch64CodeGen.so.16 juga menambah mode kegagalan
LLVM_BUILD_STATIC=ON dapat mengurangi masalah ketika lingkungan dengan toolchain modul HPC aktif mengambil library yang salah
Alat-alatnya ditautkan ke libc++.so, libc++abi.so, dan sebagainya; static libc++ layak dipertimbangkan, dan setidaknya lebih baik menautkan libc++abi dan libunwind secara statis ke dalam libc++
Kesabaran saya untuk mendistribusikan program yang ditautkan dinamis di Linux sudah benar-benar habis
Jika source ourhack di README atau variabel lingkungan yang ditinggalkan sistem modul mengubah runtime library aplikasi saya, pengalaman pengguna dan biaya laporan bug berikutnya akan mengerikan
Dibandingkan itu, static linking benar-benar bagus
- Sebagian besar kekhawatiran tentang menyentuh lingkungan sebenarnya hanya benar jika diasumsikan melakukan source environment
  Sebenarnya alasan kami menyarankan itu hanya agar biner demo memakai GCC yang kami distribusikan, dan cara penggunaan yang dimaksud adalah skrip ./revng
  Dalam kasus ini, perubahan lingkungan hanya memengaruhi pemanggilan revng
  Dokumentasinya ada di sini: https://docs.rev.ng/user-manual/working-environment/
  Sebaiknya kami menambahkan peringatan tentang source ./environment
  Kami menghabiskan banyak waktu agar tidak memakai LD_LIBRARY_PATH, dan membuat satu set biner yang sepenuhnya mandiri, dengan setiap ELF merujuk dependensinya lewat path relatif. LD_LIBRARY_PATH itu jahat
  Variabel HARD_ hanya dipakai oleh wrapper compiler, dan menurut saya hampir tidak mungkin benar-benar bentrok
  Diskusi awal tentang AWS_EC2_METADATA_DISABLED="true" ada di https://github.com/revng/revng/pull/309#discussion_r12805759...
  Bisa saja dihindari dengan mem-patch AWS SDK, tetapi bagaimanapun dampaknya hanya ada saat rev.ng dijalankan di cloud
  RPATH_PLACEHOLDER dan HARD_FLAGS_CXX_CLANG dipakai saat menautkan biner yang diterjemahkan oleh revng, dan tidak penting kalau Anda tidak tertarik pada penerjemahan biner end-to-end
  Kami memang sengaja menginginkan DT_RUNPATH. DT_RPATH direncanakan untuk ditinggalkan, dan mungkin ada use case yang perlu mengganti library kami lewat LD_LIBRARY_PATH
  Menurut saya kritik tentang “manipulasi lingkungan” hanya valid jika variabelnya bukan variabel lingkungan privat
  RPATH_PLACEHOLDER, HARD_*, REVNG_* adalah variabel privat dan semuanya untuk tujuan penerjemahan biner
  Kami bisa memindahkannya ke dalam wrapper compiler dengan cakupan yang lebih kecil, tetapi karena kami juga mendistribusikan Python, lingkungan tidak bisa dihilangkan sepenuhnya
  Menanamkan sebagian flag ke Clang saja tidak cukup. Flag ini juga memengaruhi linker, dan ada fungsi wrapper yang tidak bisa sekadar ditanamkan
  Namun memang bisa dipindahkan ke lokasi yang lebih privat
  Tampaknya Anda waspada terhadap dynamic linking, tetapi kami sudah mencurahkan upaya untuk ini dan sekarang bekerja cukup baik serta selalu menemukan lokasi yang benar
  Tidak ada path absolut yang di-hardcode, dan tidak ada tahap instalasi yang “mem-patch” biner. Direktori hasil ekstraksi bisa dipindahkan ke mana saja
  Solusi yang kami pakai tidak menggunakan LD_LIBRARY_PATH; semua biner saling merujuk dengan kokoh melalui $ORIGIN
  Coba jalankan ./root/bin/python ./root/bin/revng artifact --help, itu akan berfungsi
  Sekali lagi, source environment hampir hanya untuk demo, dan dalam penggunaan nyata cukup jalankan ./revng, lingkungan akan tetap apa adanya
  Kami juga mendistribusikan Python, tetapi Anda tidak harus memakainya. Anda bisa memakai ./revng atau berinteraksi lewat jaringan dalam mode daemon
  Pendekatannya adalah mem-parsing dan memodifikasi file proyek YAML dengan alat scripting yang Anda inginkan, lalu memanggil ./revng artifact atau berinteraksi dengan daemon: https://docs.rev.ng/user-manual/model-tutorial/
  Hasilnya, kami bisa memakai versi Python terbaru, dan pengguna bisa memakai bahasa yang mereka inginkan

Ke depannya, kami berencana menyediakan wrapper tambahan di PyPI yang kompatibel dengan berbagai versi Python
Singkatnya, jangan gunakan source ./environment; gunakan ./revng saja
Senang ada orang yang memperhatikan hal-hal seperti ini
Pada iterasi besar berikutnya, kami mungkin memperkenalkan nix + mount namespace agar /nix/store bisa digunakan tanpa hak akses root, sekaligus menyederhanakan banyak hal
Diskusi seperti ini mungkin lebih baik dibicarakan di server Discord daripada di sini

Selamat
Apakah ada penyesalan karena menyerahkan lifting kepada QEMU TCG, atau apakah itu berjalan dengan baik?
- Berjalan sangat baik. Ada dua hal yang disesalkan
  Pertama, kami tidak me-rebase fork QEMU selama beberapa tahun, sehingga situasinya jadi kurang baik
  Meski begitu, baru hari ini seorang anggota tim berhasil melakukan lifting dengan QEMU terbaru, dan kami juga bisa melakukan lifting pada kode Qualcomm Hexagon yang dukungannya kami bantu tambahkan ke QEMU
  Pada akhirnya kami akan menjadi decompiler Hexagon pertama yang benar-benar layak
  Kedua, karena terlalu berfokus pada QEMU, frontend menjadi sangat terkait erat dengan QEMU
  Sekarang, untuk mendukung frontend tambahan yang tidak berbasis QEMU, diperlukan sedikit usaha, tetapi bukan hal yang mustahil
  Gagasannya adalah, ketika pengguna menambahkan dukungan untuk arsitektur baru, mereka cukup mendefinisikan struct status CPU dalam C dan beberapa fungsi yang beroperasi di atasnya
  Tidak perlu mempelajari representasi internalnya
  Singkatnya, QEMU adalah pilihan yang sangat baik, dan karena bekerja terlalu baik, kami lama tidak menyentuh bagian codebase itu sehingga muncul technical debt, tetapi sekarang sedang kami bereskan