ניתוח זיכרון וניתוח ליבה במערכות Windows ו-Unix

אינפורמטק דיגיטל » Recursos » ניתוח זיכרון וניתוח ליבה במערכות Windows ו-Unix

כאשר מערכת הפעלה נכנסת לפאניקה או קורסת, הדרך היחידה להבין מה קרה היא באמצעות dump של זיכרון הליבה וניתוחו לאחר מכן . קבצי dump אלה לוכדים את המצב הפנימי של המערכת ברגע הכשל וחיוניים לאיתור שגיאות מורכבות, חקירת אירועי אבטחה או ביצוע בדיקות משפטיות.

למרות שזה אולי נשמע מאוד "ברמה נמוכה", ניתוח קבצי זיכרון אינו בלעדי למפתחי ליבה. מנהלי מערכת, מהנדסי תמיכה ואפילו מבקרי אבטחה יכולים להפיק ממנו תועלת אם הם מכירים את הכלים הנכונים, את הסוגים השונים של קבצי זיכרון ותכניות פירוש בסיסיות . נלווה אתכם בכל זה ב-Windows, Unix/Linux ו-BSD, תוך שימוש בכלים כמו WinDbg, crash, kgdb ו-LiME.

מהו קובץ dump של זיכרון ליבה ומדוע כדאי לנתח אותו?

קובץ dump של זיכרון ליבה (הנקרא לעתים קרובות Kernel Crash Dump או פשוט crash dump ) הוא קובץ המכיל עותק, מלא או חלקי, של הזיכרון בזמן שהמערכת סובלת מכשל קריטי, כגון panic ליבה ביוניקס/לינוקס או מסך כחול של מוות (BSOD) ב-Windows.

בפועל, קובץ dump מסוג זה שומר מבני ליבה פנימיים, מחסניות קריאה, הקשר תהליך ומנהלי התקנים טעונים . הודות לכך, לאחר האסון, ניתן לבצע ניתוח שלאחר המוות הדומה מאוד לניפוי שגיאות במערכת חיה, אך ללא הלחץ של נגיעה במכונת ייצור בזמן שהיא כושלת.

הסיבות להתעמקות בקבצי dump של ליבה מגוונות: החל מאיתור באגים אקראיים לכאורה וקריסות לסירוגין , ועד לחקירה האם מערכת עברה מניפולציה זדונית או האם קריסה הותירה עקבות של מידע רגיש בדיסק.

בנוסף ל-core dumps מלאים, קיימת אפשרות של עיבוד dumps של תהליכים בודדים ( core dumps קלאסיים ), שהם שימושיים מאוד כאשר אנו רוצים להגביל בעיה ליישום ספציפי או לבדוק את ההשפעה על הסודיות של שירות כגון דוא"ל או לקוח העברת הודעות.

סוגי זיכרון dump ב-Windows והשימושיות שלהם

במערכות Windows, מערכת ההפעלה עצמה יכולה לייצר סוגים שונים של קבצי dump כאשר מתרחשת שגיאת STOP. כל סוג כולל רמת פירוט שונה, לכן חשוב לדעת איזה סוג של dump אתם צריכים בהתאם לבעיה ולמגבלות שטח הדיסק.

אחד הפורמטים הנפוצים ביותר בסביבות משתמש ובשרתים רבים הוא זיכרון dump קטן (minidump)זהו זה שצורך הכי פחות מקום והוא ממוקם בדרך כלל ב %SystemRoot%\Minidump, עם קבצים בסגנון מיניMMDDYY-01.dmp.

קובץ המיני-dump הזה מכיל מידע ספציפי מאוד אך חשוב: קוד שגיאת STOP והפרמטרים שלו , רשימת מנהלי ההתקנים שהוטענו בזמן הכשל, ההקשר של המעבד שעצר (PRCB), ההקשרים של התהליך והשרשור המעורב (מבני EPROCESS ו-ETHREAD) ומחסנית קריאות במצב ליבה של אותו שרישור.

