Trình decompile rev.ng chuyển sang mã nguồn mở

(rev.ng)

3 điểm bởi GN⁺ 2024-03-31 | 1 bình luận | Chia sẻ qua WhatsApp

rev.ng đã công khai backend decompiler revng-c, qua đó chuyển engine decompile sang mã nguồn mở, đồng thời ra mắt bản beta kín của UI, website mới, rev.ng Hub và tài liệu
Trên máy cục bộ, có thể thiết lập CLI bằng script cài đặt rồi dùng revng artifact và revng ptml để xem kết quả decompile dưới dạng mã C hợp lệ
UI tương tác được xây dựng dựa trên VSCode, hướng tới cả trình duyệt lẫn ứng dụng độc lập, và hiện được cung cấp trong bản beta kín với lời mời gửi tới người đăng ký newsletter theo thứ tự FIFO
Khôi phục cấu trúc dữ liệu tự động, reverse engineering cộng tác, hỗ trợ nhiều kiến trúc và khả năng mở rộng là các mục tiêu cốt lõi, nhưng QA hiện vẫn tập trung nhiều nhất vào binary Linux x86-64
Framework và CLI là mã nguồn mở, UI đám mây được cung cấp miễn phí cho dự án công khai, còn dự án riêng tư và UI độc lập ngoại tuyến được phân tách theo mô hình trả phí

Chuyển sang mã nguồn mở và bản beta kín

rev.ng đã công khai mã nguồn revng-c, backend decompiler của mình
- Với lần công bố này, toàn bộ engine decompile đã trở thành mã nguồn mở
- Tài liệu ban đầu cũng được phát hành cùng lúc
Với UI, công ty sẽ bắt đầu gửi lời mời tham gia bản beta kín cho những người đăng ký newsletter
- Lời mời sẽ được gửi theo thứ tự FIFO
- Để tham gia beta, cần đăng ký newsletter
Website mới và rev.ng Hub cũng được công bố cùng đợt
- rev.ng Hub là điểm truy cập cho phiên bản đám mây
- Người dùng beta có thể tạo dự án, chạy UI trên trình duyệt và cộng tác với người dùng khác
- Kể cả khi không thuộc diện beta kín, bạn vẫn có thể xem qua các dự án công khai
rev.ng cũng tổ chức demo riêng cho những người muốn trực tiếp kiểm tra khả năng của sản phẩm

Thử dùng rev.ng qua CLI

revng có thể được cài vào một thư mục duy nhất mà không cần quyền root, và chỉ cần xóa thư mục đó là gỡ bỏ xong

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

Ví dụ example.c là một chương trình đơn giản trả về argc * 3

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

Sau khi biên dịch bằng gcc, chạy revng artifact sẽ cho ra kết quả decompile dưới dạng một file duy nhất

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

Kết quả đầu ra mẫu là mã dạng C có gắn _ABI(SystemV_x86_64), trong đó biểu thức trả về hiện thành _argument0 * 3 & 0xFFFFFFFF
Tài liệu bao gồm thiết lập môi trường làm việc, hướng dẫn tạo model, và hướng dẫn phân tích

Phạm vi beta và đối tượng thử nghiệm

Để dùng UI, cần đăng ký newsletter, và lời mời sẽ được gửi theo từng đợt nhỏ
Bản phát hành lần này tập trung vào việc demo UI và kết quả decompile trên một số binary, đồng thời thu thập phản hồi và bug report cho các tác vụ với binary thực tế
Các binary không quá đơn giản đã dùng để thử nghiệm và kích thước .text của chúng như sau
- 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 hỗ trợ nhiều ABI và nền tảng, nhưng QA ban đầu ở giai đoạn này chủ yếu tập trung vào binary Linux x86-64
Nếu gặp vấn đề, bạn có thể nhận trợ giúp trên Discourse

Trải nghiệm decompile mà rev.ng hướng tới

