發表文章

目前顯示的是 一月, 2015的文章

[C][ASM]微軟的函數頭定義要mov edi,edi的原因

在C的規範下的組語,函數頭形式會做
push ebp
mov ebp,esp
sup esp, n//stack資料轉區域變數空間
/*...接著就可以存取[ebp+4*k]的參數...*/
add esp, n ( or ret n)//平衡堆疊
pop ebp
ret
幾個比較神奇的事情:

1.
MASM為啥頭函數要多一個mov edi,edi
該不會是為了湊足五個字節方便我們破解者Hook吧XD?

2.
為啥wsprintf要使用者自己平衡堆疊?

3.
有些函數明明就不需要參數
為啥還是需要做enter跟leave?

XTab新型惡意瀏覽器插件病毒手法紀錄

圖片
可惡...本來只是想下載一個國外的殼破解版,結果又中菜花了T___T
我覺得這樣下去總有一天我會中過每種毒然後都解過一次毒XD

XTab新形態的惡意瀏覽器病毒會做的事情:

會安裝一個叫做XTab的安裝包啟動一個叫做Au__.exe的東西一直檢測各種瀏覽器首頁有沒有被流氓綁架
(如果沒被綁架 它會幫你在綁架一次)接著又是老梗的在各個瀏覽器上安裝流覽器插件設定你的瀏覽器啟動參數額外增加綁架網址設定你的瀏覽器啟動首頁成綁架網址你的windows的程式集內的瀏覽器的路徑也會被下綁架網址你的桌面上如果有瀏覽器的捷徑也會被下綁架網址你的工作列上如果有對程式"釘選"(固定程式ICON在工作列上)被下綁架網址會在XTab資料夾內找到三個DLL...用DLL Injection方式注入到explorer.exe
(你剛中毒的時候會發現資料夾管理員會崩潰一次就是這個原因,可能病毒作者沒寫好導致的,有夠蔡逼巴...雷....)
大致上提一下解毒方法:
把所有流覽器從工作列上"釘選"給取消工作管理員打開,找到公司名稱是"XTab"的,通通強制關閉並且刪除/反安裝到開始->程式集->找到你的瀏覽器,右鍵內容把後面的網址全部刪掉開啟工作管理員把explorer.exe給強制關閉,然後刪掉XTab下三個DLL.最後,去瀏覽器把首頁/開啟頁面之類設定通通改回來 最近的病毒真的是花招越來越多惹T___T

[筆記]逆向.NET需要的技術

NT Coure:
http://www.ntcore.com/netunpack.php
從內存直接dump .NET的資料出來

.NET Reflector:
優異的反編譯.NET工具

IL Spy:
http://ilspy.net/
優異的免費反編譯.NET工具

De4Dot:
http://de4dot.com/
免費的解花工具


[C++Builder][VC++][DevC++]逆向分析for迴圈能否使用多重條件句

圖片
for迴圈標準寫法:

for(int i = 0 ; (i < 10); i++);
或者可以用建構式初始化起始值
for(int i(0) ; (i < 10) ; i++);

for迴圈在編譯器解釋上是把;;前中後三個拆解成三個block來處理
所以可以寫:
for(int i(0),t(0),k(0), (i<10); i++);
這樣for迴圈"內"就可以一次使用三個變數

所以當然也可以在最後一個尾巴的block加上額外的運算方法:
for(int i(0),t(0),k(0), (i<10); t = i+1, k = t*2; i++);

理論上既然for迴圈內以逗號隔開應該是會被解析的,
那麼for(; 條件句1,條件句2,條件句3;);
應該這麼寫編譯器應該也是會過的
編譯一下,過了
來分析一下記憶體上是怎麼跑的
用Cheat Engine動態跟蹤一下很快就能找到存取點了(那個k值的地址) :P
跟蹤回去,可以找到int main()架構在這裡
看來Dev C++ 在組合語言上只保留了k == 99這個條件句了
(對於 i < 10這個條件句已經被無視了Otz)

為了避免是Dev C++對於for迴圈解析的問題
另外拿了Visual C++做了測試:
用Cheat Engine跟蹤一下int main()的結果:
VC++的解析狀況也是選擇只保留最後一個條件句,把 i < 10條件句給遺忘了T__T

不信邪的再拿CBuilder測一下
用Cheat Engine跟蹤:
C++Builder編譯後的結果也是選擇把條件句 i < 10做遺忘,只取最後一個

看起來各個版本的C++IDE做解析都會把
for (int i = 0 ; i < 10 , i < 9, i < 8; i++);
只解析最後一個條件句(意思是如這個for迴圈i只會跑0~7)

查了一下國外討論串Are multiple conditions allowed in a for loop?結論也是這樣Otz.

馬後炮式詳談英雄聯盟、流亡黯道網軍間諜病毒在幹嘛(下集)

圖片

馬後炮式詳談英雄聯盟、流亡黯道網軍間諜病毒在幹嘛(上集)

圖片
*注意:此篇文作者只略懂略懂資安,不是一篇專業分析文
*1/11:此文有下集囉~馬後炮式詳談英雄聯盟、流亡黯道網軍間諜病毒在幹嘛(下集)

