諾

2011-09-21T09:29:00.000+08:00

去年的這個時候,我從自己的舒適圈中跳了出來,邁向人生新的里程碑.

我們要經營一間電子書城,專門賣大專電子教科書.當時我們對書城,DRM及閱讀器的規格還沒有清楚的藍圖,是要自己實做呢?還是要委外製作... (待續)

Constructor

2010-03-14T16:35:00.007+08:00

g++

vc++

Derived constructor -> Base constructor -> Derived vtable ready

另一個 call stack 還原法

2009-08-25T00:31:00.006+08:00

http://fruitfoxlu.blogspot.com/2009/03/nt-insider-windbg3.html

Royce 大師教的 call stack 還原法

Rvalue References

2009-08-03T00:58:00.003+08:00

http://fsfoundry.org/codefreak/2009/05/19/i-like-to-move-it/

Dependency does matter

2008-07-21T00:58:00.003+08:00

話說每一版的Milestone build前夕總免不了要爆個大問題.這次比較有趣的大概就是XXListen突然倒地不起.但時間緊迫,當時只能緊急撤掉可疑的修改讓它撐下去.但是欠債總是要還的,這版第一個build一出來,魔王又重生了

程式一執行就掛了,連first chance的call stack都讓人一頭霧水

CommandLine: C:\Builds\XXA_15.1.1007_PrivateBuild \XXListen.exe

Symbol search path is: SRV*C:\Symbols*http://myfault.kicks-ass.net;C:\PrivateBuilds\Symbols

Executable search path is: C:\Builds\XXA_15.1.1007_PrivateBuild \

ModLoad: 00400000 004f5000 XXListen.exe

…

(c9c.24c): Break instruction exception - code 80000003 (first chance)

eax=00351eb4 ebx=7ffda000 ecx=00000004 edx=00000010 esi=00351f48 edi=00351eb4

eip=7c92120e esp=0022fb20 ebp=0022fc94 iopl=0 nv up ei pl nz na po nc

cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202

ntdll!DbgBreakPoint:

7c92120e cc int 3

0:000> kv

ChildEBP RetAddr Args to Child

0022fb1c 7c95e612 7ffdf000 7ffda000 00000000 ntdll!DbgBreakPoint (FPO: [0,0,0])

0022fc94 7c94108f 0022fd30 7c920000 0022fce0 ntdll!LdrpInitializeProcess+0xffa (FPO: [Non-Fpo])

0022fd1c 7c92e437 0022fd30 7c920000 00000000 ntdll!_LdrpInitialize+0x183 (FPO: [Non-Fpo])

00000000 00000000 00000000 00000000 00000000 ntdll!KiUserApcDispatcher+0x7

0:000> .ecxr

Unable to get exception context, HRESULT 0x8000FFFF

原來是因為連crt的exception handler都還沒種進去就掛了,只有ntdll!_except_handler3

0022fd0c: ntdll!_except_handler3+0 (7c92e900)

CRT scope 1, filter: ntdll!_LdrpInitialize+1d5 (7c95f0f6)

func: ntdll!_LdrpInitialize+1e6 (7c95f10c)

CRT scope 0, func: ntdll!_LdrpInitialize+249 (7c95f158)

因為最外層的exception handler把現場破壞得太嚴重了,所以一定得攔在exception發生前…費盡千辛萬苦終於發現掛在這行

0:000> p

eax=0ce590be ebx=0022f78c ecx=00000000 edx=000ce590 esi=656806d0 edi=00000000

eip=65634f25 esp=0022f774 ebp=0022f9a8 iopl=0 nv up ei pl zr na pe nc

cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246

XXSOCK!XXSsockApp::InitInstance+0x155:

65634f25 68a0066865 push offset XXSOCK!g_ppszIPList (656806a0)

0:000> p

(6a0.5f4): Stack overflow - code c00000fd (first chance)

First chance exceptions are reported before any exception handling.

This exception may be expected and handled.

eax=00033018 ebx=00230000 ecx=00000002 edx=00000001 esi=002300d4 edi=00000004

eip=7c935401 esp=00033000 ebp=00033030 iopl=0 nv up ei pl zr na pe nc

cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246

ntdll!RtlpLocateActivationContextSection+0x150:

7c935401 56 push esi

push也會出事??!! Stack明明就可讀可寫啊

00030000 : 00031000 - 001ff000

Type 00020000 MEM_PRIVATE

Protect 00000004 PAGE_READWRITE

State 00001000 MEM_COMMIT

Usage RegionUsageStack

Pid.Tid 6a0.5f4

等到冷靜下來仔細一看…不對啊…明明是單步執行怎麼一次跳好幾步? 這顯示問題不一定是那行push造成,也可能是後續被跳過無法下斷點的那幾行之一造成的.

65634eeb 8b0da0066865 mov ecx,dword ptr [XXSOCK!g_ppszIPList (656806a0)]

65634ef1 83c428 add esp,28h

0:000> p

eax=0ce590be ebx=0022f78c ecx=37fdeebe edx=000ce590 esi=656806d0 edi=00000000

eip=65634eeb esp=0022f74c ebp=0022f9a8 iopl=0 nv up ei pl nz na pe nc

cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206

TMSOCK!CTmsockApp::InitInstance+0x11b:

65634eeb 8b0da0066865 mov ecx,dword ptr [XXSOCK!g_ppszIPList (656806a0)] ds:0023:656806a0=00000000

0:000> p

eax=0ce590be ebx=0022f78c ecx=00000000 edx=000ce590 esi=656806d0 edi=00000000

eip=65634f25 esp=0022f774 ebp=0022f9a8 iopl=0 nv up ei pl zr na pe nc

cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246

TMSOCK!CTmsockApp::InitInstance+0x155:

65634f25 68a0066865 push offset TMSOCK!g_ppszIPList (656806a0)

連Windbg都不可信,正打算用OllyICE試試的時候…老天還是待我不薄,因為這時候的call stack像樣多了

