ไบนารี VPN ของคุณสร้างสำหรับ CPU นี้หรือไม่ อ่านส่วนหัว ELF

ทั้งสองไฟล์เป็น 32 บิต และมีเพียงไฟล์เดียวเท่านั้นที่ทำงานบนบอร์ดของคุณ การสร้าง ELF32 สำหรับ Intel และการสร้าง ELF32 สำหรับ ARM ตรงกันในฟิลด์คลาสและไม่ตรงกันในทุกสิ่งที่มีความสำคัญ หน้าดาวน์โหลดที่เสนอตัวเลือก 32 บิตแทบไม่ได้บอกอะไรคุณเลยจนกว่าคุณจะอ่านส่วนหัวของไฟล์ที่คุณดาวน์โหลดมาจริง การเปลี่ยนชื่อไม่เปลี่ยนคำสั่งแม้แต่คำสั่งเดียว

คลาสและเครื่องตอบคำถามที่ต่างกัน

ฟิลด์คลาสบอกว่าไฟล์ใช้โครงสร้าง 32 บิตหรือ 64 บิต ฟิลด์เครื่องระบุชุดคำสั่งที่ไฟล์ถูกคอมไพล์มา การอ่านเฉพาะฟิลด์แรกคือวิธีที่การสร้าง x86 ไปลงเอยบนบอร์ด ARM ด้วยชื่อไฟล์ที่ดูน่าเชื่อถืออย่างสมบูรณ์ ค่าทั้งสองมาจากคำสั่งเดียวกัน จึงเป็นเรื่องง่ายมากที่จะข้ามไปหนึ่งค่า

ความสับสนเดียวกันใช้กับป้ายกำกับ 64 บิต ซึ่ง aarch64 และ x86-64 ใช้ขนาดคำร่วมกันและไม่มีคำสั่งใดร่วมกันเลย หน้าของผู้จำหน่ายที่แสดงรายการดาวน์โหลด 64 บิตหนึ่งรายการกำลังอธิบายการสร้างของตนเอง ไม่ใช่เครื่องของคุณ ตรวจสอบส่วนหัวของไฟล์แทนที่จะดูหัวคอลัมน์บนหน้า

readelf -h ./vendor-vpn
readelf -l ./vendor-vpn | head -20
file ./vendor-vpn

คำสั่งแรกพิมพ์ส่วนหัว รวมถึงคลาสและเครื่อง คำสั่งที่สองแสดงส่วนหัวของโปรแกรม ซึ่งเป็นที่อยู่ของคำขอตัวแปลความหมาย คำสั่งที่สามให้คุณหนึ่งบรรทัดเมื่อตารางมีมากกว่าที่คุณต้องการ

การเพิ่มสิทธิ์ในการเรียกใช้หรือการแพตช์การตรวจสอบของดิสทริบิวชันไม่ได้แปลอะไรเลย การจำลอง ในที่ที่แพลตฟอร์มรองรับ เป็นการตัดสินใจติดตั้งใช้งานที่มีต้นทุนด้านประสิทธิภาพและการพึ่งพาของตัวเอง

อ่านส่วนหัวก่อนเรียกใช้ตัวติดตั้ง

ตรวจสอบอาร์ติแฟกต์ที่เชื่อถือได้ก่อนเรียกใช้อะไรก็ตามจากมัน ตัวติดตั้งที่ล้มเหลวกลางทางอาจทิ้งไลบรารีที่ถูกแทนที่และไม่มีอะไรทำงาน ซึ่งเป็นจุดเริ่มต้นที่แย่กว่าอาร์ไคฟ์ที่คุณเริ่มต้น การตรวจสอบส่วนหัวเป็นการอ่านเท่านั้นและย้อนกลับได้ในแง่ที่ว่าไม่มีอะไรบนระบบเปลี่ยน

เปรียบเทียบฟิลด์เครื่องกับสถาปัตยกรรมแพ็กเกจของระบบที่กำลังทำงาน ไม่ใช่ชื่อทางการตลาดของบอร์ด CPU 64 บิตที่รันยูสเซอร์แลนด์ 32 บิตต้องใช้การสร้าง 32 บิต และรายละเอียดนั้นตัดสินว่าการดาวน์โหลดใดเป็นแบบเนทีฟ ข้อจำกัดไม่ใช่ความสามารถของบอร์ด แต่เป็นยูสเซอร์แลนด์ที่ติดตั้งไว้

