Volatility กับ Live Forensics

คำว่า volatility ถ้าคนที่เรียนคอมมาก็คงเคยได้ยินกันมาไม่มากก้อน้อย คำๆนี้หมายถึง ลักษณะบางอย่างของอุปกรณ์คอมพิวเตอร์ที่สามารถเก็บข้อมูลเมื่อมีไฟเลี้ยง และข้อมูลจะหายไปเมื่อไม่มีไฟเลี้ยง ซึ่งโดยปกติแล้วมักจะหมายถึง RAM นั่นเอง แต่ที่เราจะกล่าวกันในวันนี้นั้นไม่ใช่วิชาพื้นฐานคอมพิวเตอร์ครับ แต่เป็นวิชา Forensics และ Volatility ที่จะกล่าวถึงในวันนี้ก็ไม่ใช่อาการดังกล่าวครับ แต่เป็น tools ที่ช่วยให้ชีวิตง่ายขึ้น

Voliatility เป็น tools ไว้ใช้สำหรับการวิเคราะห์ memory image ครับ หากใครไล่อ่านเนื้อหาอันไร้สาระมาตลอดก็จะพอทราบได้มีคนพัฒนาสคริปต์ต่างๆ เพื่อช่วยสำหรับการวิเคราะห์ memory image อยู่บ้างแล้ว เช่น lsproc ซึ่งตัวสคริปต์ดังกล่าวนั้นเป็นเพียง Proof of Concept และสามารถใช้ได้กับ image ของระบบปฏิบัติการ Windows 2000 เท่านั้น ไม่สามารถใช้กับ image ของ XP หรือ 2003 ได้ (ผมเขียน lsproc สำหรับ XP และ 2003 ไว้แล้ว แต่สำหรับสคริปต์อื่นๆนี่ไม่ไหวครับ เกิด error) แต่ก็มีกลุ่มคนสนใจและพัฒนาสคริปต์ต่างๆจนกระทั้งกลายเป็นเจ้า Volatility ขึ้นมาซึ่งสามารถทำงานได้กับ image ของ XP และ 2003 ได้ครับ วันนี้ผมจะนำภาพบางส่วนจากการใช้งานจริงของเจ้า Volatility มาให้ดูกันครับ

ความสามารถแรกคือการแสดงรายชื่อของโปรเซสที่รันขณะที่ทำการ image memory มา ซึ่งความสามารถนี้ก็คือ lsproc ที่เราคุ้นกันนั่นเองครับ



ข้อแตกต่างระหว่างผลลัพธ์ของ lsproc กับ Volatility คือ lsproc นั้นจะมีแสดงข้อมูลของโปรเซสที่หยุดการทำงานไปแล้ว และตำแหน่งของ physical address ของโปรเซสแต่ละโปรเซสด้วย แต่ทว่าถ้าอยากได้ข้อมูลครบแบบ lsproc แล้วละก็ Volatility ก็สามารถทำได้ครับ โดยใช้ความสามารถในการแสกนหา EPROCESS ใน memory image ดังภาพ



เหมือนกันเด๊ะๆ แต่สังเกตว่าพอให้เทคนิคสแกน EPROCESS นั้น Volatility จะทำงานช้ากว่าการเลือกแสดงโปรเซสเพียวๆ อาจเป็นไปได้ว่าใช้คนละ algorithm ในการค้นหา

พอก่อนละกันวันนี้ เด๋วมาต่อตอนสองใหม่

ทำ data-carving บน memory image ของโทรศัพท์มือถือ

สวัสดีครับวันนี้มีโจทย์ forensics มาอีกแล้ว ^_^ โดยเจ้าของโจทย์อยากทราบว่า memory image ที่ได้จากโทรศัพท์มือถือมีไฟล์อะไรอยู่บ้าง ซึ่งเทคนิคที่เราจะใช้ในการค้นหาครั้งนี้เรียกว่า data-carving ครับ

data-carving เป็นเทคนิคการค้นหาไฟล์จาก image ต่างๆไม่ว่าจะเป็น image ของ harddisk, memory, หรือ USB storage โดยการค้นหาดังกล่าวนี้จะอาศัยการค้นหา header ของประเภทของไฟล์ที่ต้องการหา ไม่ว่าจะเป็นไฟล์รูปภาพ (.gif, .jpg, .png) ไฟล์เสียง (.mp3, .wav) หรือไฟล์วีดีโอต่างๆ (.avi) โดยหลังจากที่เจอ header ของไฟล์ดังกล่าวแล้ว ก็จะ extract ไฟล์ต่างๆออกมาตามข้อมูลที่ได้จาก header ไฟล์ครับ

โปรแกรมที่ใช้สำหรับทำ data carving คราวนี้คือ foremost ครับ เป็นโปรแกรมฟรีรันบน Linux ดาวน์โหลดมา compile แล้วรันได้ทันทีเลยครับ ตามภาพ



สำหรับ image ที่ support โดย foremost นั้นมี image ที่ได้จาก dd ครับ แต่ image ที่ผมได้มานี่ใช้ซอฟต์แวร์ตัวอื่นที่ไม่ใช่ dd ทำ image เอา แต่ก็สามารถอ่านได้เหมือนกัน สำหรับเวลาที่ใช้ในการรันนั้นถือว่าเร็วมากครับ image ขนาด 1GB ใช้เวลาไม่ถึง 10 นาที ซึ่งถ้าเปรียบเทียบกับซอฟต์แวร์กู้ข้อมูลซึ่งใช้เวลาชาติกว่า ถือว่า work มากๆครับ (ผมไม่ได้เทสซอฟต์แวร์กู้ข้อมูลนะครับ เลยไม่ทราบว่าเจ้าของโจทย์ใช้ตัวไหน แต่บอกมาว่าช้ามากๆ)

เมื่อ foremost รันเสร็จก็จะสรุปผลให้ครับว่าเจอไฟล์ประเภทใดบ้าง จำนวนกี่ไฟล์



โดยไฟล์ที่ foremost เจอจะถูกสร้างไว้ที่โฟลเดอร์ชื่อ output ครับดังภาพ



เข้าไปเลือกดูตามใจชอบเลยครับ ข้อเสียอย่างเดียวของ foremost คือยังไม่ support ไฟล์ประเภท mp3, เละไฟล์ประเภทใหม่ๆบนโทรศัพท์มือถือครับ จบ.

การอ่าน ext2/ext3 file system บน Windows

คงมีหลายครั้งที่เวลาทำ forensics เราต้องประสบกับปัญหาเรื่อง compatibility ของ file system ของระบบที่ต่างกัน เช่น อุปกรณ์เก็บข้อมูลต่างๆของเราถูก format เป็น NTFS แต่ ระบบที่เราใช้อ่าน/เขียนข้อมูลลงไปในอุปกรณ์กลับเป็น Linux ซึ่งมีเพียงไม่กี่ตัวเท่านั้นที่สนับสนุนความสามารถในการเขียน NTFS ได้แบบ default ส่วนที่เหลือต้อง compile kernel เอง หรือถ้าเรา format อุปกรณ์เก็บข้อมูลเป็น ext2/ext3 ซึ่ง Linux สามารถอ่านเขียนได้ เราจะพบปัญหาอีกว่า Windows ไม่สามารถมองเห็นได้เลย ถ้าเราใช้ Windows เปิดอุปกรณ์ที่ format เป็นแบบ ext2/ext3 เราจะพบความเอ๋อๆดังภาพ



แน่นอน เราไม่สามารถ format ได้ เพราะข้อมูลจะหายหมด - -" ... แล้วมันมีวิธีไหนบ้างหว่าที่สามารถทำให้ Windows อ่าน ext2/ext3 ได้ ?

