ดีคอมไพเลอร์ rev.ng เปลี่ยนเป็นโอเพนซอร์ส

(rev.ng)

3 คะแนน โดย GN⁺ 2024-03-31 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

rev.ng เปิดเผย revng-c ซึ่งเป็นแบ็กเอนด์ของดีคอมไพเลอร์ ทำให้เอนจินดีคอมไพล์กลายเป็นโอเพนซอร์ส พร้อมเปิดตัว UI แบบ closed beta, เว็บไซต์ใหม่, rev.ng Hub และเอกสาร
บนเครื่อง local สามารถตั้งค่า CLI ด้วยสคริปต์ติดตั้ง แล้วใช้ revng artifact และ revng ptml เพื่อตรวจสอบผลลัพธ์การดีคอมไพล์ในรูปแบบ โค้ด C ที่ถูกต้อง ได้
UI แบบ interactive เป็น VSCode-based ตั้งเป้าให้ใช้งานได้ทั้งในเบราว์เซอร์และแอปแบบ standalone โดยให้บริการใน closed beta ที่เชิญผู้สมัครรับจดหมายข่าวตามลำดับ FIFO
การกู้คืนโครงสร้างข้อมูลอัตโนมัติ, collaborative reversing, การรองรับสถาปัตยกรรมหลากหลาย และความสามารถในการขยาย เป็นเป้าหมายหลัก แต่ QA ปัจจุบันโฟกัสที่ ไบนารี Linux x86-64 มากที่สุด
เฟรมเวิร์กและ CLI เป็นโอเพนซอร์ส ส่วน cloud UI ให้ใช้ฟรีกับโปรเจกต์สาธารณะ และแยกเป็นโมเดลแบบเสียเงินสำหรับโปรเจกต์ส่วนตัวและ UI แบบ standalone ที่ทำงานออฟไลน์

การเปลี่ยนเป็นโอเพนซอร์สและ closed beta

rev.ng เปิดเผย revng-c ซึ่งเป็นแบ็กเอนด์ของดีคอมไพเลอร์เป็นโอเพนซอร์ส
- การเปิดเผยครั้งนี้ทำให้ เอนจินดีคอมไพล์ ทั้งหมดกลายเป็นโอเพนซอร์ส
- มี เอกสาร ระยะแรกให้มาพร้อมกันด้วย
UI จะเริ่มเชิญเข้าร่วม closed beta สำหรับผู้สมัครรับจดหมายข่าว
- การเชิญจะดำเนินตามลำดับ FIFO
- จำเป็นต้อง ลงทะเบียนรับจดหมายข่าว เพื่อเข้าร่วมเบต้า
เว็บไซต์ใหม่และ rev.ng Hub ก็เปิดตัวพร้อมกัน
- rev.ng Hub เป็นจุดเข้าสู่เวอร์ชันคลาวด์
- ผู้ใช้เบต้าสามารถสร้างโปรเจกต์ รัน UI ในเบราว์เซอร์ และทำงานร่วมกับผู้ใช้อื่นได้
- แม้ไม่ใช่กลุ่ม closed beta ก็สามารถดู โปรเจกต์สาธารณะ ได้
ยังมี เดโมแบบส่วนตัว สำหรับผู้ใช้ที่ต้องการดูความสามารถของ rev.ng โดยตรง

ทดลองใช้ rev.ng ผ่าน CLI

revng สามารถติดตั้งในไดเรกทอรีเดียวโดยไม่ต้องใช้สิทธิ์ root และลบออกได้ด้วยการลบไดเรกทอรีนั้น

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

ตัวอย่าง example.c เป็นโปรแกรมง่าย ๆ ที่คืนค่า argc * 3

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

หลังคอมไพล์ด้วย gcc แล้วรัน revng artifact จะได้ผลลัพธ์การดีคอมไพล์ในรูปแบบ ไฟล์เดียว

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

เอาต์พุตตัวอย่างเป็นโค้ดลักษณะ C ที่มี _ABI(SystemV_x86_64) ต่อท้าย และนิพจน์คืนค่าจะแสดงเป็น _argument0 * 3 & 0xFFFFFFFF
เอกสารมี การตั้งค่าสภาพแวดล้อมการทำงาน, ทูโทเรียลการสร้างโมเดล, ทูโทเรียลการวิเคราะห์

ขอบเขตเบต้าและเป้าหมายการทดสอบ

หากต้องการใช้ UI ต้องลงทะเบียนที่ จดหมายข่าว และการเชิญจะทำเป็นกลุ่มเล็ก ๆ
รีลีสนี้โฟกัสที่การเดโม UI และผลลัพธ์การดีคอมไพล์กับไบนารีบางส่วน รวมถึงรับฟีดแบ็กและรายงานบั๊กจากการทำงานกับไบนารีจริง
ไบนารีที่ไม่ใช่แบบง่ายซึ่งใช้ทดสอบและขนาด .text มีดังนี้
- 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 รองรับ ABI และแพลตฟอร์มหลายแบบ แต่ QA ระยะแรกของขั้นตอนนี้โฟกัสที่ ไบนารี Linux x86-64
หากเกิดปัญหา สามารถขอความช่วยเหลือได้ที่ Discourse

