Defcon 21 競賽解題思路 - linked

題目給了一個 C 的 struct
typedef struct _llist {
   struct _llist *next;
   uint32_t tag;
   char data[100];
 } llist;

並且給了一小段 C 的程式碼

register char *answer;
char *(*func)();
llist *head;
...
func = (char *(*)(llist *))userBuf;
answer = (char *)(*func)(head);
send_string(answer);
exit(0);

此關卡程式會亂數配置若干 linked-list。要解開此關，則要送一段 shellcode 給 Server 執行，即 answer = (char *)(*func)(head); 這行呼叫。

Write me shellcode that traverses the randomly generated linked list, looking for a node with a tag 0x41414100, and returns a pointer to the data associated with that tag, such that the call to send_string will output the answer.

看來只要寫個 shellcode，走訪每個 linked-list，檢查 tag 是否為 0x41414100，若是則將此 linked-list 的位址傳回，應該就能讓 Server 吐出答案。
用 C 來表示大概像這樣:

char *shellcode(llist *head)
{
while(1) {
if (head->tag == 0x41414100)
return head->data;
head = head->next;
}
}

看來很簡單吧！
不過實際轉換成 shellcode 送出才發現，Server 回應 shellcode 只吃 16 bytes，也就是 shellcode 長度不能超過 16 bytes。這個長度限制馬上讓這題變成一個難解之題，不管怎麼縮小，改變 asm 指令等，都相當有難度。
此時，就想到如果不照題目所給的流程走，讓 shellcode 直接吐出走訪 linked-list 的所有資料，那 shellcode 能否控制在 16 bytes 之內呢?

用 C 來表示大概像這樣:

char *shellcode(llist *head)
{
dump:
                write(4, head, 100);
head = head->next;
                goto dump:
}

若是照正常的系統呼叫設定各暫存器，那鐵定超出長度，因此有些暫存器要故意忽略不設，例如呼叫 write() 的長度，C 這邊我寫 100，實際上完全不確定會 write 多少字元。

最後寫出的 shellcode 長得這樣:



沒幾行，分別解說如下:

7. pop   edi        
8. pop   ecx          

此兩行主要是因為  (char *)(*func)(head); ，也就是 call 之前會將參數 head 先放入堆疊(Stack) 再執行 call 時 x86 又會將返回位址放到堆疊，因此 pop edi 則會將返回位址取到 edi，而 pop ecx 則會將 head 存至 ecx。此時 ecx = head

10. mov ecx,[ecx]

此行則為 head = head->next，會放在一開始則完全是 shellcode 長度限制考量。

11. xor eax,eax
12. add eax,4

設定 eax = 4，因為 write 系統呼叫編號為 4。

14. push eax
15. pop ebx

恰好打算要輸出的 socket = 4，所以透過 push/pop 把 eax 複製到 ebx，一樣是長度限制考量。

16. ;mov edx,100
17. int 0x80
18. jmp _run

本來想設定 edx，代表要輸出的長度，不過受到長度限制考量，就完全不理長度，看當時執行此 shellcode 時 edx 暫存器值為何，就輸出多少長度，所以把這行註解掉了。
最後就是系統呼叫 int 0x80 把記憶體內容吐出來，然後 jmp _run 則不斷地走訪 linked-list 不斷地吐資料。

寫個小程式 dump，把 shellcode 輸出到 stdout，再透過 nc 送出給 Server。

大概收集個100M ~ 900M，完全看運氣，然後再從 dump 出的記憶體中找尋關鍵字 "The key"。
答案出來!

Defcon 21 競賽解題思路 - incest

好久沒來寫點東西啦！前兩天又是一年一度的 Defcon Quals，照例 CHROOT 集合多位朋友一塊解題闖關。今年我沒能花太多時間在解題，只看了較有把握的兩題也順利解出，先來分享 "\xff\xe4\xcc" 的第一題 - incest。

此題目給了兩隻 Linux x64 binary，maw 和 sis 。當然二話不說，先來 strings。

$ strings maw

eth0
Could not open key.
/home/services/sis

$ objdump -D sis > sis.disasm