00033030 7c93532a ntdll!RtlpLocateActivationContextSection+0x150

00033060 7c93528d ntdll!RtlpFindNextActivationContextSection+0x61

00033078 7c935571 ntdll!RtlpFindFirstActivationContextSection+0x41

000330c4 7c935cc9 ntdll!RtlFindActivationContextSectionString+0x8e

00033188 7c935b8a ntdll!RtlDecodeSystemPointer+0x9e7

000332f0 7c936748 ntdll!RtlDosApplyFileIsolationRedirection_Ustr+0x267

0003337c 7c936698 ntdll!LdrGetDllHandleEx+0xc9

00033398 7c80e524 ntdll!LdrGetDllHandle+0x18

000333e8 7c80e63b kernel32!GetModuleHandleForUnicodeString+0x1d

0003386c 7c80e4ec kernel32!BasepGetModuleHandleExW+0x18e

00033884 7c80b750 kernel32!GetModuleHandleW+0x29

00033890 0060c192 kernel32!GetModuleHandleA+0x2d

0003389c 0060c1e8 libNetCtrl!_decode_pointer+0x3f

000338a8 0060c30d libNetCtrl!__set_flsgetvalue+0x1e

000338b8 0060a6c8 libNetCtrl!_getptd_noexit+0x15

000338bc 0060e786 libNetCtrl!_errno+0x5

000338c4 0060c08b libNetCtrl!_get_winmajor+0x10

000338e0 0060c19d libNetCtrl!_use_encode_pointer+0x1b

000338e8 0060c1e8 libNetCtrl!_decode_pointer+0x4a

000338f4 0060c30d libNetCtrl!__set_flsgetvalue+0x1e

等等…這不太像是個call stack的起點呀… 完整的call stack呢?

00033030 7c93532a ntdll!RtlpLocateActivationContextSection+0x150

00033060 7c93528d ntdll!RtlpFindNextActivationContextSection+0x61

00033078 7c935571 ntdll!RtlpFindFirstActivationContextSection+0x41

000330c4 7c935cc9 ntdll!RtlFindActivationContextSectionString+0x8e

00033188 7c935b8a ntdll!RtlDecodeSystemPointer+0x9e7

000332f0 7c936748 ntdll!RtlDosApplyFileIsolationRedirection_Ustr+0x267

0003337c 7c936698 ntdll!LdrGetDllHandleEx+0xc9

00033398 7c80e524 ntdll!LdrGetDllHandle+0x18

000333e8 7c80e63b kernel32!GetModuleHandleForUnicodeString+0x1d

0003386c 7c80e4ec kernel32!BasepGetModuleHandleExW+0x18e

00033884 7c80b750 kernel32!GetModuleHandleW+0x29

00033890 0060c192 kernel32!GetModuleHandleA+0x2d

0003389c 0060c1e8 libNetCtrl!_decode_pointer+0x3f

000338a8 0060c30d libNetCtrl!__set_flsgetvalue+0x1e

000338b8 0060a6c8 libNetCtrl!_getptd_noexit+0x15

000338bc 0060e786 libNetCtrl!_errno+0x5

000338c4 0060c08b libNetCtrl!_get_winmajor+0x10

000338e0 0060c19d libNetCtrl!_use_encode_pointer+0x1b

000338e8 0060c1e8 libNetCtrl!_decode_pointer+0x4a

000338f4 0060c30d libNetCtrl!__set_flsgetvalue+0x1e

…

000fe250 0060e786 libNetCtrl!_errno+0x5

000fe258 0060c08b libNetCtrl!_get_winmajor+0x10

000fe274 0060c19d libNetCtrl!_use_encode_pointer+0x1b

000fe27c 0060c1e8 libNetCtrl!_decode_pointer+0x4a

000fe288 0060c30d libNetCtrl!__set_flsgetvalue+0x1e

000fe298 0060a6c8 libNetCtrl!_getptd_noexit+0x15

上面兩塊簡直像鬼打牆一樣出現了幾萬次,原來stack overflow是它造成的.

裡面出現了libNetCtrl!_errno,看來像是個error handler…好樣的,error handler寫出error…

讓我想到Dr.Watson crash之後又生出一個Dr.Watson前仆後繼的情景

(其作者Don Corbitt很久前就於空難中過世了,基於尊敬在下得說實話:Dr.Watson雖有小瑕疵但還是很好用)

接下來就直接攔在這個error handler的進入點,來看到底是誰造成第一個error啟動了這場災難

0022f4b4 0060a6c8 libNetCtrl!_getptd_noexit

0022f4b8 0060e786 libNetCtrl!_errno+0x5

0022f4c0 0060c08b libNetCtrl!_get_winmajor+0x10

0022f4dc 0060c126 libNetCtrl!_use_encode_pointer+0x1b

0022f4e4 0060c151 libNetCtrl!_encode_pointer+0x4a

0022f4ec 00616393 libNetCtrl!_encoded_null+0x7

0022f520 0060eaf4 libNetCtrl!__crtMessageBoxA+0xe

0022f544 00607c19 libNetCtrl!_NMSG_WRITE+0x162

0022f55c 006040e9 libNetCtrl!malloc+0x2f

0022f574 0060298b libNetCtrl!NetLocalMachine::LoadAdapters+0x19

終於找到了,不過怎麼是malloc?

00607c01 33f6 xor esi,esi

00607c03 393598fa6100 cmp dword ptr [libNetCtrl!_crtheap (0061fa98)],esi

00607c09 8bfd mov edi,ebp

00607c0b 7518 jne libNetCtrl!malloc+0x3b (00607c25)

00607c0d e8206f0000 call libNetCtrl!_FF_MSGBANNER (0060eb32)

00607c12 6a1e push 1Eh

00607c14 e8796d0000 call libNetCtrl!_NMSG_WRITE (0060e992)

00607c19 68ff000000 push 0FFh