ประสบการณ์ดีคอมไพล์ที่ rev.ng ตั้งเป้าไว้

จุดโฟกัสหลักของ rev.ng คือการกู้คืนโครงสร้างข้อมูลอัตโนมัติ, UX สมัยใหม่, collaborative reversing, การรองรับแพลตฟอร์มกว้าง และความสามารถในการขยาย
การกู้คืนโครงสร้างข้อมูลอัตโนมัติ
- Data Layout Analysis สามารถกู้คืนเลย์เอาต์ของ struct โดยอัตโนมัติผ่าน การวิเคราะห์ข้ามโพรซีเยอร์
- ตัวอย่างโหนด linked list ใช้โครงสร้างที่มีอาร์เรย์ int64_t data[5] และพอยน์เตอร์ไปยังโหนดถัดไป
- เอาต์พุตของ rev.ng สร้างโค้ดโครงสร้างและฟังก์ชันที่ตรวจจับขนาดอาร์เรย์ 5 และการเข้าถึงพอยน์เตอร์ขององค์ประกอบถัดไปได้โดยอัตโนมัติ
- เอาต์พุตของดีคอมไพเลอร์เป็นโค้ด C ที่ถูกต้องตามไวยากรณ์
- ฟีเจอร์นี้ใช้งานได้ในปัจจุบัน
UI แบบ interactive ที่อิง VSCode
- UI เป็น VSCode-based จึงเข้าถึงได้ในรูปแบบที่ผู้ใช้ VSCode คุ้นเคย
- สามารถรันได้ทั้งในแท็บเบราว์เซอร์และแอปพลิเคชันแบบ standalone
- คีย์ลัดหลักมีดังนี้
  - Ctrl + Click: ไปยังฟังก์ชันหรือ type definition ใต้เคอร์เซอร์
  - N: เปลี่ยนชื่อ
  - Y: แก้ไข type
  - X: แสดง reference
- rev.ng เป็น interactive decompiler ที่เมื่อมีการเปลี่ยนแปลง จะคำนวณใหม่เฉพาะส่วนที่ได้รับผลกระทบ
- ขณะนี้ UI ให้บริการแก่ผู้เข้าร่วม closed beta
Collaborative reversing
- rev.ng UI ใช้สถาปัตยกรรม client-server
- ผู้ใช้หลายคนสามารถเชื่อมต่อกับ daemon instance เดียวกันและทำงานพร้อมกันในโปรเจกต์เดียวกันได้
- ในเวอร์ชันคลาวด์ สามารถใช้ rev.ng Hub ซึ่งเป็นแอปพลิเคชันคล้าย GitHub สำหรับจัดการโปรเจกต์ได้
- ฟีเจอร์การทำงานร่วมกันใช้งานได้แล้ว แต่ยังต้องปรับปรุงประสบการณ์ผู้ใช้ และมีการติดตามใน รายการโรดแมป #797

สถาปัตยกรรมและวิธีรองรับแพลตฟอร์ม

rev.ng ใช้ส่วนต้นของ pipeline ของ QEMU เพื่อ lift โค้ดที่รันได้เป็น tiny code แล้วแปลงเป็น LLVM IR ก่อนดำเนินการดีคอมไพล์
ด้วยโครงสร้างนี้ จึงสามารถรองรับ สถาปัตยกรรมที่ QEMU รองรับ ได้ค่อนข้างง่าย
การรองรับแพลตฟอร์ม โดยเฉพาะ ABI มีความสำคัญพอ ๆ กับการรองรับสถาปัตยกรรม
- rev.ng ใช้ ABI description format เพื่ออธิบายคุณสมบัติของ ABI แบบ declarative
- รูปแบบนี้ออกแบบให้ทั่วไปพอที่จะทำให้การรองรับ ABI ใหม่ทำได้ง่าย
สถานะการรองรับปัจจุบันมีดังนี้
- สถาปัตยกรรม: รองรับ x86, x86-64, ARM, AArch64, MIPS, s390x ในระดับความสมบูรณ์ที่ต่างกัน
- รูปแบบไบนารี: รองรับ ELF, PE/COFF, Mach-O
- การนำเข้า: รองรับ .idb, ข้อมูลดีบัก DWARF, ข้อมูลดีบัก PDB
QA ส่วนใหญ่ดำเนินการกับไบนารี Linux x86-64 และส่วนที่เหลือยังต้องการ QA เพิ่มเติม
QA สำหรับแพลตฟอร์มเพิ่มเติมติดตามได้ใน รายการโรดแมป #58

ความสามารถในการขยายและ scripting

