備份NVR監控錄影 一些策略與無限雲端備份整合

Posted on Leave a commentPosted in 軟體

想法的緣由
現在的監控設備鏡頭畫素越來越高,但是儲存容量有限,為了這些高畫質的錄影檔案還得為了怎麼儲存大傷腦筋,更不用說還得把這些檔案備份起來,在這一篇我們想要讓有限儲存空間的設備更方便省錢的解決這個問題有兩個部分要完成:

 

1. 錄影檔案的本地端備份再備份到雲端空間
2. 方便存取錄影檔案之外也能在行動裝置瀏覽

 

在這邊我們使用海康的設備來作為範例,不過在海康原廠提供的方案裡面,錄影檔是儲存在NVR本機的硬碟裡面,備份需透過原廠的Hikvision tools,而這個備份工具的備份檔又只能儲存在一個磁碟機根目錄下,不支援其他備份方法,這樣也造成如果電腦損壞,錄影檔的資料也跟著損毀,因此我們想到,如果透過有無限空間的Google Drive來備份就能提高安全性,而且放置於雲端在任何地方也方便存取,就不需要把備份的機器架設成檔案伺服器,也不用設定防火牆等麻煩的工作。

 

執行的規劃

與這個想法相對應的,我們需要做個規劃,因為要與雲端連結,頻寬是很大的關鍵。一般的錄影預設值的解析度(1080P)所產生的錄影檔相當龐大,在有限儲存空間上面會浪費空間且造成備份天數的減少,上傳也更耗時,所以要注意解析度的設定,建議使用1280*720P即可兼具畫質又節省空間,急需清晰度跟空間足夠用1080P跟4K都可以。

 

如果備份NVR同時又有很多台IP CAM正在錄影存到NVR,NVR的負載及頻寬會非常吃重,備份效率會大打折扣又造成網路緩慢。所以建議在只有少量重點需要記錄的時段設為移動偵測錄影,例如在上班時段要全程錄影,下班之後到上班之前的無人時段只要作移動偵測錄影(例如23:00~09:00),那麼就將移動偵測錄影設為23:00~09:00,而這段時間IP CAM不會將影片頻繁寫入NVR,備份的時間就可以設定在移動偵測錄影這段時間,就不會發生負載過重及搶頻寬的問題。

 

然後,算好NVR備份大約完成的時間,再找網路離峰的時段上傳。

 

備份的流程為:

工作時段NVR全程錄影 → 23點之後切換為移動偵測錄影並開始備份至虛擬機器 → 2點結束虛擬機備份工作,開始由虛擬機同步到Google Drive → 9點之前完成同步動作,NVR切回全程錄影

 

實作的設定

HIKVISION NVR只能用原廠的Hikvision Tools作備份到電腦上,而Hikvision Tools有兩個需要注意的地方:

1. 備份儲存只能設定為磁碟機,不能放置於某個目錄,請準備一個空的磁碟機來備份。
2. 程式是為32位元,在WINDOWS Server 2012 R2執行會有不可預期的錯誤, 且程式執行之後無法正常關閉, 使用任務管理員也無法強迫關閉,建議不要於2012 R2環境中直接執行。

 

而這邊我們是透過WINDOWS Server 2012 R2環境執行虛擬機器,可以安裝VMWare的虛擬機器安裝Windows 7/8來執行程式,便於公司管理且不用另外添購設備。

 

以下是備份環境的設定步驟:

這邊所使用的範例是Hikvision NVR DS-7832N-K2,搭配兩顆5TB做RAID 0,作為通常監控用的錄影設備。

第一階段,備份錄影內容,這邊我們是運用公司的伺服器製作虛擬機器來做為備份的主要設備:

1. 用WINDOWS Server 2012 R2建立一個2TB的虛擬VHD (VMWare不支援大於2TB的VHDX磁碟機)。
2. 在VMWare掛載此VHD。
3. 虛擬機器安裝Windows 7/8至此VHD之後安裝Hikvision Tools,將備份目的地設為此VHD磁碟機。

 

接下來,開始針對監控系統進行規劃,以下為監視器設定:

螢幕快照 2016-08-26 下午6.04.15

預設是1080P,4Mb/s 錄製起來檔案相當大,因此改為 720P,1024Kb/s 播放品質不會差距太大,但檔案大小差距很大。

 

螢幕快照 2016-08-26 下午6.05.17