คำตอบคือมีหลายวิธีเลยครับ ไล่ตั้งแต่ติดตั้ง driver ซึ่งทำขึ้นมาเพื่อ support ext2/ext3 โดยเฉพาะ จนถึง application ที่ support การอ่าน ext2/ext3 ในตัวเลย ใน entry นี้ผมจะกล่าวถึงตัวหลังนะครับ เพราะตัวแอพพลิเคชั่นที่ผมจะกล่าวถึงต่อไปนี้สามารถใช้อ่านและ copy ได้อย่างเดียวครับ ไม่สามารถเขียนได้ ซึ่งหลายๆคนอาจจะไม่ีสะดวก แต่สำหรับการทำ forensics ถือว่ามีประโยชน์ครับเพราะมีส่วนช่วยป้องกันทำการเขียนทับข้อมูล evidence ที่เราเก็บมาจากระบบครับ ถ้าใครอยากให้สามารถทั้งอ่านและเขียนได้เลย ผมแนะนำว่าใช้ตัวนี้ดีกว่าครับที่ fs-driver.org

สำหรับตัวที่ผมใช้ชื่อว่า linux-reader ครับ หน้าตานี่เหมือน Windows Explorer เลยครับ



Linux-Reader จะแบ่งมุมมองออกเป็น 3 ส่วนครับ คือ harddisk ที่มีในระบบ, removeable disk และ physical disk จริงๆที่มีอยู่ในระบบ โดย Linux-Reader จะไม่สามารถเข้าไปอ่านพื้นที่ที่เป็น NTFS ได้ หากเราใช้ Linux Reader เข้าไปอ่าน มันจะฟ้องดังภาพ



ส่วนอุปกรณ์ที่เป็น ext2/ext3 นั้นมันจะขึ้น label ว่า Linux Native Volume (ดูภาพข้างบนนู้นประกอบ) และเมื่อเรียกเข้าไปดูจะเป็นดังภาพครับ



เราสามารถนำไฟล์ดังกล่าวออกมาใช้งาน/ตรวจสอบได้ครับ นอกจากนี้แล้วเจ้า Linux-Reader นี้ยังมีความสามารถในการ mount image ของ linux ที่สร้างขึ้นจาก dd ได้อีกด้วย ลองไปเล่นดูนะครับ

P.S. การนำไฟล์จาก Linux-Reader ไปใช้ ให้ click ขวาที่ไฟล์/โฟลเดอร์และเลือก save ครับ

การ repair ไฟล์ Event Log ของระบบปฏิบัติการ Windows ที่ Corrupted

สวัสดีครับ ไม่ได้อัพนาน ล็อกอินเข้ามาเจอคำถามค้างไว้เป็นเดือนๆเลย - -" ตอบให้แล้วนะครับ อย่าถือโทษโกรธกันเลยนะครับ ^_^

มานั่นไล่ดู ผ่านมาครึ่งปีถ้าไม่นับ entry นี้นี่ปี 2008 เพิ่งโพสไป entry เดียวเอง ทำไมเราช่างขี้เกียจอย่างนี้ ว่าแล้วก็เลยสวมบทมนุษย์ active ซะหน่อย เดี๋ยวสมองจะสนิมขึ้น หาเรื่องมาโพสต์ให้ครับ โดยวันนร้จะโพสต์เกี่ยวกับเรื่อง Event Log ของระบบปฏิบัติการ Windows ครับ

Event Log ก็คือล็อคไฟล์ของระบบปฏิบัติการ Windows ครับ เป็นไฟล์ที่ลงท้ายด้วย .Evt จะอยู่ที่ C:\WINDOWS\system32\config โดยปกติแล้วจะมีทั้งหมด 3 ไฟล์ครับคือ AppEvent.Evt, SecEvent.Evt และ SysEvent.Evt ซึ่งก็คือล็อคไฟล์ของ Application, Security และ System ของระบบปฏิบัติการ Windows ตามลำดับครับ (อาจมีไฟล์อื่นๆอีกตามแอพพลิเคชั่นที่ติดตั้งลงบนเครื่องครับ แต่ตัวหลักจะเป็นสามตัวนี้) หากใครทำ forensics หรือ incident handling/response บน Windows บ่อยๆ ก็คงเคยเจออาการที่ว่า Event Log ที่ copy ออกมานั้นเปิดด้วย Event Viewer ไม่ได้ อาการเอ๋อๆดังภาพข้างล่างใช่มั้ยครับ ^_^



อาการที่ปรากฏในภาพคือ ไฟล์ evt ทั้งหลายที่เรา copy มามัน corrupted ครับ - -" สาเหตุนั้นเกิดจากเราไม่ได้หยุด services ที่เก็บ Log ของ Windows ครับ ชื่อว่า EventLog ครับ เหตุการณ์เอ๋อๆของไฟล์ .Evt นี้นี่นับว่าเป็นเหตุการณ์ปกติมากครับ โดยเฉพาะอย่างยิ่งหากนำไฟล์ .Evt ที่ได้จากการ image harddisk มาใช้ครับ ซึ่งหากว่าคนที่ทำ forensics ไม่ได้ตรวจสอบและนำไฟล์เหล่านี้ไป feed ให้โปรแกรมพวก Log Analyzer ต่างๆแล้วล่ะก้อ.... ขึ้นอยู่กับดวงล่ะครับ ว่า Log Analyzer ตัวนั้นมันเก่งขนาดไหน

คำถาม: แล้วจะแก้ไขยังไงดี ?

สาเหตุที่ไฟล์ corrupted เพราะ header ไฟล์ของ Event Viewer มันเน่าครับ ถ้าอยากทราบว่าทำไมเน่าให้ไปอ่าน paper ของ Rich Murphey ครับ บรรยายไว้ละเอียดเหมือนกัน แต่...เราไม่ต้องใช้ hex edit เปิดแก้ header ครับ มีวิชามารที่สบายกว่านั้น ใช้โปรแกรมที่ชื่อว่า FixEvt ครับ Rich Murphey เขียนไว้แล้ว เป็น command line ครับ แค่พิมพ์สั้นๆว่า

C:\Documents and Settings\trirat\Desktop\Corrupted.Event.Log>fixevt.exe *.Evt
Repaired: AppEvent.Evt
Repaired: SecEvent.Evt
Repaired: SysEvent.Evt

ถ้าขึ้นว่า Repaired ข้างหน้าชื่อไฟล์ .Evt แสดงว่าซ่อมได้ครับ ;)

จบ...

ว่าด้วยเรื่องของ Slack Space

พอดีมีคนอยากรู้คำศัพท์ที่เกี่ยวข้องกับ forensics ครับ สัญญาไว้แล้ว เลยก่ะว่าทยอยๆเขียนลง blog ซะเลย วันนี้เลยเริ่มที่คำนี้ครับ "Slack Space"

...แต่เพื่อให้สามารถเข้าใจคำว่า Slack Space มากขึ้น จะขออธิบายเกี่ยวกับลักษณะการเก็บข้อมูลของฮาร์ดดิสก์ก่อนนะครับ เพราะคำว่า Slack Space นี้เกี่ยวข้องกับฮาร์ดดิสก์โดยตรงครับ :)

โดยปกติแล้วลักษณะรูปทรงของฮาร์ดดิสก์นั้นจะเป็นแผ่นวงกลมซ้อนกันหลายๆแผ่น ซึ่งในแต่ละวงกลมนั้นจะถูกแบ่งออกเป็นชั้นๆเรียกว่า Track ดังรูป



โดยปกติแล้วในแต่ละวงจะมีจำนวน Track อยู่ทั้งหมด 1024 tracks โดย Track แรกสุดหรือที่เรียกกันว่า Track 0 นั้นจะเป็น Track ที่อยู่ด้านนอกสุดของวงกลม ถัดเข้ามาจะเป็น Track 1, 2, 3, ... ตามลำดับ

ในแต่ละ Track นั้นจะถูกแบ่งย่อยออกเป็นส่วนย่อยเล็กลงไปอีก เรียกว่า Sector ดังรูป



Sector เรียกได้ว่าเป็นหน่วยที่เล็กที่สุดของฮาร์ดดิสก์ก็ว่าได้ โดยปกติแล้วมีขนาด 512 bytes ครับ

Sector หลายๆอันที่อยู่ติดกันและระบบปฏิบัติการนำไปใช้สำหรับเก็บข้อมูลจะถูกเรียกว่า์ Cluster ดังรูป



เออ... แล้วที่พูดมานี่มันเกี่ยวอะไรกับ Slack Space เหรอ ??? เกี่ยวครับ :) เพราะ Slack Space คือพื้นที่ว่างส่วนที่เหลือของ Cluster หลังจากใช้ในการเก็บข้อมูลครับ ดังภาพ