Các trọng tâm chính của rev.ng là khôi phục cấu trúc dữ liệu tự động, UX hiện đại, reverse engineering cộng tác, hỗ trợ nền tảng rộng và khả năng mở rộng
Khôi phục cấu trúc dữ liệu tự động
- Với Data Layout Analysis, có thể tự động khôi phục layout của struct thông qua phân tích liên thủ tục
- Ví dụ về node danh sách liên kết dùng một cấu trúc có mảng int64_t data[5] và con trỏ tới node kế tiếp
- Đầu ra của rev.ng tự động phát hiện kích thước mảng là 5 và truy cập con trỏ phần tử kế tiếp để sinh ra cấu trúc cùng mã hàm tương ứng
- Đầu ra của decompiler là mã C hợp lệ về mặt cú pháp
- Tính năng này hiện đã dùng được
UI tương tác dựa trên VSCode
- UI dựa trên VSCode, nên người dùng VSCode có thể tiếp cận theo cách quen thuộc
- Nó có thể chạy cả trong tab trình duyệt lẫn ứng dụng độc lập
- Các phím tắt chính gồm
  - Ctrl + Click: chuyển tới định nghĩa hàm hoặc kiểu dưới con trỏ
  - N: đổi tên
  - Y: chỉnh sửa kiểu
  - X: hiển thị tham chiếu
- rev.ng là một decompiler tương tác chỉ tính toán lại những phần bị ảnh hưởng khi có thay đổi
- UI hiện được cung cấp cho người tham gia bản beta kín
Reverse engineering cộng tác
- UI của rev.ng dùng kiến trúc client-server
- Nhiều người dùng có thể kết nối vào cùng một instance daemon và làm việc đồng thời trên cùng một dự án
- Trong phiên bản đám mây, có thể dùng rev.ng Hub như một ứng dụng kiểu GitHub để quản lý dự án
- Tính năng cộng tác đã hoạt động, nhưng trải nghiệm người dùng vẫn cần cải thiện, và đang được theo dõi tại mục lộ trình #797

Cách hỗ trợ kiến trúc và nền tảng

rev.ng dùng phần đầu của pipeline QEMU để lift mã thực thi thành tiny code, rồi chuyển nó sang LLVM IR trước khi decompile
Nhờ cấu trúc này, có thể hỗ trợ các kiến trúc mà QEMU hỗ trợ tương đối dễ dàng
Bên cạnh hỗ trợ kiến trúc, hỗ trợ nền tảng, đặc biệt là ABI, cũng rất quan trọng
- rev.ng dùng ABI description format để mô tả thuộc tính ABI theo cách khai báo
- Định dạng này được thiết kế đủ tổng quát để việc bổ sung hỗ trợ ABI mới trở nên dễ dàng
Tình trạng hỗ trợ hiện tại như sau
- Kiến trúc: hỗ trợ x86, x86-64, ARM, AArch64, MIPS, s390x với mức độ trưởng thành khác nhau
- Định dạng binary: hỗ trợ ELF, PE/COFF, Mach-O
- Nhập dữ liệu: hỗ trợ .idb, thông tin debug DWARF, thông tin debug PDB
Phần lớn QA được thực hiện trên binary Linux x86-64, còn lại cần thêm QA bổ sung
Việc QA cho nhiều nền tảng hơn đang được theo dõi tại mục lộ trình #58

Khả năng mở rộng và scripting

rev.ng hướng tới trở thành một framework cho các công cụ reverse engineering, và toàn bộ dự án ngoại trừ UI tương tác đều là mã nguồn mở
File dự án model là tài liệu YAML, nên chỉ cần có thể phân tích JSON hoặc YAML là có thể script hóa rev.ng
Model bao gồm kiến trúc của binary cần decompile, ABI mặc định, các segment, danh sách hàm, danh sách kiểu, v.v.
Có thể chỉnh sửa model bằng wrapper cho Python và TypeScript
- Hiện đã có wrapper để thao tác model, nhưng chưa có cách thuận tiện để chạy phân tích và lấy artifact
- Một Python client hoàn chỉnh đang được theo dõi tại mục lộ trình #17
LLVM IR được dùng nhiều trong biểu diễn nội bộ, nên có thể tận dụng các công cụ trong hệ sinh thái LLVM
- Thực thi symbolic bằng KLEE
- Fuzzing dựa trên coverage bằng SanitizerCoverage và libFuzzer
- Thử nghiệm áp dụng clang static analyzer lên đầu ra decompile C hợp lệ để tìm các lỗ hổng phổ biến