錄影時段的安排上,我們設定9點到23點為全程錄影,23點至9點為移動偵測錄影,減低閒置時刻的錄影量。

 

再來是虛擬機器上 Hikvision Tools的設定

螢幕快照 2016-08-26 下午6.12.33

設置的裡面,將備份目的地設定為虛擬的2TB磁碟機,另外當備份空間不足時就開始覆蓋掉舊的紀錄。

 

螢幕快照 2016-08-26 下午6.13.14

設置備份計畫管理裡面,我們安排在23點之後開始備份,因為23點開始我們改為移動偵測錄影,IP CAM此時的傳輸量大幅降低,預估備份在3小時內完成,這是怎麼預估的,請看下一張。

 

螢幕快照 2016-08-27 上午10.52.21

在這邊我們看到,備份總大小約為45GB,總共花了一個半小時,這是23點至9點沒有事情發生所以沒什麼錄影檔案的量,假設負載更大,也不太可能超過90GB,所以我們設定3小時內完成NVR的備份工作,這是透過實際操作後再調整過的數值。

 

要這樣使用的時候請注意畫質備份檔案總量備份起始時間備份持續時間備份結束時間備份設定切換,才能順暢的自動執行。

 

接下來就是在虛擬機器端如何把檔案同步到Google Drive。

 

我們研究過了一些軟體,雖然是做到雲端的同步,但是只能覆蓋舊有的,或者在比對上容易出錯,目前找到較好的解決方案為 Syncovery,可以直接設定 Google Drive 帳號及備份資料夾,本身又有增量備份等方式來比較檔案狀態,一套就可以搞定。

 

螢幕快照 2016-08-27 上午11.46.20

上面可以看到Right-hand side是直接指定Google Drive的NVR這個資料夾,要選不同的雲端服務就按下地球來選擇,大廠牌都有支援。同步模式我們是選SmartTracking,會去追蹤比較上傳檔案的狀態而留下記錄,這邊可以根據自己的需要修改。而這套的好處是不會刪掉舊有的檔案,有的同步是一直覆蓋掉舊檔,但是如果遇到現在的加密病毒,當檔案被感染,又上傳上去,那會全部都毀壞,但是如果軟體是增量備份而不是覆蓋舊有檔案再備份,就不怕遭遇全面性的毀滅。我們設定的同步時間為4:00,也是使用離峰的時間,到9:00之前來完成同步。

 

這個是實際執行的log,我們可以看到總共上傳41.7GB,使用了約52分鐘的時間來完成。

 

注意事項:
Hikvision Tools要用v1.2.1.2(或之後更新版本), 在中文(簡體)網站是有問題的舊版,用English-Europe則可以直接下載,下載網址: http://overseas.hikvision.com/europe/Tools_82.html#prettyPhoto

 

行動裝置的瀏覽

設定完成之後,就會備份至雲端空間,因為備份出來的影片檔是MP4格式,這個時候我們就可以透過行動裝置去查看之前錄影下來的畫面,因為原廠提供的軟體在跨平台瀏覽上常常會有錯誤或失敗,使用Google Drive是個可靠許多的選擇。下面是操作的效果

IMG_7021
在iPhone上使用,可以看到錄影的日期,裡面會有各個IP CAM錄下來的畫面

 

IMG_7022
可以即時播放錄影片段,延遲也很低。

 

IMG_0254
iPad上的使用也沒有任何問題

 

IMG_0255
支援Google Drive的裝置都能輕鬆使用。

 

因此這個方法提昇了錄影資料的保存可靠度,也提昇了使用上的方便程度,也不用煩惱所使用的裝置是什麼平台,因為Google Drive在各平台上都能使用。又大幅減低儲存設備容量的依賴,就算儲存設備本來的容量不夠,但是因為有Google Drive 作為後盾就可以省去添購NAS或大容量磁碟陣列的開支。對於想省錢又不想犧牲安全度相信會是個不錯的解決方案。

 

 

精靈寶可夢 ios 外掛下載與用法

Posted on Leave a commentPosted in 軟體

messageImage_1470563167068

2016 8.25 更新
本外掛 目前已經無法工作 請學習外掛開發精神跟自我簽證書用法

感謝ADR的傑作 Hacking iOS PokemonGo for iOS 版本
https://github.com/aaaddress1/madPocket

內有自動孵蛋+自動走到指定坐標+控制器(前後左右)功能

無jb 版要自我證書簽章

這邊講傻瓜方法是 把機器UUID給 有開發者帳號朋友請他給證書.. 如果沒這種神人朋友 就去taobao買吧