เรามาดูตัวอย่างง่ายๆเทียบกับรูปข้างบนกันดีกว่า ให้ไฟล์ที่ต้องการเก็บมีขนาด 1200 bytes และกำหนดให้ระบบปฏิบัติการมีขนาดของ Cluster คือ 2048 bytes (เท่ากับ 4 sectors นั่นเอง) จะได้ว่า ไฟล์ที่เก็บลงไปในนั้นจะใช้พื้นที่ไป 1200 bytes ซึ่งกินที่ไป 2 sectors กว่า และเหลือพื้นที่อีก 848 bytes ซึ่งพื้นที่ส่วนที่เหลือนี้โดยปกติแล้วระบบปฏิบัติการจะไม่นำไปใช้งานในการเก็บไฟล์อื่นๆ้อีก

แล้วมันเกี่ยวยังไงกับ forensics หว่า ??? เกี่ยวตรงที่ผู้บุกรุกที่มีทักษะสูงขึ้นมาหน่อย มักนำไฟล์ต่างๆของตนเองไปเก็บไว้ที่ Slack Space น่ะสิ (สามารถทำได้โดยใช้โปรแกรมที่เขียนขึ้นมาเพื่องานนี้โดยเฉพาะ) ข้อดีของการซ่อนไฟล์ไว้ใน Slack Space คือไม่เป็นที่สะดุดตา และสามารถตรวจสอบได้ยากครับ

ยังกับบรรยายให้เด็กๆฟังเรื่องฮาร์ดดิสก์เลยแฮะ์

เออ...ขอจบแบบห้วนๆละกัน ช่วงนี้มีอาการนอย T-T

USB forensics ตอนที่ 2: จะรู้ได้ยังไงว่าเวลาไหนคือเวลาล่าสุดที่เสียบ USB thumb drive เข้าเครื่อง

ช่วงนี้หมกมุ่นอยู่กับ USB ก็เลยกลายเป็น series ที่เกี่ยวกับ USB ไปซะงั้น post เมื่อคราวก่อนเลยกลายเป็น USB forensics ตอนที่ 1 ไปซะงั้น สำหรับในตอนที่ 2 นี้จะกล่าวถึงการดูเวลาครั้งสุดท้ายที่ USB thumb drive ถูกเสียบเข้าเครื่องคอมพิวเตอร์ที่ต้องสงสัย ซึ่งจะใช้ข้อมูลจากในตอนที่ 1 พอสมควรดังนั้นถ้าคราวนี้แล้วยังมึนๆก้อกลับไปอ่านให้เข้าใจก่อนนะครับ จะได้มึนน้อยลง

ในตอนนี้เราจะใช้ USB thumb drive คือ Kingmax USB Flash Disk Rev 2.00 ซึ่งมี serial number คือ EC5543658C8B00EA&0 หรือ EC5543658C8B00EA ถ้าดูใน UVCView ให้เราเข้าไปที่ registry key ที่เกี่ยวข้องกับอุปกรณ์ USB ดังกล่าวคือ

HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR\
Disk&Ven_KINGMAX&Prod_USB_Flash_Disk&Rev_2.00\
EC5543658C8B00EA&0


จะปรากฏข้อมูลต่างๆที่เกี่ยวข้องกับอุปกรณ์ตรงด้านขวามือดังภาพ



ข้อมูลที่เราสนใจคือ ParentIdPrefix ซึ่งในที่นี้คือ 7&24e36f51&0 เด๋วจะได้อธิบายต่อไปว่าใช้ทำอะไรได้

การดูเวลาครั้งสุดท้ายที่ USB thumb drive ถูกเสียบเข้าเครื่องนั้นเราจะอาศัยการดู Last Write Time ของ registry key ที่เคยกล่าวไว้ใน post แรกของ blog นี้เลยครับ :) ให้เข้าไปที่ registry key ดังต่อไปนี้

HKLM\SYSTEM\CurrentControlSet\Control\DeviceClasses\

และเข้าไปยัง subkey ทั้งสองอันนี้ครับ

{53f56307-b6bf-11d0-94f2-00a0c91efb8b}

{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}

registry ดังกล่าวจะเกี่ยวข้องกับอุปกรณ์ disk และ volume ตามลำดับครับซึ่ง USB thumb drive ของเราเข้าข่ายพอดี

มาดูที่ {53f56307-b6bf-11d0-94f2-00a0c91efb8b} ก่อนครับ เมื่อคลิกเข้าไปจะเห็นเป็นดังภาพ



รูปแบบชื่อของแต่ละ sub key เป็นดังนี้

##?#Device#Disk#Ven_VendorName&Prod_ProductName&Rev_Revision#Serial Number#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}

Device ที่เราสนใจในที่นี้คือ USBSTOR ครับ และเมื่อนำมารวมกับข้อมูลของ USB thumb drive ของเราคือ Kingmax USB Flash Disk Rev 2.00 ซึ่งมี serial number คือ EC5543658C8B00EA&0 ก็จะได้ว่า subkey ที่เราต้องการดู Last Write Time คือ

##?#USBSTOR#Disk&Ven_KINGMAX&Prod_USB_Flash_Disk&Rev_2.00#EC5543658C8B00EA&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}

เมื่อดู Last Write Time พบว่าเป็นดังข้างล่าง

Last Write Time: 12/12/2007 - 10:37 AM
Value 0
Name: DeviceInstance
Type: REG_SZ
Data: USBSTOR\Disk&Ven_KINGMAX&Prod_USB_Flash_Disk&Rev_2.00\EC5543658C8B00EA&0

วันที่ 12 ธันวาคม 2007 เวลา 10.37 น. คือเวลาครั้งสุดท้ายที่เสียบ USB thumb drive เข้าไปยังเครื่องที่ทำการตรวจสอบ ไม่ยากเลยชิมิ :)

อ้าว....แล้วไอ้เจ้า ParentIdPrefix เอาไปทำอะไรหว่า ??? เจ้าค่าตัวนี้จะเอาไปใช้งานกับ sub key {53f5630d-b6bf-11d0-94f2-00a0c91efb8b} อีกอันครับ โดยที่เมื่อเี่ราคลิ๊กไปที่ sub key ดังกล่าวจะเห็นเป็นดังภาพ



รูปแบบของชื่อใน sub key นี้ค่อนข้างจะดูมึนๆเล็กน้อย แต่ sub key ที่เราสนใจนั้นจะมี ParentIdPrefix ของ USB thumb drive ที่เราสนใจปรากฏอยู่ครับ ซึ่งในที่นี้คือ 7&24e36f51&0 เมื่อเราทำการค้นหา sub key ที่มี ParentIdPrefix ซึ่งจะได้ sub key ชื่อ

##?#STORAGE#RemovableMedia#7&24e36f51&0&RM#{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}

เมื่อดู Last Write Time ของ sub key ดังกล่าวพบว่าผลลัพธ์เป็นดังข้างล่าง

Last Write Time: 12/12/2007 - 10:37 AM
Value 0
Name: DeviceInstance
Type: REG_SZ
Data: STORAGE\RemovableMedia\7&24e36f51&0&RM

เป็นวันที่ 12 ธันวาคม 2007 เวลา 10.37 น. เหมือนกันครับ ตรงกับอันแรกที่เราได้มา เราสามารถใช้ค่า Last Write Time ของ sub key ทั้งสองอันในการ cross checkได้ครับ

จะรู้ได้อย่างไร ว่าเครื่องเราเสียบ USB thumb drive อะไรไปบ้าง

หลังจากที่พักร้อนยาวไปตามหาหัวใจตัวเอง (น้ำเน่าๆ แหะๆ) วันนี้ก้อได้เวลากลับมาทำงานอีกครั้ง ว่าจะทำเขียนเรื่องเกี่ยวกับ Windows Memory Analysis ต่อ แต่มันตันๆยังไงไม่รู้ ก็เลยเปลี่ยนมาเรื่องเบาๆบ้างดีกว่า โดยเรื่องที่จะเอามายำวันนี้เกี่ยวกับ USB forensics โดยจะเป็นการตรวจสอบว่าเครื่องที่เราสงสัยได้เสียบ USB thumb drive ใดไปบ้าง

