Re: [請益] 要如何繞過Keypro的驗證?
: 推 purplebfly:重買一套或是換套新的吧...別自己找自己麻煩了 02/10 18:38
: → ofese0207:會不會 新電腦裝備太新 軟體不支援 新電腦的等級是？ 02/10 19:08
: → ofese0207:該不會是用六核心電腦灌win98吧 02/10 19:09
: 怎麼可能= ="
: 隨便找了一台P4的電腦就灌起來當Server了
: → ggg12345:keypro是硬體應該不隨意壞,常用LPport位址與中斷要設對. 02/11 00:38
: 最後整個資訊室的人都解決不了 只能採購新設備Orz
前面有高人提到 如果使用 DEBUG 這類工具讀出的會跟原來 keypro 讀出的不同.
對此種解釋法, 個人是不太同意. 另有高人提出 anti-debug 利用 8086 的 prefetch
instruction queue 已讀到 指令 進 processor 中無法被 self modifying code
就 queue 中指令立即覆蓋, 若用 debug 一步步做跟放其快速做再遮斷, 結果會不
同. 前一測試已說明 P4 cpu 不會有此種差異, 結果都跟一步一步做相同.
特地再從倉庫找了一台 80486-DX2 測試, 這個 CPU 就明顯有 self modifying
code 對 PFIQ 的效應.
就前一例的測式結果在 80486-DX2 為:
-d190 19f
14CC:0190 73 06 06 06 06 06 06 06-06 06 06 06 06 06 06 06
=======
1. 假如 keypro 用了類似此種手法防追蹤, 那就會變成 P4 CPU 與 80486-DX2 不
相容. 若原來是舊機器那就得用 PFIQ 相容的 8086 (如 486-DX2)cpu才是.
2. 使用 Vmware 或 其他 VM OS (如 QEMU) 提供 8086cpu 與 dos/win98 模擬環
境的虛擬機時應該會有 PFIQ 相容的選項適當設定才能達到完全相容.
→
03/16 23:06, , 1F
03/16 23:06, 1F
→
03/17 10:38, , 2F
03/17 10:38, 2F
→
03/17 10:38, , 3F
03/17 10:38, 3F
8086 pfiq 的副作用應該是設計時的一種失誤. self modifying code 一直都是
精簡程式與迷惑追蹤者的手段, 只是她更利用了 PFIQ 這個設計失誤的副作用.
會使得追蹤者掉入陷井增加難度. prefetch 是用來加快執行的, 利用 pipleline
的構思使 fetch cycle 與 execution cycle 可以併時平行加快速度. 原設計不
是用來防 debug 的.
推
03/17 14:20, , 4F
03/17 14:20, 4F
沒有這個副作用, 也是可照用這種 self-modifying code 來迷惑追蹤者, 但
對有經驗的, 不論那一種招, 很快就看穿過關了.
keypro 靠的是要認證這個 "keypro信物" 的存在, 只是不讓人知道檢驗的程
式在何處, 何時會被執行, 因此會防追蹤. 理論上, 虛擬機更容易偵測到這
種 i/o 動作的發生. 若是永遠不變的信物更容易被模擬出來.
→
03/18 11:50, , 5F
03/18 11:50, 5F
如果透過 debug 讀出來的結果跟其他程式讀出來的結果會不同, 那也不必用 debug
來驗證 prefetch instruction queue 的副作用了.
某些程式會干擾 debug 的執行, 但也未必就能全干擾得到, 那是看怎麼用.
用software做debug single step trace 的, 都知道 self-modifying code 會干
擾 next single step. 這現象不應說成 debug 可能會讀出不同的結果. 若是被監
測的與監測的產生相互干擾, 監測的儀器根本就不可能監測出被監測對象的正確效
應.
實況是選擇不相互干擾且正確必經的斷點觀測, 就能觀察出被監測程式的執行效應.
A 程式使用 PFIQ 產生的效果, 跟用 B程式 也是同樣使用 PFIQ 的效果如果會不
同, 那這個執行程式的硬體不可能會被認定是穩定可靠. 若(A+B)程式交互或同時
執行, A與B若沒有相互干擾, 結果應該跟各別執行是相同的效果.
debug 依舊是能判讀出某型 CPU 的 PFIQ 是否有副作用的問題. 檢驗法依舊是靠
極端特例的 self-modifying code. 此法本就會使下一步的執行受影響, 而難如正
常下, 不做特別干擾, 因此可於未執行前就事先觀察做預測. SMC是引入干擾使之
無法事先有可預測性, 必須待執行後才知曉, 但不影響執行後的可觀測性.
→
03/18 14:35, , 6F
03/18 14:35, 6F
一直還沒看你舉出一個 debug 跟 keypro 相關程式會讀出來不一樣的例子! 這疑問
跟誰老毫不相干. 這是個儀測的 load effect 基本問題.
→
03/18 18:00, , 7F
03/18 18:00, 7F
→
03/18 18:00, , 8F
03/18 18:00, 8F
→
03/18 18:02, , 9F
03/18 18:02, 9F
→
03/18 18:03, , 10F
03/18 18:03, 10F
→
03/18 18:03, , 11F
03/18 18:03, 11F
step trace 靠預測下一步先堵斷, 先預測錯誤可不是讀錯喔!
self-modifying code 做那一步時覆蓋了debug先堵斷的位置, 使真正的下一步
指令變了. 這是執行那步後更改覆蓋. debug 讀的並沒錯, debug 先設的斷點被
覆蓋失效, 無法使斷點發生 int3 進入不了 debug , 可不是 debug 程式去讀讀
錯.
debug step trace 是使每個單步執行前都事先預測可能的下一步,使之執行一步
前就覆蓋下一步的 op-code 為 int-3 , 靠 int 3 接回去 debug 顯示. 這動作
會改變實際執行次序, 使得逐步做跟快速放開隔距截斷的執行次序有所不同. 用
self-modifying code 更改 prefetch instruction queue 對應的記憶體位置,
將隨逐步接回 debug 的次序與放開快步做緊跟的指令次序有所不同, 有副作用
的 PFIQ 就因指令次序位置而產生不同結果. 這跟 debug 是否讀錯一點關係都
沒有.
沒有副作用的 P4 cpu PFIQ 就會照 self modifying code 的修改立即生效, 使
得逐步做跟放開快速做的結果都相同. 這是 CPU 硬體的特性問題, 不論是否有無
副作用, 都不會隨那種片段程式的執行而有差別性地因不同程式帶來差異.
Debug 程式讀的跟 keypro 程式讀的, 都作用在同一個 cpu, 不會結果有所不同.
這些 cpu 硬體也沒有做成會認得某個程式就讀出給x, 認得另個程式就讀出給y.
→
03/18 20:16, , 12F
03/18 20:16, 12F
→
03/18 20:17, , 13F
03/18 20:17, 13F
我在等你的程式例子. 別再拿self-modifying code 蒙混.
※ 編輯: ggg12345 來自: 140.115.4.90 (03/18 20:33)
討論串 (同標題文章)
完整討論串 (本文為第 6 之 6 篇)：