ตรวจสอบว่ากระบวนการเฉพาะเป็น 32- หรือ 64- บิต

ให้เคอร์เนล 2.6.x หรือใหม่กว่า Linux และ userland ที่มีอยู่ซึ่งสามารถใช้งานทั้ง ELF32 และ ELF64 ไบนารี (เช่นที่ผ่านมาฉันจะรู้ได้อย่างไรว่า CPU ของฉันรองรับระบบปฏิบัติการ 64 บิตภายใต้ Linux? ) ฉันจะทราบได้อย่างไรว่ากระบวนการที่กำหนด โดย PID) กำลังทำงานในโหมด 32- หรือ 64- บิต?

วิธีแก้ปัญหาไร้เดียงสาจะทำงาน:

file -L /proc/pid/exe | grep -o 'ELF ..-bit [LM]SB'

แต่ข้อมูลนั้นถูกเปิดเผยโดยตรง/procโดยไม่ต้องพึ่งพาlibmagicหรือไม่

หากคุณต้องการ จำกัด การตรวจจับเอลฟ์คุณสามารถอ่านส่วนหัวเอลฟ์ของ/proc/$PID/exeตัวคุณเอง มันค่อนข้างเล็กน้อย: ถ้าไบต์ที่ 5 ในไฟล์คือ 1 มันคือไบนารี 32 บิต ถ้าเป็น 2 ก็คือ 64- บิต สำหรับการเพิ่มสติตรวจ:

1. ถ้า 5 ไบต์แรกคือ0x7f, "ELF", 1มันเป็นไบนารี ELF 32 บิต
2. ถ้า 5 ไบต์แรกคือ0x7f, "ELF", 2: มันเป็นไบนารี 64 บิตของ ELF
3. มิฉะนั้น: มันไม่สามารถสรุปได้

คุณสามารถใช้งานobjdumpได้ แต่นั่นจะทำให้การlibmagicพึ่งพาของคุณหายไปและแทนที่ด้วย alibelfหนึ่ง

อีกวิธีหนึ่ง : คุณสามารถแยกวิเคราะห์/proc/$PID/auxvไฟล์ ตามproc(5):

สิ่งนี้มีเนื้อหาของข้อมูลล่ามของ ELF ที่ส่งไปยังกระบวนการในเวลา exec รูปแบบคือหนึ่ง ID แบบยาวที่ไม่ได้ลงชื่อบวกค่าแบบยาวที่ไม่ได้ลงชื่อหนึ่งรายการสำหรับแต่ละรายการ รายการสุดท้ายมีสองศูนย์

ความหมายของคีย์อยู่ในunsigned long /usr/include/linux/auxvec.hคุณต้องการซึ่งเป็นAT_PLATFORM 0x00000fอย่าอ้างฉันในสิ่งนั้น แต่ดูเหมือนว่าค่าควรจะถูกตีความว่าเป็นchar *เพื่อให้ได้คำอธิบายสตริงของแพลตฟอร์ม

คุณอาจพบคำถาม StackOverflowมีประโยชน์

อีกวิธีหนึ่ง : คุณสามารถสั่งให้ไดนามิกman ldลิงค์เกอร์ ( ) เพื่อถ่ายโอนข้อมูลเกี่ยวกับปฏิบัติการ มันพิมพ์ออกไปยังเอาต์พุตมาตรฐานกับโครงสร้าง AUXV ที่ถอดรหัสแล้ว คำเตือน: นี่เป็นแฮ็ก แต่ก็ใช้ได้

LD_SHOW_AUXV=1 ldd /proc/$SOME_PID/exe | grep AT_PLATFORM | tail -1

สิ่งนี้จะแสดงสิ่งที่ชอบ:

AT_PLATFORM:     x86_64

ฉันลองมันในไบนารี 32 บิตและได้รับ i686แทน

วิธีการทำงาน: LD_SHOW_AUXV=1สั่งให้ Dynamic Linker ทำการดัมพ์โครงสร้าง AUXV ที่ถอดรหัสแล้วก่อนที่จะเรียกใช้ไฟล์ปฏิบัติการ ถ้าคุณจริงๆชอบที่จะทำให้ชีวิตของคุณที่น่าสนใจที่คุณต้องการที่จะหลีกเลี่ยงจริงทำงานกล่าวว่าปฏิบัติการ วิธีหนึ่งในการโหลดและเชื่อมโยงแบบไดนามิกโดยไม่ต้องเรียกใช้main()ฟังก์ชั่นของมันคือทำงานldd(1)บนมัน ข้อเสีย: LD_SHOW_AUXVเปิดใช้งานโดยเชลล์ดังนั้นคุณจะได้รับทิ้งโครงสร้าง AUXV สำหรับ: subshell lddและไบนารีเป้าหมายของคุณ ดังนั้นเราgrepสำหรับ AT_PLATFORM แต่ให้บรรทัดสุดท้ายเท่านั้น