พระเอกของเราในตอนนี้คือ registry key ครับ (แน่นอน วิธีการนี้ใช้ได้แต่ระบบปฏิบัติการ Windows เท่านั้นแหะๆ) โดย registry key ที่เราสนใจสำหรับการตรวจสอบคือ

HKLM\System\CurrentControlSet\Enum\USBSTOR

โดยภายใต้ key ดังกล่าวจะเป็นรายชื่อและรุ่นของอุปกรณ์ USB ที่เชื่อมต่อเข้ากับคอมพิวเตอร์ที่ทำการตรวจสอบดังภาพ



โดยรูปแบบของชื่ออุปกรณ์เป็นดังข้างล่างนี้

Type&Ven_VendorName&Prod_ProductName&Rev_Revision

โดย Type นั้นเป็นประเภทของอุปกรณ์ ถ้าเป็น USB thumb drive นั้น Type จะเป็น Disk แต่ถ้าเป็น CD-ROM Type จะเป็น CdRom

VendorName เป็นชื่อของผู้ผลิตของอุปกรณ์ดังกล่าว

ProductName เป็นชื่อรุ่นของอุปกรณ์ดังกล่าว

Revision เป็นการ revision ของอุปกรณ์ในรุ่นนั้นๆ

ดังนั้น Disk&Ven_Kingston&Prod_DataTraveler_2.0&Rev_1.00 จึงสามารถแปลงข้อมูลได้เป็น

อุปกรณ์: USB Thumb drive (Disk)

ผู้ผลิต: Kingston

รุ่น: Data Traveler 2.0

Revision: 1.00

ไม่ยากเลยชิมิ :)

แต่ยัง... ยังไม่จบ เพราะว่าตอนนี้เราเพิ่งรู้แค่ว่า USB รุ่นอะไรที่เสียบเข้ามาที่เครื่องคอมพิวเตอร์เท่านั้น แต่เราไม่รู้ว่าเป็น USB อันไหน ซึ่งการที่เราจะสามารถระบุ USB thumb drive แบบเจาะจงลงไปนั้น เราจะต้องใช้หมายเลข serial number ของอุปกรณ์ในการระบุครับ โดยหมายเลข serial number ของอุปกรณ์ USB ที่เสีบเข้าเครื่องนั้นสามารถดูได้จาก sub key ของ registry ของอปุกรณ์ที่เราสนใจดังภาพ



ที่วงไว้ตรงสีแดงคือ serial number ของอุปกรณ์ครับ โดย serial ของ USB thumb drive Kingston Data Traveler ที่เราทำการตรวจสอบไปในตัวอย่างแรกนั้นคือ 135000000000001357924712&0 ซึ่ง serial number ดังกล่าวจะไม่มีการซ้ำกับอุปกรณ์ชิ้นอื่นถึงแม้ว่าเป็นรุ่นเดียวกัน (กล่าวคือ USB thumb drive Kingston Data Traveler 2 อันถึงแม้จะเป็นรุ่นเดียวกัน แต่จะมี serial number ที่ต่างกัน) นอกจากนี้ถึงแม้จะนำไปเสียบที่ต่างเครื่องกันก็จะขึ้นเป็นเลขเดียวกันด้วย

อีกวิธีการหนึ่งที่สะดวกสำหรับระบุว่าอุปกรณ์ USB นี้มีหมายเลข serial คืออะไรโดยเราโปรแกรมชื่อว่า UVCView ครับ ซึ่งตัวอย่างของการใช้โปรแกรมเป็นดังภาพ



จากภาพตำแหน่งที่วงสีแดงๆคือ serial number ของอุปกรณ์ USB ซึ่งในที่นี้คือ Kingmax USB Flash Disk Rev 2.00 นั่นเอง

อย่างไรก็ตามก็มีข้อควรระวังสำหรับการตรวจสอบคือ

1. การตรวจสอบนี้อาศัยข้อมูลจาก registry key ซึ่งสามารถเปลี่ยนแปลงและแก้ไขได้ ซึ่งผู้กระทำความผิดอาจแก้ไขข้อมูลตรงจุดดังกล่าวเพื่อทำลายหลักฐานได้
2. ถึงแม้อุปกรณ์ USB ส่วนมากจะมี serial number ที่แตกต่างกับในแต่ละชิ้นระบุไว้ ก็ยังมีอีกอุปกรณ์ USB อีกจำนวนมากที่ไม่มี serial number ซึ่งอุปกรณ์ที่ไม่มี serial number นั้น ระบบปฏิบัติการ Windows จะทำการสร้าง serial number ให้เอง ซึ่ง serial number ดังกล่าวไม่สามารถนำไประบุอุปกรณ์ที่ต้องสงสัยได้ ตัวอย่างของ serial number ที่ไม่สามารถนำไปใช้ได้คือ serial ที่มีเครื่องหมาย & อยู่เป็นลำดับที่สอง ยกตัวอย่างเช่น 6&355c3fd8&0
   

จบแหละ เด๋วนี้ขี้เกียจหาคำลงท้ายน่ะ แหะๆ

การเปลี่ยน Virtual Address เป็น Physical Address ของระบบปฏิบัติการ Windows

มีหลายคนถามว่าทำไมช่วงนี้อัพบ่อยจัง เหตุผลก็คือช่วงนี้มันว่างครับ หลังจากที่ยุ่งวุ่นวายอยู่หลายเดือน มาว่างช่วงปลายปีก็ดีเหมือนกันนะ ชิวดี มีความสุข

หลังจากที่ได้เขียน lsproc จนสามารถทำงานกับ Windows 2000, xp และ 2003 ไปแล้วนั้น ก็เลยมีความคิดที่จะเขียนโปรแกรมอันใหม่ให้มันทำอะไรได้มากกว่านั้น เหมือนๆกับ lspd ของ Harlan Carvey (ความจริงคือจะเอา lspd มาดัดแปลงให้ทำงานกับหลายๆระบบปฏิบัติการได้นั่นแหละ แหะๆ) แต่หลังจากที่ไล่ดูโค้ดแล้วก็รู้สึกว่ามี concept บางอย่างที่จำเป็นที่จะต้องทำความเข้าใจก่อนที่จะลงไปในระดับลึก concept ที่ว่าคือการเปลี่ยน virtual address เป็น physical address นั่นเอง

ในการเปลี่ยน virtual address เป็น physical address นั้น สิ่งที่จำเป็นจะต้องทราบมีอยู่ดังต่อไปนี้

1. virtual address ที่เราต้องการเปลี่ยนเป็น physical address
2. Page Directory Base ซึ่งเราสามารถหาได้จากตำแหน่งที่ 0x18 จากตำแหน่งเริ่มต้นของ EPROCESS ีซึ่งค่านี้คงที่สำหรับระบบปฏิบัติการ Windows 2000 SP4 จนถึง Windows Vista เลยทีเดียว
   

เมื่อทราบค่าทั้ง 2 ค่าแล้ว ขั้นตอนในการเปลี่ยนค่ามีดังต่อไปนี้

• ทำการแบ่ง virtual address ซึ่งมีขนาด 32 bits ออกเป็นสามส่วนด้วยกันคือ bit 1 - 12 ทำหน้าที่เป็น byte index, bit ที่ 13 -22 ทำหน้าที่เป็น page table index และ bit ที่ 23 - 32 ทำหน้าที่เป็น page directory index

• นำค่า page directory base (pdb) และ page directory index (pdi) มาคำนวนหาตำแหน่งของ page table โดยใช้สูตร: pdb + (pdi * 4) = ตำแหน่งของ page table ใน physical memory
  

• อ่านค่า page table ใน physical memory จากนั้นทำการตรวจสอบ bit ที่ 1 (present bit) ว่าเป็น 1 หรือไม่ การที่ present bit เป็น 1 หมายถึง page นั้นยังอยู่ใน memory

• ทำการคำนวนค่า page table base (ptb) ได้จาก สูตร: ptb = (page table >> 12) * 0x1000