rev.ng ตั้งเป้าเป็นเฟรมเวิร์กสำหรับเครื่องมือ reverse engineering และทั้งโปรเจกต์เป็นโอเพนซอร์ส ยกเว้น interactive UI
ไฟล์โปรเจกต์อย่าง model เป็นเอกสาร YAML ดังนั้นหาก parse JSON หรือ YAML ได้ ก็สามารถ scripting rev.ng ได้
โมเดลประกอบด้วยสถาปัตยกรรมของไบนารีเป้าหมายสำหรับดีคอมไพล์, ABI พื้นฐาน, segment, รายการฟังก์ชัน, รายการ type ฯลฯ
สามารถแก้ไขโมเดลด้วย wrapper สำหรับ Python และ TypeScript
- ปัจจุบันมี wrapper สำหรับจัดการโมเดลแล้ว แต่ยังไม่มีวิธีที่ทำให้การรันการวิเคราะห์และการนำเข้า artifact ทำได้ง่าย
- Python client แบบสมบูรณ์ติดตามได้ใน รายการโรดแมป #17
มีการใช้ LLVM IR เป็นจำนวนมากใน internal representation จึงสามารถใช้เครื่องมือใน ecosystem ของ LLVM ได้
- symbolic execution ด้วย KLEE
- coverage-based fuzzing ด้วย SanitizerCoverage และ libFuzzer
- การทดลองใช้ clang static analyzer กับเอาต์พุตดีคอมไพล์ C ที่ถูกต้อง เพื่อค้นหาช่องโหว่ทั่วไป

การแยกระหว่าง CLI แบบโอเพนซอร์สกับ UI แบบเสียเงิน

เฟรมเวิร์ก rev.ng เป็นโอเพนซอร์สอย่างสมบูรณ์ และสามารถดีคอมไพล์เป้าหมายที่ต้องการได้จาก CLI
รูปแบบการให้บริการ UI แบ่งเป็นสามแบบ
- cloud UI สำหรับโปรเจกต์สาธารณะใช้งานได้ฟรี
- cloud UI สำหรับโปรเจกต์ส่วนตัวต้องสมัครสมาชิก
- UI แบบ standalone เต็มรูปแบบและออฟไลน์เต็มรูปแบบให้บริการแบบเสียเงิน
วิธีใช้งานบนคลาวด์มีดังนี้
- สร้างโปรเจกต์และเชิญผู้ร่วมงานที่ rev.ng Hub
- UI รันในเบราว์เซอร์
- แบ็กเอนด์รันบนคลาวด์ของ rev.ng
หากสามารถเปิดเผยไฟล์โปรเจกต์เป็นสาธารณะได้ ก็สามารถใช้ rev.ng เวอร์ชันคลาวด์ที่รวม UI ได้ฟรี
สามารถหารือเรื่องการติดตั้งบริการ private cloud แบบ on-premise ที่ใช้ Kubernetes ได้เช่นกัน

โรดแมป 1.0 และช่องทางติดต่อ

โรดแมปจนถึง 1.0 แบ่งเป็น 4 tier
- Tier 1: เวอร์ชัน alpha, เดโมสำหรับคนรู้จัก, เสร็จสิ้นแล้ว
- Tier 2: เวอร์ชัน beta, ให้ผู้สมัครรับจดหมายข่าวเข้าถึงเวอร์ชันคลาวด์, เริ่มแล้วในปัจจุบัน
- Tier 3: open beta, อยู่ในแผน
- Tier 4: รีลีส 1.0, อยู่ในแผน
สามารถดูความคืบหน้าโดยละเอียดได้ที่ หน้าโรดแมป
ข่าวสารโปรเจกต์และช่องทางซัพพอร์ตมีดังนี้
- X/Twitter: ข่าวการพัฒนาและประกาศสำคัญ
- Discord: สนทนาแบบเรียลไทม์กับทีมพัฒนา
- Discourse: ซัพพอร์ตผู้ใช้และรายงานบั๊ก
- GitHub: การพัฒนาโอเพนซอร์สและการลงทะเบียน issue
- Monthly newsletter: เข้าร่วม closed beta และข่าวสารรายเดือน
- E-mail: สอบถามแบบส่วนตัว

1 ความคิดเห็น

GN⁺ 2024-03-31

ความเห็นจาก Hacker News

