למה להשתמש ב-NotHoly להנדסה הפוכה

הנדסה הפוכה היא קריאה. כבר פתוח אצלכם Ghidra, radare2 או IDA, והחלק האיטי הוא להבין dump של decompiler, לתת שמות ל-locals, ולכתוב את הסקריפט שישנה את השמות של המאתיים הבאים. מודל עוזר שם, אבל רק אם הוא מקבל את השאלה בלי הטפה וקורא את מה שאתם מדביקים. NotHoly עושה את שניהם. אתם שומרים על הכלים שלכם, והמודל מסביר את הפלט וכותב את הסקריפטים. מקרה השימוש של הנדסה הפוכה מכיל את הזרימה הארוכה יותר; כאן מדובר למה זה מתאים.

#הדביקו את הפלט, קבלו הסבר וסקריפט

הפלט של ה-decompiler וה-disassembler הוא הקלט. הדביקו פונקציה מ-Ghidra, בלוק מ-radare2 או רשימה מ-IDA, והמודל מסביר מה היא עושה, נוקב בשם המבנה שהוא רואה, ומסמן את החלקים שנראים כמו בדיקת גבול, שגרת decode או parser. בקשו סקריפט והוא כותב אחד לכלי שלכם: מעבר ב-Ghidra Python שמשנה שמות לפי תבנית, רצף פקודות radare2, קטע IDAPython, hook של Frida ללוג של קריאה. הסקריפט רץ על המכונה שלכם, מול הדגימה שלכם, לעולם לא שלנו. מכיוון שהמודל לא מסרב למשימה, שגרת unpacking, לולאה מעורפלת, טריק anti-debug או בדיקת רישיון נקראים כמו כל קוד אחר, כל עוד העבודה ב-scope שלכם.

r2 -q -c "pdf @ sym.main" ./bin | notholy "explain this function and write a radare2 script to rename the locals"

#מבט ראשון לפני הכלי הכבד

צרפו בינארי בצ׳אט, או הריצו notholy analyze, והכלים הסטטיים נותנים מעבר ראשון בלי לפתוח את ה-decompiler. ל-ELF או PE אתם מקבלים את ה-SHA-256, הגודל, האנטרופיה, הפורמט, ה-entry point, ה-sections וה-imports. לדגימה אתם מקבלים גם את ה-strings ותצוגה מקדימה של disassembly מתחילת הקובץ. APK נותן את ה-manifest ואת הטקסט של כל רשומה, וארכיון נותן את העץ שלו. כל קובץ נפרסר ב-sandbox חד-פעמי בלי רשת ועם שורש לקריאה בלבד, שום דבר בו לא מורץ, ו-pickle של Python מפורק עם pickletools, לעולם לא נטען. אנטרופיה גבוהה וטבלת imports קצרה כבר מספיקות כדי להחליט אם דגימה שווה את השעה ב-Ghidra. מדריך הקבצים מפרט את הסוגים והמגבלות.

#מה עוד בהישג יד

בסיס הידע הוא חלק מהמודל, אז שאלה על packer, פורמט קובץ או מוסכמת קריאה מביאה טכניקה אצורה עם מקור ורישיון בכל קטע. string של גרסה שאתם משחזרים הולך ישר ל-lookup של CVE שמחזיר CVSS, EPSS וסטטוס KEV עם תאריכים. גם בסיס הידע וגם נתוני ה-CVE נקראים דרך ה-CLI ודרך ה-API, אז אפשר לעשות triage לאצווה של דגימות מסקריפט, ואותו מודל שהסביר את הפונקציה מנסח את הדוח שהולך איתה. אותו מודל שניסח את הדוח הופך פורמט משוחזר ל-parser, כך שאתם עוברים מה-bytes לסקריפט עובד בלי להחליף כלי.

#איפה זה לא מתאים

הפלטפורמה לא עושה decompile. אין decompiler ואין גרף זרימת בקרה אצלנו, והתצוגה המקדימה המובנית של disassembly עוצרת בתחילת הקובץ ובמספר קצר של הוראות, אז הרשימה האמיתית באה מה-Ghidra או ה-IDA שלכם. שום דבר לא מורץ ואין ניתוח דינמי, אין debugger ואין אמולציה, אז ההתנהגות של דגימה ארוזה בזמן ריצה היא שלכם לצפות בה במעבדה שלכם. תמונות נותנות רק מידות, בלי OCR עדיין. והמודל יכול לקרוא offset לא נכון, להמציא API או להסביר פונקציה לא נכון, אז התייחסו להסבר כרמז ובדקו מול ה-bytes.

שמרו על ה-decompiler שלכם ותנו למודל לקרוא את הפלט שלו. שימו יתרה קטנה בתמחור, הדביקו פונקציה, ובקשו את הסקריפט.