從 sis.disasm 反組譯的內容中，可以看到此程式有 fork() 產生的子行程，會配置一塊記憶體，再將 recv() 收到的內容放到此記憶體空間，最後直接呼叫 callq *rdx，跳躍到該記憶體區域執行。而父行程也配了一塊記憶體，從某檔案中讀取內容後，就不斷呼叫 sched_yield()。
如果轉寫成 C 程式碼，大概長得像這樣:

很明顯 maw 是一個網路 daemon，accept() 連線後再執行 sis，執行時會先 open() key file，然後將 key file 的 fd 和 socket fd 一塊傳給 sis。根據 strace/ltrace 可以發現，key_fd = 3，sock_fd = 4，而且 sis 的子行程會直接跳到遠端傳送的資料裡執行。注意到，呼叫 mmap() 配置 sock_buffer 時，是用 PROT_READ|PROT_WRITE|PROT_EXEC，可讀可寫可執行，就可以塞 shellcode 執行啦。

但是，要怎麼取得 key file 的資料呢?

原來的想法是透過打造 open("key", O_RDONLY)，然後 read(key_fd) 再 write(sock_fd)，但測試結果發現會 Permission denied。而根據題目 incest 原意，搭配 sis.c，可以猜想應該是要由子行程透過 ptrace() 來讀取父行程裡的資料，也就是父行程已 read(key_fd, key_buffer)，只要能讀取父行程的 key_buffer 內容，再 write(sock_fd) 就能遠端取得 key_buffer 內容啦。

打造 x64_86 的 shellcode，我是參考此文 64-bit-linux-shellcode，然後用 nasm 寫了一小段程式碼。流程大概如下:
shellcode()
{
int ppid;
int key_buffer_address;
int key_buffer;
int i;
char buffer[40];
user_regs_struct regs;
ppid = getppid();

ptrace (PTRACE_ATTACH, ppid, NULL, NULL);
wait(NULL);
ptrace (PTRACE_GETREGS,ppid, NULL, &regs);
key_buffer_address = regs.rbp-0x18;
ptrace (PTRACE_PEEKDATA, ppid, key_buffer_address, &key_buffer);
for(i = 0; i < 10; i++)
ptrace (PTRACE_PEEKDATA, ppid, key_buffer+i*8, buffer+i*8);
write(4, buffer, 40);
}

根據前面所提的 sis.disasm

1. 400949:       e8 82 fd ff ff          callq  4006d0
2. 40094e:       48 89 45 e8             mov    %rax,-0x18(%rbp)

可以發現，取得父行程 rbp 暫存器值後去 -0x18，即為存放 calloc() 配置的記憶體位址。所以透過
key_buffer_address = regs.rbp-0x18;
ptrace (PTRACE_PEEKDATA, ppid, key_buffer_address, &key_buffer);

則會得到父行程的 key_buffer 位址啦，接著用一個 for-loop 把父行程的 key_buffer 存的內容讀出來，再透過 write() 輸出到 sock_fd = 4，就能看到解答。
此題  shellcode 的 nasm 如下:

使用 nasm 編譯後，寫了一個小程式 dump，把 shellcode 輸出 stdout。

這樣就過關啦！

Gaim-Encryption

Gaim-Encryption 是一個 Gaim 通訊加密模組，它利用 Mozilla 的 NSS (Network Security Services) 來提供 RSA 加密。
今天 Nanika 要找人測試 Gaim-Encryption，才想起一年前我曾抽了點空將 Gaim-Encryption zh_TW.po 翻譯好。
連上官方網站才發現 i18n 網頁上竟把中文放在第一行，而 進度統計 卻是將 zh_TW.po 排在最後。這讓偷懶了一年的我看了真有點汗顏。於是，馬上就抽空下載了 Gaim-Encryption 3.0beta2 並試著更新 zh_TW.po。
此外，我也順便下載了 Gaim 2.0beta1，果然高級啊，可以看得到 MSN 小動畫了哩。真讚！
經過一番努力，已把 zh_TW.po 更新並送至 mailing-list了。希望可以順利在 Gaim-Encryption 3.0 Release 時看到中文化的成果囉。