Phân tách giữa CLI mã nguồn mở và UI trả phí

Framework rev.ng hoàn toàn là mã nguồn mở, và có thể decompile mục tiêu mong muốn từ CLI
Hình thức cung cấp UI được chia thành ba loại
- UI đám mây cho dự án công khai có thể dùng miễn phí
- UI đám mây cho dự án riêng tư yêu cầu đăng ký thuê bao
- UI hoàn toàn độc lập và hoàn toàn ngoại tuyến được cung cấp theo hình thức trả phí
Cách dùng trên đám mây như sau
- Tạo dự án và mời cộng tác viên tại rev.ng Hub
- UI chạy trong trình duyệt
- Backend chạy trên đám mây của rev.ng
Nếu chấp nhận công khai file dự án, bạn có thể dùng miễn phí phiên bản rev.ng trên đám mây kèm UI
Việc cài đặt dịch vụ private cloud on-premises dùng Kubernetes cũng có thể được thảo luận

Lộ trình 1.0 và các kênh liên hệ

Lộ trình đến 1.0 được chia thành 4 tier
- Tier 1: phiên bản alpha, demo cho người quen, đã hoàn thành
- Tier 2: phiên bản beta, cung cấp quyền truy cập bản đám mây cho người đăng ký newsletter, hiện đã bắt đầu
- Tier 3: open beta, dự kiến
- Tier 4: phát hành 1.0, dự kiến
Có thể xem tiến độ chi tiết tại trang lộ trình
Các kênh cập nhật dự án và hỗ trợ gồm
- X/Twitter: tin tức phát triển và các thông báo chính
- Discord: trò chuyện thời gian thực với đội ngũ phát triển
- Discourse: hỗ trợ người dùng và bug report
- GitHub: phát triển mã nguồn mở và đăng issue
- Monthly newsletter: tham gia beta kín và nhận tin hàng tháng
- E-mail: liên hệ riêng tư

1 bình luận

GN⁺ 2024-03-31

Ý kiến trên Hacker News

Mô hình giá của rev.ng là framework hoàn toàn mã nguồn mở, và trên CLI có thể dịch ngược bất cứ thứ gì
UI sẽ miễn phí trên cloud cho dự án công khai, có gói thuê bao cloud cho dự án riêng tư, còn ứng dụng offline hoàn toàn độc lập sẽ được cung cấp dưới dạng trả phí
Để so sánh, Hopper có giá 100 USD kèm 1 năm cập nhật https://www.hopperapp.com/index.html, Ghidra và Radare2 là phần mềm tự do, mã nguồn mở nên hoàn toàn miễn phí, còn IDA Pro thì rất đắt
- Binary Ninja cũng là một lựa chọn tốt
  Theo trải nghiệm của tôi, nó khá giống IDA nhưng thân thiện với người dùng hơn, và có nhiều tính năng được thiết kế tốt giúp tăng năng suất
  Tôi chưa dùng Hopper, nhưng trải nghiệm phát triển với Ghidra và Radare2 không tốt lắm, và mã C sinh ra cũng khó đọc. Tuy vậy, đó là nhận xét dựa trên lần dùng cách đây vài năm
  Binja có giá 300 USD, bản thương mại 1500 USD và cũng có giảm giá cho sinh viên: https://binary.ninja/features
- Dịch ngược thường là phần ít quan trọng nhất và kém đáng tin cậy nhất trong IDA/Ghidra, nên so sánh hai công cụ chỉ dựa trên điểm đó là không công bằng
  Dù vậy, decompiler C tốt thì lúc nào cũng thiếu, nên các nỗ lực mới luôn đáng hoan nghênh
- Tôi thật sự thích mô hình giấy phép trả tiền một lần kèm thời hạn cập nhật cố định
  Tuy nhiên tôi tò mò họ sẽ thực thi điều đó thế nào mà không bắt ứng dụng phải có kết nối Internet
