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
   

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

โครงสร้างข้อมูล (data structure) ของ PEB บน Windows XP SP2

ตอนนี้อยู่ระหว่างการพัฒนา lspd ให้สามารถทำงานได้บน Windows XP SP2 (ของเก่าที่เขียนโดย Harlan Carvey ทำงานได้บน Windows 2000 เท่านั้น) ซึ่งจากการไล่โค้ดดูพบว่ามันมีการอ่าน PEB ด้วย เนื่องจาก PEB บน Windows 2000 กับบน Windows XP SP2 น่าจะมีความแตกต่างกันบ้าง...

ว่าแล้วก็เปิด Windbg ขึ้นมาแล้วเลือกที่ File -> Kernel Debug ... จากนั้นเลือกที่แถบ Local จากนั้น click ที่ OK เพื่อเป็นการรัน Kernel Debugger แบบ Local (การรัน Kernel Debugger นั้นสามารถทำได้ตั้งแต่ระบบปฏิบัติการ Windows XP SP เท่าไหร่ก็ไม่รู้ขึ้นไป แต่รันบน Windows 2000 ไม่ได้ครับ ต้องใช้ livekd แทน)

เมื่อรันได้ผลดังนี้

Microsoft (R) Windows Debugger Version 6.6.0007.5
Copyright (c) Microsoft Corporation. All rights reserved.

Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE
Symbol search path is: C:\WINDOWS\SYSTEM32\ntoskrnl.exe;C:\WINDOWS\Symbols
Executable search path is:
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntoskrnl.exe -
*******************************************************************************

(มีต่ออีกแต่ตัดมาแค่นี้) มัน error แฮะ - -" ลองรันคำสั่ง .reload ก้อยังมี error เหมือนเดิม พอรันคำสั่ง dt _PEB เพื่อทดสอบมันก็ฟ้องว่าไม่สามารถ resolve _PEB ได้

ไปๆมาลองสังเกตที่ Symbol search path ดูพบว่ามันเป็น C:\WINDOWS\SYSTEM32\ntoskrnl.exe;C:\WINDOWS\Symbols แต่ไอ้ที่ตั้งค่าไว้มันมีแค่ C:\WINDOWS\Symbols นี่หน่า... ว่าแล้วก็เลยไปไปดูที่ File --> Symbol Path File... พบว่ามันตั้งค่าเป็น C:\WINDOWS\system32 - -" ไปกันใหญ่เลย ว่าแล้วก็ตั้งค่าเป็น C:\WINDOWS\Symbols ซะแล้วรันคำสั่ง .reload จากนั้นรันคำสั่งเพื่อดูโครงสร้างข้อมูลของ PEB ได้ผลดังข้างล่าง

lkd> dt _PEB
+0x000 InheritedAddressSpace : UChar
+0x001 ReadImageFileExecOptions : UChar
+0x002 BeingDebugged : UChar
+0x003 SpareBool : UChar
+0x004 Mutant : Ptr32 Void
+0x008 ImageBaseAddress : Ptr32 Void
+0x00c Ldr : Ptr32 _PEB_LDR_DATA
+0x010 ProcessParameters : Ptr32 _RTL_USER_PROCESS_PARAMETERS
+0x014 SubSystemData : Ptr32 Void
+0x018 ProcessHeap : Ptr32 Void
+0x01c FastPebLock : Ptr32 _RTL_CRITICAL_SECTION
+0x020 FastPebLockRoutine : Ptr32 Void
+0x024 FastPebUnlockRoutine : Ptr32 Void
+0x028 EnvironmentUpdateCount : Uint4B
+0x02c KernelCallbackTable : Ptr32 Void
+0x030 SystemReserved : [1] Uint4B
+0x034 AtlThunkSListPtr32 : Uint4B
+0x038 FreeList : Ptr32 _PEB_FREE_BLOCK
+0x03c TlsExpansionCounter : Uint4B
+0x040 TlsBitmap : Ptr32 Void
+0x044 TlsBitmapBits : [2] Uint4B
+0x04c ReadOnlySharedMemoryBase : Ptr32 Void
+0x050 ReadOnlySharedMemoryHeap : Ptr32 Void
+0x054 ReadOnlyStaticServerData : Ptr32 Ptr32 Void
+0x058 AnsiCodePageData : Ptr32 Void
+0x05c OemCodePageData : Ptr32 Void
+0x060 UnicodeCaseTableData : Ptr32 Void
+0x064 NumberOfProcessors : Uint4B
+0x068 NtGlobalFlag : Uint4B
+0x070 CriticalSectionTimeout : _LARGE_INTEGER
+0x078 HeapSegmentReserve : Uint4B
+0x07c HeapSegmentCommit : Uint4B
+0x080 HeapDeCommitTotalFreeThreshold : Uint4B
+0x084 HeapDeCommitFreeBlockThreshold : Uint4B
+0x088 NumberOfHeaps : Uint4B
+0x08c MaximumNumberOfHeaps : Uint4B
+0x090 ProcessHeaps : Ptr32 Ptr32 Void
+0x094 GdiSharedHandleTable : Ptr32 Void
+0x098 ProcessStarterHelper : Ptr32 Void
+0x09c GdiDCAttributeList : Uint4B
+0x0a0 LoaderLock : Ptr32 Void
+0x0a4 OSMajorVersion : Uint4B
+0x0a8 OSMinorVersion : Uint4B
+0x0ac OSBuildNumber : Uint2B
+0x0ae OSCSDVersion : Uint2B
+0x0b0 OSPlatformId : Uint4B
+0x0b4 ImageSubsystem : Uint4B
+0x0b8 ImageSubsystemMajorVersion : Uint4B
+0x0bc ImageSubsystemMinorVersion : Uint4B
+0x0c0 ImageProcessAffinityMask : Uint4B
+0x0c4 GdiHandleBuffer : [34] Uint4B
+0x14c PostProcessInitRoutine : Ptr32
+0x150 TlsExpansionBitmap : Ptr32 Void
+0x154 TlsExpansionBitmapBits : [32] Uint4B
+0x1d4 SessionId : Uint4B
+0x1d8 AppCompatFlags : _ULARGE_INTEGER
+0x1e0 AppCompatFlagsUser : _ULARGE_INTEGER
+0x1e8 pShimData : Ptr32 Void
+0x1ec AppCompatInfo : Ptr32 Void
+0x1f0 CSDVersion : _UNICODE_STRING
+0x1f8 ActivationContextData : Ptr32 Void
+0x1fc ProcessAssemblyStorageMap : Ptr32 Void
+0x200 SystemDefaultActivationContextData : Ptr32 Void
+0x204 SystemAssemblyStorageMap : Ptr32 Void
+0x208 MinimumStackCommit : Uint4B

ได้แหล้ว :) จะได้เขียนต่อซะที

การเปลี่ยน 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 มีการเปลี่ยนแปลงในบางส่วนครับ (เอ๊ะ สองข้อนี้มันเขียนรวมกันได้นี่หว่า - -" แหะๆ)
  

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