perror
2013-08-23 20:01:18 UTC
נתקלתי בהוראה x86-32 מוזרה (opcode 0x65 ) מפוענחת על ידי objdump כ- gs (לא % gs קוד> אבל gs ). מצאתי אותו בזמן טאטא ליניארי מלא של בינארי ( objdump -D ), ולכן הפענוח בוודאי לא נכון. אבל, עדיין, objdump לא פענח אותו כהוראה (רע) , אז זה אומר שאפשר להיתקל בזה ואני רוצה לדעת מה זה אומר.
הנה דוגמה להוראה זו:
080484fc <_IO_stdin_used>: 80484fc: 01 00 add% eax, (% eax) 80484fe: 02 00 add (% eax), % al 8048500: 48 dec% eax 8048501: 65 גרם < ========================= כאן !!! 8048502: 6c insb (% dx),% es: (% edi) 8048503: 6c insb (% dx),% es: (% edi) 8048504: 6f outsl% ds: (% esi), (% dx) 8048505: 20 57 6f ו-% dl, 0x6f (% edi) 8048508: 72 6c jb 8048576 <_IO_stdin_used + 0x7a> 804850a: 64 21 0a ו-% ecx,% fs: (% edx) 804850d: 00 44 6f 64 add%%, edi,% ebp, 2) 8048511: 67 65 20 54 68 and% dl,% gs: 0x68 (% si) 8048516: 69 .byte 0x69 8048517: 73 21 jae 804853a <_IO_stdin_used + 0x3e> שים לב כי חיפוש ההוראה הזו באינטרנט הוא די קשה בגלל הרישום % gs המסווה את כל שאר הלהיטים האפשריים. אז האם מדובר ב"הוראות "אמיתיות? או שמא מדובר בתקלה המיוצרת על ידי גז ?
הממ, נראה שזה באג מקריני השיניים של GNU ... הקוד הקוד "0x65" תואם למעשה לקידומת המתאימה ל-% gs: (mem_ref) ". אבל הנה, נראה שמנתח 'libopcodes' מפרש את זה בטעות ו * שוכח * לפרש את הדברים הבאים בהמשך כהפניה לזיכרון ... (יכול להיות שאני טועה, אבל אנסה לענות מתי אדע יותר על כל זה) .
על פי המדריכים של אינטל, ההוראות "ins *" * מתעלמות * מקדמות מקטעות ומשתמשות תמיד ב-% es.
אז, זה אומר שזה בגלל שיש לך את קוד הקודים '0x65' ואחריו הוראות 'ins' שהמפענח טועה ... אני מבין, זה מעניין. תודה.
קצת מאוחר, אבל: המפענח מבין את זה "לא בסדר" מכיוון שאתה מפרק מחרוזת טקסט * אפסית. אינך יכול לקבל החלטות על פירוק "טוב" או "רע" תוך הזנתו עם קלט רע. (מצחיק: המחרוזת הזו כל כך ידועה שקיבלתי אותה אחרי שפענחתי את שלוש התווים הראשונים.)