הודות למבנים בסיסיים אלה, אפילו עם minidump ניתן לעתים קרובות לזהות איזה מנהל התקן או מודול גורם לקריסות, אם כי לא תמיד ניתן יהיה לעקוב אחר המסלול המלא אם הבעיה מקורה הרחק מה-thread שפעל בזמן הקריסה ומידע ההקשר הזמין מוגבל.

Windows יכול גם ליצור קבצי dump של זיכרון הליבה וקבצי dump מלאים גדולים בהרבה המכילים חלקים או את כל הזיכרון הפיזי. אלה שימושיים במיוחד לניתוח ברמה נמוכה, חקירות פורנזיות וניפוי שגיאות מתקדמים של מנהלי התקנים או המערכת עצמה.

הגדרת ופתיחה של קבצי זיכרון ב-Windows באמצעות WinDbg ו-KD

כדי לנצל את תוכנות dump המערכת ב-Windows, הצעד הראשון הוא להגדיר כראוי את אפשרויות ההפעלה והשחזור . מלוח הבקרה, במאפייני המערכת המתקדמות, באפשרותך לבחור את סוג קובץ ה-dump שברצונך ליצור במקרה של כשל: לדוגמה, "קובץ dump זיכרון קטן (256 KB)" ואת הנתיב שבו הוא יאוחסן.

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

לאחר יצירתם, ישנן מספר דרכים לאמת את נכונותם של קבצי ה-dump. כלי עזר קלאסי הוא Dumpchk.exe , המאפשר לך לבדוק את שלמות הקובץ הבסיסית ולהדפיס מידע סיכום. לניתוח מתקדם יותר, נעשה שימוש בכלי ניפוי שגיאות של Windows , כולל WinDbg (ממשק גרפי) ו-KD (גרסת שורת פקודה).

לאחר התקנת חבילת ניפוי השגיאות מאתר האינטרנט של מיקרוסופט, הכלים בדרך כלל יהיו ממוקמים בתיקייה כגון C:\Program Files\Debugging Tools for Windows . משם, ניתן לפתוח שורת פקודה ולטעון קובץ dump באמצעות WinDbg או KD, תוך ציון הקובץ עם הפרמטר -z .

windbg -y <RutaSimbolos> -i <RutaBinarios> -z <RutaDump>

נתיב הסמלים יכול להצביע על שרת סמלים עם אחסון במטמון מקומי , לדוגמה:

srv*C:\Symbols*https://msdl.microsoft.com/download/symbols

בעוד שהנתיב הבינארי הוא בדרך כלל משהו כמו C:\Windows\I386 או התיקייה שאליה העתקנו את קבצי ההפעלה של המערכת התואמים לגרסה שיצרה את קובץ ה-dump. זה חשוב מכיוון מיני-dumps אינם כוללים את כל הקבצים הבינאריים, רק הפניות אליהם, כך שדיבאג-הבאגים צריך להיות מסוגל למצוא אותם.

ניתוח בסיסי של קובץ dump של קריסת ליבה ב-Windows

לאחר טעינת קובץ ה-dump באמצעות WinDbg או KD, ניתוח קובץ dump של קריסת ליבה דומה למדי לביצוע ניפוי שגיאות לאחר המוות. הפקודה הראשונה שכמעט כולם מפעילים היא `!analyze` , אשר מפעילה ניתוח אוטומטי ומייצרת דוח ראשוני.

הפקודה !analyze -show תראה את ה קוד בדיקת באגים והפרמטרים שלובעוד !analyze -v זה מייצר פלט מפורט הרבה יותר: מודול חשוד, מחסנית קריאות, מידע הקשרי, ובמקרים רבים, הצעות לגבי גורמים אפשריים או שלבי אבחון.

כדי להשלים את הניתוח, הפקודה .bugcheck מדפיסה שוב את קוד השגיאה והפרמטרים הנלווים, אותם ניתן להשוות לקוד בדיקת הבאגים של מיקרוסופט כדי לגלות את המשמעות המדויקת של כל ערך וסיבות אופייניות.