閱讀此文須服用前置資訊:
12/31Garena 資訊安全聲明
HITCON Freetalk 20150109:Operation GG 台灣最熱門網遊安裝檔 驚見網軍後門

其實在一開始12/31,
魯宅我還在義大宿舍爽爽準備跨年,然後有看到Garena官方發出這份公告
不過我沒有多想XD

反正我宿舍電腦Windows都是裸奔沒有裝防毒的習慣再加上我每天無聊都會開封包工具跟一些資安有關逆向工具,都沒有發現有任何異狀,所以我應該是沒有事XD


接著我們進入正題吧。
我們看完HITCON大神們(說到這我正在跪著敲鍵盤)和
Garena官方公告後可以得知幾件事情:

這是一個安裝程序感染事件,主要問題應該是出在完整安裝包身上(這應該也能解釋為什麼魯宅我沒中毒...因為我都用版本升級的補丁做安裝)。安裝包程序上綑綁上了病毒插件,執行完安裝包後安裝好的遊戲主程式會被Patch成一個後門木馬遊戲程式。當你正常開啟遊戲後,除了打開遊戲本身外,會在C:\Windows\System32\下生產兩個檔案,分別為NtUserEx.dll、NtUserEx.dat。從HITCON的FreeTalk大神口中我們可以得知,NtUserEx.dll其實幾乎是正常的dll Library(不過它來源好像因為是Windows NT的DLL所以自動被防毒當白名單?這不太清楚,Google找不太到);而整份NtUserEx.dll函數中只Patch了兩個函數去存取NtUserEx.dat。NtUserEx.dat的內容物應該就是整隻病毒核心要幹的壞事,加密起來包在這個.dat文件內動態載入存取,然後監控整個你的Windows系統。 *附註:是說有問題的安裝包我是跑去跟HITCON的大神要的XD,點開了有問題的遊戲主程式後就會在System32下生產兩個病毒文件並且修改有問題的主程式回正常的主程式,意思是有問題的遊戲主程式只要製造出病毒後就會恢復正常遊戲主程式了!(至於為啥要這樣幹...可能想避免引起注意吧?)