Nhìn vào trang đội ngũ https://rev.ng/about và đóng góp mã nguồn https://github.com/revng/revng/graphs/contributors, việc CEO(aleclearmind) có số commit nhiều hơn CTO(pfez) rất nhiều trông hơi khác thường
Các CEO khác thường nói rằng họ gần như không có thời gian code, còn CTO thì thường cũng thiên về quản lý nhiều hơn và ít trực tiếp code hơn
Dù vậy, nếu cách này vận hành tốt thì với đội ngũ hẳn là khá thú vị. Sửa: tôi chưa kiểm tra timeline
- CTO chủ yếu làm việc trên backend decompiler revng-c vừa được công bố: https://github.com/revng/revng-c/commits/develop/
  Cuối cùng hai repository sẽ được hợp nhất
  Và tôi vẫn phát triển hằng ngày, nhưng vì lý do nào đó GitHub không nhận diện đúng user của tôi
  Thực sự cũng rất vui
- CTO có nhiều commit gần đây hơn, còn commit của aleclearmind giảm về 0 sau năm 2020, nên có vẻ phía đó cũng đã khó thu xếp thời gian code hơn
- Tôi hoàn toàn không có ý phê phán, nên hơi tò mò vì sao lại bị downvote
  Trái lại, tôi thích hình ảnh này và thấy thú vị vì nó khác với những nơi khác tôi từng thấy
  Bị downvote vì điều này không thú vị hay không khác thường sao?
Trông như một công ty tuyệt vời được tiếp sức từ một trong những cuốn sách lý thuyết ngôn ngữ lập trình hay nhất hiện nay: https://link.springer.com/book/10.1007/978-3-662-03811-6
“Anh ấy cũng đã gặp Pietro, người sẽ trở thành đồng phạm của mình. Khá lãng mạn là anh gặp anh ấy nhờ cuốn sách sẽ trở thành nền tảng của công ty.”
https://rev.ng/about
- Toàn bộ câu chuyện liên quan đến cuốn sách đó là thế này. Tôi bắt đầu học compiler nhưng lý thuyết quá khó, các cuốn sách nổi tiếng cũng không hợp với tôi nên tôi khá nản
  Rồi tôi tìm thấy cuốn này, cô đọng nhưng có vẻ rõ ràng, và hỏi giáo sư hướng dẫn liệu có nên mua không thì ông ấy nói “trước hết hãy kiểm tra thư viện đại học xem”
  Thư viện có một bản, nhưng đã được mượn; là người thuộc nhóm duy nhất nghiên cứu compiler, tôi nghĩ “ai bên ngoài nhóm mình lại dám làm compiler nhỉ?”
  Tôi đến thư viện hỏi ai đã mượn, nhưng họ nói không thể cho biết vì lý do riêng tư, nên tôi chỉ hỏi chữ cái thứ ba của họ và chữ cái thứ hai của tên, và lấy được Z và I
  Tôi đã tìm ra ở đây: https://www.deib.polimi.it/ita/personale-lista-alfabetica
  Thời gian trôi qua, chúng tôi trở thành bạn và cùng khởi nghiệp
  Để ra mắt được sản phẩm thật sự đã cần rất nhiều công sức
Sẽ thật tốt nếu có thể tự động đặt tên biến và tên thành viên struct dựa trên cách mã xử lý biến và thành viên struct
Ví dụ, con trỏ next trong danh sách liên kết nên dễ được nhận diện là next
Có vẻ có thể tải toàn bộ GitHub xuống, tìm các biến có layout và tương tác trong mã giống nhất, rồi nếu độ tin cậy đủ cao thì dùng tên đó
- Trước đây tôi từng định thử làm thủ công kiểu này
  Ví dụ, nếu phát hiện biến quy nạp thì đổi tên thành i
  Nhưng giờ có vẻ khá rõ rằng cách đúng để làm việc này là dùng LLM
  Tuy nhiên ở giai đoạn hiện tại, chúng tôi giống những người đang xây nền móng vững chắc hơn; một khi nền tảng đã sẵn sàng, việc đổi tên hoặc thêm chú thích bằng các mô hình có sẵn sẽ tương đối dễ
  Điểm mấu chốt là chúng tôi xử lý phần dịch ngược khó, cần độ chính xác 100%, còn với những phần có thể chấp nhận xấp xỉ như tên và chú thích thì có thể đưa LLM vào
  Dù sao thì viết script đổi tên cũng khá dễ, cứ xem tài liệu: https://docs.rev.ng/user-manual/model-tutorial/