הפקודה lm N T (רשימת מודולים) מאפשר לך לראות את רשימת מודולים טעונים עם הנתיב, הכתובות והסטטוס שלהםזה עוזר לאשר האם מנהל ההתקן שזוהה על ידי הניתוח האוטומטי אכן נמצא בזיכרון ואיזו גרסה הוא. רשימה זו שימושית במיוחד כאשר אנו חושדים במנהלי התקנים או רכיבי אבטחה של צד שלישי אשר מקיימים אינטראקציה עם הליבה.

אם רוצים, נוכל לפשט את טעינת קבצי ה-dump על ידי יצירת קובץ אצווה שמקבל את הנתיב לקובץ ה-dump ומפעיל את KD או WinDbg עם הפרמטרים המתאימים. בדרך זו, עלינו לכתוב רק פקודה קצרה הכוללת רק את מיקום הקובץ, והסקריפט יטפל בכל השאר.

שימוש ב-WinDbg עבור עיבודי ליבה עמוקים

עבור קבצי Dump של זיכרון במצב ליבה, WinDbg מציע גם את היכולת לעבוד עם קבצים וסשנים מרובים. ניתן לפתוח קבצי Dump משורת הפקודה באמצעות -z , או מהממשק הגרפי באמצעות תפריט קובץ > פתיחת Dump זיכרון או קיצור המקשים Ctrl+D.

אם WinDbg כבר פתוח במצב פסיבי, פשוט בחר את הקובץ בתיבת הדו-שיח "פתח קובץ crash dump", ציין את הנתיב או עיין בדיסק. לאחר הטעינה, תוכל להתחיל את ההפעלה באמצעות פקודת "g" (Go) בתרחישים מסוימים, או להפעיל ישירות את פקודות הניתוח הראשוניות.

בנוסף לקלאסי !analyzeמומלץ להכיר את ה- סעיף עזר לפקודות ניפוי באגיםזה מתאר את כל הפקודות הזמינות לקריאת מבנים פנימיים, בחינת זיכרון, פירוש מחסניות ועוד. רבות מהטכניקות הללו ישימות הן לסשנים חיים והן לעיבודי dump לא מקוונים.

WinDbg מאפשר לך גם לעבוד עם מספר dumps מקביליםאנו יכולים להוסיף מספר פרמטרים של -z בשורת הפקודה, כשכל אחד מהם כולל שם קובץ שונה, או להוסיף מטרות חדשות באמצעות הפקודה .opendumpניפוי באגים ביעדים מרובים שימושי להשוואת כשלים חוזרים או אירועים משורשרים.

בסביבות מסוימות, קבצי זיכרון ארוזים בקבצי CAB כדי לחסוך מקום או להקל על השידור. WinDbg יכול לפתוח ישירות .cab עם קובץ dump בפנים, גם באמצעות -z וגם עם .opendumpלמרות שהוא יקרא זה יחלץ רק אחד מהקבצים שנשלחו ולא יחלץ קבצים אחרים. שיכול להיכנס לאותה חבילה.

קבצי קריסה ביוניקס ובלינוקס: כלי עזר, כלים ודרישות

במערכות יוניקס וגנו/לינוקס, הפילוסופיה דומה, אך מערכת הכלים השונה במידה ניכרת. רוב הליבות דמויי יוניקס מציעות את היכולת לשמור עותק של זיכרון כאשר מתרחש אירוע קטסטרופלי , המכונה core dump או kernel crash dump.

למרות שהשימוש העיקרי שלהם נותר בפיתוח ליבה ומנהלי התקנים, לקבצי dump אלה יש היבט אבטחה ברור. קריסה יכולה להיגרם משגיאות תכנות, אך גם מפעולות זדוניות כושלות, ניסיונות לתמרן רכיבי מערכת או ניצול מגושמות של תנאי מרוץ.

במערכת יוניקס שתצורתה תקינה, קריסות יומיומיות אינן נדירות, אך כאשר הן מתרחשות, מומלץ שתהיה תשתית dump זמינה, כגון Kdump, LKCD או פתרונות אחרים המאפשרים ללכוד זיכרון מערכת. עם זאת, חשוב לשקול הן את הערך האבחוני של ה-dump והן את הסיכון שהוא מכיל נתונים רגישים ביותר.