• ทำการคำนวนหาค่าตำแหน่งของ page table entry ใน Physical Memory โดยใช้สูตร: ptb + (pti * 4) = ตำแหน่งของ page table entry
  

• อ่านค่า page table entry ใน physical memory จากนั้นทำการตรวจสอบ bit ที่ 1 (present bit) ว่าเป็น 1 หรือไม่ การที่ present bit เป็น 1 หมายถึง page นั้นยังอยู่ใน memory

• ทำการคำนวนค่า page base address (pba) ได้จากสูตร pba = (page table entry >> 12) * 0x1000
  

• ทำการคำนวน physical address ได้จากสูตร pba + byte index
  

งงล่ะสิ งงเหมือนกัน แหะๆ ตัวหนังสือพรืดๆอ่านแล้วคงมีน้อยคนที่เข้าใจทันที ดังนั้นตามสไตล์ครับ ปิดท้ายด้วยผังคร่าวๆในการเปลี่ยนจาก virtual address เป็น physical address ครับ ;)

lsproc สำหรับระบบปฏิบัติการ Windows 2003 Server SP0

ว่างๆเสาร์อาทิตย์ก็เลยไปนั่งเขียน lsproc สำหรับระบบปฏิบัติการ Windows 2003 Server SP0 มา เสร็จแล้ววันนี้ก็เลยเอามาทดสอบเลย ผลที่ได้เป็นดังภาพ



ใช้ได้ๆ เด๋วต่อไปจะเอา lsproc ทั้ง 3 เวอร์ชั่นมารวมกัน แล้วจะใส่ automatic operating system detection เข้าไปด้วยครับ :)

การเก็บ physical memory image ด้วย dd และ netcat (#2)

เมื่อคราวก่อนนู้น ผมได้กล่าวถึงการทำ image ของ physical memory โดยใช้ Helix Live CD ไปแล้ว ซึ่งในตอนนั้นใช้วิธีการย้าย image ไปไว้ที่ share ของเครื่องอื่น วิธีการนี้นั้นจะทำให้เครื่่องคอมพิวเตอร์ที่ทำการตรวจสอบมี connection เพิ่มขึ้นมาอีกอันหนึ่ง ดังนั้นผู้ที่ทำการตรวจสอบจะต้องทำการบันทึกผลกระทบนี้ลงไปในรายงานด้วย

การใช้ Helix มีข้อดีคือสะดวก ไม่ต้องพิมพ์คำสั่งที่ซับซ้อน แต่ข้อเสียคือการใช้งาน Helix นั้นจะทำให้ helix.exe ถูกโหลดเข้าไปในหน่วยความจำด้วย (นอกเหนือจากโปรเซสที่จำเป็นเช่น dd) ซึ่งอาจจะไปทับข้อมูลของโปรเซสที่จบการทำงานไปแล้ว แต่มีความสำคัญก็เป็นได้ (helix.exe เป็น GUI ดังนั้นพื้นที่ในการใช้งานในหน่วยความจำย่อมมีขนาดใหญ่กว่าโปรแกรมแบบ command line ธรรมดา)

ดังนั้นวันนี้ก็เลยจะนำเสนออีกวิธีการหนึ่งในการทำ physical memory image และย้ายไปไว้ในเครื่องอื่นโดยอัตโนมัติโดยใช้ dd และ netcat เพียงแค่สองโปรแกรมเท่านั้น วิธีการนี้ทำให้เราไม่ต้องโหลด helix.exe เข้าสู้หน่วยความจำ และไม่ต้องสร้าง connection สำหรับนำไฟล์ไปไว้ใน share เครื่องอื่น แต่จะสร้าง connection ระหว่าง netcat ของเครื่องที่เราต้องการเก็บ image กับเครื่องปลายทาง

ในขั้นตอนแรก ให้เรารันคำสั่งต่อไปนี้บนเครื่องที่จะย้ายไฟล์ image มาเก็บไว้
nc.exe -l -p 8000 | dd.exe of=image-xpsp2.dd

คำสั่งดังกล่าวเป็นการบอกให้เครื่องคอมพิวเตอร์ที่เราต้องการย้ายไฟล์มาเปิด port หมายเลข 8000 เพื่อรอรับ connection เมื่อมี connection เข้ามาจะทำการส่งต่อข้อมูลไปยังโปรแกรม dd เพื่อทำการเขียนไฟล์ image-xpsp2.dd ซึ่งเป็นไฟล์ image ที่เราต้องการ

ในขั้นต่อมา ให้เรารันคำสั่้งต่อไปนี้บนเครื่องที่เราต้องการทำ physical memory image

dd.exe if=\\.\PhysicalMemory bs=4096 conv=noerror | nc.exe remote-address 8000

คำสั่งดังกล่าวเป็นการรัน dd เพื่อเก็บ image จากเครื่องที่เราต้องการตรวจสอบ จากนั้น netcat จะทำการส่งต่อข้อมูลไปยังเครื่อง remote-address ที่ port หมายเลข 8000 อีกทีหนึ่ง

หลังจากที่ได้ image มาแล้วก็ลองมาทำการทดสอบว่า lsproc-xpsp2 ที่เขียนขึ้นมาสามารถ parsing เพื่อเรียกดูข้อมูลได้หรือไม่



lsproc-xpsp2 ก็ยังสามารถอ่าน image ที่เก็บด้วยวิธีการนี้เช่นกัน :)

lsproc สำหรับระบบปฏิบัติการ Windows XP SP2

หลังจากที่วันก่อนได้ใช้ lsproc ทำการอ่านข้อมูลของ physical memory image ของระบบปฏิบัติการ Windows 2000 Server SP4 ไปแล้ว ในวันนี้เราจะมาดู physical memory image ของระบบปฏิบัติการ Windows XP SP2 กัน

ดังที่ทราบกันดีว่า lsproc ซึ่งพัฒนาขึ้นโดย Harlan Carvey นั้นสามารถอ่าน image ของระบบปฏิบัติการ Windows 2000 SP4 เท่านั้น (เนื่องจากมันเป็น PoC ซึ่งคาดว่าขี้เกียจเขียนให้มัน support image ที่ได้จากระบบปฏิบัติการรุ่นอื่นๆ ให้รู้ว่ามันทำได้เป็นพอ) ดังนั้นด้วยความที่ช่วงนี้ว่างงาน จึงได้หยิบเอาเจ้า lsproc มาทำการตัดแปลงใหม่ให้สามารถอ่าน physical memory image ของ Windows XP SP2 ได้โดยตั้งชื่อเป็น lsproc-xpsp2

ผลที่ได้จากการอ่าน physical memory image ของระบบปฏิิบัติการ Windows XP SP2 ด้วย lsproc-xpsp2 เป็นดังภาพข้างล่าง



:) ดูดีทีเดียวแหละ จากการทดสอบหลายๆครั้งพบว่ายังไม่มีข้อผิดพลาดขึ้นในการทำงาน ซึ่งเด๋วจะให้ชาวบ้านช่วยทดสอบอีกทีหนึ่ง

วกกลับมาดูที่ผลลัพธ์กันนิดนึง สังเกตว่าจะเห็นโปรเซสของ dd.exe ซึ่งมีเครื่องหมาย (x) อยู่ประมาณ 3 - 4 โปรเซส (เป็นโปรเซสที่จบการทำงานไปแล้ว) ซึ่งสาเหตุเนื่องมาจากผมพิมพ์ syntax ผิดตอนเก็บ image ครับ - -" เลยทำให้ content ของ physical memory image นี่มีโปรเซสของ dd.exe ปนอยู่กระจายเต็มไปหมด

หลังจากที่ดูประสิทธิภาพการทำงานของ lsproc-xpsp2 ไปแล้ว เรามาดูกันสักหน่อยดีกว่าว่า lsproc-xpsp2 มีอะไรแตกต่างกับ lsproc จึงสามารถอ่าน physical memory image ของ Windows XP SP2 ได้ (ลืมบอกไปว่า lsproc-xpsp2 อ่าน image ของ Windows 2000 SP4 ไม่ได้นะครับ แหะๆ แต่ในอนาคตจะ merge รวมกับ lsproc แต่คงต้องขออนุญาตเจ้าของก่อน)

lsproc-xpsp2 แตกต่างจาก lsproc ดังนี้