不過我是把這支病毒養在OSX系統內的Windows沙箱啦...沒有灌LOL、POE ♪(´ε` ),所以我直接把病毒Dll注入到記事本(Notepad.exe)身上,讓…

解除mystartsearch首頁綁架

圖片
寫這篇文章純粹因為我MacBook中的Windows沙箱首頁被綁架了T__T 然後到設定內可以看到它把預設開啟網頁設為流氓網站的網址.
把它更改回來之後,不過會發現無效....會自己被設定回來流氓網站的網址.
於是看了一下,有個流氓擴充套件在每次Chrome開啟都會修改我的首頁...
所以把它移除掉就可以了
不過移除掉之後每次開Chrome這個擴充套件又會被裝回來,
於是從桌面上的Chrome的捷徑查看一下....
原來是目標被下了參數,詳細參數為:"C:\Program Files\Google\Chrome\Application\chrome.exe" http://www.mystartsearch.com/?type=sc&ts=1414216660&from=smt&uid=WindowsX7-0XSSD_47TN9V1WXRFMQ2QRRRH2X(意味著一啟動Chrome就跟著shell了www.mystartsearch.com的網頁)

把目標格子的值改為"C:\Program Files\Google\Chrome\Application\chrome.exe"
按確定,收工~

下一次開啟就是乾淨的Chrome囉~

[C++Builder][Delphi]讓IdHTTP可以正常Post出Big5漢字的參數

圖片
因為寫比賽作品需要,要對學校系統做POST封包,
設定指定email文字內容,像底下這樣
不過到了學校系統一看發現...
中文字的部分通通被設置為了問號...Otz.
於是用封包工具攔截一下看出了什麼狀況
原來Indy控件組內的IdHTTP在做POST的時候對漢字解析上有問題...
會自動把漢字變成了問號(找不到對應字詞做發送)
所以能知道的事情是,我們在POST前先做URL Encode,
把原本的文字轉%XX%XX的形式那麼IdHTTP做發送就不會有無法解析中文字的問題.

翻了一下,學校的asp網站採用的編碼為Big5.
所以我們得設計一個URL Encode去把當前UncodeString轉Big5編碼再做URL Encode.

做法上因為我對URL Encode整個機制處理上沒那麼清楚,
所以問了一下C++Builder前輩蕭沖大大
Big5編碼URL Encode的Delphi Code寫法在這(原版)

我重新用C++Builder寫一份
String nURLEncode(String S,bool InQueryString){ String Ret = ""; TByteDynArray bys = TEncoding::GetEncoding(950)->GetBytes(S); //採用Big5(950)設置轉換用途編碼 for (int i = 0; i < (bys.Length); i++) { if (((bys[i] >= 0x41)&&(bys[i] <= 0x5A))|| ((bys[i] >= 0x61)&&(bys[i] <= 0x7A))|| ((bys[i] >= 0x30)&&(bys[i] <= 0x39))|| (bys[i] == 0x2D)||(bys[i] == 0x5F)|| (bys[i] == 0x2E)) { Ret += char(bys[i]); }else if (bys[i] == 0x20) { Ret += (InQueryString?"+":"%20"); }else{ …

以Debugger原理拆解LINE的Anti-Debug Attach

圖片
在Windows版上的LINE開啟後,如果使用Cheat Engine做進程掛接上去,會看到LINE直接崩潰掉.

先單看Windows提供的一組WinAPI怎麼建立Debugger機制:
Win32 Debug API 原理使用VS调试时,被调试进程如何被断下来的。【原创】反OD调试的一些想法与实践
看完之後會知道Debugger的核心機制是:
1.創建進程(CreateProcess)使用DEBUG_PROCESS這個Flag,此時該進程內的PEB中的BeingDebugged Flag會被設為True,呼叫完後,進成被創建完就會先是被凍結主線程(UI Thread)的進程了.
2.接著激活主線程後,WinNT消息機制發現了BeingDebugged為True,就會主動調用 DbgBreakPoint API,在組語上遇到了int 3(0xCC)線程又會被凍結,然後會反彈一個Create_PROCESS_DEBUG_EVENT訊息回去給父進程,給Debugger做事情.

3.如果Debugger想下新的Ring3層斷點,會先用CreateThread在指定進程中創線程,使此線程Call DbgUiRemoteBreakin,那麼指定進程內所有線程就會被Debugger掛起.那麼Debugger便可以對需要的指定記憶體段下int 3異常點.DbgUiRemoteBreakin內可以看到所有線程主動去Call DbgBreakPoint來把當前線程控制權交給Debugger.
4.如果是進程已經被運行,Debugger才去Attach,則用到DebugActiveProcess去Attach指定進程,接著BeingDebugged又會被設為True,然後做異常機制的掛起線程.
最後我比較好奇的是 DbgUserBreakPoint函數內寫法跟DbgBreakPoint其實一模一樣,我不太懂微軟幹嘛把同個功能寫成兩個不同的API?

接著總結一下 所以一般Ring3層需要防Debugger可能會防止 1.自身DbgBreakPoint被呼叫.(只要此函數呼叫了便把控制權交出去了) 2.自身DbgUserBreakPoint被呼叫. 3.自身DbgUiRemoteBreakin被呼叫.(此函數會導致所有線程去呼叫上述其一API)
先看一下LINE的資料夾: 可以看得出來資料夾內沒有任何驅動文件…

OllyICE手拆OCR付費引擎

圖片
原本只是Coding需要用到把驗證碼圖內的驗證碼給取出來

大致上網路上Google了一下有三種方案:  - Windows Office 插件 (不過對扭曲,有線條干擾的支持度很差)  - Tessnet (好像是個開源專案,可以丟大量圖資讓引擎學習增加辨識度,不過不好用)  - Asprise - OCR (這好像本來就開發給商業使用的所以本來是要付費der)
至於本文主角當然就是....付費的那個(?) 至於詳細怎麼調用這個函數庫不多做介紹(Google一下都有) 大致上在.NET上調用作法為: [調用.NET的asprise-ocr-api.dll的API]→[根據平台自動切換為aocr.dll/aocr_x64.dll的函數做處理]
不過如果你用的是官方頁面上下載的試用版本會發現: 要求付費的提示 每幫開發者辨識五張驗證碼便跳出一次訊息提示付費訊息 (至於為啥我知道五次?因為後面逆向發現的XD)
大致上反編譯一下asprise-ocr-api.dll可以看到註冊機制設置的不在這裡面,而是藏在Win32的aocr.dll跟Win64的aocr_x64.dll內做檢測到底要不要幫你辨識圖片 OK,現在我們可以確定我們的目標是逆向aocr.dll身上(Win32)
看到那個訊息可以很直接了當的知道用了MessageBoxA/W(後來實測是用A) 在MessageBoxA下斷點F8跟蹤回呼叫點可以看到狀態在這 如果按是(yes)返回值為6,就會跳到0F2E67E0做一個Shell官方網站的頁面 如果不為6則繼續辨識圖片

往上翻可以看到在進入授權請求的這個block上面有個eax對edx做or運算 如果兩者or完不為空則直接跳至0F2E67FD繼續做辨識圖片的行為 找到爆破點了,在這邊下強跳 理論上到這邊就可以完美不跳出請求授權的視窗(我一開始也破解到這邊就收工了) 事隔幾個月後發現大事不妙,原來這層是在試用時間測試階段 意思是它好像有個次數給你用完就不能再繼續使用了Otz. (所以你就算爆破跳窗問題也沒用,查了一下大部分網路上教學爆破也到這裡而已)

但可以往上翻一下會看到: 原來它在未使用過此引擎的電腦會先在註冊表生成一個鍵值存放剩餘次數
OK,現在真相大白惹,整個環節是: 引擎檢測授權→沒有授權就在註冊表開一個鍵值存放剩餘次數,並且每五次跳出授權請求視窗Mes…