然後會有二個文件檔 以下必須在os x底下完成
打開 p12 副檔名文件 輸入賣家會給你密碼. 使用iresign 重新簽名
https://github.com/aaaddress1/madPocket/releases/download/v4/adr.pokemongo.ipa.zip

27c375dba05077739d7c09738cc308ce

直接用itunes 或itools 安裝ipa 到ios device上

有jb 會比較省事 
https://github.com/aaaddress1/madPocket/releases/download/v4/adr.pokemongo.ipa.zip
解開 就直接用itunes 或itools 安裝

但是要先安裝反越獄偵測補丁
建議先裝xcon 42b1版
http://mrmad.pixnet.net/blog/post/154258991-%5Bcydia-for-ios7%E3%80%81ios8%5D%E3%80%8Cxcon%E3%80%8D%E8%A7%A3%E6%B1%BAjb%E5%BE%8Cline%E9%81%8A%E6%88%B2

玩了幾下已經九級捕獲二百多隻 ..

 

不同Raid Stripe大小對效能的影響

Posted on Leave a commentPosted in 軟體

什麼叫Stripe size

126427_orig
在raid card上有個stirpe size
單位為 64 Kbbytes = 128 Sectors

 

透過不同型態的RAID架構來評估Host-CPU的使用狀況….

基本上要指出到底從I/O request發出中斷使CPU被干涉多少次…

先放這張, 後續整理完後在貼上:

summary201012210102

從這張圖不難看出, Driver-based RAID體下,所有相關RAID計算都必須依靠Host CPU協助, 例如像是Stripping, 相關的計算都會引發對CPU的I/O請求觸發大量的I/O中斷操作. 看看SSD; Max I/O Read Test好了…

當條帶尺寸為8KB的時候, 這是一個較小的尺寸,在大量I/O的情況下, 是必要依靠Host-CPU多次操作8KB條帶切割/重組到不同的Disk, 尺寸很小的話, I/O需求量相對也會提高, 你可以看到8KB所觸發的中斷數量達到5萬多次, 反過來看看IOP-based RAID, 由於LSISAS2108透過built-in processor的這種協同式處理器, 像這類條帶操作都會被依賴到RAID chip上的built-in processor操作, 自然而然, Host CPU相對於I/O請求所觸發的中斷操作就明顯減少許多. 你可以注意到8KB的情況下, Driver-based RAID和IOP-based RAID明顯相差有10倍左右, 這意味著IOP-based RAID有更好的操作性能.

另外從Driver-based RAID看到, Response Time也有所不同, 對於I/O請求所需的回應時間, 大量I/O情況下, 我從們128KB來看, 最大Response Time相差了30ms左右, Avg. Response Time也有10ms之差異, 明顯可以看到IOP-based RAID這種Hardware RAID有更低的I/O延遲性.

CPU Effectivness指的是子I/O系統操作對於CPU所獲得的效益, 子I/O系統建構在kernel之下,子I/O系統包含了對各種裝置驅動程式(Device Driver), 裝置驅動程式的下層就是相關的控制器. 基本上這是可以算出來的:

CPU Effectiveness= IOPS / CPU Utilization

可以得到每單位使用量所能獲取的I/O效益, 這意味著大量IOPS情況下, CPU被過少的干涉(意味較低的CPU負載), 所能得到的效益就愈高, 你可以很清楚的看到Hardware RAID所獲得的效益遠遠高於Driver-based RAID. 雖然, ICH10R僅支持3Gb/s, 就算是6Gb/s也無法改變當前這樣的情況, 我懷疑支持6Gb/s可能會需要更多的I/O操作.

LSI不同RAID Stack測試(For LSISAS2008)

Posted on Leave a commentPosted in 軟體

此篇為LSI IR與IMR Stack之間的比較測試… 不過在此之前還是說明一些LSISAS2008相關的特徵 先看架構方塊圖…

924593_orig

 

可以看到有幾個部件, 大體上有一些重點:
1. 這是Software RAID, 硬凹的話, 沒意義的稱作"Hardware-assisted Software RAID", 有沒有比較好聽 了一點呢?
2. Fusion MPT是一個I2O裝置, 主要拿來和Host協調.
3. 這顆有整合PPC440 533MHz IOP, 但是明確用途不知, 姑且稱作他會有副作用.
4. 2MB SRAM不是Cache喔, 請注意! 他只是單純的buffer用來存放相關的FIFO數據.
5. 那個32-bit Memory Bus是串接低速的OPB Bridge, 銜接例如FLASH, NVRAM這類等.
6. LSISAS2008的internal Bus應該是PLB4, 128-bit, crossbar架構, 頻寬其實很大.