• offset ของข้อมูลต่างๆในโครงสร้างข้อมูล EPROCESS และ ETHREAD ซึ่งสามารถดูข้อมูลสรุปได้จาก blog ของ Andreas Schuster ซึ่งเป็นหนึ่งในบุคคลแรกๆที่ทำเกี่ยวกับเรื่อง memory analysis และเป็นคนเขียนโปรแกรม PTFinder ครับซึ่งเป็นโปรแกรมทำงานใกล้เคียงกับ lsproc ครับ
  
• โครงสร้างข้อมูลของ EPROCESS และ ETHREAD ของ Windows 2000 SP4 และ Windows XP SP2 มีการเปลี่ยนแปลงในบางส่วนครับ (เอ๊ะ สองข้อนี้มันเขียนรวมกันได้นี่หว่า - -" แหะๆ)
  

จบแหล้ว ห้วนๆนี่แหละ

การอ่านข้อมูล image ของ physical memory (RAM) เพื่อทำการค้นหาว่า ณ เวลาที่เก็บข้อมูลมีโปรเซสใดรันอยู่บ้าง

หลังจากที่ได้กล่าวถึงการ dump ข้อมูลจาก Physical Memory มาในคราวที่แล้ว วันนี้จะกล่าวถึงเรื่องการนำข้อมูลของ RAM ที่ได้มาไปทำการวิเคราะห์ โดยจะดูว่า ณ เวลาที่ทำการเก็บข้อมูลนั้นมีโปรเซสใดรันอยู่บ้าง

หมายเหตุ: ซอฟต์แวร์และวิธีการที่ใช้วิเคราะห์ที่จะกล่าวต่อไปนี้นั้น สามารถวิเคราะห์ RAM ที่ได้จากระบบปฎิบัติการ Windows เท่านั้น ไม่สามารถวิเคราะห์ข้อมูล RAM ของระบบปฏิบัติการ Linux ได้ เนื่องจากโครงสร้างในการเก็บข้อมูลนั้นต่างกัน

แล้วเราจะวิเคราะห์ยังไง ?? ก่อนที่จะไปดูวิธีการ เราจะไปดูกันก่อนว่ามีโปรแกรมใดบ้างที่ช่วยในการวิเคราะห์...

โปรแกรมที่ช่วยในการวิเคราะห์นี้มีชื่อว่า lsproc ซึ่งเขียนโดย Harlan Carvey โดย lsproc นั้นจะทำการอ่าน image ที่เราได้จาก RAM แล้วทำการค้นหาโครงสร้างข้อมูลต่างๆ (data structure) และทำการแสดงข้อมูลออกมาเป็นดังภาพข้างล่าง

หมายเหตุ: ข้อมูลจาก RAM ที่นำมาวิเคราะห์นี้ได้จากระบบปฏิบัติการ Windows 2000 Server SP4



จากภาพ lsproc จะทำการแสดง หมายเลขโปรเซส (PID), หมายเลขโปรเซสที่ทำให้เกิดโปรเซสนั้น (PPID) ชื่อของโปรเซส, ตำแหน่งที่อยู่ใน Physical memory (offset) และเวลาที่โปรเซสถูกสร้างขึ้น สังเกตว่าผลลัพธ์ที่ได้มานั้นมีโปรเซสของ dd (PID หมายเลข 216) และโปรเซสของ helix (PID หมายเลข 404) ที่เราใช้ในการเก็บข้อมูลของ physical memory รวมอยู่ด้วย นอกจากนี้ lsproc ยังสามารถดึงรายชื่อของโปรเซสที่จบการทำงานไปแล้วขึ้นมาแสดงได้ หากข้อมูลของโปรเซสดังกล่าวที่อยู่ใน RAM ยังไม่ถูกเขียนทับโดยโปรเซสอื่นๆ โปรเซสที่จบการทำงานไปแล้วนั้นข้างหลังชื่อของโปรเซสจะมีเครื่องหมาย (x) อยู่ ซึ่งในที่นี้ก็คือ userinit.exe (PID หมายเลข 1048) และ winmgmt.exe (PID หมายเลข 1052)

หลังจากที่รู้จักโปรแกรมช่วยกันไปแล้ว คราวนี้เราจะมาดูกันว่า lsproc ทำงานกันอย่างไร

lsproc ทำงานโดยทำการอ่าน image ที่ได้จาก RAM แล้วทำการค้นหาโครงสร้างข้อมูลที่เรียกว่า EPROCESS ซึ่งเป็นโครงสร้างข้อมูลที่ระบบปฏิบัติการ Windows ไว้ใช้สำหรับทำการเก็บข้อมูลของโปรเซสต่างๆที่เกิดขึ้นบนระบบ โดยโครงสร้างข้อมูล EPROCESS ของระบบปฏิบัติการ Windows 2000 Server SP4 นั้นสามารถดูได้จาก Forensik Blog (เค้าเขียนว่า Forensik จริงๆ ไม่มีเขียนผิดนะ แหะๆ)

ในโครงสร้างข้อมูล EPROCESS นั้น ได้เก็บโครงสร้างข้อมูลที่น่าในใจอย่างหนึ่งคือ DISPATCHER_HEADER ซึ่งโครงสร้างข้อมูลดังกล่าวมีลักษณะดังต่อไปนี

      +0x000 Header           : struct _DISPATCHER_HEADER, 6 elements, 0x10 bytes
         +0x000 Type             : UChar
         +0x001 Absolute         : UChar
         +0x002 Size             : UChar
         +0x003 Inserted         : UChar
         +0x004 SignalState      : Int4B
         +0x008 WaitListHead     : struct _LIST_ENTRY, 2 elements, 0x8 bytes
            +0x000 Flink            : Ptr32 to 
            +0x004 Blink            : Ptr32 to 

ชนิดของข้อมูลที่ทำตัวหนานั้นคือ Type และ Size ซึ่งจากข้อมูลของ Forensik Blog ได้บอกไว้ว่าค่า Type จะเป็น 0x03 และ Size จะเป็น 0x1b เสมอ ซึ่งค่านี้จะคงที่ตั้งแต่ Windows 2000 Server SP4 ไปจนถึง Windows 2003 Server ดังนั้นเราสามารถใช้ค่านี้ทำการระบุตำแหน่งของข้อมูลที่เกี่ยวข้องกับโปรเซสใน physical memory ได้

เมื่อทำการระบุตำแหน่งของข้อมูลที่เกี่ยวข้องกับโปรเซสได้แล้ว จากนั้นเราทำการอ่านข้อมูลทั้งหมดที่เกี่ยวข้องกับโปรเซสนั้นๆ โดยจำนวนข้อมูลที่อ่านจะขึ้นอยู่กับขนาดของ EPROCESS ของแต่ละระบบปฏิบัติการ โดยระบบปฏิบัติการ Windows 2000 Server SP4 นั้นจะมีขนาด 0x290 bytes

เมื่ออ่านข้อมูลจำนวน 0x290 bytes ของ EPROCESS แล้ว เราจะทำการตรวจสอบอีกขั้นหนึ่งว่าข้อมูลที่เราอ่านมานั้นเป็น EPROCESS จริงๆหรือไม่ ซึ่งขั้นตอนที่ lsproc ทำการตรวจสอบนั้นคือทำการตรวจสอบค่าของ Synchronization Event #2 และ #3 ของ EPROCESS ซึ่งทั้ง 2 ค่านี้จะอยู่ที่ตำแหน่ง 0x13c และ 0x164 จากตำแหน่งเริ่มต้นของ EPROCESS ซึ่งหากค่าของ Synchronization ทั้งสองเป็น 0x040001 แล้ว แสดงว่าข้อมูลจำนวน 0x290 bytes ที่อ่านมานั้นเป็น EPROCESS

หลังจากที่มั่นใจว่าข้อมูลที่อ่านมาจำนวน 0x290 bytes นั้นเป็น EPROCESS แล้ว lsproc จึงทำการอ่านข้อมูล ณ ตำแหน่งต่างๆ เช่น ชื่อของโปรเซส (0x1fc), เวลาที่โปรเซสถูกสร้างขึ้น (0x088), PID (0x09c), PPID (0x1c8) แล้วจึงนำมาแสดงผลต่อไป

ปิดท้ายกันด้วยขั้นตอนการทำงานแบบหยาบๆของ lsproc ครับ :)