โมเดลราคามีโครงสร้างว่าเฟรมเวิร์ก rev.ng เป็นโอเพนซอร์สทั้งหมด และใน CLI สามารถดีคอมไพล์อะไรก็ได้
UI จะใช้ฟรีบนคลาวด์สำหรับโปรเจกต์สาธารณะ, เป็นการสมัครสมาชิกคลาวด์สำหรับโปรเจกต์ส่วนตัว และแอปออฟไลน์แบบสแตนด์อโลนเต็มรูปแบบจะมีค่าใช้จ่าย
ถ้าเทียบกัน Hopper ราคา 100 ดอลลาร์พร้อมอัปเดต 1 ปี https://www.hopperapp.com/index.html, ส่วน Ghidra และ Radare2 เป็นซอฟต์แวร์เสรีและโอเพนซอร์สจึงฟรีทั้งหมด ขณะที่ IDA Pro แพงมาก
- Binary Ninja ก็เป็นตัวเลือกที่ดี
  จากที่เคยใช้ มันค่อนข้างคล้าย IDA แต่เป็นมิตรกับผู้ใช้กว่า และมีฟีเจอร์ที่ออกแบบมาดีหลายอย่างที่ช่วยเพิ่มประสิทธิภาพการทำงาน
  ยังไม่เคยใช้ Hopper แต่ประสบการณ์พัฒนากับ Ghidra และ Radare2 ไม่ค่อยดีนัก และโค้ด C ที่สร้างออกมาก็อ่านไม่ค่อยรู้เรื่อง อย่างไรก็ตาม ทั้งหมดนี้อิงจากที่เคยใช้เมื่อหลายปีก่อน
  Binja ราคา 300 ดอลลาร์ รุ่นเชิงพาณิชย์ 1500 ดอลลาร์ และมีส่วนลดนักศึกษาด้วย: https://binary.ninja/features
- การดีคอมไพล์มักเป็นส่วนที่สำคัญน้อยที่สุดและเชื่อถือได้น้อยที่สุดใน IDA/Ghidra ดังนั้นการเอาทั้งสองมาเทียบกันตรง ๆ จึงไม่ค่อยยุติธรรม
  ถึงอย่างนั้น ดีคอมไพเลอร์ C ที่ดีก็ยังขาดแคลนอยู่เสมอ จึงยินดีเสมอเมื่อมีความพยายามใหม่ ๆ
- ชอบโมเดลไลเซนส์แบบ จ่ายครั้งเดียวพร้อมระยะเวลาอัปเดตที่กำหนดไว้ มาก
  แต่ก็สงสัยว่าจะบังคับใช้แบบนั้นอย่างไรโดยไม่ทำให้แอปต้องเชื่อมต่ออินเทอร์เน็ตเป็นข้อบังคับ
เมื่อดูหน้าทีม https://rev.ng/about และการมีส่วนร่วมในโค้ด https://github.com/revng/revng/graphs/contributors แล้ว ดูแปลกนิดหน่อยที่ CEO(aleclearmind) มีจำนวนคอมมิตมากกว่า CTO(pfez) มาก
CEO คนอื่น ๆ มักพูดบ่อย ๆ ว่าแทบไม่มีเวลาเขียนโค้ด และ CTO โดยทั่วไปก็มักทำงานบริหารมากกว่า เขียนโค้ดจริงน้อยกว่า
แต่ถ้าวิธีนี้เวิร์กดี สำหรับทีมก็น่าจะค่อนข้างสนุกทีเดียว แก้ไข: ไม่ได้ตรวจไทม์ไลน์
- CTO ทำงานหลัก ๆ กับแบ็กเอนด์ดีคอมไพเลอร์ revng-c ที่เพิ่งเปิดตัว: https://github.com/revng/revng-c/commits/develop/
  สุดท้ายจะรวมสองรีโพซิทอรีเข้าด้วยกัน
  และผมก็พัฒนาอยู่ทุกวัน แต่ไม่รู้ด้วยเหตุผลอะไร GitHub จับคู่ผู้ใช้ของผมได้ไม่ถูกต้อง
  จริง ๆ แล้วก็สนุกจริง
- CTO มีคอมมิตช่วงหลัง ๆ มากกว่า และคอมมิตของ aleclearmind ลดลงเป็น 0 หลังปี 2020 จึงดูเหมือนว่าฝั่งนั้นก็คงหาเวลาเขียนโค้ดยากขึ้นแล้ว
- ไม่ได้ตั้งใจจะวิจารณ์เลยสักนิด เลยสงสัยนิดหน่อยว่าทำไมถึงโดน downvote
  จริง ๆ แล้วกลับชอบภาพแบบนี้ และรู้สึกว่าน่าสนใจเพราะต่างจากที่เคยเห็นที่อื่น
  โดน downvote เพราะมันไม่น่าสนใจหรือไม่ได้แปลกเหรอ?