再來看另一張比較:

intel_compare

這張左邊兩個當然是Intel自家開發的RAID Stack.. ERST2只會在它們自家的Server主板才看的到.. RST就應該不用說了吧..
這邊有一個重點特性, 就是IR3 RAID其實就是MegaRAID… 但是要點在於那個Persistent Controller Log… 這是一個與Event Log不同的地方..

他是Firmware Log, 這是極為有用的除錯Log…. 對應LSI就是TTY log…
MegaRAID支持這項機能…
這項功能相當有用… 相關的相容性問題或著錯誤問題可以由這Log來查…

另外IR的Software Stack支持MSI-X 當然我是指6Gb/s以後的產品…

3Gb/s產品全部都只能運行在Legacy Mode… 這是一個相當重要的特徵.. 雖然他不是甚麼新技術… IR和IMR的支持有所不同… IR提供大量的IRQ資源…

ir_irq_resource

IMR比較基本面…

mr_irq_resource由於在用途上有所不同因而有差異… LSISAS2008在IR下.. 不支持Stagger Spn-up 不支持Spin-down 相關的MAID機能通通都沒有.. 而在IMR下就是相反了…

下面就是不厚道的貼一部分測試.. 這邊是故意拿兩顆SAS HDD來測試… Seagate的7.2K SAS ES2… 直接就是RAID 0, 64K ioMeter不同測試設定: (QD深度從1個單位達到沒啥意義的256) >>Read(讀取)

io_meter_read_config

>Write(寫入)

io_meter_write_config-1

結果表(請點擊放大觀看):

io_meter_stack_compare

結果不好說…
不方便講可能的原因性, 不做亂猜測.. IMR的Response Time和Intterupts比IR高出不少…

下面這個HD Tach的情況比較怪異, IR連續測了4次左右, 結果一樣, 寫入很奇怪!..

>IMR情況

megaraid_hdtach

>IR情況

ir_hdtach

歡樂的ATTO當然是少不了的, 一律直接QD10…

>>IMR情況

megaraid_atto_qd10

>>IR情況

ir_atto_qd10

IR的情況也同樣比較詭異… AS SSD直接測SEQ. I/O:

IMR情況

megaraid_asssd

IR情況

 

ir_asssd

沒有差距太遠, IR我也是跑好幾次, 寫入似乎偏弱….. 最後的HDD Tune看看就好(其實沒甚麼參考性)…

IMR情況

ir_hdtune_write-1
ir_hdtune_read

IR情況

megaraid_hdtune_write

megaraid_hdtune_read

###關於LSISAS2008的補充: 對岸網友的詢問:

唉,有時候真的會弄不清楚這些 RAID 的種類,不知道這樣說對不對:
– 軟RAID,Driver based 的,就是不裝 driver 認不了的那種,例如 ICH, P67
– 軟+硬 RAID,可以支援 Firmware based RAID,不裝 driver 也能夠認得了,不過沒有自帶 IOP (?!),所以 RAID 5 靠 CPU? 例如 LSI SAS2008
– 全硬 RAID,有 IOP 可以算 RAID 5,不用 Host CPU 自己全部搞定,例如 LSISAS2108

“- 軟RAID,Driver based 的,就是不裝 driver 認不了的那種,例如 ICH, P67
– 軟+硬 RAID,可以支持 Firmware based RAID,不裝 driver 也能夠認得了" 都要裝driver(除非你打穿它(pass-through), 但是這樣不能用相關的RAID Utility做RAID)… 不管firmware-based RAID或著driver-based RAID也好..
他們全部都是Software RAID…
你可以把像ICH10或著P67這類稱為典型的ROMB RAID… 確實LSI可能在f/w封裝RAID算法..
不過這依然改變不了LSISAS2008是S/W RAID的事實…
像依照主板晶片採用的RAID..
例如Intel封裝的RST…
這類也可以稱為Firmware-based…
他依然有封入相關的RAID代碼在firmware… 不過通常是相關的啟動暫存器和相關的RAID BIOS代碼…
沒有所謂的軟+硬RAID…
稱其為H/W-assisted S/W RAID也只是針對LSI產品的特殊性…