如果你怕你的 MSN 訊息被監聽，或是怕被監控記錄，請愛用 Gaim-Encryption 吧！

BTW, 我是用 gtranslator 這套工具處理 po 檔的。

註：Gaim-Encryption i18n 統計其實是用開頭字母順序排的啦！ :-)

Enigmail OpenPGP

自從下定決心開始要來使用 OpenPGP 後，我花了幾乎一整個下午在處理 Thunderbird Enigmail。

當然，我不會錯過用 urpmi 工具來輕鬆安裝 enigmail，只要敲入 urpmi enigmail，相關套件就裝好了。只不過，重新啟動 Thunderbird 後，Enigmail 並不能正確的運作。幾乎所有 Enigmail 相關的功能，全數不能使用。

然後就不斷的從 google 裡找答案，試了好幾次的移除(rpm -e) 和安裝(urpmi)。即使，試著直接從 Enigmail 的網站 http://enigmail.mozdev.org下載，最後安裝還是失敗。

也許是 mozilla-thunderbird-1.0.2-5.1.102mdk 版本太舊? 好吧，我決定從 Thunderbird網站直接下載升級 Thunderbird。不用 RPM 套件了！

將下載回來的 thunderbird-1.0.7.tar.gz 解壓到 /usr/lib
# tar zxf /tmp/thunderbird-1.0.7.tar.gz
# mv thunderbird/ /usr/lib/mozilla-thunderbird-1.0.7
再編輯 /usr/bin/mozilla-thunderbir，將其中 moz_libdir=/usr/lib/mozilla-thunderbird-1.0.2 字串改為
moz_libdir=/usr/lib/mozilla-thunderbird-1.0.7

然後下載 Enigmail-0.93.0後，執行 Thunderbird。
再從 Thunderbird 裡的 Tools->Extensions 裡安裝 enigmail-0.93.0-tb10-linux.xpi。
最後，重新執行 Thunderbird。



太讚了，OpenPGP Key Management 可以用了。看來一切應該都正常可以用了。酷吧！

可愛小硬碟

下午跑去 NOVA 買了顆 2.5 吋 WD800UE 小硬碟，它的外觀如下：

據說 WD Scorpio?技術還不錯，夠安靜。

當然，回到家就馬上接上 X31，底下是 Linux 偵測到的硬體資訊：

USB Mass Storage support registered.
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
Vendor: WDC WD80 Model: 0UE-00HCT0 Rev: 09.0
Type: Direct-Access ANSI SCSI revision: 00
usb-storage: device scan complete
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
sda: assuming drive cache: write through

接著用 fdisk /dev/sda 作切割：

Command (m for help): p

Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sda1 1 9729 78148161 83 Linux

再用 mkfs.ext3 -c -j /dev/sda 作檢查並格式化，最後用 tune2fs -m 0 將保留空間釋放。
# mount /dev/sda1 /mnt/tmp/
# df -h /dev/sda1
Filesystem 容量 已用 可用 已用% 掛載點
/dev/sda1 74G 33M 74G 1% /mnt/tmp

來測測看速度吧！X31 裡硬碟的速度：
# hhdparm -t /dev/hda
/dev/hda:
Timing buffered disk reads: 74 MB in 3.00 seconds = 24.66 MB/sec
而新入手的 WD 小硬碟呢
# dparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 60 MB in 3.05 seconds = 19.64 MB/sec

嗯，慢了一點，不過還是適合我用來備份資料 :)

聊聊 ASUS WL500g