- Nghe sẽ rất tuyệt, giống như http://jsnice.org/
  Bài báo giải thích JSNice làm gì bên trong: https://files.sri.inf.ethz.ch/website/papers/jsnice15.pdf
- Nghe giống sidekick của Binary Ninja
- Kiểu như GitHub Copilot cho reverse engineering à?
Không chạy được với tệp ELF của tôi
Khi chạy ./revng artifact --analyze --progress decompile-to-single-file ../maytag.ko thì hiện Only ELF executables and ELF dynamic libraries are supported, còn tệp được nhận diện là ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped
Có phải không hỗ trợ binary FreeBSD không?
Sửa: tôi đã bỏ sót việc công cụ không hỗ trợ kernel module, và có vẻ lý do là vì đây không phải tệp thực thi đơn giản hơn là do FreeBSD
- Bạn có thể mở issue trên GitHub và đính kèm binary đó không?
  Có vẻ việc load cái này sẽ không quá khó
Mong mọi người quan tâm nhiều đến quy trình cộng tác
Tôi chưa dùng thứ như IDA Teams, nhưng nếu có thể có trải nghiệm reverse engineering mượt như Google Docs thì sẽ rất tuyệt
- Đó chính là mục tiêu của chúng tôi
  Trước đây chúng tôi dùng QtCreator cho UI, nhưng đó là một lựa chọn tệ hại
  Sau đó chuyển sang VSCode, và tình cờ là nó cũng chạy được trên trình duyệt
  Vì vậy, chúng tôi trộn thêm một chút Kubernetes để tạo ra một decompiler trên cloud có trải nghiệm người dùng giống hệt bản hoàn toàn độc lập
  Phần cộng tác vẫn cần QA thêm, nhưng về cơ bản đã hoạt động
  Cấu trúc rất đơn giản: một daemon với nhiều client
  Có lẽ chúng tôi lấy cảm hứng từ trải nghiệm “cộng tác” hồi trước trong CTF, với nhiều cửa sổ IDA và nhiều con trỏ trên X session của server. Cách đó cực kỳ đáng nguyền rủa, nhưng có hiệu quả
Có kế hoạch hỗ trợ suy luận kiểu không?
Hiện tại có vẻ mọi biến đều hiện là generic64_t; sẽ tốt nếu có thể tự động phát hiện kiểu như Ghidra. Dĩ nhiên Ghidra đôi khi cũng sai
- Có
  Mục trong roadmap: https://rev.ng/roadmap#feature-798
  Bản thiết kế: https://pad.rev.ng/s/eDHi2PUoP#