“不過沒有自帶 IOP (?!),所以 RAID 5 靠 CPU? 例如 LSI SAS2008″ 我想你指的IOP應該是指I/O Processor.. 不過LSISAS2008本身就是一種IOP… 我認為你應該要有更明確的稱呼….

Pure-H/W RAID的條件很簡單:
1. Hardware RAID Assist的存在
2. Internal MCU做為控制硬件Cache Memory的設計
3. Built-in Processor的存在
4. firmware stack的控制必須要將相關的I/O Processing轉移到RAID Controller上處理.. 可以看如下這張方塊圖…

lsisas1078_layout

ppc440spe

在記憶體控制器部分..
他銜接了XOR Engine..
你可以把XOR Engine稱為XOR加速器.. 這個是決定H/W RAID的最大關鍵… 根據這個設計與AMCC的PPC440spe幾乎長一個模樣..

如何用 PC3000 做Seagate Building Self Test(自校準)

Posted on Leave a commentPosted in 軟體

4884297_orig

servo2

Self Test 是真正的low level format 具有良好維修效果.
邊做磁訊號效果測試 邊做servo pattern 寫入
是工廠標準生產流程也是RMA必跑測試
像Seagte 是設計專用機台以TTL 連接硬碟通訊

限於智財權,東歐Hacker 想盡辦法去做協定分析.
找出低階通訊協定,再自行以軟硬體去包裝

使用昂貴 PC3000 UDMA 啟動方法:

先從其他同系列 +同主控晶片組 硬碟備份LDR

從這開始

1.進入安全模式 如果是用 非UDMA 內建可切換電源 需要自己手動硬碟斷電 通電
safe
2.切換Bandrate 速度為921000 最高
bandrate
Self Writing 啟動方式

1.選這加載LDR :選Starting LDR
LDR Start
以安全模式加載 LDR 請參考圖
LDR
如果是用 非UDMA 內建可切換電源 需要自己手動硬碟斷電 通電1~2次

如果 CERT table 中有99要改掉(99=stop) CERT 可以另存 module 改掉 後 , 再額外指定
指令E4E 檢查已做好的self Test 流程跟時間 (Exam 4E)
指令T4E 檢驗預定做的Self Test流程

1.終端下輸入ctrl-z
把速度改回9600 bps
再輸入 #,,22 (改序號 ) 按下Enter
前三碼跟磁頭有關 不可亂輸入 如果磁頭沒變化就一樣 (9QF12345)
再任意輸入PW 五位數(12345 ok)

2.N2,,22 (2代表從第2步開始做 ,,22 是確定執行) , (所以 N94,,22 是 從 94 開始)

3. 再按下 ctrl -t執行

. 可以看到目前流程

: 可看age
硬碟AGE 說明 代表目前硬碟狀況

硬盤安裝和伺服校正測試
TEST 01 – 製造臨時日誌
TEST 02 – 格式化和測試錯誤日誌
磁頭和電路校正測試
TEST 03 – 伺服校正信息
TEST 04 – 斜波加載/卸載測試
TEST 05 – 傳感器滯後測試
TEST 06 – 磁頭切換測試
TEST 07 – RUNOUT補償測試
TEST 08 – 當檢查伺服錯誤時盤上寫入2T類型
TEST 09 – 磁頭低飛顯示
TEST 0A – 磁頭穩定性測試
TEST 0C – 讀取伺服缺陷測試位置
TEST 0D – 重學RRO ZAP測試
TEST 0E – 尋找跳過柱面測試(還未實現過)
TEST 0F – 當前寫測試 磁頭和電路校正測試
TEST 10 – 1E, 2A – 2E 適配區域#(最後區域)通過 0 -所有磁頭
TEST 1F – 顯示適配性,VCO,和DIODE溫度設置
TEST 2F – 顯示FIR適應性設置 伺服性能驗證測試
TEST 20, TEST 60 – 伺服訪問次數
TEST 21, TEST 25 – RRO/NRRO 測試
TEST 23 – 開始/停止 (10次)
TEST 24 – 開始/停止 (2000次)
TEST 29 – 伺服缺陷掃瞄
缺陷查找和再分配測試
TEST 30 – 驗證所有磁盤組讀取,AT級
TEST 31 – 楔形缺陷掃瞄. 磁頭 0-1無讀取級,50寫級
TEST 32 – 楔形缺陷掃瞄. 磁頭 2-3無讀取級,50寫級
TEST 36 – 在對磁頭0-1楔形掃瞄中查找出來的缺陷進行定位
TEST 37 – 在對磁頭2-3楔形掃瞄中查找出來的缺陷進行定位
TEST 3A – 使用1重複讀取所有磁頭拋光和缺陷測試,重複50次
TEST 3B – 建立缺陷表;填充受損磁頭0,1
TEST 3C – 建立缺陷表;填充受損磁頭2,3
TEST 3D – 建立缺陷表;填充受損磁頭4,5
TEST 3E – 建立缺陷表;填充受損磁頭6,7
TEST 3F – 回送測試,寫通過測試
錯誤率性能測試
TEST 40- 開始/停止(10次)
TEST 41- 磁道侵入
TEST 42- SPIN STAND模擬器- 區域較小錯誤碧綠
TEST 43- RAM 測試
TEST 46- 數據編譯比率
TEST 47- 冷寫/磁道擦除顯示
TEST 48- 錯誤率,寫通過
TEST 49- 寫/讀/比較(零式樣)
TEST 4A- 補償係數檢測
TEST 4B- 讀
TEST 4B -所有磁道冷寫顯示
TEST 4C- 磁頭飛行高度測量
TEST 4D- 收集自動FA數據
TEST 4E- 檢查積累健康和創建自檢概要
TEST 4F- 失敗磁盤測試
TEST 50- 通過磁盤測試