dpkg --print-architecture
uname -m
getconf LONG_BIT

คำสั่งแรก รายงานสถาปัตยกรรมที่ระบบติดตั้งแพ็กเกจสำหรับ และนั่นคือค่าที่ต้องตรงกัน อีกสองคำสั่งอธิบายเคอร์เนลและขนาดคำ และอาจไม่ตรงกับยูสเซอร์แลนด์ในการติดตั้งหลายสถาปัตยกรรม

เมื่อคำตอบเหล่านั้นต่างกัน ให้ตัดสินว่าผู้จำหน่ายรองรับตัวใดก่อนดาวน์โหลดอาร์ไคฟ์อื่น การเดาสร้างวงจรของการติดตั้งที่แต่ละครั้งล้มเหลวในจุดที่ต่างกัน และทุกความล้มเหลวดูเหมือนปัญหาใหม่

ตรวจสอบตัวแปลความหมาย ไม่ใช่แค่สถาปัตยกรรม

ไฟล์ปฏิบัติการแบบไดนามิกบันทึกตัวโหลดที่คาดหวังไว้ในส่วนหัวของโปรแกรม บนระบบที่มีเส้นทางตัวโหลดต่างกัน เคอร์เนลปฏิเสธที่จะเริ่มไฟล์แม้ว่าฟิลด์เครื่องจะตรงกันทุกประการ นี่คือความล้มเหลวที่ทำให้ผู้คนออกตามหาไลบรารีที่หายไป

ข้อความแสดงข้อผิดพลาดบอกคุณว่าคุณอยู่ในกรณีใด และสองกรณีนี้สับสนได้ง่าย การปฏิเสธรูปแบบหรือสถาปัตยกรรมแตกต่างจากไฟล์หรือตัวแปลความหมายที่หายไป และมีเพียงกรณีเดียวเท่านั้นที่แก้ได้ด้วยการติดตั้งแพ็กเกจอื่น

readelf -l ./vendor-vpn | grep -A1 INTERP
ls -l /lib64/ld-linux-x86-64.so.2

คำสั่งแรกแสดงเส้นทางของตัวแปลความหมายที่ไบนารีร้องขอ คำสั่งที่สองตรวจสอบว่าเส้นทางนั้นมีอยู่หรือไม่ ซึ่งแยกการสร้างที่ผิดออกจากตัวโหลดที่หายไป

อย่าเรียกใช้ตัวแสดงรายการการพึ่งพากับไบนารีที่ไม่น่าเชื่อถือ เพราะบางการนำไปใช้อาจเรียกใช้ไฟล์ที่กำลังตรวจสอบได้ รักษาการตรวจสอบให้เป็นการอ่านเท่านั้นและต้านทานสิ่งล่อใจที่จะเพิ่มซิมลิงก์ของตัวโหลดเพื่อให้การสร้างที่ไม่รองรับเริ่มทำงาน

ขอการสร้างเมื่อมีข้อเท็จจริงอยู่ในมือ

ส่งเวอร์ชัน OS สถาปัตยกรรมแพ็กเกจ ค่าคลาสและเครื่อง และข้อความแสดงข้อผิดพลาดแรกให้ผู้จำหน่าย การผสมผสานนั้นจะได้รับคำตอบที่มีประโยชน์ ขณะที่ภาพหน้าจอของความล้มเหลวทั่วไปจะได้รับเทมเพลตการสนับสนุน

แยกคำถามเรื่องไบนารีออกจากคำถามเรื่องการกำหนดค่า เมื่อการสร้างที่ถูกต้องเริ่มทำงาน โปรไฟล์ ข้อมูลรับรอง และเส้นทางยังคงเป็นปัญหาของมันเอง และการแก้ไขโปรไฟล์ไม่ว่าจะมากเพียงใดก็ไม่ทำให้ไบนารีที่สถาปัตยกรรมผิดทำงานได้