ดูเป็นบริษัทเจ๋ง ๆ ที่ได้รับแรงบันดาลใจจากหนึ่งใน หนังสือทฤษฎีภาษาโปรแกรมมิง ที่ดีที่สุดที่ยังมีอยู่: https://link.springer.com/book/10.1007/978-3-662-03811-6
“เขายังได้พบกับ Pietro ผู้ที่จะมาเป็นผู้ร่วมขบวนการด้วย และในแบบที่ค่อนข้างโรแมนติก เขาพบเขาเพราะหนังสือเล่มที่จะกลายเป็นรากฐานของบริษัท”
https://rev.ng/about
- เรื่องราวทั้งหมดเกี่ยวกับหนังสือเล่มนั้นเป็นแบบนี้ ผมเริ่มศึกษาเรื่องคอมไพเลอร์ แต่ทฤษฎียากเกินไป และหนังสือดัง ๆ ก็ไม่เหมาะกับผม เลยค่อนข้างท้อใจ
  แล้วผมก็พบหนังสือเล่มนี้ที่ดูแน่นแต่ชัดเจน จึงถามอาจารย์ที่ปรึกษาว่าซื้อได้ไหม เขาตอบว่า “ลองเช็กห้องสมุดมหาวิทยาลัยก่อน”
  ห้องสมุดมีสำเนาอยู่ แต่ถูกยืมไปแล้ว และในฐานะคนที่อยู่ในกลุ่มเดียวที่ทำวิจัยคอมไพเลอร์ ผมก็คิดว่า “ใครกันที่บังอาจทำคอมไพเลอร์นอกกลุ่มเรา?”
  ผมไปที่ห้องสมุดแล้วถามว่าใครยืมไป แต่เขาบอกว่าเป็นข้อมูลส่วนบุคคล จึงบอกให้ไม่ได้ ผมเลยถามได้แค่ตัวอักษรตัวที่สามของนามสกุลกับตัวอักษรตัวที่สองของชื่อ และได้ Z กับ I มา
  แล้วก็หาเจอจากที่นี่: https://www.deib.polimi.it/ita/personale-lista-alfabetica
  เวลาผ่านไป เรากลายเป็นเพื่อนกันและเริ่มบริษัทด้วยกัน
  กว่าจะเปิดตัวได้ต้องทำงานกันหนักมากจริง ๆ
คงดีถ้าตั้ง ชื่อตัวแปรและชื่อสมาชิกของ struct ให้อัตโนมัติได้ โดยอิงจากวิธีที่โค้ดจัดการตัวแปรและสมาชิกของ struct
เช่น พอยน์เตอร์ถัดไปใน linked list ควรระบุได้ง่ายว่าเป็น next
ดูเหมือนเป็นไปได้ที่จะดาวน์โหลด GitHub ทั้งหมด แล้วหาในโค้ดว่าตัวแปรใดมี layout และปฏิสัมพันธ์คล้ายกันที่สุด จากนั้นถ้าความเชื่อมั่นสูงพอก็ใช้ชื่อนั้น
- เมื่อก่อนเคยพยายามทำอะไรแบบนี้ด้วยมือ
  เช่น ถ้าตรวจพบตัวแปรเหนี่ยวนำ ก็เปลี่ยนชื่อเป็น i
  แต่ตอนนี้วิธีที่ถูกต้องสำหรับงานแบบนี้ดูค่อนข้างชัดเจนว่าเป็นการใช้ LLM
  อย่างไรก็ตาม ในขั้นนี้เราเป็นเหมือนคนที่สร้างรากฐานที่แข็งแรงมากกว่า และเมื่อมีรากฐานพร้อมแล้ว การใช้โมเดลสำเร็จรูปมาเปลี่ยนชื่อหรือเพิ่มคอมเมนต์ก็ค่อนข้างง่าย
  ประเด็นหลักคือ งานดีคอมไพล์ที่ยากและต้องการความถูกต้อง 100% เราจะทำเอง ส่วนที่ยอมให้เป็นค่าประมาณได้อย่างชื่อและคอมเมนต์จึงสามารถนำ LLM มาใช้ได้
  ยังไงก็ตาม การเขียนสคริปต์เปลี่ยนชื่อนั้นค่อนข้างง่าย ลองดูเอกสารได้: https://docs.rev.ng/user-manual/model-tutorial/
- น่าจะเจ๋งมาก และให้ความรู้สึกเหมือน http://jsnice.org/
  งานวิจัยที่อธิบายว่า JSNice ทำอะไรภายใน: https://files.sri.inf.ethz.ch/website/papers/jsnice15.pdf
- ฟังดูคล้าย sidekick ของ Binary Ninja
- เหมือน GitHub Copilot สำหรับงานรีเวิร์สหรือเปล่า?
ใช้ไม่ได้กับ ไฟล์ ELF ของผม
เมื่อรัน ./revng artifact --analyze --progress decompile-to-single-file ../maytag.ko จะได้ข้อความ Only ELF executables and ELF dynamic libraries are supported และไฟล์แสดงเป็น ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped
แปลว่าไม่รองรับไบนารี FreeBSD หรือเปล่า?
แก้ไข: ผมพลาดไปว่าไม่รองรับเคอร์เนลโมดูล และน่าจะเป็นเพราะมันไม่ใช่ไฟล์ executable ธรรมดา มากกว่าจะเป็นเพราะ FreeBSD
- ช่วยเปิด issue บน GitHub แล้วแนบไบนารีให้ได้ไหม?
  การโหลดสิ่งนี้น่าจะไม่ได้ยากนัก
