Một công cụ decompiler Java mới có tên garlic-decompiler đã xuất hiện, được viết hoàn toàn bằng ngôn ngữ C và tuyên bố có những cải thiện hiệu suất đáng kể so với các công cụ truyền thống dựa trên Java. Dự án này nhằm mục đích chuyển đổi bytecode Java đã biên dịch trở lại thành mã nguồn có thể đọc được, hỗ trợ các tệp .class, kho lưu trữ JAR và tệp WAR.
Các loại tệp được hỗ trợ:
- Tệp .class (Java bytecode)
- Tệp .jar (Java archives)
- Tệp .war (Web application archives)
- Tệp .dex (đang trong kế hoạch, hiện tại chưa được hỗ trợ)
Tuyên bố về hiệu suất so với thực tế
Nhà phát triển tuyên bố garlic-decompiler chạy nhanh hơn khoảng 10 lần so với các phương án thay thế dựa trên Java trong khi sử dụng ít tài nguyên hệ thống hơn. Tệp nhị phân đã biên dịch chỉ nặng 300KB, khiến nó trở nên cực kỳ nhẹ. Tuy nhiên, việc thử nghiệm sớm bởi các thành viên cộng đồng đã tiết lộ một số vấn đề phát triển điển hình của các chương trình C khi xử lý các cấu trúc dữ liệu phức tạp.
Một người dùng đã báo cáo lỗi segmentation fault khi xử lý tệp JAR với chế độ đa luồng được bật, làm nổi bật những thách thức của việc quản lý bộ nhớ trong C khi xử lý phân tích bytecode Java. Nhà phát triển đã phản hồi nhanh chóng, yêu cầu tệp có vấn đề để khắc phục sự cố.
Tuyên bố về Hiệu suất:
- Nhanh hơn 10 lần so với các decompiler dựa trên Java
- Sử dụng tài nguyên thấp hơn so với các phương án thay thế Java
- Hỗ trợ xử lý đa luồng (mặc định: 4 luồng)
Các thách thức quản lý bộ nhớ nổi lên
Các cuộc thảo luận kỹ thuật trong cộng đồng đã tập trung vào cách tiếp cận quản lý bộ nhớ của dự án. Decompiler sử dụng một thư viện chuỗi tùy chỉnh và triển khai các pool bộ nhớ riêng biệt cho các hoạt động đa luồng, với một pool toàn cục cho chế độ đơn luồng.
Tuy nhiên, các nhà phát triển có kinh nghiệm đã xác định các vấn đề tiềm ẩn khi mã trộn lẫn các chuỗi tĩnh với các chuỗi được phân bổ heap một cách không nhất quán. Điều này tạo ra các tình huống mà các hàm gọi không thể xác định đúng cách liệu bộ nhớ được trả về có nên được giải phóng hay không, có thể dẫn đến rò rỉ bộ nhớ hoặc sự cố.
Cách tiếp cận phát triển và kế hoạch tương lai
Dự án đại diện cho một nỗ lực chủ yếu thủ công, với nhà phát triển tuyên bố nó được thực hiện 90% bằng tay, 10% AI - một tỷ lệ mà nhiều người trong cộng đồng coi là lý tưởng cho các dự án tập trung vào học tập. Động lực dường như vừa mang tính giáo dục vừa thực tế, nhằm hiểu các thành phần nội bộ của JVM trong khi tạo ra một công cụ nhanh hơn.
Tôi đang viết phần decompile dex và apk. Tốc độ hiện tại nhanh hơn khoảng 10 lần so với Java, và chiếm ít tài nguyên hơn Java.
Phát triển tương lai bao gồm kế hoạch hỗ trợ cho các tệp Android DEX, mặc dù tính năng này vẫn chưa được triển khai. Dự án cũng bao gồm một chế độ giống javap để phân tích bytecode nhanh hơn, với các thuộc tính LineNumber và StackMapTable bị vô hiệu hóa để cải thiện hiệu suất.
Yêu cầu Build:
- cmake >= 3.26
- Không có dependencies khác
- Kích thước binary đã compile: ~300KB
Kết luận
Trong khi garlic-decompiler cho thấy triển vọng với các tuyên bố về tốc độ và thiết kế nhẹ, nó phải đối mặt với những thách thức điển hình của các chương trình C xử lý các tác vụ phân tích phức tạp. Phản hồi tích cực của nhà phát triển đối với các báo cáo lỗi và bản chất giáo dục của dự án cho thấy nó có thể trưởng thành thành một phương án thay thế khả thi cho các decompiler Java hiện có, miễn là các vấn đề quản lý bộ nhớ được giải quyết. Hiện tại, người dùng nên mong đợi một số khuyết điểm điển hình của các dự án C giai đoạn đầu khi xử lý phân tích bytecode phức tạp.
Tham khảo: garlic-decompiler