AGE 50正常就為正常 再寫入APP to HDD 就可


原作:http://bbs.intohard.com/thread-111709-1-1.html
下載

Windows XP VM建立

Posted on Leave a commentPosted in 軟體

微軟供應的XP SP3 mode 不是單純vhd file ,為exe file 因此需要用VMlite 程式先提取出vhd 檔案.以下為說明

1.下載
   XP mode file    http://www.microsoft.com/windows/vir…/download.aspx
   VMlite plugin   http://www.vmlite.com/index.php/down…setup/download

2.執行安裝下載的VMlite plugin
   步驟如下:

2902334_orig

破解Windows 登入密碼實驗

Posted on Leave a commentPosted in 軟體

未用EPS 加密 的Windows 2000 ,2003 Sever , XP ,7   ,Vista 各版本 (已經過實測 ,2008尚未)

Windows 將其登入密碼存入於註冊表的  SAM     HKEY_LOCAL_MACHINE\SAM     使用者及密碼的資料庫
以可讀取Ntfs 分區的開機os 開啟後,再用 Offline nt 修改windows sam文件系統
若帳號資料在AD內 ,無法修改.

指紋辨識原機器也將其指紋密碼存SAM  因此用此法清空後也可登入系統.

參考本文後配合 微軟官方全部 VHD image file +虛擬機 可以實證全部狀況

另外方法. 

1.http://ophcrack.sourceforge.net/
2.http://jay-fva.blogspot.com/2009/12/…nistrator.html

參考前文準備好 下載 XP mode 檔案,並轉成 VHD file , 

啟動此  XP  VM VHD in Virtualbox
剛好XP mode 的VM 預設administrator 一定要設定密碼

實作 Apple Macbook EFI 軔體漏洞寫入破解

Posted on Leave a commentPosted in 軟體
研究人員爆Macbook漏洞:可讓駭客遠端改寫BIOS植入木馬
https://reverse.put.as/2015/05/29/the-empire-strikes-back-apple-how-your-mac-firmware-security-is-completely-broken/
以上安全報告再說Apple 的EFI  write protect 進入S2(睡眠模式)後就可解除防寫保護.說真的挺嚇人的,因為光官方 Apple 綁定EFI  bios 防寫區 這塊有二大應用.一般不具程式經驗人也可操作.
1.Find My computer ,贓物機序號會鎖定,如同iphone一樣.這樣就可以修改機器序號回寫.
2.Apple 官方維修中心則是用AST(Apple Service Toolkit) 會連回GSX Server,主機板更換後,對全新主機板ROM 安全區寫入序號,只能寫一次.

(os x 10.12 Sieera 已經防堵 DirectHW 讀取EEPROM)