อยากให้มีคนสนใจ เวิร์กโฟลว์การทำงานร่วมกัน กันมาก ๆ
ผมยังไม่เคยใช้ของอย่าง IDA Teams แต่ถ้ามีประสบการณ์รีเวิร์สเอนจิเนียริงที่ลื่นไหลเหมือน Google Docs ได้ก็น่าจะยอดเยี่ยมมาก
- นั่นคือเป้าหมายของเรา
  ก่อนหน้านี้เราใช้ QtCreator เป็น UI ซึ่งเป็นตัวเลือกที่แย่มาก
  หลังจากนั้นก็เปลี่ยนมาใช้ VSCode และมันบังเอิญรันบนเบราว์เซอร์ได้ด้วย
  ดังนั้นเราจึงผสม Kubernetes เข้าไปเล็กน้อย แล้วสร้าง คลาวด์ดีคอมไพเลอร์ ที่ให้ประสบการณ์ผู้ใช้เหมือนกับเวอร์ชันแบบสแตนด์อโลนทุกประการ
  ส่วนการทำงานร่วมกันยังต้อง QA เพิ่มเติม แต่โดยพื้นฐานแล้วใช้งานได้
  โครงสร้างเรียบง่ายมาก คือหลายไคลเอนต์ต่อหนึ่งเดมอน
  คิดว่าได้แรงบันดาลใจมาจากประสบการณ์สมัย CTF ที่ “ทำงานร่วมกัน” ด้วยหน้าต่าง IDA หลายหน้าต่างและเคอร์เซอร์หลายอันบน X session ของเซิร์ฟเวอร์ เป็นวิธีที่ต้องสาปมาก แต่ก็ได้ผล
มีแผนจะรองรับ type inference ไหม?
ตอนนี้ดูเหมือนว่าตัวแปรทั้งหมดจะแสดงเป็น generic64_t ถ้าตรวจจับชนิดโดยอัตโนมัติได้แบบ Ghidra ก็คงดี แน่นอนว่า Ghidra เองก็พลาดเป็นบางครั้ง
- มี
  รายการในโรดแมป: https://rev.ng/roadmap#feature-798
  แผ่นออกแบบ: https://pad.rev.ng/s/eDHi2PUoP#