การเก็บข้อมูลที่อยู่ใน RAM สำหรับการทำ Computer Forensics

ขึ้นชื่อว่า Live Response (การวิเคราะห์ข้อมูลเกี่ยวกับการบุกรุกโดยอาศัยข้อมูลและสถานะปัจจุบันของเครื่องที่ถูกบุกรุกเป็นหลัก) ก็คงจะปฏิเสธไม่ได้ว่าข้อมูลที่อยู่ใน RAM นั้นมีความสำคัญอย่างยิ่งยวดสำหรับการวิเคราะห์ เนืองจากข้อมูลดังกล่าวเป็นจะเป็นสิ่งที่ช่วยให้เห็นภาพมากขึ้น ณ ขณะที่เครื่องที่ถูกบุกรุกมีโปรเซสใดรันอยู่บ้าง ดังนั้นในวันนี้ผมจะมากล่าวถึงวิธีการเก็บข้อมูลที่อยู่ใน RAM ว่าสามารถทำได้อย่างไร

วิธีการที่ง่ายที่สุดคือใช้ Helix Live CD ซึ่งมี GUI ให้ใช้แบบง่ายๆเลย หน้าตาของ Helix ก็เป็นดังภาพข้างล่าง



โดยปกติแล้วเราจะใช้ dd เพื่อทำการสร้าง image ของฮาร์ดดิสก์แต่อย่างไรก็ตาม dd สามารถทำการ "dump" ข้อมูลจาก Physical memory หรือ RAM ได้อีกด้วย จากภาพข้างบนเป็นการดึงข้อมูลจาก RAM บนระบบปฏิบัติการ Windows ซึ่งหากต้องการรันแบบ command line นั้นสามารถรันได้โดยใช้คำสั่ง

dd if=\\.\PhysicalMemory of=ram.img bs=4096 conv=noerror

if ย่อมาจาก input file ซึ่งหมายถึงว่าให้ dd ทำการอ่านข้อมูลจากอะไร หากเป็น RAM บนระบบปฏิบัติการ Windows เราจะใช้ \\.\PhysicalMemory ในขณะที่บนระบบปฏิบัติการ Linux นั้นจะเป็น /dev/mem

หมายเหตุ: \\.\PhysicalMemory สามารถใช้ได้ตั้งแต่ Windows 2000 จนถึง Windows 2003 Server SP0 แต่ Windows 2003 Server SP1 จนถึง Vista จะไม่สามารถใช้ dd อ่านได้เนื่องจากระบบปฏิบัติการรุ่นใหม่ไม่ยอมให้ dd ซึ่งเป็นโปรแกรมในระดับ user-mode สามารถเข้าถึง \\.\PhysicalMemory ได้ จะยอมให้เฉพาะระดับ kernel-mode เท่านั้นเช่น device-driver ที่สามารถเข้าถึงได้ แต่อย่างไรก็ตามผมได้พบว่าเค้าให้ไปอ่านที่ \\.\DebugMemory ซึ่งไว้จะตรวจสอบความถูกต้องอีกทีครับ

of ย่อมาจาก output file ซึ่งหมายถึงว่าให้ dd ทำการเขียนข้อมูลไปที่ใด ในที่นี้คือเขียนผลลัพธ์ไปที่ไฟล์ ram.img แต่อย่างไรก็ตามไม่แนะนำให้เขียนข้อมูลลงในในเครื่องที่ทำการตรวจสอบ เพราะอาจจะไปเขียนทับข้อมูลสำคัญที่ถูกลบไปแล้วในฮาร์ดดิสก์ได้ ซึ่งทางเลือกก็คือ

• เขียนข้อมูลลงไปใน external storage เช่น USB thumb drive หรือไม่ก็ external harddisk
• เขียนข้อมูลลงไปใน share ของคอมพิวเตอร์อีกเครื่องหนึ่ง
  

วิธีการแรกเป็นที่นิยมมากกว่าเนื่องจากระบบที่ทำการเก็บข้อมูลนั้นไม่ต้องเชื่อมต่อออกไปยังภายนอก ซึ่งส่งผลกระทบต่อสภาพแวดล้อมของระบบน้อยกว่าวิธีการที่สอง

bs ย่อมาจาก byte sector (ถ้าจำไม่ผิด) เป็นการบอกให้ dd ทำการอ่านและเขียนข้อมูลทีล่ะ 4096 byte

conv=noerror อันนี้ไม่รู้จะอธิบายยังไงดี สรุปใจความสั้นๆคือในกรณีที่ dd ทำการอ่านข้อมูลแล้วเกิดข้อผิดพลาดขึ้น ให้ dd ทำการอ่านข้อมูลต่อไปโดยที่ไม่ต้องหยุดการทำงาน

หลังจากทำการดึงข้อมูลจาก RAM ออกมาแ้ล้ว ควรทำการ hash ไฟล์ข้อมูลจาก RAM ทุกครั้งด้วย md5 หรือ SHA-1 ตามแต่สะดวก ในกรณีถ้าใช้ Helix มันจะทำการ hash ให้โดยอัตโนมัติครับ

การดูเวลาที่สร้างและเวลาครั้งสุดท้ายที่ทำการแก้ไขไฟล์ PDF

วันก่อนเจอ case เกี่ยวข้องกับการปลอมเอกสาร PDF ก็เลยนำมาเล่าสู่กันฟังเด้อ :) โจทย์ก็คือเราจะสามารถทราบได้อย่างไรว่าไฟล์เอกสาร PDF ที่ทำการตรวจสอบนั้น ถูกสร้างขึ้นเมื่อใดและถูกแก้ไขครั้งสุดท้ายเมื่อใด

วิธีการดูค่าเวลาต่างๆของไฟล์ PDF นั้นจะดูที่ค่า metadata ของไฟล์ PDF นั่นเอง ซึ่งสามารถดูได้ด้วยวิธีการนี้

• เปิดไฟล์ PDF ที่ต้องการตรวจสอบด้วยโปรแกรม Adobe Reader
• คลิกที่เมนู File แล้วเลือกที่ Document Properties...

• ที่ tab ชื่อ Description จะมีข้อมูลเกี่ยวข้องกับไฟล์ PDF อยู่ไม่ว่าจะเป็น ผู้ที่ทำการสร้างไฟล์ (Author), เวลาที่ทำการสร้างไฟล์ (Created) หรือ เวลาครั้งสุดท้ายที่ทำการแก้ไขไฟล์ (Modified)

เวลาที่ทำการสร้างไฟล์และเวลาครั้งสุดท้ายที่ทำการแก้ไขไฟล์ที่ดูด้วยวิธีนี้นั้นมีความน่าเชื่อถือมากกว่าวิธีการดูด้วยคำสั่ง dir เนื่องจากค่าที่ได้จากคำสั่ง dir นั้นจะเปลี่ยนแปลงไปเมื่อไฟล์ถูก copy หรือดาวน์โหลดมาจากที่อื่น ในขณะที่ค่าเวลาที่ดูด้วยวิธีการดังกล่าวนั้นจะไม่เปลี่ยนแปลงถึงเม้ว่าไฟล์นั้นจะถูกย้ายไปไว้ที่อื่นก็ตาม ซึ่ง forensic investigator สามารถใช้ค่าเวลาดังกล่าวในการวิเคราะห์และสร้างความสัมพันธ์ของเหตุการณ์ได้

อย่างไรก็ตามค่า metadata ดังกล่าวของไฟล์ PDF นั้นสามารถปลอมแปลงได้ ซึ่งอาจทำให้ผู้ที่ทำการปลอมแปลงเอกสารนั้น ทำการปลอมแปลงวันเวลาที่สร้างเอกสารให้เป็นวันที่เกิดขึ้นก่อนเอกสารของฝ่ายเรา ทำให้ดูเหมือนว่าเอกสารของเราเป็นของปลอม ดังนั้น forensic investigator จึงควรระวังตรงจุดนี้ไว้ สำหรับวิธีการรับมือกับการปลอมเวลาการสร้างไฟล์ PDF นั้นสามารถทำได้โดยการทำ construct timeline ของ activitity ของไฟล์บนระบบ ซึ่งถ้า activity timeline ไม่ตรงกับเวลาที่ไฟล์ถูกสร้างขึ้น เราจะสร้างใช้ข้อมูลตรงจุดนี้ทำการแย้งได้ (วิธีนี้จะใช้ได้ผลก็ต่อเมื่อค่า MAC ของไฟล์บนระบบไม่ถูกปลอมแปลงให้สัมพันธ์กับค่า metadata ของไฟล์ PDF)