การแยกวิเคราะห์ auxv : หากคุณแยกวิเคราะห์auxvโครงสร้างด้วยตัวคุณเอง (ไม่ต้องพึ่งพาตัวโหลดแบบไดนามิก) จากนั้นจะมีปริศนาเล็กน้อย: auxvโครงสร้างตามกฎของกระบวนการที่อธิบายไว้ดังนั้นsizeof(unsigned long)จะเป็น 4 สำหรับกระบวนการ 32 บิตและ 8 สำหรับ 64 กระบวนการบิต เราสามารถทำสิ่งนี้ให้กับเราได้ เพื่อให้สิ่งนี้ทำงานบนระบบ 32 บิตรหัสคีย์ทั้งหมดจะต้องเป็น0xffffffffหรือน้อยกว่า บนระบบ 64 บิต 32 บิตที่สำคัญที่สุดจะเป็นศูนย์ เครื่องของ Intel นั้นเป็น endian เล็ก ๆ น้อย ๆ ดังนั้น 32 บิตเหล่านี้จึงตามมาน้อยที่สุดในหน่วยความจำ

เช่นนี้สิ่งที่คุณต้องทำคือ:

1. Read 16 bytes from the `auxv` file.
2. Is this the end of the file?
3.     Then it's a 64-bit process.
4.     Done.
5. Is buf[4], buf[5], buf[6] or buf[7] non-zero?
6.     Then it's a 32-bit process.
7.     Done.
8. Go to 1.

การแยกไฟล์แผนที่ : สิ่งนี้ได้รับการแนะนำโดย Gilles แต่ก็ไม่ได้ผล นี่คือเวอร์ชั่นที่แก้ไขแล้ว มันอาศัยการอ่าน/proc/$PID/mapsไฟล์ หากไฟล์แสดงรายการที่อยู่ 64 บิตกระบวนการจะเป็น 64 บิต มิฉะนั้นจะเป็น 32 บิต ปัญหาอยู่ที่เคอร์เนลจะลดความซับซ้อนของการส่งออกโดยการปอกศูนย์นำจากที่อยู่ฐานสิบหกในกลุ่ม 4 ดังนั้นแฮ็คความยาวไม่สามารถทำงานได้ค่อนข้าง awkช่วยเหลือ:

if ! [ -e /proc/$pid/maps ]; then
    echo "No such process"
else
    case $(awk </proc/$pid/maps -- 'END { print substr($1, 0, 9); }') in
    *-) echo "32 bit process";;
    *[0-9A-Fa-f]) echo "64 bit process";;
    *) echo "Insufficient permissions.";;
    esac
 fi

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

ระวัง: ทั้งหมดยกเว้นวิธีแรกและวิธีสุดท้ายต้องการ Linux kernel 2.6.0 หรือใหม่กว่าเนื่องจากauxvไฟล์ไม่เคยมีมาก่อน

/proc/$pid/mapsดูใน ช่วงที่อยู่นั้นมีที่อยู่มากกว่า 32 บิต (เลขฐานสิบหก 8 หลัก) หรือที่อยู่ 64 บิต (ตัวเลขฐานสิบหก 16 หลัก) สิ่งนี้ใช้ได้กับการปฏิบัติการทุกรูปแบบไม่ว่ารูปแบบใด คุณสามารถรับข้อมูลเกี่ยวกับกระบวนการที่ทำงานในฐานะผู้ใช้คนเดียวกัน (เว้นแต่คุณจะรูท)

if ! [ -e /proc/$pid/maps ]; then
  echo No such process
elif grep -q '^........[^-]' /proc/$pid/maps; then
  echo 64-bit
elif grep -q . /proc/$pid/maps; then
  echo 32-bit
else
  echo Insufficient permissions
fi

หากคุณไม่ได้รับอนุญาตให้เข้าถึงไฟล์นี้ฉันคิดว่าวิธีเดียวที่จะพยายามวิเคราะห์ไฟล์ที่เรียกใช้งานได้คือ (ในขณะที่คุณสามารถอ่านเสมอ/proc/$pid/statไม่มีเขตข้อมูลที่แสดงให้เห็นกระบวนการทำงานเป็นผู้ใช้ที่แตกต่างกันเผยให้เห็นขนาดบิตของกระบวนการ.) คุณสามารถทำให้การคาดเดาที่ดีของกระบวนการของปฏิบัติการด้วยps -o comm=และมองว่าขึ้นมาในPATH- แต่ระวังว่ากระบวนการ อาจจะได้รับการเปิดตัวกับที่แตกต่างกันหรืออาจจะเขียนใหม่ของมันPATH argv[0]จากนั้นคุณสามารถวิเคราะห์ปฏิบัติการ - ถ้าคุณยินดีที่จะถือว่าเป็นเอลฟ์, ดูที่ไบต์ที่ 5