Trông khá thú vị
Tôi muốn thử phiên bản hoàn toàn độc lập
Có thông tin gì về mức giá ước tính không? Hy vọng là người dùng hobby cũng có thể chi trả
Việc có thêm các công cụ hack binary luôn là điều đáng mừng
Vì có thể tôi cũng muốn tự dùng thử, nên xin để lại một vài góp ý khá chi tiết về định dạng đóng gói đã chọn
source ./environment là một dấu hiệu không tốt. Tôi tải tar về xem thì đúng là nó thiết lập nhiều biến môi trường, gồm cả PATH; may là không có LD_LIBRARY_PATH
Phần lớn có tiền tố HARD_, có lẽ là đủ riêng biệt, nhưng REVNG có vẻ rõ ràng hơn; xung đột với các biến môi trường hiện có là điều không hay
Nó cũng đặt AWS_EC2_METADATA_DISABLED="true"; tôi không dùng AWS nên không bị hỏng gì, nhưng nói chung điều này khá đáng nghi
Những thứ như RPATH_PLACEHOLDER, HARD_FLAGS_CXX_CLANG, PATH dài, các chuỗi mingw32/gentoo/mips trông có vẻ dễ tổn thương
Nếu hướng dẫn chạy có câu “bây giờ hãy đổi biến môi trường” thì thường tôi sẽ bỏ cuộc; điều đó có tương quan rất mạnh với các chương trình không hoạt động đúng trên hệ thống không phải Ubuntu
Khi gắn luồng điều khiển của ứng dụng với môi trường thực thi, số chế độ lỗi sẽ nhiều hơn so với nhìn ban đầu, và nó rất giống biến toàn cục
Clang có thể nhúng sẵn các giá trị mặc định lúc build như -DCLANG_DEFAULT_CXX_STDLIB=libc++, và DEFAULT_SYSROOT cũng hữu ích
Ngay cả khi dùng rpath, nếu người dùng chạy trong trạng thái đã đặt LD_LIBRARY_PATH thì DT_RUNPATH của binary có thể bị ghi đè
Ngày nay -Wl,rpath thực ra không có nghĩa là rpath mà là runpath kém hữu ích hơn; có lẽ lời gọi mong muốn là -Wl,rpath -Wl,--disable-new-dtags để loader bỏ qua LD_LIBRARY_PATH khi tìm thư viện
Bằng cách kết hợp cờ build của Clang, liên kết tĩnh, nhúng binary vào trong binary, v.v., có nhiều khả năng loại bỏ hoàn toàn việc thao tác biến môi trường
Việc binary clang-16 được liên kết động và phải tìm những thứ như libLLVMAArch64CodeGen.so.16 ở runtime cũng làm tăng các chế độ lỗi
Nếu LLVM_BUILD_STATIC=ON, có thể giảm vấn đề nhặt nhầm thư viện trong môi trường đã kích hoạt toolchain bằng module của HPC
Các công cụ đang liên kết tới libc++.so, libc++abi.so, v.v.; nên cân nhắc libc++ tĩnh, và tối thiểu nên liên kết tĩnh libc++abi và libunwind vào trong libc++
Tôi đã hoàn toàn cạn kiên nhẫn với việc phân phối chương trình liên kết động trên Linux
Nếu source ourhack trong README hoặc các biến môi trường do hệ thống module để lại làm thay đổi thư viện runtime của ứng dụng của tôi, trải nghiệm người dùng và chi phí xử lý báo cáo lỗi sau đó sẽ rất khủng khiếp
So với vậy, liên kết tĩnh thật sự rất tuyệt
- Phần lớn lo ngại về việc đụng vào môi trường thực ra chỉ đúng nếu giả định rằng người dùng sẽ source environment
  Thực tế, lý do chúng tôi đề xuất điều đó chỉ là để dùng GCC mà chúng tôi phân phối cho các binary demo; cách dùng dự định là script ./revng
  Trong trường hợp này, thay đổi môi trường chỉ ảnh hưởng tới lời gọi revng
  Tài liệu ở đây: https://docs.rev.ng/user-manual/working-environment/
  Có lẽ nên thêm cảnh báo về source ./environment
  Chúng tôi đã dành rất nhiều thời gian để tránh dùng LD_LIBRARY_PATH, và đã tạo ra một bộ binary hoàn toàn tự chứa, trong đó mỗi ELF tham chiếu dependency bằng đường dẫn tương đối. LD_LIBRARY_PATH là điều xấu
  Các biến HARD_ chỉ được dùng trong compiler wrapper, và tôi nghĩ khả năng xung đột thực tế là rất thấp
  Thảo luận gốc về AWS_EC2_METADATA_DISABLED="true" nằm ở https://github.com/revng/revng/pull/309#discussion_r12805759...
  Cũng có thể patch AWS SDK để tránh việc này, nhưng dù sao nó chỉ ảnh hưởng khi rev.ng chạy trên cloud
  RPATH_PLACEHOLDER và HARD_FLAGS_CXX_CLANG được dùng khi link các binary do revng dịch; nếu bạn không quan tâm tới dịch binary end-to-end thì không quan trọng
  Chúng tôi chủ ý muốn DT_RUNPATH. DT_RPATH dự kiến bị loại bỏ, và có thể có các use case cần thay thế thư viện của chúng tôi bằng LD_LIBRARY_PATH
  Tôi nghĩ nhận xét về “thao tác môi trường” chỉ hợp lý trong trường hợp không phải các biến môi trường riêng tư
  RPATH_PLACEHOLDER, HARD_*, REVNG_* là biến riêng tư và tất cả đều nhằm mục đích dịch binary
  Có thể đẩy chúng vào bên trong compiler wrapper với phạm vi nhỏ hơn, nhưng vì chúng tôi phân phối kèm Python nên không thể loại bỏ hoàn toàn môi trường
  Chỉ nhúng một số cờ vào Clang là không đủ. Các cờ này cũng ảnh hưởng tới linker, và có những chức năng của wrapper không thể đơn giản nhúng sẵn
  Tuy vậy, có thể chuyển chúng sang một vị trí riêng tư hơn
  Có vẻ bạn cảnh giác với liên kết động, nhưng chúng tôi đã đầu tư công sức vào việc này, và giờ nó hoạt động khá tốt, luôn tìm đúng vị trí
  Chúng tôi không hardcode đường dẫn tuyệt đối, cũng không có bước cài đặt nào “patch” binary. Thư mục sau khi giải nén có thể được di chuyển tới bất cứ đâu
  Giải pháp chúng tôi dùng không dùng LD_LIBRARY_PATH; mọi binary tham chiếu lẫn nhau một cách vững chắc thông qua $ORIGIN
  Nếu chạy ./root/bin/python ./root/bin/revng artifact --help thì sẽ thấy nó hoạt động
  Nhắc lại, source environment gần như chỉ dành cho demo; trong sử dụng thực tế chỉ cần chạy ./revng là môi trường giữ nguyên
  Chúng tôi cũng phân phối kèm Python, nhưng không nhất thiết phải dùng nó. Bạn có thể dùng ./revng hoặc tương tác qua mạng ở chế độ daemon
  Cách tiếp cận là dùng công cụ scripting bạn muốn để parse và chỉnh sửa file dự án YAML, rồi gọi ./revng artifact hoặc tương tác với daemon: https://docs.rev.ng/user-manual/model-tutorial/
  Kết quả là chúng tôi dùng phiên bản Python mới nhất, còn người dùng có thể dùng ngôn ngữ họ muốn