אחד הכלים המקיפים והנפוצים ביותר לסוג זה של ניתוח בלינוקס הוא crash , שפותח בתחילה על ידי Red Hat. כלי זה הפך למעשה לסטנדרט דה פקטו לבדיקת קבצי ליבה וגם לניתוח מערכות פעילות.

קריסה יכולה לפעול נגד הזיכרון החי של המערכת דרך /dev/mem או, ב-Red Hat ובהתפלגויות נגזרות, באמצעות ההתקן הספציפי /dev/crashאף על פי כן, מקובל להזין את הכלי בקובץ dump שנוצר על ידי מנגנונים כגון קדמפ, קובץ makedump, דיסקdump או קבצי dump ספציפיים לארכיטקטורה כמו s390/s390x או קסנדאמפ בסביבות וירטואליות.

תפקיד הקריסה וחשיבותה של vmlinux בלינוקס

כלי ההתרסקות נוצר, בין היתר, כדי להתגבר על מגבלות השימוש gdb ישירות על /proc/kcoreבין היתר, הגישה לתמונה המדומה של הזיכרון עשויה להיות מוגבלת, ובנוסף, אפשרויות קומפילציה מסוימות של הליבה מקשות על פירוש נכון של המבנים הפנימיים אם יש לנו רק קובץ בינארי דחוס להרצה.

כדי שהקריסה תפעל כראוי, נדרשים שני אלמנטים מרכזיים: קובץ vmlinux שעבר קומפילציה עם סמלי ניפוי שגיאות (בדרך כלל עם דגלים כמו -g) וקובץ ה-kernel עצמו. שילוב זה מאפשר לכלי למפות כתובות זיכרון לפונקציות, מבנים ושורות קוד.

חשוב להבחין ביניהם vmlinux ו-vmlinuzברוב המערכות, רק vmlinux גלוי, שהוא גרסה דחוסה וניתנת לאתחול של הליבה. קריסה דורשת את vmlinux שעבר פירוק סמלי; בלעדיו, בעת ניסיון לטעון קובץ dump או /dev/mem ניתקל בשגיאות מהסוג לא ניתן למצוא את הליבה המופעלת - אנא הזן את ארגומנט רשימת השמות.

למרות שניתן לחלץ ידנית את vmlinuz, התהליך לא תמיד פשוט, ובפועל, לעתים קרובות הרבה יותר נוח לקמפל מחדש את הליבה כדי להשיג גם את vmlinux וגם את vmlinuz בו זמנית. בסביבות ניהול רציניות, מומלץ לשמור על חבילת vmlinuz נפרדת עבור כל גרסת ליבה שנפרסה, במיוחד עבור מצבים אלה.

לאחר עמידה בדרישות, הרצת קריסה כנגד קובץ dump היא פשוטה יחסית: אתם מציינים את קובץ ה-vmlinux וה-dump המתאימים, והכלי פותח סשן אינטראקטיבי שממנו תוכלו לחקור מבני ליבה, לרשום תהליכים, לצפות במחסניות קריאות ולחלץ מידע פורנזי . אלו המעוניינים להעמיק יכולים לעיין בתיעוד ייעודי, כגון המסמך הטכני הידוע בנושא קריסות.

מגבלות של /dev/mem וגישות ראשונות בלינוקס

לפני שפנו לכלים ספציפיים, מנהלים רבים ניסו בעבר להשיג קובץ dump של זיכרון. קריאה ישירה מהמכשיר /dev/memגישה זו נראתה פשוטה: השתמשו בכלי כמו memdump (אשר שולח את ההתקן ל-STDOUT) או מושך מ dd if=/dev/mem of=volcado.mem.

עם זאת, גרעינים מודרניים מציעים אפשרויות קומפילציה כגון CONFIG_STRICT_DEVMEMאשר מגבילים באופן חמור את הגישה ממרחב המשתמש אל /dev/memהתוצאה האופיינית היא שהקריאה נקטעת לאחר בלוק קטן (למשל, 1 מגה-בייט) או, במקרה הגרוע ביותר, באג באינטראקציה זו יכול להסתיים ב... קרל פאניקה הפעלה מחדש מיידית והפעלה מחדש של המכונה.