ดูน่าสนใจ
อยากลองใช้ เวอร์ชันแบบสแตนด์อโลนเต็มรูปแบบ
มีข่าวเรื่องราคาโดยประมาณไหม? ถ้าอยู่ในระดับที่ผู้ใช้สายงานอดิเรกพอรับได้ก็คงดี
เครื่องมือสำหรับแฮ็กไบนารีที่มีมากขึ้นเป็นเรื่องน่ายินดีเสมอ
เพราะอาจอยากลองใช้เอง เลยขอฝากข้อเสนอแนะที่ละเอียดเกินไปเกี่ยวกับ รูปแบบแพ็กเกจ ที่เลือกไว้
source ./environment เป็นสัญญาณที่ไม่ค่อยดี พอลองโหลด tar มาดู พบว่ามันตั้งค่าตัวแปรสภาพแวดล้อมหลายตัวรวมถึง PATH จริง ๆ และโชคดีที่ไม่ใช่ LD_LIBRARY_PATH
ส่วนใหญ่ใช้คำนำหน้า HARD_ ซึ่งน่าจะไม่ซ้ำกับใคร แต่ REVNG ดูชัดเจนกว่า และการชนกับตัวแปรสภาพแวดล้อมเดิมเป็นเรื่องไม่ดี
ยังตั้งค่า AWS_EC2_METADATA_DISABLED="true" ด้วย ผมไม่ได้ใช้ AWS เลยไม่พัง แต่โดยทั่วไปก็น่าสงสัย
RPATH_PLACEHOLDER, HARD_FLAGS_CXX_CLANG, PATH ที่ยาว, สตริงอย่าง mingw32/gentoo/mips ฯลฯ ดูเปราะบาง
ถ้าคำแนะนำการรันมีข้อความว่า “ตอนนี้ให้เปลี่ยนตัวแปรสภาพแวดล้อม” ปกติผมจะถอดใจ ซึ่งมักสัมพันธ์อย่างมากกับโปรแกรมที่ทำงานไม่ถูกต้องบนระบบที่ไม่ใช่ Ubuntu
การผูก control flow ของแอปพลิเคชันเข้ากับสภาพแวดล้อมการรันมี failure mode มากกว่าที่เห็นในตอนแรก และคล้ายกับตัวแปร global มาก
Clang สามารถ bake ค่าเริ่มต้นอย่าง -DCLANG_DEFAULT_CXX_STDLIB=libc++ เข้าไปตอน build ได้ และ DEFAULT_SYSROOT ก็มีประโยชน์
แม้จะใช้ rpath ถ้าผู้ใช้รันโดยตั้งค่า LD_LIBRARY_PATH ไว้ DT_RUNPATH ของไบนารีก็อาจถูก override ได้
ทุกวันนี้ -Wl,rpath จริง ๆ แล้วไม่ได้หมายถึง rpath แต่หมายถึง runpath ที่มีประโยชน์น้อยกว่า และคำสั่งที่น่าจะต้องการคือ -Wl,rpath -Wl,--disable-new-dtags เพื่อให้ loader เพิกเฉยต่อ LD_LIBRARY_PATH ตอนค้นหาไลบรารี
การผสมผสาน build flags ของ Clang, static link, การฝังไบนารีไว้ในไบนารี ฯลฯ น่าจะทำให้ตัดการปรับแต่งตัวแปรสภาพแวดล้อมออกไปได้ทั้งหมด
การที่ไบนารี clang-16 ถูก dynamic link แล้วไปหาอะไรอย่าง libLLVMAArch64CodeGen.so.16 ตอน runtime ก็เพิ่ม failure mode
ถ้า LLVM_BUILD_STATIC=ON จะช่วยลดปัญหาในสภาพแวดล้อมที่เปิดใช้ HPC module toolchain แล้วไปหยิบไลบรารีผิดตัวมาใช้
เครื่องมือต่าง ๆ link กับ libc++.so, libc++abi.so ฯลฯ อยู่ น่าพิจารณาใช้ static libc++ และอย่างน้อยก็ควร link libc++abi กับ libunwind แบบ static เข้าไปใน libc++
ผมหมดความอดทนกับการแจกจ่ายโปรแกรม dynamic link บน Linux อย่างสิ้นเชิงแล้ว
ถ้า source ourhack ใน README หรือตัวแปรสภาพแวดล้อมที่ระบบ module ทิ้งไว้ เปลี่ยนไลบรารี runtime ของแอปผม ประสบการณ์ผู้ใช้และต้นทุน bug report ภายหลังจะแย่มาก
เมื่อเทียบกันแล้ว static link ดีจริง ๆ
- ความกังวลส่วนใหญ่เกี่ยวกับการแตะสภาพแวดล้อม จะถูกต้องจริง ๆ เฉพาะเมื่อสมมติว่ามีการ source environment เท่านั้น
  อันที่จริง เหตุผลที่เราแนะนำแบบนั้นก็แค่เพื่อให้ใช้ GCC ที่เราแจกจ่ายสำหรับไบนารีเดโม และวิธีใช้งานที่ตั้งใจไว้คือสคริปต์ ./revng
  ในกรณีนี้ การเปลี่ยนสภาพแวดล้อมมีผลเฉพาะกับการเรียก revng เท่านั้น
  เอกสารอยู่ที่นี่: https://docs.rev.ng/user-manual/working-environment/
  น่าจะเพิ่มคำเตือนเกี่ยวกับ source ./environment
  เราใช้เวลามากเพื่อหลีกเลี่ยงการใช้ LD_LIBRARY_PATH และสร้างชุดไบนารีที่ self-contained สมบูรณ์ ซึ่งแต่ละ ELF อ้างอิง dependency ด้วยเส้นทางสัมพัทธ์ LD_LIBRARY_PATH คือสิ่งชั่วร้าย
  ตัวแปร HARD_ ใช้เฉพาะใน compiler wrapper เท่านั้น และคิดว่าแทบไม่มีโอกาสชนกันจริง ๆ
  การอภิปรายเดิมเกี่ยวกับ AWS_EC2_METADATA_DISABLED="true" อยู่ที่ https://github.com/revng/revng/pull/309#discussion_r12805759...
  อาจหลีกเลี่ยงได้ด้วยการ patch AWS SDK แต่ไม่ว่าอย่างไรก็มีผลเฉพาะตอน rev.ng รันบนคลาวด์เท่านั้น
  RPATH_PLACEHOLDER และ HARD_FLAGS_CXX_CLANG ใช้เมื่อ revng link ไบนารีที่แปลแล้ว และถ้าไม่สนใจการแปลไบนารีแบบ end-to-end ก็ไม่สำคัญ
  เราตั้งใจต้องการ DT_RUNPATH เพราะ DT_RPATH กำลังจะเลิกใช้ และอาจมี use case ที่ต้องแทนที่ไลบรารีของเราด้วย LD_LIBRARY_PATH
  ผมคิดว่าข้อทักท้วงเรื่อง “การปรับแต่งสภาพแวดล้อม” จะสมเหตุสมผลเฉพาะเมื่อไม่ใช่ตัวแปรสภาพแวดล้อมแบบ private เท่านั้น
  RPATH_PLACEHOLDER, HARD_*, REVNG_* เป็นตัวแปร private และทั้งหมดมีไว้เพื่อวัตถุประสงค์ด้านการแปลไบนารี
  อาจย้ายเข้าไปใน compiler wrapper ที่มีขอบเขตเล็กลงได้ แต่เพราะเราแจกจ่าย Python มาด้วย จึงกำจัดสภาพแวดล้อมออกไปทั้งหมดไม่ได้
  แค่ bake flag บางส่วนเข้าไปใน Clang ยังไม่พอ flag เหล่านี้มีผลกับ linker ด้วย และมีความสามารถบางอย่างของ wrapper ที่ไม่สามารถฝังเข้าไปตรง ๆ ได้
  แต่สามารถย้ายไปไว้ในตำแหน่งที่เป็น private มากขึ้นได้
  ดูเหมือนคุณจะระวัง dynamic link แต่เราได้ทุ่มเทกับเรื่องนี้ และตอนนี้มันทำงานได้ค่อนข้างดี โดยหา location ที่ถูกต้องเจอเสมอ
  เราไม่ hardcode absolute path และไม่มีขั้นตอนติดตั้งที่ “patch” ไบนารี ไดเรกทอรีที่แตกไฟล์แล้วสามารถย้ายไปที่ไหนก็ได้
  วิธีแก้ของเราคือไม่ใช้ LD_LIBRARY_PATH และให้ไบนารีทั้งหมดอ้างอิงกันอย่างแข็งแรงผ่าน $ORIGIN
  ลองรัน ./root/bin/python ./root/bin/revng artifact --help ดู จะทำงานได้
  ขอย้ำว่า source environment แทบมีไว้สำหรับเดโม และในการใช้งานจริงแค่รัน ./revng สภาพแวดล้อมก็ยังเหมือนเดิม
  เราแจกจ่าย Python มาด้วย แต่ไม่จำเป็นต้องใช้มันก็ได้ ใช้ ./revng หรือโต้ตอบผ่านเครือข่ายใน daemon mode ก็พอ
  แนวทางคือใช้เครื่องมือ scripting ที่ต้องการ parse และแก้ไขไฟล์โปรเจกต์ YAML แล้วเรียก ./revng artifact หรือโต้ตอบกับ daemon: https://docs.rev.ng/user-manual/model-tutorial/
  ผลคือเราใช้ Python เวอร์ชันล่าสุดได้ และผู้ใช้ก็ใช้ภาษาที่ต้องการได้