原來是因為"libnetctrl!_crtheap"等於0,跑進了malloc裡一開頭的error handling block

0:000> dd libNetCtrl!_crtheap

0061fa98 00000000 00000000 00000000 00000000

為啥是0咧? 從VC裡附的crt source可以知道,只要_DllMainCRTStartup有被呼叫,此DLL對應的crt heap就應該被建立好了.

這麼說…_DllMainCRTStartup沒有被呼叫?

// 為說明而做了簡化,雙底線和單底線版本的差異與本主題無關,可以把它們看成一樣

#define _DllMainCRTStartup __DllMainCRTStartup

__declspec(noinline)

BOOL __cdecl

__DllMainCRTStartup(

HANDLE hDllHandle,

DWORD dwReason,

LPVOID lpreserved

)

{

if ( dwReason == DLL_PROCESS_ATTACH || dwReason == DLL_THREAD_ATTACH ) {

…

if ( retcode )

retcode = _CRT_INIT(hDllHandle, dwReason, lpreserved);

呼叫DllMainCRTStartup是Executable loader的責任耶…還好,之前曾經在路上撿到一份pseudo code,裡面說Loader大致是這樣運作的:

NTLoadDLL(DLL)

{

if (!AlreadyLoad(DLL) {

MapDLL(DLL);

if (IsDLL()){

RecirsivelyLoadDependencyDLL();

}

InsertDLLInitRoutineToList();

If (All_Implicitly_Linked_DLL_Loaded()) {

RunTheInitRoutineList();

}

也就是說,只有當所有隱式連結的DLL都已載入完畢時,各DLL的_DllMainCRTStartup(精確來說,是該DLL的PE header內標記的Entry point)才會被整批逐一執行.

而libNetCtrl.dll是XXListen.exe隱式連接的DLL之一,當它被XXSock.dll載入時,Loader認為XXListen.exe尚有未完全載入的DLL(libNetCtrl.dll就是其中之一囉),

所以並沒有執行libNetCtrl.dll的_ DllMainCRTStartup. 沒有Main就沒有_CRT_INIT,沒有_CRT_INIT就沒有_crtheap可以用.

這三個project之間的關係可以用下面的pseudo code來理解:

XXListen.cpp:

void main()

{

fun_in_DLL1();

fun_in_DLL2();

}

DLL1.cpp (就是XXSOck.dll):

typedef void (*_fun_in_DLL2)(void);

class _obj_in_DLL1 {

_obj_in_DLL1() {

fun_in_DLL2 = GetProcAddress(LoadLibraryA("DLL2.dll"), "fun_in_DLL2"));

fun_in_DLL2();

}

} obj_in_DLL1;

extern "C" void fun_in_DLL1(void)

{

printf("fun_in_DLL1\n");

}

與DLL2.cpp(也就是libNetCtrl.dll):

extern "C" void fun_in_DLL2(void)

{

printf("fun_in_DLL2\n");

malloc(65536);

}

然後令XXListen依賴DLL1與DLL2,但不對DLL1標記其依賴DLL2的事實

這樣等於向Loader宣稱DLL1和DLL2沒有互相依賴關係,所以該先執行誰的DllMain都可以.

若是Loader先執行DLL2的DllMain就天下太平,但若哪天它決定先執行DLL1的DllMain,問題就爆發了.

附帶一提,目前以路上撿來的那份pseudo code內容來看,

Loader將會把眾DllMain們按照他們的所屬DLL出現在Import Table內的順序,以先出現先執行的原則執行之.

倘若這行為永遠不變,還是存在一個變數,就是連結器又該如何決定兩個不互相依賴的DLL,誰該在前而誰又該在後?

總之這兩個變數就是讓這問題時而出現時而消失的元凶.

Stack, a locker without lock

2007-12-02T01:04:00.005+08:00

A function 呼叫 B function, 並傳遞了兩個 4-byte 參數. 但當 B function 要取用的時候, 參數在 stack 裡被歸零了!

goto CLEANUP or TRAP

2007-12-01T22:17:00.003+08:00

這幾天犯了一個嚴重的錯誤, 害 XXXNT 在 64-bit Vista 上一執行就會 GPF

void foo()
{
　if (something is wrong)
　goto CLEANUP;
　char *ptr = NULL;
　ptr = new char [100];
CLEANUP:
　if (ptr) delete [] ptr;
}

這段 code 會被編譯成:

　cmp something_is_wrong
　je CLEANUP1
　push 64h
　call operator new
　add esp,4
　jmp CLEANUP2
CLEANUP1:
　mov eax, dword ptr [esp+4]
CLEANUP2:
　test eax,eax
　je END
　push eax
　call operator delete
　add esp,4
END:
　xor eax,eax
　ret

也就是說, 假如真的執行到了 goto 指令, 則將存取到 esp+4 這塊記憶體, 而其內容並非我們所想像的 NULL, 因此將會引發不可預期的後果.

幸好, 當 VC8 的 compile warning level 開到 /W4 的時候, 這種 code 將會引發一個 C4701 warning

Kernel object deadlock hunting

2007-10-14T01:00:00.002+08:00

這報告的知識都是取之於網路, 所以我打算回饋一下...

Kernel object deadlock hunting

當 event 或 semaphore 這種不具 ownership 紀錄的 Windows kernel object 發生 deadlock, 怎麼找出咬住該 object 的執行緒?
只要運氣夠好, 還是有機會把它揪出來!

When operator new and delete are overwritten

2007-09-11T01:36:00.002+08:00

上個禮拜, 本 team 的強者查理大大發現了一個 Vista 上的 Crash... 其 Dump 可謂匪夷所思

我們首次到手的 Dump, call stack 長這樣:

# 1 Id: d30.fd4 Suspend: 1 Teb: 7ffde000 Unfrozen
ChildEBP RetAddr Args to Child
029fc564 773a1d37 01390000 006d5748 029fc60c ntdll!RtlpCoalesceFreeBlocks+0x26d
029fc65c 773a1c21 006d5748 006d5750 006d5750 ntdll!RtlpFreeHeap+0x1e2
029fc678 75d97a7e 01390000 00000000 006d5748 ntdll!RtlFreeHeap+0x14e
029fc68c 1000d343 01390000 00000000 006d5750 kernel32!HeapFree+0x14
029fc6cc 1000961b 006d5750 1bdb284a 029fc798 libXXXXXSecure!free+0x6e
029fc73c 10008c5a 46e56fb6 00000d30 00000fd4 libXXXXXSecure!LogWriteW+0xeb
029fe778 10008d7f 00000008 01390c08 00000154 libXXXXXSecure!vdprintfW+0x1da
029fe7a0 10008edf 00000008 01390c08 00000154 libXXXXXSecure!dprintfW+0x2f
029fe7b8 100090a8 1bdb0952 75d97b60 773a2f1d libXXXXXSecure!CDebugLogW::EnterDebugLog+0x1f
029fe7e4 10025a05 1002f274 00000154 1002f398 libXXXXXSecure!CDebugLogW::CDebugLogW+0x158
029fec40 0044bcd6 1bc66186 00000000 006ad738 libXXXXXSecure!TSECURE::clearTGPTempDir+0x45

...

3 Id: d30.51c Suspend: 1 Teb: 7ffdc000 Unfrozen
ChildEBP RetAddr Args to Child
03ebf92c 773a06a0 7737b18c 00000338 00000000 ntdll!KiFastSystemCallRet
03ebf930 7737b18c 00000338 00000000 00000000 ntdll!NtWaitForSingleObject+0xc
03ebf994 7737b071 00000000 00000000 01390000 ntdll!RtlpWaitOnCriticalSection+0x154
03ebf9bc 77368f4a 01390130 03eb9ea4 01390000 ntdll!RtlEnterCriticalSection+0x152
03ebfaa0 773a214c 00000214 00000220 0139039c ntdll!RtlpAllocateHeap+0x15c
03ebfb18 10018acb 01390000 00000008 00000214 ntdll!RtlAllocateHeap+0x1e3
03ebfb58 1001133a 00000214 00000214 00000000 libXXXXXSecure!_calloc_impl+0xc4
03ebfb70 1000daf3 00000001 00000214 00000000 libXXXXXSecure!_calloc_crt+0x13
03ebfb90 1000dbaa 10000000 00000002 00000000 libXXXXXSecure!_CRT_INIT+0x17b
03ebfbd0 1000dc64 10000000 773aa604 10000000 libXXXXXSecure!__DllMainCRTStartup+0x59
03ebfbd8 773aa604 10000000 00000002 00000000 libXXXXXSecure!_DllMainCRTStartup+0x1d
03ebfbf8 7737ab3b 1000dc47 10000000 00000002 ntdll!LdrpCallInitRoutine+0x14
03ebfc98 7737a954 03ebfd24 03eb9904 00000000 ntdll!LdrpInitializeThread+0x149
03ebfd00 7737a980 03ebfd24 77340000 00000000 ntdll!_LdrpInitialize+0x21d
03ebfd10 00000000 03ebfd24 77340000 00000000 ntdll!LdrInitializeThunk+0x10

列出這兩個 Thread 主要是因為, 我們一度以為 Vista 環境中竟然平行執行 DllMainCRTStartup 及 mainCRTStartup...

但後來發現_CRT_INIT 的 dwReason 參數, 它並非我們所想像的 DLL_PROCESS_ATTACH(1) 而是 DLL_THREAD_ATTACH(2).

03ebfb90 1000dbaa 10000000 00000002 00000000 libXXXXXSecure!_CRT_INIT+0x17b

也就是說, 這根 Thread 根本是來擾亂視聽的, 它其實正常運作中, 只不過被 crashed thread 所 own 住的 Heap lock 給卡住了而已.

所以我們似乎可以把重心全部放在 fd4 這根 thread 上.

此外, 感謝查理大的指示, 我們還擁有一個很重要的線索, 就是該 crash 的 process 會間接 include 到一個

overwrite 掉 operator new 及 delete 的 header file:

static inline void* operator new(size_t size)
{
void* ptr = ::HeapAlloc(::GetProcessHeap(), 0, size);
if (!ptr)
{
_THROW_NCEE(std::bad_alloc, "Insufficient memory");
}
return ptr;
}
static inline void operator delete(void* ptr) { ::HeapFree(::GetProcessHeap(), 0, ptr); }

我們幾乎可以確定問題一定是由它造成的, 但接下來我們想知道的是:

問題到底是怎麼造成的呢? 它真的會 overwrite 掉 CRT 當中對 operator new 及 delete 的實作嗎?

於是我們追進 crashed thread 所呼叫的 free() 當中, 可以看到它操作的是 _crtheap (由 _head_init@CRT 所建立)

libXXXXXSecure!free:
1000d2d5 6a0c push 0Ch
1000d2d7 68f8220310 push offset libXXXXXSecure!_CT??_R0?AVout_of_rangestd+0x2b8 (100322f8)
1000d2dc e837910000 call libXXXXXSecure!__SEH_prolog4 (10016418)
1000d2e1 8b7508 mov esi,dword ptr [ebp+8]
1000d2e4 85f6 test esi,esi
1000d2e6 7475 je libXXXXXSecure!free+0x88 (1000d35d)
1000d2e8 833da08d031003 cmp dword ptr [libXXXXXSecure!__active_heap (10038da0)],3
1000d2ef 7543 jne libXXXXXSecure!free+0x5f (1000d334)
1000d2f1 6a04 push 4
1000d2f3 e8ed850000 call libXXXXXSecure!_lock (100158e5)

...

1000d337 ff35f4880310 push dword ptr [libXXXXXSecure!_crtheap (100388f4)]
1000d33d ff1514b00210 call dword ptr [libXXXXXSecure!_imp__HeapFree (1002b014)]

由此可見, 該 header file 並沒有 overwrite 掉 CRT 當中的 operator delete 實作.

那 operator new 呢? 我們追進 basic_string::_Copy > basic_string::allocate > std::_Allocate > operator new,

可以看到其實作如下:

libXXXXXSecure!operator new:
10025d10 55 push ebp
10025d11 8bec mov ebp,esp
10025d13 83ec10 sub esp,10h
10025d16 8b4508 mov eax,dword ptr [ebp+8]
10025d19 50 push eax
10025d1a 6a00 push 0
10025d1c ff1518b00210 call dword ptr [libXXXXXSecure!_imp__GetProcessHeap (1002b018)]
10025d22 50 push eax
10025d23 ff1544b00210 call dword ptr [libXXXXXSecure!_imp__HeapAlloc (1002b044)]
...

很明顯地, 它是被 overwrite 掉之後的結果.

平平都是 include 那個 overwrite header file, 為啥 operator new 被蓋掉了, 但 operator delete 卻沒有?

我們展開呼叫了 operator delete 的 LogWriteW:

100095fc e8fffaffff call libXXXXXSecure!Send (10009100)
10009601 397c2448 cmp dword ptr [esp+48h],edi
10009605 8ad8 mov bl,al
10009607 c744241044bc0210 mov dword ptr [esp+10h],offset libXXXXXSecure!CCmdProtocol::`vftable' (1002bc44)
1000960f 720d jb libXXXXXSecure!LogWriteW+0xee (1000961e)
10009611 8b442434 mov eax,dword ptr [esp+34h]
10009615 50 push eax
10009616 e864350000 call libXXXXXSecure!operator delete (1000cb7f)

它理應要呼叫 CCmdProtocol::~CCmdProtocol() 來做 cleanup 動作, 但因為被 optimize 的緣故, 此處只出現了一個 delete,

而且這個 delete 忽略掉 overwrite function, 仍舊與 CRT 的實作相連結, 這應該算是個 optimization error 吧...

所謂禍不單行, 取消掉 libLogClient 的 optimization 之後, 程式仍然會 crash...

這次的 Dump, crashed thread 的 call stack 如下:

# 1 Id: 820.f94 Suspend: 1 Teb: 7ffdd000 Unfrozen
ChildEBP RetAddr Args to Child
02bfe684 773a1d37 002f0000 01670c38 02bfe72c ntdll!RtlpCoalesceFreeBlocks+0x35
02bfe77c 773a1c21 01670c38 01670c40 773a2f1d ntdll!RtlpFreeHeap+0x1e2
02bfe798 75d97a7e 002f0000 00000000 01670c38 ntdll!RtlFreeHeap+0x14e
02bfe7ac 10027f56 002f0000 00000000 01670c40 kernel32!HeapFree+0x14
02bfe7c0 10002ffa 01670c40 02bfea20 01670c40 libXXXXXSecure!operator delete+0x16
02bfe7d4 10002f7d 67c8f9a4 02bfea0c 02bfec34 libXXXXXSecure!std::auto_ptr::~auto_ptr+0x1a
02bfe7f0 10025d18 67c8f214 003a0043 0050005c libXXXXXSecure!CDebugLogW::~CDebugLogW+0x4d
02bfec40 0044bcd6 67dbc520 00000000 0031d738 libXXXXXSecure!TSECURE::clearTGPTempDir+0x1a8

出現了 auto_ptr object... 顯然又是個 new/delete 不相符造成的 crash

以同樣的方法追進去, 可以看到這次 operator delete 被 overwrite 掉了, 但 operator new 並沒有

原來是因為 CDebugLogW::~CDebugLogW 的實作放在 header file 裡, 而 CDebugLogW::CDebugLogW 的實作放在另一個 library 內.

從這個例子我們可以看到, 這種寫法會造成建解構函式分別採用到不同的 CRT function 實作.

crackme2.exe in Makkakko tutorial

2007-04-08T15:59:00.002+08:00

下載
1. 攔 USER32!GetDlgItemTextA, 可知序號將被存入 0x0040217E.

2. 在 0x0040217E 處設存取中斷點, 可知序號將經過下列加工:
a. 所有英文小寫字母轉大寫
b. 跟 "Messing_in_bytes" 這 16 bytes 做 XOR.

3. 把 XOR 完之後的 16 bytes 跟下面 byte sequence 比對:
1f, 2c, 37, 36, 3b, 3d, 28, 19, 69, 6e, 5f, 62, 79, 74, 65, 73
若超過兩個 byte 以上相異, 則序號不合法.

攻擊 Tor 的匿名性

2007-03-27T01:56:00.003+08:00

Tor 的匿名性再度被攻擊 (原文)
攻擊的技巧在於利用了 Tor entrance/non-entrance algorithm 均傾向選擇 uptime 高且頻寬大的 onion router 作為下一站.
而上述資訊是由各 onion router 自行評估公告, 攻擊者可謊報以爭取同時成為 Entrance 及 Exit node, 並可由收到 request 的時間據以判斷自己是否如願.

Google Analytics

2007-03-24T15:25:00.003+08:00

Google Analytics

分析你的網頁點擊狀況

http://www.google.com/analytics

Firefox 2.0.0.x 及 IE 6,7 共有的 onUnload 漏洞

2007-02-26T02:47:00.003+08:00

若在 onUnload 事件處理函數當中透過 document.write() 寫入 script, 則 IE 和 Firefox 都會執行之.

由於輸入新 URL 亦將觸發 onUnload 事件, 攻擊者可透過上述 script 構造出 phishing 頁面.

不過攻擊者將不知道 User 究竟想連到哪裡, 所以他只能瞎猜或總是構造出某個特定頁面, 希望可以矇對.

但 Firefox 的漏洞更糟糕, 它使得攻擊者得以取得 User 欲前往的 URL.

原因是 Firefox 不但執行了該 script, 還以新的 context 執行之, 也就是說, 倘若我們在該 script 當中修改了 location 屬性, 則 Firefox 不但將導向至新 location, 還會夾帶 Referer tag, 當中正是 User 欲前往的 URL.

Proof of concept: IE, Firefox

UPX file parser vulnerable

2007-02-26T02:00:00.003+08:00

http://esupport.trendmicro.com/support/viewxml.do?ContentID=EN-1034289

需要換 pattern

如何不區分實虛部地表示一個複數

2007-02-26T00:30:00.003+08:00

1965 年 Walter Penney 提出以 (i-1) 為 base 的複數表示法. [1]
以該 base 表示一個複數的時候, 各 digit 數值非 0 即 1, 他同時証明了任一複數基於該 base 的表示法唯一.
2000 年被再度發現以 (-i-1) 亦可造出另一套表示法 [2] , 而且証明了 (-i+1) 及 (i+1) 不行, 並整理了基於 (i-1) 表示法時, 數字的運算方法.

使用這表示法所表示的數字到底長怎樣呢? 以 (i-1)-base 為例:

1: 1
2: 1100
3: 1101
4: 111010000
4+i: 111010011

Snort 2.6.1 存在緩衝區溢出漏洞

2007-02-22T19:00:00.003+08:00

以下這些版本存在緩衝區溢出漏洞

Snort 2.6.1, 2.6.1.1, and 2.6.1.2
Snort 2.7.0 beta 1

緩衝區溢出問題被發現於 ReassembleSMBWriteX() (smb_andx_decode.c) 和 ReassenbleDCERPCRequest() (dcerpc.c) 當中.

其中 ReassenbleDCERPCRequest() 溢寫的緩衝區位於 data segment 內 (global variable - u_int8_t DecodeBuffer[65535] in decode.c).

ReassembleSMBWriteX() 溢寫的緩衝區位於 stack 內 (local variable - SMB_WRITEX_REQ temp_writeX in ReassembleSMBWriteX()).

ICMP flood 判例

2007-02-13T00:59:00.004+08:00

本文轉載自司法院判決書資料庫, 此處僅節錄判決結果及主要原因並隱去所有姓名, 如有不妥請來信告知刪除

【裁判字號】 93,易,1310
【裁判日期】 931215
【裁判案由】妨害電腦使用罪
【裁判全文】
臺灣高雄地方法院刑事判決九十三年度易字第一三一０號
　　公　訴　人　臺灣高雄地方法院檢察署檢察官
　　被　　　告　○○○　男　.
右列被告因妨害電腦使用罪案件，經檢察官提起公訴（九十三年度偵字第一四二五九號），本院判決如左：
主文
○○○無罪。
理由

一、(略)
二、(略)
三、(略)
四、(略)
五、經查：本件系爭二點ＩＰ位址間封包有互相傳送之現象，並非僅由被告網咖店之ＩＰ址二一一‧七二‧二三‧一二四往告訴人之ＩＰ址為六一‧二二一‧一八一‧一六一傳送；且發生此種現象之原因很多，若有通訊協定之設定也會造成封包回傳，此外，線上遊戲或聊天室如有執行ＩＣＭＰ程式，亦可能發生此種現象，而本件無法知道哪一方有執行ＩＣＭＰ程式等情，業據證人中華電信網路維運部門系統工程師ＹＹＹ於本院審理時證述明確。另告訴人所經營之「ＸＸＸＸＸ」網咖店之電腦，確實於九十三年三月二十九日下午三時三十分間，因封包互傳而造成網路有阻塞，且被告之二一一．七二．二三．一二四ＩＰ位址有時為封包之來源位址（執行ICMP Echo），有時為封包之目的位址（執行ICMP Reply）等情，亦有中華電信公司之檢測數據資料影本一紙在卷可稽，核與前揭證人之證詞相符，應堪信為真實。而被告與告訴人均為網咖業者亦為被告及告訴人所互相供承在卷。則衡諸前揭說明，ＩＣＭＰ之ＤＯＳ攻擊可由駭客經由正常網路之使用而發動，且被告及告訴人所經營之網咖復為不特定多數人得以使用電腦網路之營業處所，則本件既無法證明是由何人啟動封包互傳之機制，是否該ＩＣＭＰ之ＤＯＳ攻擊係由被告所經營之網咖店之ＩＰ址為二一一．七二．二三．一二四上之電腦所啟動，已有可疑，況且縱令該ＩＣＭＰ之ＤＯＳ攻擊係由被告所經營之網咖店之電腦所發動，但被告所經營者既為網咖店，使用被告電腦者乃不特定之多數人，如無實據，亦難僅以ＩＰ址為六一．二二一．一八一．一六一、ＩＰ址為二一一．七二．二三．一二四二點之間有封包互傳之情形，即排除駭客利用被告或告訴人所經營網咖店之電腦進行ＩＣＭＰ之ＤＯＳ攻擊之可能，而遽認係被告利用曾為告訴人處理網際網路之設置，而設定封包互傳之通訊協定以電腦程式干擾告訴人之電腦或相關設備之犯行係被告所為。況告訴人亦自承被告係於四年前為告訴人處理網際網路之問題，此亦為被告所不爭，則事隔四年之久，被告如何記得四年前所為網際網路設定，實有可疑，此外復查無其他積極證據足資證明被告有何以電腦程式干擾他人電腦或相關設備之犯行，參酌前揭二之說明，實難對被告率以干擾電腦或相關設備罪相繩。
六、(略)

Hackers Delight 2-2

2007-02-11T15:21:00.002+08:00

2-2 只用到加(減)法與基本邏輯運算的式子

本節選錄一系列只用到加(減)法與基本邏輯運算的式子.

a.

(譯註: by definition of 2's complement)

(譯註: -x = -(NOT(NOT(x-1))+1) = -(-NOT(x-1)) = NOT(x-1) )

c.

(譯註: by a.)

(譯註: by c.)

(譯註: x+y = x-(-y) = x-(NOT(y)+1) = x-NOT(y)-1)

(譯註: (x XOR y) = x+y with carry bits ignored,

2(x AND y) = carry bits )

(譯註: (x OR y) = x+y - (x AND y) )

(譯註: by g. and h.)

(譯註: by a.)

(譯註: (x XOR y) = x-y with borrow bits ignored,

2(NOT(x) AND y) = borrow bits)

(譯註: first calculate 1-0 parts, then minus the 0-1 parts)

(譯註: by k. and l.)

(譯註: by definition of XOR)

(譯註: (x AND NOT(y)) = the mask where x(i)=1 AND y(i)=0)

(譯註: NOT(x-y) = -(x-y)-1 = y-x-1)

r.

(譯註: by q. - NOT(x) = -x-1)

(譯註: NOT(x XOR y)

= NOT((x OR y) - (x AND y))

= (x AND y) - (x OR y) -1)

(譯註: by s.)

(譯註: by o.)

(譯註: by p. (x AND y)

= (x - (x AND NOT(y)))

= x + (NOT(x AND NOT(y)) + 1)

= x + (NOT(x) OR y) + 1

= (NOT(x) OR y) + NOT(NOT(x)) + 1

= (NOT(x) OR y) - NOT(x) )

(d) 式可以循換地套用, 例如 -NOT(-NOT(x)) = x + 2, 依此類推. 同樣地, (e) 式也一樣: -NOT(-NOT(-x)) = x - 2. 我們可以利用這兩招對 x 任意增減任意常數.

(f) 式是 (j) 式的共軛式, (j) 式是使用加法來計算減法的常見技巧.

(g) 式跟 (h) 式出自 HAKMEN. (g) 式首先忽略進位地計算 x+y, 再補上忽略掉的進位.

對於兩個各位元獨立, 且為0與為1機率同高的亂數, 計算其加法的時候, 已被證明任一位元上發生進位的機率為 0.5. 當使用 (g) 式來計算兩數和的話, 任一位元上發生進位的機率小於 0.5.

(譯註: 原文此處估計為機率大於 0.25 且小於 0.5, 但證明不嚴謹故此處僅保留部份結論)

(k), (l) 式與 (g), (h) 式是共軛式. (k) 式首先忽略借位地計算 x-y (該借位的位元憑空加1, 不實際借位), 再扣回忽略掉的借位.

(n) 式只使用三種運算(AND, OR 跟減) 來實作 XOR 運算, 花費三個指令. 若只用 AND, OR 跟 NOT 的話, 須花費四個指令: (x XOR y) = (x OR y) AND NOT(x AND y).

與此相似, (u), (v) 兩式分別使用三種運算來實作 OR 跟 AND 運算, 花費三個指令.

Cisco 捨棄 CTA, 改採微軟 NAP client

2007-02-10T14:57:00.003+08:00

九月份 Cisco 和微軟公佈了整合 NAC(Cisco) 跟 NAP(Microsoft) 的新一代 NAC 系統架構.
此後, 對於安裝了 Windows Vista 及 Longhorn 的電腦, 將直接使用其內建的 NAP client 取代原先 CTA 的功能.
未來 CTA 將主要被用來支援非 Windows 平台, Cisco 甚至即將公開其原始碼.

與 Cisco 前一代 NAC 相比, 除了改採 NAP client 之外, 最顯著的差異在於整合了微軟的 Health certificate infrastructure. NAP client 將向 HRA (Health Registration Authority) server 回報自己的狀態以索取 Health Certificate, 屆時再以此 Certificate 當作通行證向 ACS 申請網路存取的權限.

Hackers Delight 2-1 (5/5)

2007-02-07T13:29:00.002+08:00

總和以上流程, 可以得到以下式子:

(譯註: 原文附上了C語言的實作原始碼, 我想這裡就免了吧)

如果你的處理器算除法很慢, 但是可以很快地計算尾端0-位元序列長度函數 ntz(x), 前端0-位元序列長度函數 nlz(x), 或1-位元個數函數 pop(x). 則上述式組中的最後一式, 可以代換為下列任一式:

Hackers Delight 2-1 (4/5)

2007-02-06T22:32:00.002+08:00

根據此定理, 我們可以推得 - 想要透過基本運算序列來關閉最左的1-位元是不可能的, 因為某個1-位元是否應該被關閉, 取決於它的左側是否還有其他的1-位元. 觀察其左側位元的需求是絕對無法迴避的, 也因此不可能透過右至左計算法達成.

同理, 想要透過基本運算序列來對一個 word 右移, 旋轉, 左移不定位元, 或計算當中的尾端0-位元序列長度, 都是不可能的. (計算尾端0-位元序列長度時, 輸出的最右位元取決於序列長度的奇偶性, 該性質是不可能只看輸入的最右位元就能決定的)

(譯註: 左移不定位元之所以無法達成, 可透過以下觀察得証: 令輸入當中的最右1-位元為第 x 號位元, 則輸出的第 x 號位元究竟是1還是0, 取決於左移量是否為0, 而想判斷左移量是否為0, 只看左移量的第 x 號位元或其右的位元是絕對不足以判定的)

對於上述的位元運算技巧, 有一個特別的應用: 輸入一個數字, 輸出下一個比它大, 而且含有等量 1-位元的數字. 這技巧可以幫助我們在利用數字來表示子集合的情形下, 窮舉所有相同大小的子集合.

(譯註: 原文很囉唆地說明了用數字來表示子集合的方法, 以下簡單帶過)
想要表示一個子集合, 我們可以把元素宇集存入序列當中, 如此一來每個子集合可以透過一個唯一個數字來表示: 數字當中的 i 號位元為1的時候, 代表該子集內包含 i 號元素.

R. W. Gosper 提出了一個演算法達成了上述的功能. 令 x 為輸入的數字, 該演算法的概念是尋找 x 當中最右的連續1-位元以及其右的0-位元序列, 並"增加"其數值直到含有等量的1-位元為止.

例如, 輸入 xxx0 1111 0000 (xxx 表示任意位元), 輸出 xxx1 0000 0111. 該演算法首先透過 s = x AND (-x) 來找出最右的1-位元. 在本例中得到的是 0000 0001 0000.
然後把它加入 x 得到 r (譯註: r 當中少了 n-1 個1-位元, n 代表連續1-位元的長度). 在本例中 r=xxx1 0000 0000.

接著, 我們必須補上少了的 n-1 個1-位元, 首先計算 r XOR x, 將造出一個有著 n+1 個1-位元的數字. 在本例中 r XOR x = 0001 1111 0000. 很明顯這數字又有了太多的1-位元, 我們將它除以 s, 可消去右側的0-位元序列, 最後再右移兩位元使得當中的1-位元個數為 n-1.

把這個拼拼湊湊造出來的, 有著 n-1 個置右1-位元序列的數字, 和 r 做 OR 運算就可以得到最終的輸出.

Hackers Delight 2-1 (3/5)

2007-02-06T00:06:00.002+08:00

定理一 . 一個函數 f: word -> word 可由能同時計算的加, 減, AND, OR, NOT指令序列所實作, 若且為若其輸出的 word 當中, 每一個位元都只和所有運算元的對應位元, 或其右的位元有關聯.

(譯注: 例如 f1(x,y) = x AND (SHL(y, 1)) 可由基本運算序列達成: x AND (SHL(y, 1)) = x AND (y + y). 而 f2(x,y) = x AND (SHR(y, 1)) 就辦不到)

換句話說, 想像你嘗試計算某函數輸出當中的最右位元, 如果你能夠只看每個運算元的最右位元就能夠計算出來, 而且, 當你嘗試計算右二位元時, 也能只看各運算元的最右及右二位元就能獲得答案, 如此依此類推地嘗試計算.

如果你能夠在上述的限制之下完成計算, 那麼這個函數必定可以可由能同時計算的加, 減, AND, OR, NOT指令序列所實作, 反之則不行.

定理當中, "反之不行"的部分, 証明相當容易.

因為加, 減, AND, OR, NOT指令有個共通的特性, 它們都是即使施以上述限制(以後將以 "右至左計算法" 代稱之), 也能夠進行計算的指令. 所以這些指令的任意組合, 也必定能夠以右至左計算法完成.

而另一個方向的証明, 我們以一個例子來非嚴謹證明之.

假設有一個函數 f 能使用右至左計算法得到輸出, 並假設輸出當中的 2 號 (右 3) 位元定義如下:

我們可以透過下面的方法這樣計算該位元:

首先計算出 SHL(x, 2) (譯註: = (x+x+x+x)), SHL(y, 1) 以及 2 號位元的遮罩

計算 (列 1 OR (列 2 AND 列 3)) AND 列 4 將得到一個輸出, 當中的 2 號位元就是我們想計算的 r_2. 對於其他位元我們可以如法泡製造出它們各自的計算式, 然後和 2 號位元同步地進行運算. 等 32 個輸出被同步地計算完成之後, 再把它們全部 OR 起來即可得到最終輸出.

很容易可以觀察出來, 任何可使用右至左計算法達成的函數, 都能夠以上述的方法造出 32 個基本運算序列並平行計算之, 定理一得証.

Hackers Delight 2-1 (2/5)

2007-02-04T10:55:00.002+08:00

使用下面式子可指示出數字內最右為1的位元以及其右的連續0-位元, 如果根本沒有為1的位元存在, 本式輸出零 (例如 01011000 => 00001111)

使用下面式子可延伸數字內最右為1的位元, 如果根本沒有為1的位元存在, 本式輸出全1 (例如 01011000 => 01011111)

使用下面式子可關閉最右的連續1-位元序列 (例如: 01011000 => 01000000)

這式子亦可用來判斷一個非負整數是否為 2^j - 2^k, j>=k>=0 型. 將數字帶入本式之後檢查是否為0即可.

以上所有式子都有對應的共軛型. 把每個式子的用途描述裡的1和0交換, 然後把式子裡的x-1用x+1取代, x+1用x-1取代, -x用NOT(x+1)取代, AND用OR取代, OR用AND取代, 但維持x跟NOT(x)不變. 轉換後的式子將達成轉換後的用途. 以本節第一個式子為例

用下面式子可以關閉word裡最右為0的位元, 如果根本沒有該位元, 本式將輸出全1 (例如: 10100111 => 10101111)

譯注: 令 f(x) 為原式, f'(x) 為共軛式, 則 f'(x) = NOT(f(NOT(x)) 據此可推得上述的取代規則

Hackers Delight 2-1 (1/5)

2007-02-04T00:54:00.002+08:00

2-1 操縱最右位元

這節提到的式子, 有些看其來沒啥用, 但在後面的章節會陸續找到它們可應用之處

下面式子將把word內 (譯注: 本書所述的word大小為32位元) 最右為1的位元關閉, 當最右為1的位元根本不存在的時候, 本式輸出零 (例如: 01011000 => 01010000)

該式亦可用來偵測一個無號整數是否為power of 2. 把數字帶入該式之後再判斷輸出是否為0即可.
下面這個式子可用來偵測一個無號整數是否為2^n-1型 (包含0跟全1)

下面這個式子可以孤立最右為1的位元, 如果根本沒有為1的位元, 本式輸出零 (例如 01011000 => 00001000)

下面這個式子可以孤立最右為0的位元, 如果根本沒有為0的位元, 本式輸出零. (例如 01011000 => 00001000)

使用下列任一式可產生找出數字最右的連續0-位元串, 如果輸入為零則輸出全1 (例如01011000 => 00000111)

當中第一式可以切割成能同時計算的多個指令 (譯注: 原因詳見本節定理1)