הגנה זו הגיונית לחלוטין מבחינה ביטחונית, אך היא מאלצת אותנו לחפש דרכים אחרות להשיג dump אמין ומלא מבלי להסתמך לחלוטין על מכשירים גנריים שכבר אינם נגישים כמו בעבר.

לפיכך, המגמה הנוכחית היא להסתמך על מודולים ספציפיים או תשתיות משולבות של קבצי קריסה, במקום פשוט לנסות "לגרד זיכרון" בעזרת כלי מרחב משתמשים שאינם מיועדים להתקיים יחד עם מדיניות הגנה מודרנית על הליבה.

LiME Forensics: חילוץ זיכרון בלינוקס ואנדרואיד

אלטרנטיבה חזקה מאוד בעולם הפורנזיקה היא LiME (Linux Memory Extractor) , מודול ליבה שתוכנן בדיוק כדי ללכוד זיכרון נדיף בצורה מבוקרת וללא המגבלות המשפיעות על /dev/mem. LiME פועל במרחב הליבה, כך שהוא יכול לגשת ל-RAM בצורה ישירה הרבה יותר.

LiME מופץ עם קוד המקור שלו ומקומפל כנגד כותרות ליבה בשימושתהליך הקומפילציה יוצר מודול .ko ספציפי לגרסת הליבה שאליה היא תטען. לאחר הקומפילציה, נוכל לאמת אותה בעזרת כלים כגון file כדי לוודא שמודול ה-ELF המתאים לארכיטקטורה שלנו נוצר כהלכה.

כדי להשתמש ב-LiME, פשוט טען את המודול עם insmod מ-root ולהעביר לו את האפשרויות המתאימות, לדוגמה על ידי ציון א יעד dump של רשת באמצעות TCP ופורמט raw:

insmod lime-3.x.y.ko "path=tcp:4444 format=raw"

במקביל, במחשב שתקבל את ה-dump, אנו מאזינים לפורט שהוגדר באמצעות כלי כמו ncניתוב מחדש של הפלט לקובץ:

nc <IP_origen> 4444 > volcado.mem

לאחר מספר דקות, בהתאם לכמות ה-RAM ולביצועי הרשת, יהיה לנו קובץ שגודלו תואם את הזיכרון הפיזי של מערכת המקור. זהו קובץ RAM dump מלא שנוכל לנתח באמצעות כלים פורנזיים או אפילו באמצעות מחרוזות או כלי עזר אחרים כצעד ראשון לאיתור מחרוזות מעניינות.

dumps של תהליכים וסיכוני חשיפת נתונים

קובץ Dump מלא של הליבה הוא אינפורמטיבי ביותר, אך הוא יכול להיות גם מוגזם כשאנחנו מתעניינים רק בתהליך ספציפי. במקרה כזה, הגיוני מאוד לפנות ל... קבצי dump של תהליכים בודדים באמצעות כלים כמו gcore ביוניקס/לינוקס.

קבצי ה-dump הללו, המבוססים על כל תהליך, קטנים בהרבה וקלים יותר לניהול, ומאפשרים לך למקד את הניתוח שלך ביישומים ספציפיים כגון תוכנת העברת הודעות (למשל, סקייפ) או תוכנת דוא"ל (למשל, ת'אנדרבירד), שבהם קל יחסית למצוא סיסמאות בטקסט רגיל, אסימוני סשן או נתוני קשר על ידי חקירת מחרוזות זיכרון.

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

אם משתמש מתזמן, לדוגמה, משימה cron על ידי לכידת קבצי dump של תהליכים רגישים באופן תקופתי והשארתם בספרייה קריאה גלובלית, תוקף פותח דלת ענקית לחשיפת מידע קריטי. בתרחישי ביקורת רבים, ניתוח קבצים אלה מאפשר לתוקף להתאושש אישורים, רשימות אנשי קשר, היסטוריית תקשורת ונתונים פרטיים אחרים במאמץ נמוך יחסית.

