Repository navigation
th ARCHITECTURE
Languages: English | العربية | Čeština | Deutsch | Español | فارسی | Français | हिन्दी | Bahasa Indonesia | Italiano | 日本語 | 한국어 | Nederlands | Polski | Português | Русский | Svenska | ไทย | Türkçe | Tiếng Việt | 中文
VD Google ถูกสร้างขึ้นอย่างไรและเพราะเหตุใด หน้านี้อธิบายการออกแบบและหลักการ ไม่ได้ระบุไฟล์ ตาราง หรือคิวรีที่แน่นอนซึ่งผู้อ่านแต่ละคนใช้ สิ่งเหล่านั้นอยู่ในซอร์สโค้ดเท่านั้นโดยเจตนา เพื่อให้แอปและเอกสารไม่มีวันเลื่อนไหลไปกลายเป็นคู่มือสอนวิธีสำหรับคนที่อยากปลอมค่าเดียวกัน
- อ่านความจริง แสดงสิ่งที่แอปของ Google เองบันทึกไว้อยู่แล้ว อธิบายมัน และไม่กุค่าขึ้นมา เองเด็ดขาด เมื่ออุปกรณ์ไม่มีคำตอบ ให้บอกว่า Unknown
- ไม่มีเครือข่าย แอปไม่ประกาศสิทธิ์ใด ๆ เลย WebUI บล็อกต้นทางระยะไกลทุกแห่ง ไม่มีอะไร ถูกส่งไปที่ใดเลย ไม่ว่าเมื่อใด
- หนึ่งพฤติกรรม สองหน้าตา แอปและโมดูล WebUI ถูกทำให้เหมือนกันอย่างสมบูรณ์: สัญญาณ เดียวกัน ถ้อยคำเดียวกัน รายงานที่ส่งออกเดียวกัน
- ซื่อตรงดีกว่าประจบ ค่าลบจริงจะถูกแสดงเป็นลบ แคชที่เก่าค้างจะถูกระบุว่าเป็นแคช ค่าที่ขาด หายไปคือ Unknown การตรวจจับจะไม่ถูกทำให้นุ่มนวลลงเพื่อให้ดูดีขึ้น
-
แอป เขียนด้วย Kotlin กับ Jetpack Compose (Material 3) ได้รับ root ผ่าน libsu
RootServiceไม่เคยเรียกsuโดยตรง และอ่านข้อมูลอยู่ภายในเซอร์วิสที่มีสิทธิ์พิเศษนั้น - โมดูล WebUI เป็น web root แบบ HTML/JS ขนาดเล็กที่ให้บริการโดยตัวจัดการ root ของคุณ (KernelSU, APatch หรือ Magisk) มันทำการอ่านแบบเดียวกันผ่านบริดจ์ root ของตัวจัดการ Content-Security-Policy ที่เข้มงวดห้ามต้นทางระยะไกลทุกแห่ง ดังนั้นหน้าเว็บจึงไม่สามารถ ส่งข้อมูลกลับบ้านได้แม้แต่ในหลักการ
ทั้งสองถูกสร้างขึ้นจากชุดสตริงที่ใช้ร่วมกันชุดเดียวใน 21 ภาษา ดังนั้นป้ายกำกับจึงไม่เคยถูก แปลซ้ำสองครั้ง
สถานะบางส่วนที่ VD Google อ่านอยู่ในฐานข้อมูล SQLite ที่เป็นของแอปต่าง ๆ ของ Google
Android มี SQLite ของตัวเองมาให้ แต่ SQLite ของเฟรมเวิร์กนั้นไม่น่าเชื่อถือในการเปิดสำเนา
ฐานข้อมูลของแอปอื่นที่คัดลอกแยกไว้ บนรอม ROM ของผู้ผลิตบางราย มันล้มเหลวกับฐานข้อมูล
ทุก ฐาน โดยคืนค่าว่างเปล่า เพื่อให้อ่านได้เหมือนกันบนทุกอุปกรณ์ VD Google จึงมาพร้อมกับ
ไบนารี sqlite3 ของตัวเอง (arm64 และ arm32) และรันคิวรีผ่านมันในฐานะ root แอปและ WebUI
ใช้ไบนารีตัวเดียวกันเป๊ะ ดังนั้นจึงอ่านด้วยเอนจินเดียวกันและได้ผลลัพธ์เดียวกันเสมอ ที่มาและ
เช็กซัมของไบนารีนั้นมีบันทึกไว้ใน ไบนารีที่มาพร้อมในตัว
การอ่านจะคัดลอกฐานข้อมูลออกมาแยกไว้ก่อนเปิด ไม่เคยแตะต้องไฟล์ที่กำลังใช้งานจริง และไม่เคย คัดลอกดัชนีหน่วยความจำร่วม (shared-memory index) ซึ่งฐานข้อมูลที่กำลังทำงานอยู่อาจรายงานว่า เสียหายได้
ส่วนที่ยากที่สุดของการอ่าน RCS อย่างซื่อตรงคือแฟล็กที่เห็นชัด ๆ นั้นโกหก แฟล็ก "available" แบบง่าย ๆ แฟล็กฟีเจอร์ และสถานะการจัดเตรียม (provisioning) ล้วนอ่านเป็นลบได้บนสายที่ RCS ทำงานได้อย่างสมบูรณ์แบบ เพราะมันเป็นแคช หรือเพราะสายนั้นทำงานบนแบ็กเอนด์ของ Google เอง (Jibe) แทนที่จะเป็นเครือข่าย IMS ของผู้ให้บริการ VD Google คำนวณคำตัดสิน Connection เพียงค่าเดียวจากการตั้งค่าแชทจริงและเอนจินการจัดเตรียม ซึ่งยังคงถูกต้องข้ามเวอร์ชันของ Android และ Google Messages และนำเสนอแฟล็กที่โกหกโดยติดป้ายกำกับไว้ชัดเจนว่าเป็นแคช เพื่อ ให้ข้อมูลโดยไม่ทำให้เข้าใจผิด ดูคู่มือผู้ใช้ สำหรับความหมายของแต่ละบรรทัด
การส่งออกคือสแนปช็อต JSON ที่ผ่านการล้างข้อมูล (sanitize) ตัวล้างข้อมูลจะทำงานก่อนที่จะมี การเขียนสิ่งใด มันจะตัดคีย์และค่าที่ดูเหมือนข้อมูลรับรอง (credentials) เซ็นเซอร์ชุดตัวเลขยาว ๆ และไม่เคยปล่อยหมายเลขโทรศัพท์ เนื้อหาข้อความ ชื่อผู้ติดต่อ หรือ blob ความสามารถดิบของคุณ ออกมา ส่วนการวินิจฉัย (diagnostics) ที่เลือกได้นั้นบรรจุเพียงชื่อสคีมา จำนวน ขนาด และเวอร์ชัน และแม้แต่ตรงนั้น ลายนิ้วมือต่อตัวตน (per-identity fingerprint) ใด ๆ ที่ฝังอยู่ในชื่อก็จะถูก ยุบทิ้งไป แอปและ WebUI สร้างสคีมาเดียวกัน
- มันไม่เคยประกาศสิทธิ์เครือข่าย และ WebUI ไม่เคยติดต่อต้นทางระยะไกล
- มันไม่เคยกุ ปลอม หรือซ่อนค่าใด ๆ
- มันไม่เคยรายงานคำตัดสิน Play Integrity เพราะคำตัดสินนั้นไม่ได้อยู่บนอุปกรณ์
- มันเปลี่ยนสถานะผ่านการกระทำที่ชัดเจน ยืนยันแล้ว และถูกบันทึกไว้ในเครื่องเท่านั้น
เอกสารนี้สร้างขึ้นด้วย Claude (Anthropic) และดูแลโดย VD171 ยินดีรับการแก้ไขและการปรับปรุง ดู CONTRIBUTING.md