“非官方"則在做EFI的rootkit應用. 就不論是重灌OS X或是替換硬碟都無法清除.來看一下是怎回事brew 編譯的flashrom版本有問題  只好自己編譯
沒brew的先安裝brew 請自己google一下
brew install flashrom
brew uninstall flashrom   解除安裝不能正常工作版  這樣就有flashrom需要的lib 下載我已編譯好的FW 工具包 http://0rz.tw/8feFX
內有 DirectHW.img pciutils-3.1.7.img  跟flashrom 主程序 解壓縮二個img跟安裝
安裝完後跑載入driver
sudo kextload /System/Library/Extensions/DirectHW.kext
這時flashrom 程式應該可以工作
先下一次 這個指令
sudo ./flashrom  -p internal -r “Dump rom 檔名"
然後之後的會顯示對應IC 如Macbook Air 2013 Late 就MX25L6405 SPI ROM,要用 -c 指定SPI ROM
sudo ./flashrom  -p internal -r mbp-late-2013.bin -c MX25L6405
當休眠過再輸入一次指令,沒顯示read-only,就代表MAC EFI ROM已經任你魚肉了可寫入.請參考圖

 

4903238
有防寫區保護

 

5050498_orig
進入S2睡眠狀態再喚醒檢查過後 ,寫入保護就失效了.
以下列出OSSLasb測試成功跟失敗電腦 有空會慢慢更新清單.
成功
MBA 2011  13″  SMC :1.73f66
失敗
MBA 2013  13″  SMC :2.13f15

當然你用SPI 編程器做硬體寫入或是thunderbolt(也是不能太新FW) 漏洞,寫入EFI BIOS安全區還是行的,只是要在必需實體接觸跟短時間內辦到不容易.

從mov檔碎片分析談File Carving 原理

Posted on Leave a commentPosted in 軟體

前言:

一. Raw Recovery File 原理
當誤Ghost 純系統到儲存裝置,這時候Filesysem Index (如NTFS的MFT)損壞時,檔案系統檔案跟目錄名稱都無法辨識.
這時候只能用File Carving (Raw Recovery) ,從原始扇區hex的原始hex中“雕刻”出某些檔的“形狀”。
所以這狀況會需要從LBA 0跑到底.會很耗時間

File Carving技術就是基於檔案結構特徵和內容特點的,“架構”出檔案來。

什麼時候需要做File Carving?

例如遇到整個分區被誤格掉然後又有其他資料複蓋掉原本的分區的索引Data,用一般的救援軟體是無法回復的 也沒有原有的文件名稱。
此時就必須利用碎片搜索文件雕刻的方式慢慢的將想要的文件重組回來。
但重組回來也不見得是完整的檔案,必要時仍然必須將檔案處理過後才可使用。

但對影音檔而言,經常遇到即使在無覆蓋風險的情況下,恢復出來的視頻也是不完整的。原因在於傳統的資料恢復技術通過系統資訊進行的資料恢復不具有資料偵測能力,一旦資訊不完整,即使資料仍保留在數位設備中,也無法恢復。沒有了可依賴的系統資訊,我們唯一可以做的就是利用影音檔的結構特徵和內容特點,在“無差別”的資料區中偵測每個“未分配”的資料簇,判斷它們是不是我們期望得到的視頻碎片資料。在一個忽視系統資訊的環境中,如何偵測到每個影音檔碎片,並將它們有序銜接起來,並非本文研究的重點。這有許多工具可以做到。

本文要探討的是屬於資料重建中很難處理的視訊檔重建。而在過程當中最常碰到的問題就是MOV檔的重建,也是本文所要討論的重點。

二. 常用工具R-Studio是怎麼做的?

很多專業資料恢復公司使使用R-Studio這套軟體來做數據恢復。所以我們先來看看R-Studio怎麼做的。
實際上在救援的經驗當中發現R-Studio對於碎片搜索檔案重建的結果很不理想。

根據R-Studio的說明書中的Customizing File Type一節中,使用者可以自訂檔案的特徵值,請參考這是下載說明書看。
更詳細的說明書可至http://www.r-tt.com/zhhk/TechnicalSupport.shtml 下載。
我們以MP4檔案為例,檔案是 https://support.apple.com/en-us/HT201549 中的sample_mpeg4.mp4,下載後用Winhex打開。後可以看到MP4的特徵值。
8325402_orig

在檔頭的部分可以看到ftypmp42及mp42mp41。連續性的值(16進位)是
00 00 00 18 66 74 79 70 6D 70 34 32 00 00 00 01 6D 70 34 32 6D 70 34 31
所以這個mp4檔案的特徵值是可以寫成底下的方式以供R-Studio搜尋時使用。
\x00\x00\x00\x18ftypmp42\x00\x00\x00\x001mp42mp41

