זה היה בשנת 2019. המעבדה שלנו קיבלה כונן QUANTUM FIREBALL Plus KA יוצא דופן למדי בנפח 9.1GB. לדברי הבעלים, התקלה בכונן התרחשה בשנת 2004 עקב כשל באספקת החשמל, שלקח איתו את הכונן הקשיח ורכיבי מחשב אחרים. לאחר מכן, מוסכים רבים ניסו לתקן את הכונן ולשחזר את הנתונים, אך ללא הועיל. חלקם הבטיחו תיקון זול, אך מעולם לא פתרו את הבעיה; אחרים היו יקרים מדי, והלקוח סירב לשחזר את הנתונים. בסופו של דבר, הכונן עבר דרך מרכזי שירות רבים. הוא אבד מספר פעמים, אך הודות למאמציו היזומים של הבעלים לתעד מידע ממדבקות שונות על הכונן, הוא הצליח להחזיר לו את הכונן הקשיח שלו על ידי מספר מרכזי שירות. ההליכות לא נעלמו מעיניו; עקבות רבות של הלחמה נותרו על לוח הבקרה המקורי, וגם היעדר ויזואלי של רכיבי SMD היה מורגש (במבט קדימה, אני חייב לומר שזו הבעיה הקטנה ביותר עם הכונן הזה).
כונן קשיח אחד של אורז, Quantum Fireball Plus KA בנפח 9,1 ג'יגה-בייט.
הצעד הראשון היה חיפוש בארכיון התורם אחר התאום העתיק של הכונן הזה עם לוח בקרה תקין. לאחר השלמת חיפוש זה, ניתן היה לבצע אבחון מקיף. לאחר בדיקת סלילי המנוע לאיתור קצרים ואישור כי לא היו כאלה, התקנו את הלוח מהכונן התורם על הכונן המטופל. חיברנו חשמל ושמענו את הצליל הרגיל של סיבוב הציר, עברנו את בדיקת הכיול עם טעינת הקושחה, ולאחר מספר שניות, הכונן דיווח דרך האוגרים שלו שהוא מוכן להגיב לפקודות מהממשק.
איור 2. מחווני DRD DSC מצביעים על מוכנות לקבל פקודות.
אנו מגבים את כל עותקי מודולי הקושחה. אנו מבצעים בדיקת שלמות מודול הקושחה. אין בעיות בקריאת המודולים, אך ניתוח הדוחות מגלה כמה מוזרויות.
איור 3. טבלת אזורים.
אנו שמים לב לטבלת חלוקת האזורים ושמים לב שמספר הצילינדרים הוא 13845.
איור 4 רשימת P (רשימה ראשונית – רשימת פגמים שהוצגו במהלך מחזור הייצור).
אנו מציינים את מספר הפגמים הנמוך ביותר ואת מיקומם. אנו בודקים את יומן הסתרת הפגמים של היצרן (60 שעות) ומצאנו אותו ריק, ללא ערכים. ממצא זה מצביע על כך שייתכן שמרכז שירות קודם כל התעסק באזור השירות של הכונן, החליף בטעות או במכוון מודול אחר, או מחק את רשימת הפגמים מהמקור. כדי לאמת זאת, אנו יוצרים משימה ב-Data Extractor כאשר האפשרויות "צור עותק סקטור-אחר-סקטור" ו"צור מתרגם וירטואלי" מופעלות.
איור 5 פרמטרים של המשימה.
לאחר יצירת המשימה, אנו בוחנים את הערכים בטבלת המחיצות בסקטור אפס (LBA 0)
איור 6 רשומת אתחול ראשית וטבלת מחיצות.
יש ערך יחיד (16 בתים) בהיסט 0x1BE. סוג מערכת הקבצים במחיצה הוא NTFS, ההיסט להתחלה הוא 0x3F (63) של הסקטור, וגודל המחיצה הוא 0x011309A3 (18,024,867) סקטורים.
בעורך הסקטורים, פתח את LBA 63.
איור 7 סקטור אתחול NTFS
לפי המידע בסקטור האתחול של מחיצת NTFS, ניתן לומר את הדברים הבאים: גודל הסקטור שאומץ בנפח הוא 512 בתים (מילה 0x0200 (512) נכתבת בהיסט 0x0B), מספר הסקטורים באשכול הוא 8 (בית 0x08 נכתב בהיסט 0x0D), גודל האשכול הוא 512x8=4096 בתים, רשומת ה-MFT הראשונה ממוקמת בהיסט 6,291,519 סקטורים מתחילת הדיסק (בהיסט 0x30 המילה המרובעת 0x00 00 00 00 00 0C 00 00 (786,432) היא מספר אשכול ה-MFT הראשון. מספר הסקטור מחושב לפי הנוסחה: מספר אשכול * מספר סקטורים באשכול + היסט לתחילת המחיצה 786,432* 8+63= 6,291,519).
נעבור למגזר 6 291 519.
איור. מספר
עם זאת, הנתונים הכלולים בסקטור זה שונים לחלוטין מרשומת ה-MFT. אמנם זה מצביע על תרגום שגוי אפשרי עקב רשימת פגמים שגויה, אך זה לא מוכיח זאת. כדי לאמת זאת עוד יותר, נקרא את הדיסק 10,000 סקטורים בו זמנית בשני הכיוונים, יחסית לסקטור 6,291,519. לאחר מכן, נחפש ביטויים רגולריים בנתונים שנקראו.
איור 9 רשומת MFT ראשונה
בסקטור 6,291,551, אנו מוצאים את רשומת ה-MFT הראשונה. מיקומה שונה מזו המחושבת ב-32 סקטורים, ולאחר מכן מגיעה קבוצה רציפה של 16 רשומות (מ-0 עד 15). אנו מזינים את מיקומו של סקטור 6,291,519 לטבלת ההזזה, ומזיזה אותו קדימה ב-32 סקטורים.
איור. מספר
רשומה מספר 16 אמורה להיות בהיסט 12,551,431, אך אנו מוצאים שם אפסים במקום רשומת MFT. בואו נבצע חיפוש דומה באזור שמסביב.
איור 11 ערך MFT 0x00000011 (17)
זוהה מקטע MFT גדול, החל מרשומה מספר 17 (באורך 53,646 רשומות) עם היסט של 17 סקטורים. עבור מיקום 12,155,431, אנו מזינים היסט של +17 סקטורים בטבלת ההיסט.
לאחר קביעת המיקומים המרחביים של שברי ה-MFT, אנו יכולים להסיק כי לא נראה שמדובר בכשל אקראי או שברי MFT שנכתבו בהיסטים שגויים. ניתן לראות את התיאוריה הכרוכה במתרגם שגוי כמאומתת.
כדי למקם עוד יותר את נקודות ההזזה, נקבע את ההיסט המרבי האפשרי. לשם כך, נקבע את ההזזה של סמן סיום מחיצת NTFS (עותק סקטור האתחול). באיור 7, בהיסט 0x28, מילת המרובעת היא ערך גודל המחיצה: 0x00 00 00 00 01 13 09 A2 (18,024,866) סקטורים. הוספת היסט המחיצה מתחילת הדיסק לאורכו מניבה היסט סמן סיום NTFS של 18,024,866 + 63 = 18,024,929. כצפוי, עותק סקטור האתחול הנדרש לא נמצא שם. חיפוש באזור שמסביב גילה אותו עם הזזה הולכת וגדלה של +12 סקטורים יחסית לקטע ה-MFT האחרון.
איור 12 עותק של סקטור האתחול NTFS
אנו מתעלמים מהעותק השני של סקטור האתחול בקיזוז 18,041,006, מכיוון שהוא אינו רלוונטי למחיצה שלנו. בהתבסס על חקירות קודמות, נקבע כי המחיצה מכילה תכלילים מסקטורים 61 ש"צצו" במהלך התרגום, אשר הזיזו את הנתונים.
אנו מבצעים קריאה מלאה של הכונן, מה שמותיר 34 סקטורים שלא נקראו. למרבה הצער, אי אפשר להבטיח באופן מהימן שכולם פגמים שהוסרו מרשימת ה-P, אך מומלץ לשקול את מיקומם במהלך ניתוח נוסף, שכן במקרים מסוימים ניתן יהיה לקבוע באופן מהימן נקודות הזזה בדיוק ברמת הסקטור, ולא בדיוק ברמת הקובץ.
איור 13 סטטיסטיקות קריאת דיסק.
המשימה הבאה שלנו היא לקבוע את המיקומים המשוערים של ההזזות (עד לקובץ שבו הן התרחשו). לשם כך, נסרוק את כל רשומות ה-MFT ונבנה שרשראות מיקום של קבצים (קטעי קובץ).
איור 14. שרשראות של מיקומי קבצים או שבריהן.
לאחר מכן, במעבר מקובץ לקובץ, אנו מחפשים את הנקודה שבה כותרת הקובץ הצפויה משתנה למשהו אחר, והכותרת הרצויה מופיעה עם היסט חיובי. ככל שאנו משפרים את ההיסטים הללו, אנו ממלאים את הטבלה. לאחר האכלוס, מעל 99% מהקבצים לא ייפגעו.
איור 15. רשימת קבצי משתמש (הלקוח נתן את הסכמתו לפרסם צילום מסך זה)
כדי לזהות שינויים ספציפיים בקבצים בודדים, ניתן היה לבצע עבודה נוספת, ובהינתן מבנה הקבצים, ניתן היה למצוא הכללות של נתונים שאינם קשורים לקובץ. עם זאת, עבור משימה זו, הדבר לא היה חסכוני.
נ.ב. אני רוצה לפנות גם לעמיתיי שטיפלו בעבר בכונן זה. אנא היזהרו בעת עבודה עם קושחת המכשיר וגבו את נתוני השירות לפני ביצוע שינויים כלשהם. כמו כן, אנא הימנעו מהחמרת הבעיה בכוונה אם לא הצלחתם להגיע להסכמה עם הלקוח בנוגע לעבודה המבוצעת.
מקור: www.habr.com