ต่อจากนี้จะเตรียม wrapper เสริมที่เข้ากันได้กับ Python หลายเวอร์ชันไว้บน PyPI
สรุปคือไม่ต้องใช้ source ./environment แต่ให้ใช้ ./revng ก็พอ
ดีใจที่มีคนใส่ใจเรื่องแบบนี้
ในรอบการปรับปรุงใหญ่ถัดไป อาจนำ nix + mount namespace มาใช้ เพื่อให้ใช้ /nix/store ได้โดยไม่ต้องมีสิทธิ์ root ซึ่งอาจทำให้หลายอย่างเรียบง่ายขึ้น
การคุยเรื่องนี้อาจเหมาะไปคุยกันในเซิร์ฟเวอร์ Discord มากกว่าที่นี่

ยินดีด้วย
มีอะไรที่เสียใจไหมกับการมอบงาน lifting ให้ QEMU TCG หรือว่ามันทำงานได้ดี?
- มันทำงานได้ดีมาก สิ่งที่เสียใจมีสองอย่าง
  อย่างแรก เราไม่ได้ rebase fork ของ QEMU มาหลายปี ทำให้สถานการณ์ไม่ค่อยดี
  ถึงอย่างนั้น วันนี้พอดีสมาชิกทีมก็ lifting กับ QEMU รุ่นล่าสุดได้สำเร็จ และยังสามารถ lifting โค้ด Qualcomm Hexagon ที่เราช่วยเพิ่มการรองรับเข้าไปใน QEMU ได้ด้วย
  สุดท้ายแล้วเราจะกลายเป็น Hexagon decompiler ตัวแรกที่ใช้งานได้จริง
  อย่างที่สอง เพราะเราโฟกัสกับ QEMU มากเกินไป frontend จึงผูกติดกับ QEMU อย่างแน่นหนา
  ตอนนี้หากจะรองรับ frontend เพิ่มเติมที่ไม่ได้อิง QEMU ก็ต้องใช้ความพยายามอยู่บ้าง แต่ไม่ใช่ว่าทำไม่ได้
  แนวคิดคือ เมื่อผู้ใช้ต้องการเพิ่มการรองรับสถาปัตยกรรมใหม่ ให้กำหนดเพียง struct สถานะ CPU ในภาษา C และฟังก์ชันไม่กี่ตัวที่ทำงานบน struct นั้น
  ไม่จำเป็นต้องเรียนรู้ internal representation
  สรุปคือ QEMU เป็นตัวเลือกที่ยอดเยี่ยม และเพราะมันทำงานได้ดีมาก เราจึงไม่ได้แตะส่วนนั้นของ codebase อยู่นานจนเกิดหนี้ทางเทคนิคขึ้น แต่ตอนนี้กำลังแก้ไขอยู่