當然,MP4檔案的特徵值已直接被R-Studio所支援,使用者不需另外創立。當然R-Studio也有內建MOV的特徵值,但為什麼MOV檔案重建後的結果很不理想呢?我們推測是可能檔案重建時只有做Raw Data特徵值的比對,所以當特徵值某些部分被蓋掉後就有很大的機率判斷不出來或是誤判。為什麼會發生這樣的情況了,其實這跟MOV檔的特徵值有關。所以要做MOV檔案的檔案重建呢就必須先了解MOV檔的檔案結構。

三. MOV的特徵值
我們先來觀察一下正確的MOV長什麼樣子,下載 Apple官方的Sample mov
用Hex軟體打開後可以看到如下的檔案資訊。
4269934_orig
MOV檔案有幾個重要的Atom,Atom是QuickTime檔案的基本數據單位,每個Atom包含了大小跟類型以及之後的數據部分。Atom主要格式有wide、mdat、moov等。MOV檔在檔頭是由一些連續性的組塊(Chunk)所組合而成,每一個組塊是8個Byte:前面4個Byte代表組塊的大小,後面4個Byte代表組塊的類型。
現在跟大家介紹一下MOV檔頭是根據ISO制定而成,各有其意義。首先看到
offset 0~3分別是00_00_00_20。這個代表了這個box的大小總共有32個Byte。offset 4~7分別是66_74_79_70,指出這個box的類型是ftyp。
offset 8~B分別是71_74_20_20,指出這個類型的商標是qt(QuickTime)。
offset C~F分別是20_05_03_00,指出這個商標的主要版本。
offset 10~13分別是71_74_20_20,指出這個商標的相容的商標是qt(QuickTime)。
3617933_orig
看完了檔頭的box之後,我們來看wide atom,從這裡開始即完全要遵照Qucik Time File Format所定義的來做。
offset 20~23分別是00_00_00_08,代表了這個atom的大小總共有8個Byte。
offset24~27分別是66_74_79_70,指出這個atom的類型是wide。
在wide atom之後是另一個atom。wide atom 是表示後面是個擴展的atom,後面接的是mdat atom,也是資料主要的地方。
offset 28~2B分別是00_31_CA_34,代表了這個atom的大小總共有3263028個Byte。
offset2C~2F分別是6D_64_61_74,指出這個atom的類型是mdat。

那mdat atom的結尾在哪呢?來計算一下
0x27+0x31CA34=0x31CA5B
4008674_orig
mdat atom之後就是moov atom,moov atom由0x31CA5C開始。
offset 0x31CA5C ~0x31CA5F分別是00_00_52_C5,代表了這個atom的大小總共有21189個Byte。
offset 0x31CA60 ~0x31CA63分別是6D_6F_6F_76,,指出這個atom的類型是moov。
在這邊看到moov atom後面還有一個子結點mvhd atom。mvhd是moov的檔頭。
offset 0x31CA64 ~0x31CA67分別是00_00_00_6C,代表了這個atom的大小總共有108個Byte。
offset 0x31CA68 ~0x31CA6B分別是6D_76_68_64,,指出這個atom的類型是mvhd。
現在可以來驗證一下檔案長度是否正確,0x31CA5B+moov atom的長度
0x31CA5B+0x52C5=0x311D20。跟截圖的值是吻合的代表沒有算錯。

5856085_orig
由此可知,除了檔頭之外atom的資料也不能有錯誤,這樣才能正確的救回MOV檔案。但假如原始的資料被破壞太多的時候就會有資料不全的問題產生,導致救回的MOV檔案格式是錯的。
四. 案例分析
67072.mov是一個用R-Studio救回來的MOV檔,發現無法預覽畫面用VLC撥放器也無法撥放。用Winhex打開後觀察MOV的特徵值會發現重建後的資料是錯的,軟體將原本應該是檔案尾的moov資料寫到檔頭來了,造成撥放器無法撥放此檔案。
9927279_orig
將多餘的檔頭砍掉後即可發現已可播放幾秒鐘的畫面,此時檔案雖然已經可以預覽了但仍然不是正確的MOV檔,原因是少了後面的moov資訊。這時要將moov資料重建,重建moov資料後即可正常播放影像。

7652083_orig

5880577

為何檔案可以預覽這麼重要呢?因為當用Raw Data Recovery一次拉出來可能會有幾萬個檔案,這時確認是否是重要的資料的程序就很重要,利用此方法可以先預覽畫面確認檔案的重要性之後,再去維修檔案。