Sau này sẽ cung cấp một wrapper phụ trợ tương thích với nhiều phiên bản Python khác nhau trên PyPI
Tóm lại, đừng dùng source ./environment mà hãy dùng ./revng
Thật vui vì có người quan tâm đến những phần như thế này
Ở vòng lặp lớn tiếp theo, cũng có thể đưa vào nix + mount namespace để dùng được /nix/store mà không cần quyền root, qua đó đơn giản hóa nhiều thứ
Có lẽ những thảo luận kiểu này nên trao đổi trên máy chủ Discord thì hơn là ở đây

Chúc mừng
Có hối tiếc gì về việc giao phần lifting cho QEMU TCG không, hay nó đã hoạt động tốt?
- Hoạt động rất tốt. Có hai điều hối tiếc
  Thứ nhất, chúng tôi đã không rebase fork QEMU trong vài năm, nên tình hình trở nên không tốt
  Dù vậy, ngay hôm nay một thành viên trong nhóm đã lifting thành công với QEMU mới nhất, và cũng có thể lifting được mã Qualcomm Hexagon mà chúng tôi đã hỗ trợ bổ sung hỗ trợ vào QEMU
  Cuối cùng chúng tôi sẽ trở thành decompiler Hexagon đúng nghĩa đầu tiên
  Thứ hai, vì quá tập trung vào QEMU nên frontend bị gắn kết chặt với QEMU
  Giờ để hỗ trợ thêm các frontend không dựa trên QEMU sẽ cần một chút công sức, nhưng không phải là không thể
  Ý tưởng là khi người dùng thêm hỗ trợ cho kiến trúc mới, họ chỉ cần định nghĩa bằng C cấu trúc trạng thái CPU và một vài hàm hoạt động trên đó
  Không cần học biểu diễn nội bộ
  Tóm lại, QEMU là một lựa chọn tuyệt vời; nó hoạt động tốt đến mức chúng tôi không đụng tới phần codebase đó trong thời gian dài, dẫn đến nợ kỹ thuật, nhưng hiện chúng tôi đang xử lý