上個星期從 jouston blog 看到 ASUS WL500b/g 的消息, 當下就去網站上下載了全部的 Soure Code 來研究.
現在我就用這台 WL500g 無線上網中, 感覺還不錯用哩. 根據從原始碼來看, CPU 為 MIPS32/little edian 搭配 Linux Kernel 2.4.20, 根目錄檔案系統(rootfs)採用 Cramfs 並未使用 ramdisk(initrd). Wireless Solution 採用 Broadcom 的晶片.
MTD partition 分為四層 nvram, bootloader(pmon), kernel, rootfs. 系統參數存放在 nvram, 按住 reset 鍵五秒可恢復出廠預設值. 而 rootfs 只有一份因此沒有 backup firmware 功能, kernel 初始化後會從 flash 直接載入 rootfs.
使用的軟體還有 Busybox 0.60.0, mini_httpd, pppd/re-pppoe, birdge utils, iptables, GNU zebra 等. 令人訝異的是, 似乎toolschain, web 網頁也完整開放出來.
儘管已經是個不錯的產品, 我還是龜毛的希望有更好的功能支援, 也許透過 Firemware Upgrade 的方式, 可以私下作些改良,底下是我對此產品的建議:
1. Proxy support -
如果能把 proxy(squid) 功能加入會更好用, 不過可能需要更多的硬體資源.
2. Samba Server support -
雖然有 stupid_ftpd 來讓使用者存取 USB-storage, 但網路芳鄰應該比 FTP 來得容易使用.
3. Traffic Control (QoS) support -
真的, 若有 QoS 就更美啦! 這個功能應該多佔不了多少 flash 空間.
4. VPN/PPTP support -
哈哈哈....別理我.
說真的, 國內很多公司在做 embedded linux, 但像華碩那樣開放整個 150MB 原始碼的實在很少. 真的該多支持多鼓勵.
聽說華碩最近有在徵 Embedded 的工程師喔! 或許我該去應徵呢? 呵呵...

Who Call Me?

誰叫我? 有用過 gdb 對 core 檔作 bt (backtrace) 嗎? 所謂 backtrace 是用來回溯檢查函式呼叫的關係, 以便了解是由那一個函式呼叫出問題的函式. 尢其是在許多錯綜複雜的龐大程式碼中, backtrace 是相當有用的 debug 技巧. 而這個題目則是用來討論如何在程式執行中作 backtrace.

在實作這個技術前有兩個關鍵點要先解決:

1. 如何取得此 function 返回位址.
2. 如何依據返回位址查知函式名稱.
關於第一點, 必須先了解堆疊(Stack) 和函式呼叫的處理關係. 堆疊是一個後進先出(Last-In-First-Out)的資料結構. 當呼叫某個函式時, 相關的暫存器(Register)就會被存入堆疊. 而當函式返回時便會從堆疊裡取回返回位址以便回到原來呼叫的下一個指令繼續執行. 至於暫存器(Register), 其中 EIP 是 Instruction Pointer, 用來指出 CPU 將要執行指令的位址. ESP 暫存器則是用來指向目前堆壘的位址.

我們先寫個小程式來觀察可行性.

----------- test.c -----------
void test()
{

}

int main()
{

test();
}
------------------------------

[tim@localhost whocallme]$ gcc -o test test.c
[tim@localhost whocallme]$ gdb ./test
GNU gdb 5.3-25mdk (Mandrake Linux)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i586-mandrake-linux-gnu"...
(gdb) b test
Breakpoint 1 at 0x804832f
(gdb) r
Starting program: /home/tim/research/whocallme/test

Breakpoint 1, 0x0804832f in test ()
(gdb) info reg
eax 0x0 0
ecx 0x1 1
edx 0x4014fe50 1075117648
ebx 0x4014e9a0 1075112352
esp 0xbffff698 0xbffff698
ebp 0xbffff698 0xbffff698
esi 0x40013880 1073821824
edi 0xbffff6f4 -1073744140
eip 0x804832f 0x804832f

(gdb) disas test
Dump of assembler code for function test:
0x804832c : push %ebp
0x804832d : mov %esp,%ebp
0x804832f : pop %ebp
0x8048330 : ret
End of assembler dump.

ebp 暫存器值是 0xbffff698, 也就是原來的堆疊位址. 我們知道在呼叫函式時(call) CPU 會將返回位址存入堆疊, 因此可以從 ebp 暫存器的位址裡面找到我們需要的返回位址:

(gdb) p/x *0xbffff698
$1 = 0xbffff6a8

別忘了, 一進入此函式時 push $ebp 已被執行, 因此堆疊位址已被減 4, 所以要取得正確的值還得把 4 加回去才行:

(gdb) p/x *(0xbffff698+4)
$2 = 0x8048346

這個值應該就是 test() 正確的返回位址, 來檢查看看:

(gdb) disas main
Dump of assembler code for function main:
0x8048331

: push %ebp
0x8048332 : mov %esp,%ebp
0x8048334 : sub $0x8,%esp
0x8048337 : and $0xfffffff0,%esp
0x804833a : mov $0x0,%eax
0x804833f : sub %eax,%esp
0x8048341 : call 0x804832c
0x8048346 : leave
0x8048347 : ret
0x8048348 : nop
0x8048349 : nop
0x804834a : nop
0x804834b : nop
0x804834c : nop
0x804834d : nop
0x804834e : nop
0x804834f : nop
End of assembler dump.

果然在 call 完後的下個指令是位於 0x8048346, 也就是 test() 返回位址.
接下來我們就用 C 和一些 assembly 配合來實作.

------------- test-1.c ------------------
void test()
{
unsigned long *stack;
asm ("movl %%ebp, %0\n"
printf("ret address = 0x%x\n", *(stack+1));

}

int main()
{

test();
}
-----------------------------------------

[tim@localhost whocallme]$ ./test-1
ret address = 0x8048394
[tim@localhost whocallme]$ gdb ./test-1
(gdb) disas main
Dump of assembler code for function main:
0x804837f

: push %ebp
0x8048380 : mov %esp,%ebp
0x8048382 : sub $0x8,%esp
0x8048385 : and $0xfffffff0,%esp
0x8048388 : mov $0x0,%eax
0x804838d : sub %eax,%esp
0x804838f : call 0x804835c
0x8048394 : leave
0x8048395 : ret
0x8048396 : nop

第一個關鍵點目前已解決, 再來要想想怎麼要能夠依記憶體位址查知所處的函式名稱呢?

更多詳細的內容請看 Who Call Me? 一文.

DOSBOX 下玩 CCH

這兩天在 Sayya BBS 上有朋友討論圍棋、象棋,
後來更有人在 Linux 下直接玩一個古考的 DOS 遊戲 - 將族.
將族應該是我高中時候的遊戲, 當時的我對象棋非常著迷, 而將族的棋力又非常不錯, 我記得我曾經打敗過所有一星和二星的棋士, 但三星就很困難了.
今天我也去下載了 DOSBOX, Mandrake 的使用者可以至 cooker 下載 dosbox-0.61-1mdk, 原來 Mandrake 9.2 的 dosbox 0.58 版本太舊無法正常執行 CCH.

Ok, 從上面這張 screenshot 來看效果不錯, 而且音樂音效也有出來, 美中不足的是偶爾 dosbox 會突然爆炸....

悼 Maxtor 硬碟

去年(2003)六月時買的硬碟, 突然一聲不吭的就出問題了, 裡頭的資料啊.....

由於平時沒有勤備份的習慣, 目前已服役數年的兩顆 Maxtor 也都還十分認真,
實在料想不到好好的 Maxtor 80G 用不到一年就出問題, 以致許多重要資料就
此遺失.

底下的 messages 為已陣亡的 Maxtor 6Y080L0(/dev/hde) 記錄:

Jan 13 10:58:39 debian kernel: Partition check:
Jan 13 10:58:39 debian kernel: hda: hda1 hda2 hda3 < hda5 hda6 >
Jan 13 10:58:39 debian kernel: hde:hde: dma_intr: status=0x51 { DriveReady See
Jan 13 10:58:39 debian kernel: hde: dma_intr: error=0x40 { UncorrectableError }
Jan 13 10:58:39 debian kernel: end_request: I/O error, dev 21:00 (hde), sector
Jan 13 10:58:39 debian kernel: hde: dma_intr: status=0x51 { DriveReady SeekComp
Jan 13 10:58:39 debian kernel: hde: dma_intr: error=0x01 { AddrMarkNotFound },
Jan 13 10:58:39 debian kernel: hde: dma_intr: status=0x51 { DriveReady SeekComp
Jan 13 10:58:39 debian kernel: hde: dma_intr: error=0x40 { UncorrectableError }
Jan 13 10:58:39 debian kernel: end_request: I/O error, dev 21:00 (hde), sector
Jan 13 10:58:39 debian kernel: hde: dma_intr: status=0x51 { DriveReady SeekComp
Jan 13 10:58:39 debian kernel: hde: dma_intr: error=0x40 { UncorrectableError }
Jan 13 10:58:39 debian kernel: end_request: I/O error, dev 21:00 (hde), sector
Jan 13 10:58:39 debian kernel: hde: dma_intr: status=0x51 { DriveReady SeekComp
Jan 13 10:58:39 debian kernel: hde: dma_intr: error=0x40 { UncorrectableError }
Jan 13 10:58:39 debian kernel: end_request: I/O error, dev 21:00 (hde), sector
Jan 13 10:58:39 debian kernel: unable to read partition table

當然, 遇到問題總不能馬上投降. 因此上網找尋了 smartmontools 來檢測
使用 smartctl -H /dev/hde 確認了硬碟無法使用後才放棄.

第二天出發至 NOVA 找店家, 並在店家的指示下到地下一樓的 Maxtor 維修中心,
填妥資料即馬上領了新的硬碟, 一樣還是 Maxtor 6Y080L0. 說到這, 我在 google
時注意到有許多人的 Maxtor 6Y080L0 在用不到一年即有類似的情況.

此外, 我也特意買了新的 ATX Power 和硬碟散熱風扇, 希望這次的 Maxtor 6Y080L0
能服役更久些...

底下是良好的 Maxtor 6Y080L0 狀況
[root@www src]# smartctl -H /dev/hde
smartctl version 5.30 Copyright (C) 2002-4 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

最後,
希望大家的硬碟都身體健康, 並養成常洗手常備份的習慣, 謝謝.

關於 Dlink 650+ for Linux

各位看倌, 有人用過 Dlink 650+ wireless card 嗎?
今個兒, 我想談談這個卡用的 TI acx100 chipset 的故事...
首先, 我個人覺得這是張不錯的卡, 然而不錯在那我並不十分清楚.
只不過, 如果有人和我一樣是個 linuxer 又恰巧買了 Dlink 650+ 那就十分不妙了...
Dlink650+ 用的是 TI 的 acx100 chipset, 而前一代 Dlink 650 並非用 acx100 chipset, 而且 Dlink650 在 Linux 上 support 還算不錯.
當有些 linux 朋友見到功能更強的 Dlink 650+, 而希望在自個的 linux 上使用時, 便開始了一連串的惡夢....
首先, 來看看外國人的討論 SeattleWireless: DlinkDwl650Plus

節錄其中一段:
============
I just checked and D-Link (listed as D Link Systems Incorporated) is a member of the Better Business Bureau (their ID is 13033848). Since D-Link and TI and not listening to us this way, perhaps they will listen if their BBB status is at risk (this is valuble to companies for many reasons)..

Here are the facts:

* From around August 2002, D-Link support began telling Linux users that a driver would be released in December, so we should just hang on until then.

* Eventually, an offical FAQ item showed up on their web site stating this.

* In December, it was annouced that the driver had be delayed til Quarter 1 of 2003.

* At the end of December, D-Link reversed course and began telling users that there were no plans for a Linux driver because they coundn't obtain the source code from TI. After the Eusso driver became available and Eusso support stated that they obtained the source for the driver from TI under an NDA, this statement was retracted by D-Link

* At the current time, the driver's development has apparently been frozen and now we're all stuck with card we were told would be supported.

===========

僅管 Dlink 在不久前放出了 linux binary driver for Dlink 650+, 但是有些 hacker 已耐不住性子了, 開始了 Acx100ReverseEngineering計畫, 想利用已有的 binary driver(linux/windows)作逆向工程, 並在 sourceforge 開個 acx100 oss driver project...

從 20030706 release 的成果來看, 已令我十分吃驚. Ad-Hoc without WEP 已可使用. 而且整個 source tree & code 整理的十分好. 很難想像是完全沒有任何文件或技術支援下硬幹出來的產物.

這個 porject 會發展起來也算是對製造商的一種抗議, 據我所知, Dlink 事實上也想 release linux station driver source, 只不過 TI 基於一些商業因素(可能還有其它)並不願意釋出 source. 也可能 source 裡有一些機密形成的商業考量.


最後, 我想節錄一段 acx100 oss driver project 的 README 作為結束, 我不便譯為中文, 那會失去一些原味, 請各位好好細讀一翻 :-)

Let me mention that we REALLY dislike the way very stupid hardware vendors
name their cards containing DIFFERENT chipsets!!

One of these vendors is SpeedStream/Siemens: a card that uses the same
name "SS1021" is available in both Orinoco chip and ACX100 chip versions.

Another one is D-Link: they have "DWL-650" and "DWL-650+".
"DWL-650+" is simply an improved version of the "DWL-650", right?
WRONG!
The standard versions use Prism2.5, whereas the "+" versions use ACX100
chipset. Good luck in finding a (correct) driver!!
And it's even WORSE: I just found out that there is some newer
version of the "DWL-650" out that also contains the ACX100
(it uses the same hardware as the "+" versions).
This BRAINDEAD STUPIDITY in device naming easily entitles D-Link
for the "Most Braindead Hardware Vendor 2003" award. And of course
they were also talking about developing another Linux driver for some time,
without any results (although I guess that's because they wanted to
develop it, but were not allowed to, unfortunately, so it's understandable).

IF you dare to release cards with a different incompatible chipset
that doesn't even have proper driver support for a popular alternative OS,
then AT LEAST change the card name in order to let people know and discern
which hardware to avoid like the plague, for heaven's sake!
This is such a , I could ...

Finally, let me mention that we really dislike the way how
Texas Instruments handles Linux driver support. It's a really shameful
pity, with delays to be measured in years versus the Windows driver
support, and with poor and buggy binary driver support.
All in all our team would be very grateful to receive proper
development support and cooperation from TI in order to create
proper Linux drivers. That would be The Good Way to do it...
(although admittedly that would still only be the second-best way to do it,
with the best way being to have paid company developers work on a
well-working OSS driver, of course)
After all it's the hardware VENDOR that's earning money via OUR, the
customers', payment, so it should be the damn responsibility of the
hardware vendor to ensure good driver support, not the other way around!
Just imagine the weird looks of thousands and thousands of Linux users
when they discovered the lack of support for the product that they just
shelled out considerable amounts of money for...

傾印執行檔 (dump2bin)

很久以前曾經看到一位很有名的 hacker - silvio 將 core 檔轉換成 ELF 執行檔(core2elf), 當時覺得非常有趣. 在 Un*x 的檔案權限限制裡, 如果我們將某個執行檔設為可執行卻不可讀寫, 那麼我們將無法讀取檔案內容, 也無法對該執行檔作正常的 gdb 動作.
對執行檔進行讀取和除錯其實是逆向工程或是系統安全裡的基本操作, 有些系統管理者或程式設計者太過信賴 Un*x 權限管理, 將過多的資訊保存在執行檔裡, 卻可能導至一些問題的發生.
這個程式 dump2bin.c 是我利用 Linux 提供的 ptrace 系統呼叫, 將執行檔內容傾印至指定的檔案.
例如: ./flags 原本是不可讀寫的執行檔, 但經過 dump2bin 轉換成 ./flags2 即可讀寫.
flags 的 file owner 可以為任何人, 只要可以執行的檔案都可轉換.

[tim@localhost hack]$ ls -al ./flags
---x--x--x 1 tim tim 11400 6月 23 17:21 ./flags*
[tim@localhost hack]$ ./dump2bin ./flags ./flags2
Ready to dump ./flags to ./flags2 ...
Child pid = 12183
Converted successfully!
[tim@localhost hack]$ ls -al ./flags2
-rwx------ 1 tim tim 11400 7月 1 01:01 ./flags2*
[tim@localhost hack]$ file ./flags2
./flags2: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), stripped