לכן, בכל ביקורת רצינית של מערכת יוניקס, מומלץ להקדיש מספר דקות לבדיקה האם נוצרים קבצי dump (מלאים או חלקיים), היכן הם מאוחסנים, אילו הרשאות יש להם, ואם יש תהליך אוטומטי כלשהו שמשאיר עותקי זיכרון בהישג ידם של משתמשים לא מורשים.

ניתוח שלאחר המוות של קבצי dump ב-FreeBSD עם kgdb

בעולם ה-BSD, ובפרט ב-FreeBSD, הגישה לניתוח שלאחר המוות כרוכה... הפעלת קבצי קריסה במערכת וקבלת קומפילציה של הליבה עם סמלי ניפוי שגיאותזה נשלט מספריית תצורת הליבה, בדרך כלל ב- /usr/src/sys/<arq>/conf.

בקובץ התצורה המתאים, ניתן להפעיל יצירת סמלים באמצעות שורה כזו:

makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols

לאחר שינוי התצורה, יש לקמפל מחדש את הליבה. חלק מהאובייקטים ייווצרו מחדש (כגון trap.o) עקב השינוי בקבצי הבנייה. המטרה היא להשיג ליבה עם ה- אותו קוד כמו זה שיש בו בעיות, אך הוספת מידע ניפוי השגיאות הדרושמומלץ להשוות בין הגדלים הישנים לחדשים באמצעות הפקודה size כדי לוודא שלא חלו שינויים בלתי צפויים בקובץ הבינארי.

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

אין ערובה מוחלטת לכך שהניתוח יפתור את כל התקריות, אך בפועל, אסטרטגיה זו עובדת די טוב באחוז גבוה של תרחישים , במיוחד כאשר משולבים רשומות של קריסות עם סקירה טובה של שינויים אחרונים במערכת.

שיטות עבודה מומלצות לניתוח ותיעוד של שגיאות ליבה

ללא קשר למערכת ההפעלה, ניתוח dump של הליבה (core dump) בדרך כלל מתייחס לתיעוד טכני, מאגרי ידע, פורומים ייעודיים או אפילו קוד המקור של הליבה עצמו כדי לפרש הודעות, קודי שגיאה וסמלים לא מוכרים.

בלינוקס, כדאי מאוד להסתמך על עץ קוד המקור הרשמי, התיעוד המובנה ומשאבי הקהילה. הודעות שגיאה רבות בליבת הקרנל ניתנות לאיתור עד לקובץ המדויק שממנו הן מגיעות, מה שעוזר להבין את ההקשר שבו מופעלים BUG() או WARN() מסוימים.

ב-Windows, התיעוד של מיקרוסופט, מאגר הידע (KB) והפורומים הטכניים מספקים הסברים מפורטים על קודי בדיקת באגים, המלצות לפתרון בעיות ודפוסי שגיאה ידועים . שילוב מידע זה עם הדוחות מ-!analyze -v מאפשר לפתח תוכנית סבירה להפחתת נזקים.

הערך האמיתי של דוח קריסות מתגלה כאשר כל המידע הזה משולב עם הבנה מוצקה של מערכת ההפעלה והסביבה הספציפית בה התרחשה הכשל . רק אז ניתן לפתח פתרונות מתמשכים, ומעל הכל, למנוע את הישנותה של אותה בעיה בעתיד עם השלכות חמורות יותר.

ניתוח dump של ליבה הוא, בסופו של דבר, שילוב של מדע ואומנות: הוא דורש כלים מתאימים, תצורה מוקדמת (סמלים, אפשרויות dump, אחסון מאובטח), וניסיון רב בקריאת מחסניות, מבנים וקודי שגיאה. שליטה בטכניקות אלו מאפשרת לנו לא רק לאתר באגים באירועים מורכבים, אלא גם להגדיל באופן דרמטי את האבטחה והחוסן של המערכות שאנו מנהלים.