電腦系統休眠文件函數

① psp的破解歷程

啟蒙時代：
2005-5-7 PSP游戲光碟已被導出
2005-5-7 HELLO WORLD 1.0登場
2005-5-9 Saturn Expedition Committee發布了一個可以DUMP 1.0版本的PSP FIRMWARE的程序
2005-5-12 PSP上GB模擬器出現
2005-6-13 MD模擬器將PSP的運行頻率提高到了333Mhz
UMD引導時代：
2005-6-22 KXploit 1.5發布，1.5破解
2005-7-4 UMD LOADER出現
2005-7-20 HOOK BOOT Ver.0.10 發布（從此我們知道了PSP也能免費玩）
2005-7-26 HOOK BOOT Ver.0.90 放出
2005-7-27 PSP2.0升級
2005-8-4 Fastloader登場（好多游戲的前提只是一張UMD）
2005-8-12 Fastloader V0.6b
2005-8-24 Fastloader 0.7 版放出
2005-9-16DEVHOOK0.22發布
黃金雙引導時代（其他破解信息不多，說明了黃金雙引導的王道）：
2005-9-16 DEVHOOK0.22+DE0.8最強雙引導形成（一個時代的開始）
2005-9-28 2.0降級程序發布
MPH引導時代：
2005-12-13 Fanjita放出PSP2.01/2.5的HelloWorld程序（即後來GTA LOADER)
2005-12-15 PMP登場
2005-12-26 Eboot Loader 0.9版放出（2.00)
2006-1-29 Fanjita發布了2.0 eLoader(GTA LOADER) for v2.00、v2.01和v2.50 PSP
2006-1-30 Fanjita發布了2.0 eLoader(GTA LOADER) for v2.60 PSP
2006-2-23 MPH GTA LOADER發布，GTA告破
2006-2-24 MPH GAME LOADER發布，2.0游戲告破
2006-2-25 MPH Game Loader正式版，解除10分鍾限制
MPH黃金雙引導時代：
2006-3-3 無需UMD玩2.0破解游戲 MPH+devhook gl登場
2006-3-5 MPH Game Loader1.10可運行2.0UMD
DAXZISO時代：
2006-3-6 RUNUMD出世
2006-3-25 DAXZISO 0.4 發布
2006-4-6 DAXZISO升級0.5版
2006-4-11 RUNUMD+UE8.0登場，怪物獵人P告破
2006-4-12 DAXZISO 0.51版正式支持怪物獵人壓縮
2006-4-22 DAXZISO 0.55版
2006-4-25 PSP2.7版本升級文件正式放出下載2006-4-27 DEVHOOK放出 0.3 alpha版（這在當時人眼裡是最廢的引導器，誰知．．．）
2006-5-6 UMD EMULATOR源代碼被公布
2006-5-7 HELLO WORLD一周年
2006-5-6 DEVHOOK 0.32a發布（很爛的引導器，這次的意義主要在於CSO格式的發布，不過DEVHOOK離神壇已經不遠了）
2006-5-8 Snes9xTYL 0.4發布（我個人喜歡的模擬器）
2006-5-15 DAXZISO升級0.61版
2006-5-15 Snes9xTYL 升級 0.42版
2006-5-19 DAXZISO升級0.62版（至此，DAXZISO的傳奇就結束了，在此感謝Dark_AleX在DAXZISO方面帶給我們的歡樂）
2006-5-27 首個PSP直讀晶元Undiluted Platinum公布！
2006-5-30 DEVHOOK最新開發情報發布（一些並不起眼的情報，可就在一周之後．．．）
2006-6-1 PSP升級版本至2.71
DEVHOOK時代：
2006-6-6 DEVHOOK 0.41版發布（想一下吧，SONY有多恨BOOSTER)
2006-6-9 DEVHOOK 0.41A版發布
2006-6-13 DEVHOOK 0.41B版發布
2006-6-14 DEVHOOK 0.41C版發布
2006-6-15 DEVHOOK 0.41D版發布
2006-6-28 2.71固件可提取部分文件
2006-6-29 Dark_AleX發布2.5和2.6降級工具
2006-7-5 DEVHOOK 0.42推出
2006-7-6 Dark_AleX發布工具1.50降回1.00
2006-7-10 2.60/2.71固件解密成功
2006-7-11 Devhook0.43版推出（可模擬2.60)2006-7-14 Devhook0.44版推出（可模擬2.71)
2006-7-15 Dark_Alex製作自定固件 The proof of concept
2006-7-15 PSPVBA:GBA模擬器v1.1.0
2006-7-20 Devhook0.45版推出
2006-7-30 Devhook0.46版推出（可刷機）
2006-7-27 PSP升級固件2.80版本正式發布（很可惜，這次DEVHOOK沒跟上，且作者宣布退出devhook的製作）
2006-7-31 GBA模擬器PSPVBA 1.2.3
2006-8-23 GPSP發布，宣告GBA模擬器完美
2006-8-28 Fanjita製作PSP2.8自製程序Hello World運行成功
2006-9-1 Eloader for 2.71公開
2006-9-2 2.71版PSP成功降級
2006-9-6 Eloader 0.9.8發布 FOR 2.60
2006-9-11 全速GBA模擬器最新版本GPSP 0.7公布
2006-9-22 Eloader 0.9.9發布 FOR 2.70/2.71
2006-9-23 Dark_AleX公布Homebrew Enabler for 2.71（免Eloader運行自製程序）
2006-9-24 Dark_AleX正式公布了Devhook Launcher Port to v2.71（意味著2.71告破）
2006-9-25 Dark_AleX公布HEN FOR 2.71B2，成功率99%
2006-9-30 Dark_AleX公布Homebrew enabler vC，可運行1.5的自製程序
2.71SE時代：
2006-10-8 Dark_AleX聲明2.71修改版固件將可直接運行自製軟體，定名2.71SE
2006-10-9 2.71SE 正式發布
2006-10-25 2.71SE-B 正式發布
2006-10-28 實現免盤引導，2.71SE-B2 正式發布
2006-11-4 TA-086神秘主板登場
2006-11-9 2.71SE-B3 正式發布，攝相頭破解
2006-11-19 DARK_ALEK放話，2.8X可以被模擬
2006-11-21 PSP 2.80 固件FLASH 0已經能夠寫入
2006-11-21 PSP固件3.00系統SCE官方提供下載
2006-11-22 PSP固件3.00系統被導出
2006-11-22 PSP固件3.01系統SCE官方提供下載
2006-11-23 2.71/2.80混合系統發布
2006-11-25 Booster宣布回歸破解陣容
2006-11-27 2.71SE-C 正式發布
2006-11-29 2.71SE與3.00混合版發布
未知的時代（ 3.XX 時代來臨）：
2006-11-30 Devhook0.50發布，2.8X告破（雖然還不成熟，但我們有理由相信，它就和Devhook0.3一樣，是一個傳奇的開始）
2007-1-27 PSP全開放！3.03降級完全傻瓜包教程
2007-1-30 PSP如何對破解，3.10新版推出。但不久傳來3.10版本已經全被攻克的消息，索尼表明不會放棄，要繼續推出3.11版
2007-7-24 索尼（SCE）官方發布PSP 3.52系統固件程序。
2007-7-26 Team M33 正式發布自製系統3.52 M33。
2007-7-30 Team M33 正式發布系統升級補丁3.52 M33-2（系統界面中文化）。
2007-8-20 Team M33 正式發布系統升級補丁3.52 M33-3。
2007-8-21 Team M33 正式發布系統升級補丁3.52 M33-4。
2007-8-23 Team C+D 正式發布通用反變磚/降級程序潘多拉的電池——神奇電池發布。
2007-9-11 Team M33 正式發布新版PSP-2000第一款自製系統3.60 M33。
2007-9-11 索尼（SCE）官方發布PSP 3.70版系統固件（同時支持PSP-1000和2000）。
2007-9-20 日版PSP2000普通版發售。
接近完美的時代：
2007-9-24 Team M33 正式發布自製系統3.71 M33
2007-10-05 神奇電池V3(Cemetery v3）發布，支持薄機屏幕顯示
2007-10-29 神奇電池製作程序加入對新版1200MAH電池的支持（之前只能用厚電池）。
2007-10-30 索尼（SCE）官方發布PSP 3.72系統固件程序
2007-11-01 Team M33 正式發布系統升級補丁3.71M33-3。
2007-11-29 索尼再次升級PSP的系統版本，新版本號為3.73 且升級區域僅為日該地區。
2007-12-13 Dark_Alex正式放出3.71M33-4的升級補丁 並發布3.71M33-4更新內容
2007-12-18 索尼在日本正式發布PSP 3.80版固件系統
2008-1-14 發布PSP 3.80M33-2自製固件
2008-1-28 PSP 3.90固件放出
2008-2-1 Dark_AleX放出PSP 3.90 M33自製系統
2008-2-4 更新的3.90 版發布 修正若干BUG
2008-2-14 Dark Alex發布3.90M33-2自製系統
2008-3-31 Dark Alex發布的自製固件系統的最新版本3.90M33-3
2008-6-21 SONY發布3.92 後續改進系統有3.95，其實並無區別
2008-10-15 SONY正式發售PSP-3000，搭載系統為4.21，美版為4.20
2008-11-24 SONY發布5.00系統
2008-11-26 Dark-Alex發布5.00 M33
2008-11-30 Dark-alex發布5.00 M33-2
2008-12-3 Dark-alex發布 5.00 M33-4
2008-12-27 Dark-Alex 發布5.00 M33-6
破解新時代
2009-4-20 SONY發布5.50官方系統
2009-5-7 DAVEE發布Davee正式放出HEN for PSP3000 破解程序
2009-5-8 DAVEE發布Davee正式放出 HEN修正版 for PSP3000 和PSP2000 TA88V3
2009-5-26 PSP2000所有版本主機破解 Xenogears 和 Becus25 發布CFW Enabler v1.0 for ChickHEN，v3主機可以運行ISO
2009-6-6 5.03 GEN-A（Full）發布3K主機可以運行ISO
2009-6-8 Xenogears發布CFWEnable3.01 3k可以運行ISO
2009-6-11 SONY發布5.51官方系統
2009-6-13 5.50GEN-A(Full) 發布 支持多層文件夾（僅限1000與2000非v3）
2009-6-18 5.50U3R 發布 支持加速讀棒
2009-7-2 5.50GEN-B(full）發布 （須5.50GEN-A系統）
2009-8-28 最著名PSP破解網站Dark-AleX宣布關閉（管理員稱只是出於論壇維護成本考慮）
2009-9-6 5.50GEN-B2(full）發布 （須5.50GEN-B系統）
2009-9-10 SONY發布6.00官方系統（此前SONY已在多個游戲的UMD中加入了5.55官方系統，且這些游戲的ISO大部分無法在已有的自製系統運行）
2009-9-30 PSPGEN論壇的著名開發者Yoshihiro發布GAME DECRYPTER，能夠解密需5.55或6.00系統的游戲鏡像的EBOOT.BIN文件，使得大部分需要5.55系統要求的游戲鏡像得以在5.50GEN或更低版本的自製系統中運行
2009-10-1 GAME DECRYPTER v2發布，能夠解密更多的高版本游戲的EBOOT.BIN
2009-10-1 SONY發布6.10官方系統
2009-10-1 PSP Go(N1000）正式發售（港版、美版、歐版）
2009-10-8 GAME DECRYPTER v3發布 進一步降低游戲的版本需求，使破解後的游戲均得以運行於5.03MHU或5.03GEN
2009-10-9 GAME DECRYPTER v4發布 能夠解密6.10版本需求的游戲
2009-10-22 5.50GEN-D（僅支持1K和非v3的2K）發布，可直接運行未破解的5.55-6.xx版本要求的游戲（ISO/CSO及UMD）
2009-10-22 5.50GEN-D2（需5.50GEN-D）發布
2009-11-1 PSPGo日版發售
2009-11-2 5.03GEN-B發布 3K,V3可直接運行未解密的5.55-6.XX版本要求的游戲
2009-11-19 SONY發布6.20官方系統
2009-12-16 GEN小組的最新自製系統5.50GEN-D3（PSP1000/2000非v3適用）/5.03GEN-C（PSP3000/2000v3適用）正式發布
2009-12-25 Date公司推出全世界第一款能夠在索尼官方系統中運行的程序 Action Replay PSP
2010-01-07 PSPGEN主創人員將隱退 原因是成果被盜用
2010-01-09 《王國之心：夢中降生》發售，無法在任何現有系統上運行（解密後也不行，6.20悲劇的開始）
2010-02-04《噬神者》發售，同樣無法在任何現有系統上運行
2010-03-29 6.20系統成功運行Hello World教程放出
2010-04-15 基於試玩游戲《啪嗒砰2》存檔漏洞的E-Loader發布，5.03以上官方系統可運行部分自製軟體。
2010-04-29 PSP上首個滿分大作《合金裝備：和平行者》發售，同樣悲劇
2010-04-29 國人liquidzigong破解了 《合金裝備 和平行者》為破解6.20游戲展開了序幕。
2010-05-12liquidzigong破解了大作 《王國之心 夢中降生》（需用插件）。
2010-05-15利用破解王國之心所制插件，liquidzigong破解了大作「噬神者」。並且所用的插件可以破解大部分6.20的游戲。可以說liquidzigong破解了6.20游戲。
2010-06-17liquidzigong發布了PSP3000獨占的CFW-5.03P版本，可以直接玩6.20游戲！
2010-06-29 6.30官方系統正式發布《啪嗒嘭2》存檔漏洞被堵
2010-07-29 6.31官方系統正式發布提高Digital Comics軟體運行穩定性（可能是為了封堵Digital Comics可能存在的漏洞）
2010-11-28liquidzigong宣布退出PSP破解活動。
2010-12-24 GEN小組發布了Total_Noob的6.20官方系統破解程序TN-A。
2010-12-25 liguidzigong放出基於TN-A的ISO引導程序Prometheus_ISO_Loader。從此，6.xx系統（包括PSPGO）可以運行ISO
2010-12-31 6.20TN-B發布，部分PSP3000可以通過TN-B降級到5.03系統。
2011-01-17 自製軟體簽名工具放出。從此，官方系統可直接運行自製軟體（包括自製系統刷寫程序）
2011-03-08 國人忠貞炙烈之炎發布 6.35/6.31 PRO-B2。破解接近完美。
2011-04-20 國人忠貞炙烈之炎更新 6.20/6.31 /6.35 PRO至B5，大幅度提高了其兼容性並修復了新的引導模式Inferno。
2011-06-20 國人忠貞炙烈之炎更新 6.20/6.35 /6.39 PRO至B7，添加記憶棒加速功能。記憶棒加速功能可以將ISO游戲讀盤速度提高25%~50%。
2011-07-08 國人忠貞炙烈之炎更新 6.20/6.35 /6.39 PRO至B8，重構部分Vshctrl代碼，改進系統兼容型和操作流暢度。添加對新開發的Popsloader for PRO的支持，完善PS1模擬功能。
2011-08-106.60官方系統正式發布
2011-08-25國人忠貞炙烈之炎更新 6.20/6.35 /6.39/6.60PRO至B9，修復積累的大量BUG和重構代碼，支持PSPGO UMD視頻掛載，修復了Inferno/np9660模式下待機時的出現的光碟機雜訊。更新解密部件，6.20/6.3x版本將支持未來的6.60新增PRX加密類型，為6.20/6.3x添加了6.60新增函數，兼容未來的6.60游戲存檔，新增6.60 PRO-B9，支持6.60固件（理論上支持包括11g的所有PSP硬體版本）。新增CPU頻率166/83，新增對打過KHBBS_patch的ISO的兼容性支持。破解日臻完美。
2011-10-30 PRO至B10，修復了ISOCache的無限循環、不支持>2G的ISO，和運行NFS碳化時賽道消失問題；ISOCache默認緩沖個數改為256；修復了PSPGo下從ISO VIDEO MOUNT模式啟動游戲；修復了啟動Recovery menu時極低幾率死機問題，以及Recovery menu中頻率顯示中無333/166的問題；修復了不能正確處理ISO文件名問題（thx to popsdeco）；修復了從USB掛載UMD時ISO大小問題（thx to neur0ner）；優化了補丁應用順序；修復了解密代碼中的問題；減小了FastRecovery的文件大小，加快了恢復速度（thx to neur0ner）；支持Satelite和Recovery menu的翻譯文件，並可以更換字體文件；啟動XMB時長按R鍵可禁用VSH插件；在Recovery menu中添加了Delete Hibernation（刪除休眠文件功能）以及顯示高亮效果；2011年版本支持了2G~4G的ISO/CSO讀取，就此psp宣告完美破解，所有自製軟體，游戲皆可運行。
2012-06-02 忠貞炙烈之炎發布6.20/6.35 /6.39/6.60PRO C系統，增加了WIFI聯機功能。此次更新雖然影響並不是很大，但仍是破解歷程上的一大步。
2013-03 忠貞炙烈之炎發布6.60PRO C2系統，修正了NoDRM引擎的一個小錯誤。
2015-01-15 SONY官網宣布對PSP進行6.61官方系統的更新。此次更新與上次6.60官方系統更新已闊別3年零5個月，索尼官網稱此次更新「提升了原有系統的穩定性」。原有自製系統在升級官方系統後失效。
2015-01-18 破解工作者wololo發布6.60/6.61PRO C2系統。至此PSP全部系統再次實現破解。

② 通過CMD刪除Win10休眠文件hiberfil.sys出現無法執行操作

1、這個隱藏的系統文件hiberfil.sys，體積超大，隱藏在系統盤根目錄下(除非你通過regedit注冊表修改路徑)。這一點與pagefile.sys文件(用於虛擬內存)不一太樣，pagefile.sys可以在計算機的系統設置中，自由修改轉移到哪個盤。

注意，要找到hiberfil.sys文件，可以在文件夾選項中，取消勾選「隱藏受保護的系統文件」，或者用winrar軟體定位到系統盤，查看這個文件。

2、下面，我們使用命令行工具，來徹底關閉Windows的休眠功能，並且希望徹底刪除這個體積超大的文件。首先，打開系統開始菜單中的運行(可以按下快捷鍵Windows+R)，然後輸入cmd，並按下回車鍵確定。

3、進入命令行界面。

4、命令窗口中輸入 powercfg -h off，即可關閉休眠功能，同時 Hiberfil.sys 文件也會自動刪除。

5、當然，上述方法可能不湊效，因為從Win7開始，一些程序運行必須以管理員的身份運行。

6、這時，可以找到系統盤文件夾Windows/system32中的cmd.exe文件，或者在開始菜單中，找到所有程序 > 附件 > 命令提示符圖標

7、右擊在彈出菜單中，點擊「以管理員身份運行」。然後執行上述的命令行任務，即可成功刪除Windows系統休眠文件hiberfil.sys

③ 怎樣清除新出的華碩筆記本bios密碼

找售後吧，他們能根據主板編號給出超級密碼

④ 我電腦物理內存寫的是2G，但是系統休眠文件卻只有1.48G，這是為什麼

更全面的回答 求採納

發這份筆記時，比較惶恐，因為連我自己都覺得，這個東西沒用。但是事實上，在很多偏門或機密的領域里，它仍然是非常有價值的。鑒於國內這方面資料比較少，所以寫了一篇筆記，與大家共享。

Analyze Hibernation File

Introction
What』s Hibernation File?
Hibernation File也就是系統的休眠文件Hiberfil.sys，位於系統卷的根目錄下。windows在系統休眠時，將物理內存中的數據（包括系統運行時的狀態數據）mp到Hiberfil.sys，並生成一個有效的文件頭。下次系統開機的時候，利用hiberfil.sys文件中的數據恢復系統。

How to generate a valid Hiberfil.sys?
從用戶的角度來說，系統停機時，按下休眠按鈕，則會自動生成一個有效的Hiberfil.sys。
從電源管理器的角度來說，只有當系統電源狀態從S0àS4的時候，才會生成一個有效的休眠文件。
註：當系統正常運行時，電源狀態為S0；完全關閉時，電源狀態S5；休眠狀態時，電源狀態S4,此時只有電源電路和喚醒電路才有點滴電流；中間的幾個狀態S1,S2,S3，都是不同程度的睡眠狀態。
從S4àS0的過程，也就是利用Hiberfil.sys恢復系統的過程。

Valuation of Hibernation File
It is quick and easy
恢復系統比重啟系統要快。不解釋（除特殊情況）。
A new method to mp physical memory
利用hibernation技術mp系統物理內存中的數據。這些數據包括處理器狀態，當前EIP, IDT table, GDT table, SSDT table,當前狀態的可執行代碼和數據…
利用這些數據可以分析系統狀態。

Leak Information?
Yes。正常情況下，利用Hiberfil.sys恢復系統，雖然恢復後會清除掉Hiberfil的Header數據(one page)，使之無效，但是Header之後的數據還會保留。利用外部工具，構造一個Header，就可以讀取該Hiberfil.sys的所有信息了。

Defensive uses
kernel –land malwares detection
分析hibernation file, 可以通過檢查SSDT, IDT, GDT表的完整性來判斷系統是否被修改。雖然在內核層有了更為輕量級的方法去檢測系統關鍵表的完整性，但是存在anti對抗問題，hibernation提供了一種終極檢測方式。
根據hibernation恢復原理，不在hibernation file中的代碼，將不會被恢復執行。基於此，可以對抗SMM rootkit。（不做介紹）
Offensive uses
可以獲取敏感數據，如：password, keys.
修改hibernation file, 提高某個進程的執行許可權；繞過系統登錄密碼…

Hibernation file internals
Headline of hibernation process
當磁碟被掛起時（S0àS4），Windows內核(ntoskrnl.exe)執行體創建一個hibernation file，並將物理內存中的數據用LZ77演算法壓縮後，寫入文件。
系統恢復時(S4àS0)，OSLoader.exe讀取hibernation file,載入解壓後的數據到物理內存中，使系統以一種快捷方式恢復到休眠時的狀態。
註：恢復過程的分析，見appendix 1。

Hibernation file structure
先直觀的看下文件結構圖：（左側，域列表，是文件結構的組成域）

format.jpg下載此附件需要消耗2Kx，下載中會自動扣除。

File Header
位於休眠文件的第一頁(0x1000 bytes)數據空間。該結構PO_MEMORY_IMAGE由內核調試符號導出。結構中主要包含了休眠文件的創建日期，版本號，校驗和，有效標志，物理頁數量等信息。
註：用休眠文件恢復系統時，只有第一頁數據被清0，也就是file header，其他數據保留不變。

FreeMap Page
包含一個ulong數組，保存了空閑內存頁的映射信息。

Processor State
處理器狀態，由內核函數KiSaveProcessorControlState保存。包括控制寄存器CRX，GDT, IDT, EIP…
結構定義如下：
typedef struct _KPROCESSOR_STATE32
{
CONTEXT ContextFrame; //
KSPECIAL_REGISTERS SpecialRegisters; //
} KPROCESSOR_STATE32, *PKPROCESSOR_STATE32;

註：從vista版本以後，欄位2和3的位置就交換過來了。

Memory Range Array
存儲物理內存頁的壓縮數據。
typedef struct _MEMORY_RANGE_ARRAY
{
MEMORY_RANGE_ARRAY_LINK MemArrayLink;
MEMORY_RANGE_ARRAY_RANGE MemArrayRange[MAX_ARRAY_ENTRY];
} MEMORY_RANGE_ARRAY, *PMEMORY_RANGE_ARRAY;

欄位MemArrayLink作為鏈接表指針，將多個這樣的結構鏈接維護起來；
欄位MemArrayRange指向數據區，最多包含255個入口。這也就是為什麼要存在一個指向下一個MEMORY_RANGE_ARRAY結構的指針MemArrayLink，因為當休眠文件很大的時候，一個MEMORY_RANGE_ARRAY存儲不了所有數據。

結構MEMORY_RANGE_ARRAY_RANGE定義如下：

typedef struct _MEMORY_RANGE_ARRAY_RANGE
{
ULONG PageNo; // ???
ULONG StartPage; // Block start (physical address)
ULONG EndPage; // Block stop (physical address)
ULONG CheckSum; // Always zero, but used under Windows 2000.
} MEMORY_RANGE_ARRAY_RANGE, *PMEMORY_RANGE_ARRAY_RANGE;
指定了頁開始地址和頁結束地址，在這些地址范圍內的數據都是經過壓縮演算法來壓縮後存儲的，這個結構所對應的整塊數據就是一個壓縮塊PageCompressedData，壓縮快的起始部分是一個結構體，如下：
struct IMAGE_XPRESS_HEADER
{
CHAR Signature[8] = 81h, 81h, "xpress";
BYTE UncompressedPages = 15;
UINT32 CompressedSize;
BYTE Reserved[19] = 0;
};
也就是說，壓縮塊的標識是：\x81\x81xpress；之後就是壓縮數據了。

註：每個壓縮快所對應的解壓後的塊大小為64KB(0x10 pages)。
compression algorithm
This algorithm has been publicly documented since recent Microsoft Interoperability initiative (February 2008)
壓縮塊演算法使用LZ77+DIRECT2；
LZ77用於壓縮內存數據，DIRECT2對位元組的位置進行編碼和解碼。

Project and Application
Sandman Project
該開源項目的主要特點是定義了休眠文件的文件結構，並給出了解析休眠文件的代碼。
不過，這份代碼中存在問題。在虛擬地址轉換成物理地址時，作者將頁面映射的PAE部分解析錯了。
如果開啟了PAE頁面映射機制（實事上，幾乎所有多核計算機都開啟了PAE），那麼MMU將會用三級表來實現地址轉譯，分別是：頁目錄指針表，頁目錄索引，頁表索引，頁位元組偏移，其中前三項都是8位元組長，而作者解析時將其作為4位元組處理了。
具體改法：在mm.c文件à MmGetPhysicalAddress函數中，將處理PAE的偏移，改為8；

註：4KB分頁時，地址轉譯只需二級表，頁目錄索引，頁表索引，每項4位元組長。

Tiamo NTLDR Project
作者Tiamo基本實現了一個完整的NTLDR，可以替換系統NTLDR，主要包括了利用休眠文件hiberfil.sys恢復系統的C++實現。不過我沒有測試過可行性。
項目包括兩部分：
16位實模式代碼；
32位模式代碼，即OsLoader.exe,是windows真正的32位入口程序。作者這部分代碼參考了NT4代碼，但是NT4代碼中並沒有實現恢復hiberfil的代碼，估計作者是通過逆向寫的。

Useful application
利用Sandman，開發了若干免費小工具，一般開發人員用不上。
可訪問：http://www.moonsols.com

解析hiberfil.sys,獲取系統版本號，休眠文件的創建時間，從休眠文件mp物理內存內容(見附件)。

ANTI SMM Rootkit應用;

其他方面，取證分析，以及未知的應用…

APPENDIX
簡述用休眠文件恢復系統的過程

開機過程中，BIOS代碼首先獲得控制權，執行完硬體檢測後跳轉到MBR，MBR代碼部分主要讀取分區表信息，然後將控制權交給系統卷的引導扇區DBR，DBR執行一些初始化後，讀取文件NTLDR,NTLDR中的16位模式代碼開始執行，同樣進行一些必要的初始化工作，然後將處理器切換到32位保護模式。
控制權交給osloader.exe, 此時處理器雖然已經工作在保護模式下，但是它的虛擬地址轉譯機制尚未開啟，所以，處理器仍然直接使用物理地址。
Osloader 在入口函數NtProcessStartup里，調用全局初始化內存函數：
DoGlobalInitialization()-> InitializeMemorySubsystem() ->
實現的功能是： 用一個內存描述符數組把每一段內存的大小和用途記錄下來，然後構造頁目錄和頁表，使得16M一下的內存能夠通過頁面映射(paging)機制進行訪問，在loader階段是不使用高於16M以上的物理內存的，在設置好頁目錄寄存器，並打開頁面映射機制。
之後，osloader 繼續執行其他的初始化工作，包括IO設備的初始化。
分配PCR的頁面-> 分配TSS的頁面-> 初始化內存描述符-> 初始化IO系統BlIoInitialize。

接下來判斷控制啟動的方式。
函數：BlStartup(BootPartitionName);
過程大概這樣：打開啟動分區，以便載入驅動；初始化屏幕； 讀取hiberfil.sys,如果是一個有效的休眠文件，則系統以hiberfil.sys方式恢復系統。如果不是，打開boot.ini文件，並顯示一個引導選擇菜單。如果boot.ini只包含一個引導選項，那麼，此菜單不顯示，而是立即應用該引導選項。

如果檢測到hiberfil.sys有效，osloader將控制權交給一段能恢復系統的代碼。大致流程如下：
打開hiberfil，不成功則返回-->成功則繼續恢復 --> 分配頁面緩沖-->解析頭文件,判斷image signature,有三種標志，分別處理,如果判斷標志出錯，就直接返回-->進行一些其他的校驗工作->接下來分配PTE,讀取內存映射頁面的數據-> 分配壓縮數據的緩沖->解壓縮數據到物理內存—> 再經過一系列的恢復工作-> 讀取處理器的狀態......

通過NT4代碼，分析NTLDR的工作流
boot/bootcode/mbr/i386/x86mboot.asm ->
這里執行MBR引導代碼，讀取分區表，獲得引導分區，將引導分區的第一個扇區，即DBR讀入到內存，然後將EIP調到DBR引導代碼，執行。
boot/bootcode/ntfs/i386/ntfsboot.asm ->
該函數主要用來讀取卷上的數據，主要是將ntldr讀入到內存，然後執行。（卷上的數據是根據文件系統格式存儲和管理的，所以訪問卷上的文件內容，需藉助文件系統代碼去讀。）到目前為止，程序還是在實模式下，即16-bit模式。
boot/startup/i386/su.asm ->
直接跳到 JMP RealStart,准備stack和segment，然後去執行suMain函數，該函數位於:
boot/startup/i386/main.c ->
來到了C代碼。這里實現一些初始化，包括video ,memory,foppy等。之後在回到su.asm，進行模式切換，至32-bit;
boot/lib/i386/entry.c ->
入口函數NtProcessStartup,這里，進行一些初始化，調用DoGlobalInitialization 初始化16M以下的內存，分頁機制開始啟動。又進行了一些system memory和I/O system的初始化工作後，理解調用BlStartup函數，也就是說ntldr在BlStartup函數中執行完畢後，就返回了。該函數在:
boot/bldr/i386/initx86.c ->
這個函數打開boot.ini，獲取啟動選項，繼續調用osloader.c;
\boot\bldr\osloader.c

註：NT4不支持hiberfil休眠機制，在XP以後的系統中，恢復hiberfil的過程在 BlStartup過程中被調用。

通過逆向分析NTLDR，分析hibernation file
這里只說下分析方法，省去細節。
恢復Hiberfil的工作是由osloader完成的，所以，通過逆向分析osloader.exe，可以了解恢復hiberfil的一些具體細節。

NTLDR位於系統盤根目錄下，是一個具有隱藏只讀屬性的binary系統文件，不能直接使用IDA進行分析。
NTLDR由兩個image組成，一個是16-bit下的binary image,就像是一個.com 文件；另一個是32-bit 下的PE file image，主要包含載入任務,這個PE image對應的文件就是osloader.exe。

提取osloader.exe的方法
用一個16進制編輯器(e.g. WinHex)，打開NTLDR, 查找'MZ'或'PE'標志，然後從'MZ'標志開始，將剩下的hex data全部復制並粘貼到另外一個空文件，重命名為：osloader.exe。用winhex的話，會很簡單（找到'MZ'標志，ALT+1，然後拖到文件末尾，ALT+2，這樣就選中的從'MZ'到文件末尾的區塊，然後右鍵'edit'->' block'->'into a new file')。
提取出osloader之後，用IDA載入，載入的時候會提示從MS官方下載'未公開'的符號，選擇YES或NO，等待分析，可能要花2分鍾左右時間。

分析osloader.exe文件
常理來說，osloader應該是一個native app,其入口函數是：NtProcessStartup。但是IDA分析後，入口函數為DriverEntry，當成驅動程序來分析了。但是，事實上，native app本質上就是一個驅動。
接下來就是利用各種資源，找自己關注的代碼區分析了。