P.S. การแก้ไขค่า metadata ของไฟล์ PDF จะทำให้ค่า checksum ของไฟล์เปลี่ยนไปด้วย ดังนั้นเราจึงควรเก็บ checksum ของไฟล์เราไว้ด้วยเสมอ

ว่าด้วยเรื่องของ MAC times

หนึ่งในวิธีที่บรรดา incident handler นิยมทำกันในการสืบสวนอาชญากรรมคอมพิวเตอร์คือ การดู timeline ที่เกิดขึ้นบนระบบว่ามีไฟล์ใดถูกสร้างหรือถูกเปลี่ยนแปลงก่อน - หลังจากที่เกิดเหตุการณ์บุกรุกบ้าง การสร้าง timeline จะช่วยให้ incident handler สามารถลำดับเหตุการณ์ต่างๆที่เกิดขึ้นในระบบได้มีประสิทธิภาพมากขึ้น

โดยปกติแล้ว timeline ของเหตุการณ์จะใช้ข้อมูลจากเวลาที่ไฟล์ถูกเปลี่ยนแปลง (Modified) เวลาที่ไฟล์ถูกเข้าถึง (Accessed) และเวลาที่ไฟล์ถูกสร้างขึ้น (Created) ซึ่งข้อมูลของเวลาเหล่านี้เรียกอีกอย่างหนึ่งว่า MAC times

การเรียกดู MAC times บนระบบปฏิบัติการ Windows สามารถทำได้โดยใช้คำสั่ง dir /TW, dir /TA และ dir /TC ตามลำดับ ตัวอย่างผลลัพธ์ของการเรียกดูเวลาที่ไฟล์ถูกสร้างขึ้นแสดงดังข้างล่าง

C:\Documents and Settings\Trirat\Desktop\Sysinternals>dir /TC
Volume in drive C has no label.
Volume Serial Number is 3CCF-7B7F

Directory of C:\Documents and Settings\Trirat\Desktop\Sysinternals

04/24/2007 11:34 AM DIR .
04/24/2007 11:34 AM DIR ..
04/24/2007 11:31 AM 475,790 Autoruns.zip
04/24/2007 11:51 AM 1,539,243 ProcessExplorer.zip
04/24/2007 11:44 AM DIR PsTools
04/24/2007 11:40 AM 1,022,681 PsTools.zip

ถึงแม้ว่าการสร้าง timeline ของเหตุการณ์จาก MAC times จะเป็นเครื่องอำนวยความสะดวกให้กับ incident handler แต่ทว่าความน่าเชื่อถือของ MAC times นั้นเป็นสิ่งที่ incident handler ควรระมัดระวังเนื่องจาก MAC times ของไฟล์ต่างๆนั้นสามารถปลอมแปลงได้ !!?

เครื่องมือที่ใช้สำหรับปลอมแปลง MAC times มีอยู่มากมาย แต่ในที่นี้จะใช้เครื่องมือจาก Metasploit Anti-Forensics Project ที่ชื่อว่า timestomp

C:\Documents and Settings\Trirat\Desktop\Sysinternals> dir /TC PsTools.zip
Volume in drive C has no label.
Volume Serial Number is 3CCF-7B7F

Directory of C:\Documents and Settings\Trirat\Desktop\Sysinternals

04/24/2007 11:40 AM 1,022,681 PsTools.zip

C:\Documents and Settings\Trirat\Desktop\Sysinternals> timestomp.exe PsTools.zip -c "Sunday 1/1/2007 1:11:11 AM"

C:\Documents and Settings\Trirat\Desktop\Sysinternals> dir /TC PsTools.zip
Volume in drive C has no label.
Volume Serial Number is 3CCF-7B7F

Directory of C:\Documents and Settings\Trirat\Desktop\Sysinternals

01/01/2007 01:11 AM 1,022,681 PsTools.zip

จากตัวอย่างข้างบนแสดงการใช้งาน timestomp สังเกตว่าก่อนการใช้ timestomp นั้นเวลาที่ไฟล์ PsTools.zip ถูกสร้างขึ้นคือวันที่ 04/07/2007 เวลา 11.40 หลักจากนั้นจึงใช้ timestomp ทำการปลอมแปลงเวลาที่ไฟล์ถูกสร้างขึ้นให้เป็นวันที่ 01/01/2007 เวลา 01:11

เนื่องด้วยการปลอมแปลง MAC times สามารถทำได้อย่างง่ายดาย ดังนั้น incident handler จึงควรระมัดระวังตรงจุดนี้ไว้ :)

การดู Last Write Time ของ Registry Key

การเรียกดู last write time ของ registry (เวลาที่ registry ถูกเปลี่ยนแปลงล่าสุด) ไม่ค่อยเป็นที่สนใจกันมากนัก อย่างไรก็ตาม last write time ของ registry จะมีประโยชน์ในกรณีที่ incident handler ทำการสันนิษฐานว่าผู้บุกรุกได้ทำการติดตั้ง Malware ลงไปใน services ของระบบปฏิบัติการ Windows โดยรายชื่อของ services ในระบบจะปรากฏอยู่ที่ registry ที่ชื่อว่า

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services

ในการที่ผู้บุกรุกจะทำการติดตั้ง services ลงไปในระบบปฏิบัติการ Windows จะต้องมีการสร้าง key ขี้นมาใหม่ หรือทำการแก้ไขค่าของ key ที่มีอยู่แล้ว ซึ่งไม่ว่าผู้บุกรุกจะเลือกวิธีไหนก็ตาม ค่าของ last write time ของ registry จะต้องมีการเปลี่ยนแปลง ดังนั้นหาก incident handler ทำการสังเกตุค่านี้จะช่วยให้สามารถทำการลำดับเหตุการณ์ได้ดียิ่งขึ้น :)

สำหรับการเรียกดูเวลาที่ registry key ถูกเปลี่ยนแปลงล่าสุดสามารถทำได้โดย
1. เรียก regedit ขึ้นมา แล้วทำการ browse ไปยัง key ของ services ที่เราสนใจ
2. ให้ click ขวาที่ key ที่ต้องการแล้วเลือก export จากนั้นให้ save ผลลัพธ์เป็น .txt
3. เมื่อทำการเปิดไฟล์นี้จะพบ ค่า Last Write Time สำหรับแต่ละค่าต่างๆที่อยู่ใน registry key นั้น :)

ตัวอย่างอยู่ข้างล่างครับ

Key Name: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\-
Services\HTTP
Class Name: NO CLASS
Last Write Time: 23/4/2550 - 9:48

P.S. ค่า last write time สำหรับแต่ละ services จะถูกเปลี่ยนแปลงทุกครั้งหลังจากระบบทำการ reboot ดังนั้นถ้าระบบที่เราทำการตรวจสอบถูก reboot หลังจากที่ผู้บุกรุกทำการติดตั้ง malware ลงไปใน services แล้ว จะทำให้การสืบสวนด้วยค่า last write time ไม่มีประโยชน์ครับ

P.S. การสืบสวนด้วยค่า last write time จะมีประสิทธิภาพก็ต่อเมื่อระบบตั้งอยู่บนสมมติฐานที่ว่าค่า last write time ไม่สามารถปลอมแปลงได้ ซึ่งในปัจจุบันยังไม่มี Windows API ที่สามารถทำแบบนั้นได้ (ข้อมูลอ้างอิงจาก Windows Forensic Analysis ของ Harlan Carvey) ดังนั้นหมายความว่าการใช้ค่า last write time ของ registry เป็นแนวทางในการสืบสวนยังสามารถทำได้อยู่ครับ