上圖中，最上方的標題欄有「first.exe」，代表已載入程式了。x64dbg 的畫面和 OllyDbg 很像，也分割成幾個主要的視窗：①反組譯區 ( 藍色框 )、②訊息區 ( 紅色框 )、③資料顯示區 ( 橙色框 )、④暫存器區 ( 紫色框 )、⑤堆疊區。 接著上一章，先介紹 Windows API 的特性，再來介紹上一章 FIRST.EXE 所呼叫的 MessageBox 與 ExitProcess 兩個 API。
眼尖的讀者可能會發現，在 FIRST.ASM 中的第二行是「EXTRN MessageBoxA:PROC」、第二十一行是「call MessageBoxA」，而且上一章結尾才說要介紹 MessageBoxA，但本章第一行怎麼就變成了「MessageBox」，其中的「A」怎麼不見了？莫非是小木偶打錯字了。
其實不然。凡是牽涉到與字元有關的 Windows API 都有兩套，一套是用來處理 ANSI 編碼的字串，在其名稱後面會多了「A」字元；另一套用來處理以萬國碼 ( UNICODE ) 編碼的字串，其名稱後面會多了「W」字元 ( W 代表寬字元的意思，用兩個或兩個以上的位元組來表示一個字元，就稱為寬字元 )。不牽涉到字元的 API，結尾就沒有「A」或「W」。
好吧，MessgaeBoxA 或 MessageBoxW 的分別是在視窗內的字串及標題字串，當然牽涉到字串，所以有兩個版本，這沒有問題。那怎麼又多出一個 MessageBox 呢？這跟包含檔有關。
在第一章及這一章裡的 FIRST.ASM 並未引入包含檔，除了因為這個程式很單純外，小木偶希望能減少隱藏的細節，也是為了能解釋得更詳盡。但是往後我們撰寫程式，必定會將包含檔引入，這可以減少非常非常多煩瑣的工作。包含檔內必會有以下的宣告：
IFDEF __UNICODE__ MessageBox equ <MessageBoxW> ENDIF IFNDEF __UNICODE__ MessageBox equ <MessageBoxA> ENDIF
這段程式裡的
IFDEF name 敘述 ENDIF IFNDEF name 敘述 ENDIF
其實是兩個假指令。前者是說，如果已經定義了 name 的話，組譯器就會組譯 IFDEF 與 ENDIF 之間的敘述 ( DEF 是「定義了」的意思 )。後者則是，如果未定義 name 的話，組譯器就會組譯 IFNDEF 與 ENDIF 之間的敘述 ( NDEF 是「未定義」的意思，N 應該是 not 的意思 )。
所以剛才提到包含檔內必有的敘述是說，如果已定義了「__UNICODE__」變數，那麼「MessageBox」就等於「MessageBoxW」；如果未定義「__UNICODE__」變數，那麼「MessageBox」就等於「MessageBoxA」。由此可知，只要在程式起頭有「__UNICODE__ EQU 1」就代表已定義「__UNICODE__」變數，組譯器會使用寬字元版的 API；若無，就使用 ANSI 版的 API。不管是哪一種，只有文字的編碼方式不同其餘均相同，在微軟發佈的文件中都以 MessageBox 來稱呼。其他牽涉到字元的 API 也都如此。
這裡微軟用 ANSI 編碼的講法其實很奇怪，因為 ANSI 是 American National Standards Institute 的縮寫，中文為「美國國家標準協會」，是一個組織並非編碼方式。它所制定的 ASCII 字元後來被微軟擴充成 Windows-1252，Windows-1252 是拉丁字母的字元編碼，主要用於英語、愛爾蘭語、義大利語等，成為 Windows 的預設編碼。大概是因為這原因，所以才用「ANSI」吧，但小木偶有時也稱之為 ASCII 編碼。
如果字串包含中文，且以 Big-5 編碼，那麼就要呼叫 ANSI 版的 API。這是因為 Big-5 編碼是利用 Windows-1252 中的「空隙」完成的，所以要呼叫 ANSI 版的 API。
另一種「寬」字元版本的講法也一樣奇怪，如同前述「寬字元的意思，用兩個或兩個以上的位元組來表示一個字元」，萬國碼其實只是其中一種。再者，萬國碼的編碼方式也有許多種，常見的就有 UTF-8 和 UTF-16。而寬字元版本的 Windows API 是採用 UTF-16 編碼方式。
主程式呼叫副程式時，必須把參數傳給副程式，但要如何傳呢？利用堆疊還是暫存器、前後次序是如何安排、回傳值如何傳回給主程式、主程式還是副程式清理堆疊……等問題。這些問題，主程式與副程式都必須達成一致，才能正確執行。因此要有統一的規定，這些規定稱為呼叫慣例或呼叫協定。
呼叫協定有許多種，在 Win64 API 使用的呼叫慣例稱為「FASTCALL」。但有些文獻則說類似 FASTCALL，有些甚至說 FASTCALL 並沒有嚴格的定義，小木偶也不知採信哪一種，或許就稱為「x64 呼叫慣例」或是「Win64 呼叫慣例」。不論如何，Win64 API 必須遵守的呼叫慣例，有下列規則：
第 3 點有進一步說明的必要。一個節 ( paragraph ) 的大小是 16 個位元組，所以第 3 點的意思就是，在執行 CALL 之前，RSP 之值必須是對齊 16 個位元組；更詳細的說，就是 RSP 要能被 16 整除。最簡單判斷的方式，把 RSP 變成十六進位時 ( 通常在除錯器中都是以十六進位表示 )，最右邊那位數必須是零 ( 也可以把這個數看成是十六進位的個位數，就像十進位的 1234，個位數是 4 一樣 )。如果不是的話，那麼在執行 CALL 之前必須自行調整，方法也很簡單，使 RSP 減去八就行。你可能會問，如果沒有對齊 16 個位元組會怎樣？答案也很簡單，程式會當掉！
雖然第 6 點提到，不要改變 RBX、RBP、RSI 等暫存器，但並非硬性規定完全不能使用。只要事先將其儲存起來，就能自由使用這些暫存器，等要呼叫 Windows API 前再恢復它們之前的數值，也是可以的。不過其中的 RBP 較為特別，能不用就不用。
底下小木偶就要介紹 MessageBox 與 ExitProcess。
MessageBox 是許多 Windows API 中的其中一個，它的功能是在螢幕上建立一個視窗並顯現出來，視窗內有一段文字及圖示，也有按鈕可供使用者關閉此視窗。呼叫 MessageBox 所需要的參數有四個，可以查閱 MSDN ，得到下面的結果：
int MessageBox( HWND hWnd, // handle of owner window LPCTSTR lpText, // address of text in message box LPCTSTR lpCaption, // address of title of message box UINT uType // style of message box );
上面函式的寫法是以 C 語言的方式表現的，可能會因為 MSDN 版本不同而略微不同，不影響不大。「int MessageBox」中的 int 表示回傳值的資料類型為整數 ( integer )，Windows API 的回傳值都存放在 RAX 暫存器裏。接下來是函式名稱，MessageBox，要注意大小寫。接下來，在「( )」內有四個參數，這四個參數都是用「資料類型」和「參數名稱」為一組的方式表示。
例如第一個參數的資料類型是「HWND」，名稱是 hWnd。「HWND」是一種資料類型，在包含檔案內，必有一條宣告「HWND TYPEDEF QWORD」，也就是說「HWND」其實就是「QWORD」。
所以第一個參數，hWnd，的資料類型是四字組的整數，那麼這個整數有什麼意義呢？查閱 MSDN 得知，hWnd 是指哪一個視窗呼叫了 MessageBox，也可以想成 MessageBox 屬於哪個視窗。如果是 0 的話，表示 MessageBox 不屬於任何視窗。在 Windows 作業系統裏，每個視窗都有一個號碼，Windows 用這個號碼處理視窗的所有動作，例如使用者把視窗放大、縮小、移動位置……等等，Windows 就會以這個號碼處理相對應的動作，這個表示視窗的號碼是以一個 64 位元的正整數，稱之為視窗代碼 ( handle of window，本義是操作視窗，但翻譯程式窗代碼比較通順吧 )，每個視窗的視窗代碼都是獨一無二的。從這裏，也可以猜出來，hWnd 的 h 是 handle 的意思，Wnd 是視窗的意思。
往後還會遇到許多代碼，英文都稱為 handle，在 Win64 裡，都是長 64 位元的正整數。對我們的程式而言，只需知道它代表甚麼，其數值並不重要，至於如何處理它通常都是交由 Win64 API 去做；儘管如此，Windows 作業系統卻是依據這些代碼去管理它們。常見的代碼有視窗代碼、檔案代碼、模組代碼、圖示代碼……等等。
MessageBox 剩下參數的資料類型還有 LPCTSTR 和 UINT，其實依序就是 QWORD 與 DWORD 的意思。你可能會問，為何要這麼麻煩，設立新的資料類型，結果卻跟原來的一樣？這是因為在 Windows 系統裏，用 LPCTSTR 能夠很容易的從字面上就知道，此類型的資料是指向萬國碼常數字串的遠程指標 ( L 代表 long，遠程之意；P 代表 pointer，指標之意；C 代表 constant，常數之意；T 代表 _T，是處理萬國碼字串的巨集；STR 代表 string，字串的意思 )。UINT 是指無號的整數 ( unsigned integer )。
第二個參數，lpText，要顯示在視窗裏的字串位址，而此字串須以「0」為結尾。在組合語言裏，位址就是 C 語言裏的指標。
第三個參數是 lpCaption，是視窗標題欄的字串位址，而此字串須以「0」為結尾。
第四個參數是 uType，顯示於視窗的按鈕形式或圖示，常用的數值如下表：
| uType | 數值 | 意義 |
| MB_OK | 0h | 只顯示「確定」按鈕 |
| MB_OKCANCEL | 1h | 顯示「確定」與「取消」兩個按鈕 |
| MB_ABORTRETRYIGNORE | 2h | 顯示「終止」、「重試」、「略過」三個按鈕 |
| MB_YESNOCANCEL | 3h | 顯示「是」、「否」、「取消」三個按鈕 |
| MB_YESNO | 4h | 顯示「是」、「否」兩個按鈕 |
| MB_RETRYCANCEL | 5h | 顯示「重試」、「取消」兩個按鈕 |
| MB_CANCELTRYCONTINUE | 6h | 顯示「取消」、「重試」、「繼續」三個按鈕 |
解釋完從 MSDN 裡查到的 Windows API 之後，將其改寫成組合語言的兩種樣子：
invoke MessageBox,hWnd,lpText,lpCaption,uType
或
invoke Message,\
hWnd,\ ; handle of owner window
lpText,\ ; address of text in message box
lpCaption,\ ; address of title of message box
uType ; style of message box
第一種是僅寫一行，較為簡單，但若參數多時可讀性較差。第二種是把一個參數佔用一行，佔用篇幅大，但可讀性較好。兩種方式組譯結果都一樣，沒有差別。
第二種寫法的第一行是呼叫的 Windows API 名稱，MessageBox。接著的四行就是四個參數，每一行最後面有這個參數的註解，註解前的「\」稱為「連續字元」，它使組譯器把下一行看成是連接在這一行之後。這種情形多用在「invoke」假指令上，尤其是呼叫的參數很多時，往往會分成好幾行寫，這時候就是「\」派上用場的時候了。往後的 Windows API 都會以組合語言的形式 ( 第二種寫法 ) 介紹，畢竟小木偶不是在做 C 語言教學，也為了將來方便查閱。
上面的兩種寫法是往後引入包含檔時的寫法，是不是簡單明瞭？事實上，在 MASM64 中，invoke 是一個在包含檔內的巨集指令；在 UASM 中，invoke 已經寫在 UASM64.EXE 組譯器內，成為假指令。invoke 能把前四個參數存放到對應的暫存器裡，把超過四個的參數存放到堆疊裡，然後會執行 CALL 指令呼叫 Win64 API。
如果不用包含檔，就變成下面的程式碼，這也是 FIRST.ASM 的程式碼。現在你就知道為何會有這五行了，原因很簡單，它們都是 MessageBox 的參數，必須遵守 x64 呼叫慣例，前四個參數由暫存器傳遞。
xor rcx,rcx ; hWnd＝0，存入 RCX mov rdx,OFFSET szText ; RDX＝szText 的位址 lea r8,OFFSET szCaption ; R8＝szCaption 的位址 mov r9,MB_OK ; R9＝MB_OK call MessageVoxA
ExitProcess 是結束 Windows 程式時所用的 API，它會把控制權交還給 Windows，同時也傳回一個數值給 Windows，可以供其他程式或 Windows 使用。它的語法是：
C 語言形式：
VOID ExitProcess(
UINT uExitCode
);
組合語言形式：
invoke ExitProcess,\
uExitCode ; exit code for all threads
VOID 代表 ExitProcess 沒有回傳值。廢話，執行完 ExitProcess 程式就已經結束了，控制權也不會回來原本的程式，當然沒有回傳值。ExitProcess 只有一個參數，就是把一個數值傳給 Windows，這個數值可以給 Windows 或其他程式使用。一般而言，如果正常結束，此數值設為零；如果是因為產生錯誤，此數值可以表示錯誤編號。
FIRST.ASM 的第二十三、二十五行是：
pop rcx
call ExitProcess
在第十六行是「push rcx」，此刻 RCX 為零，到了第二十三行「pop rcx」，所以第二十三行其實是把在第十六行推入堆疊的 RCX 取回來，執行完後 RCX 為零。接著是呼叫 ExitProcess 就結束程式，同時將零回傳給系統。
現在再來檢視下面的 main 副程式。第十五、第十七∼第十九行是呼叫 MessageBoxA 的四個參數，分別存放在 RCX、RDX、R8、R9 裡，第二十一行是呼叫 MessageBoxA。第十五行使 RCX 變為零，而後會呼叫 ExitProcess，也希望把零傳回給 Windows，所以第十六行把這個零值推入堆疊保存起來，到了第二十三行就可以自堆疊取回來，到第二十五行呼叫 ExitProcess 作為參數使用。到此幾乎所有程式都已說明過了，剩下第二十、第二十二、第二十四行尚未解釋 ( 以白色字標示 )。
14 15 16
17 18 19 20
21 22 23 24
25 26 |
main PROC
xor rcx,rcx
push rcx
mov rdx,OFFSET szText
lea r8,OFFSET szCaption
mov r9,MB_OK
sub rsp,20h
call MessageBoxA
add rsp,20h
pop rcx
sub rsp,28h
call ExitProcess
main ENDP |
這三行都是把 RSP 加上某數或減去某數，它跟保留影子空間與 RSP 對齊節位址有關。等會追蹤 FIRST.EXE 時再一起解釋。
為了讓我們更瞭解 FIRST.EXE 運作情形，也為了將來除錯，小木偶簡單的介紹如操作 x64dbg。依據第零章除錯器的說明安裝好 x64dbg 後，以滑鼠左鍵在其圖示上點擊兩次，執行 x64dbg。然後在選單上選擇檔案→開啟→切換到 FIRST.EXE 所在子目錄，選擇它，畫面如下：
上圖中，最上方的標題欄有「first.exe」，代表已載入程式了。x64dbg 的畫面和 OllyDbg 很像，也分割成幾個主要的視窗：①反組譯區 ( 藍色框 )、②訊息區 ( 紅色框 )、③資料顯示區 ( 橙色框 )、④暫存器區 ( 紫色框 )、⑤堆疊區。
現在在反組譯區內顯示的程式是屬於 Windows 系統內的程式，並不是我們所撰寫的 FIRST.EXE 程式，因此得先顯示我們的程式才行。按下鍵盤上的「F9」快捷鍵（F9 是執行的意思。也可以用滑鼠點選標題欄下方的主選單「除錯」→「執行」），這時才真正的到達 FIRST.EXE 的進入點，如下圖。如果每次載入程式除錯，都要重新做一次就很麻煩。可以在主選單上選擇「選項」→「偏好設定」→「事件」頁面→僅勾選「入口中斷點」，其餘的勾選都取消，然後按「儲存」即可。
下圖中，x64dbg 已經顯示 FIRST.EXE 程式了：
我們先看看反組譯區，這個區域又分成五欄。最左邊一欄，有一個背景為藍色的「RIP」字樣，同時延伸到後面幾欄黑色、灰色反白的「游標」，這些告訴使用者現在程式即將執行這個指令，但尚未執行。RIP 其實是 CPU 裡面的特殊暫存器，稱為指令指標暫存器 ( instruction pointer )，當 CPU 要執行指令時，就到 RIP 所指的記憶體位址去讀取指令。此外 RDX、R9 這兩個暫存器之值 ( 察看暫存器區的這兩個暫存器 )，恰好與 RIP 之值都一樣，都是「13F751000」。第二欄是程式碼的位址。第三欄是機械碼。第四欄是 x86 指令。第五欄是備註。
第二欄全都是位址，均以十六進位表示。如果你照上面操作，結果位址不同，這很正常。Windows 開機載入驅動程式的多寡、開啟服務程式的多寡、當前執行程式的多寡等等，都會影響位址，如果一樣那才奇怪。好了，那麼我們該怎麼看位址「13F751000」中的記憶體內容是什麼呢？答案是在第三欄。
上圖反組譯區的第三欄是機械碼。例如位址「13F751000」中的機械碼是「48:33C9」，依照順序解讀，位址「13F751000」中的資料是「48」、位址「13F751001」中的資料是「33」、位址「13F751002」中的資料是「C9」。而下一行剛好又由位址「13F751003」開始，其內的資料是「51」。
照上面所說的，看起來第三欄似乎只是顯示記憶體內存放的資料，事實上，這些資料還有另一層更重要的意義，它還代表著機械碼 ( machine code )。大家都說電腦只認得 0 與 1，也都這麼認為，但是更進階的意義是什麼？只有學過組合語言才能稍微瞭解。剛才所提的「48:33 C9」是十六進位數值，轉換成二進位是「0100 1000:0011 0011……」等一長串的 0 與 1，這些 0 與 1 被 CPU 讀取進入其電路之中，CPU 就能根據這些零或一將電路開或關，而解析其功能為何。當然，這段電路的設計極其複雜，不論如何，CPU 能自己分析出來原來是要把 RCX 暫存器與自身做互斥或運算，於是 CPU 就能執行此指令。同理，當 CPU 讀取到機械碼 51 時，就知道要把 RCX 推入堆疊。
機械碼與組合語言的關係極其密切。在電腦剛發明時，有一段時間程式設計師真的就是把這一連串的 0 與 1 輸入電腦，可想而知這樣的做法非常容易出錯，所以聰明的人就想出用簡單幾個字母代表這些指令，例如剛剛說的以「XOR RCX,RCX」代替「48:33C9」，再加上假指令，就形成組合語言。因此，大致上可以說，組合語言的 x86 指令與機械碼有一對一的關係。
組譯器的工作就是把人類撰寫的純文字檔「轉換」成機械碼，讓 CPU 能看得懂，這樣的過程稱為「組譯」( assembly )。而像 x64dbg 這類除錯器，能夠載入執行檔，並把它變成組合語言的形式，讓人類讀得懂，這樣的過程稱為「反組譯」(disassembly )。這兩個過程是恰好相反。
第四欄是 x86 指令。這一欄看起來，跟我們所撰寫的原始碼很相像，但是似乎多了很多「修飾」的辭彙，像「qword ptr」、「[]」等等，還有把字串名稱改成了位址。
剛剛我們曾經用 x64dbg 快捷鍵，「F9」鍵操作「執行」( run ) 指令，這個 x64dbg 指令會直接執行程式，直到程式結束或遇到中斷點才會停止。
現在我們再介紹另一個 x64dbg 指令，稱為單步追蹤 ( 也翻譯成單步步入 )，快捷鍵是「F7」鍵。單步追蹤的意思是，一次只執行一道指令，然後停下來，把暫存器區、堆疊區、資料顯示區的相關資料列出來，讓程式設計師觀察，是否與預期結果一樣。
現在按一次「F7」鍵，表示執行「xor rcx,rcx」指令，執行完後畫面如下。可以與上圖比較，RCX 變成了 0，同時 RIP 也指向下一個尚未執行的指令位址，那個橫跨好幾欄黑色、灰色反白的「游標」也往下移。操作暫存器區的捲動軸，使能觀察到 RFLAGS 文字，它就是旗標暫存器，其中的 ZF＝1，就表示零值旗標被設定，這是因為 RCX 運算後為零。
如上圖，現在在反組譯區反白的是「push rcx」，表示即將執行它但尚未執行，這指令與堆疊有關。x64dbg 每執行完一指令就會把堆疊頂端顯示於堆疊區的最上面，但小木偶希望能看到堆疊區的變化，所以每次執行完指令，都會調整堆疊區的捲動軸。觀察堆疊區會發現堆疊區有兩欄，左邊的顯然是位址，右邊的是堆疊內所儲存的數值。右邊那一欄又分成上、下兩部分，上半部為灰色字，下半部為黑色字。黑色的部分是已存有資料的堆疊 ( 雖然都是零 )，灰色的是未存有資料。
按一次「F7」鍵，執行「push rcx」，RSP 減八變成 2DFB10，然後把 RCX 之值，也就是零，存入位址 2DFB10 的記憶體中；同時堆疊區頂反白部分也往低位址移八個位元組，如下圖；且 RIP 指向下一個指令，反組譯區反白的部分也往下移。
接著的指令是「mov rdx,OFFSET szText」，我們知道這是把 szText 的位址存入 RDX 裡，而 szText 在「.CONST」區段內 ( 見 FIRST.ASM 第八到十行 )。但是因為「資料顯示區」內的資料並非 FIRST.EXE 中「.CONST」區段的資料，必須變更到該處。把滑鼠移至下圖資料顯示區內的藍色區域，在其內任意處點擊滑鼠右鍵，會出現一個選單，如下圖。選擇①「前往」→②「表述式」，會出現一對話盒，輸入「13F752030」( 英文字母大小寫都一樣 )。為何輸入此數值呢？因為我們要觀察的是 szText 字串，照剛才的講法，此字串在「OFFSET szText」的位址上，經組譯後在下圖的③處就是其位址。而我們從 FIRST.ASM 的原始程式可以知道，szCaption 在 szText 前面，所以也可以調整資料顯示區的捲動軸，觀察這兩個字串。
但這樣還不夠，因為「資料顯示區」內顯示的是 ASCII 編碼 ( 上圖④處 )，必須更改。把滑鼠移至上圖資料顯示區內的藍色區域，在其內任意處點擊滑鼠右鍵，會出現一個選單，選擇⑤「十六進位」→「Big5」，就變成下圖：
從資料顯示區內，就可以看到 szText 字串在位址 13F752030 處，順便也可以看到 szCaption 字串是在位址 13F752020 處。兩字串都變成了以 Big5
編碼的中文了。( 上圖藍色框內 )
從「mov rdx,OFFSET szText」開始到「mov r9,0」三個指令都是改變 RDX、R8、R9 三個暫存器之值，沒什麼特殊之處，按三次「F7」鍵執行它們，使其分別變為 13F752030、13F752020、0，可觀察暫存器區驗證，如下圖。
按「F7」鍵執行「sub rbp,20」，如下圖，RSP 減 20H，變成 2DFAF0，堆疊區的堆疊頂也往上移。這個指令看起來很簡單，但是為什麼要把 RSP 減去 20H 呢？這一行是在堆疊中預留影子空間 ( shadow space )，保存前四個暫存器參數的，為了遵循 Win64 的呼叫慣例。那為什麼是「sub rsp,20」，讓 RSP 減 20H，使其他暫存器減 20H 可不可以呢？不要減 20H，減其他數行不行呢？
首先，必須是要使 RSP 減去某個數，不能讓其他暫存器減。原因是影子空間要保存在堆疊上，所以只有把堆疊頂往低位址移才可以。在眾多暫存器中，只有 RSP 是堆疊的指標，所以只能減去 RSP 之值。並且不能用加的，如果使用加法，RSP 會指向更高位址，會破壞掉原來保存在堆疊內的資料。
其次，依據 x64 呼叫慣例，影子空間至少要保存前四參數，不足四個也要以四個計算；如果超過四個，多出來的參數也要在堆疊上保留空間。而 MessageBoxA 恰好四個參數，這四個參數都由四個暫存器：RCX、RDX、R8、R9 傳給副程式，每個暫存器都是 64 位元，也就是 8 個位元組，乘以四，就是 32 個位元組，換算成十六進位是 20H。
最後，還要注意到，在呼叫 Windows API 前，就是即將執行「call MessageBoxA」但尚未執行時，RSP 還要對齊 16 位元組。觀察下圖，RSP 是 2DFAF0，正好對齊節位址就沒有問題。那如果沒有對齊呢？這時候就可以把 RSP 減去 28H，而不是減去 20H。( 事實上，Win64 API 中，剛一進入副程式或 Windows API 時，RSP 的最末位數，必定是 8。這是因為未執行 CALL 之前，對齊節位址，RSP 最末位為零，執行 CALL 指令時，CALL 會把返回位址推入堆疊，故 RSP 少了 8，最末位就會變成 8 )
接下來就要執行「call MessageBoxA」指令，但尚未執行。注意到，前面提過 x64 呼叫慣例，有一項「在執行 CALL 之前，RSP 所指的位址必須對齊一個節」。觀察下圖檢查一下，發現 RSP 所指的堆疊頂位址是「2DFAF0」，果真對齊 16 位元組。假如沒有對齊，呼叫 Windows API，程式會當掉。現在按一次「F7」鍵，執行「call MessageBoxA」。你會看到 CALL 把下一道指令的位址，也就是返回位址，13F751025，推入堆疊，然後轉移到 MessageBoxA 處。
如上圖，這時候即將進入 MessageBoxA 裡面了。
按下「F7」鍵，變成下圖畫面：
藍色框住的就是 MessageBoxA 的程式碼，這段程式碼很陌生，因為這不是我們撰寫的，小木偶不打算去追蹤這段程式，要直接跳過去。方法是設置「中斷點」。猜想藍色框住的最底下是「RET」指令，這是返回主程式的指令，也可以說 MessageBoxA 執行到這裡就結束了，小木偶打算在此處設置中斷點。
方法不難：①把滑鼠游標移到位址為 77751702 的「RET」指令上，以滑鼠左鍵點擊一次，整列指令會反白，代表選擇此位址。②然後按下「F2」鍵，則第二欄的位址處，變成醒目的紅色，代表此處已設為中斷點。這樣就完成了，如上圖。
按一下「F9」鍵，x64dbg 會執行 FIRST.EXE 直到遇到設置的中斷點，才會停止。但在停止之前，MessageBoxA 會產生一個視窗，要使用者按「確定」按鈕才會繼續執行，如果使用者沒按，MessageBoxA 就會一直等待。這個視窗並不會彈出來在最上層，必須到工作列去找。下圖是已經在工作列點擊 FIRST.EXE 圖示，以滑鼠對 MessageBoxA 產生視窗內的「確定」按鈕按一次。
這時 x64dbg 執行到中斷點的地方停了下來，即將執行「RET」指令，這個指令會返回到 FIRST.EXE 主程式，如下圖。
按一下「F7」鍵，執行「ret」指令。堆疊區的返回位址已取出，堆疊頂往高位址移八個位元組，反組譯區的內容變回 FIRST.EXE 的程式碼，如下圖。下一指令是「add rsp,20」，為何要有這道指令呢？這也是為了要遵循 Win64 API 的呼叫慣例，「由主程式清理堆疊」。呼叫過程中，在堆疊上會建立保存參數的空間，這些在返回主程式後都沒有用了，必須清除。MessageBoxA 只建立了 20H 的空間，所以執行「add rsp,20」即可。
按下「F7」鍵執行「add rsp,20」指令，堆疊區內的堆疊頂端往高位址移，同時 RSP 由 2DFAF0 變為 2DFB10，並沒有進位，結果也不是零，所以 CPU 清除進位旗標與零值旗標。注意到，這裡的進位必須是 RSP 的第 63 位元相加之後的進位才會設定進位旗標。
接下來即將執行「pop rcx」，但尚未執行。在反組譯區的位址 13F751003 處，把 RCX 推入堆疊位址 2DFB10 ( 以藍色表示 )，而此處則把該位址，也是現在堆疊頂端的數值，存回 RCX 裡。這樣就不必再使 RCX 變為零。此外，通常 PUSH 與 POP 成對出現，所以 x64dbg 以藍色標註，但也有少數例外的情形。
按一下「F7」鍵，執行「pop rcx」指令，由堆疊頂端彈出原先存入的資料，RCX 變為零，堆疊區的堆疊頂端往高位址移，如下圖。
接著即將要執行「sub rsp,8」，如上圖。為何要執行這道指令呢，你可以觀察 RSP 之值為 2DFB18，並沒有對齊 16 位元組，但接下來就要呼叫 ExitProcess API，此 API 僅一個參數，我們要在堆疊中保留 20H 個位元組的空間，但如果只減去 20H，會讓 RSP 沒有對齊節位址。因此我們得自行調整，方法就是讓 RSP 多減一點，即減去 28H。那麼減去 38H、48H……是否可行呢？是的，的確可以這樣做。那麼加上 8 或 18H……可以嗎？這樣就不行，因為在高位址有資料，這可能是系統保存的，如果改用加 8、18H……可能會破壞這些資料。
底下呼叫完 ExitProcess，程式就結束了。小木偶就不再囉唆了。
在呼叫 Win64 API，時要在堆疊上保留參數，即使前四個參數是以暫存器傳遞，也要保留；而且就算是所呼叫的 API 參數不足四個，也要保留四個。在堆疊上保留這些參數，可以使 RSP 減去某個數即可。
不僅如此，執行 CALL 之前，RSP 指向的堆疊位址必須是 16 位元組的整數倍，也就是位址以十六進位表示時，其最右邊那位 ( 或說最末位、個位數 ) 必須是「0」。這是 Win64 API 呼叫慣例的規則，無法違背，假設違背了，程式就當給你看。
在任何情形下，程式一開始執行時或者呼叫 Win64 API 而剛剛進入 API 時，RSP 的最右邊那位，也就是「個」位數，都是「8」。每個程式都必須遵守上面的規則，依所呼叫的 Win64 API 參數多寡，可以分成下面幾種情形：
最後整理如下表：
| 表：參數個數與 RSP 保留大小 | |||
| 參數個數 | RSP 減去多少 | 參數個數 | RSP 減去多少 |
| 4 或小於 4 | 28H | 10 | 58H |
| 5 | 28H | 11 | 58H |
| 6 | 38H | 12 | 68H |
| 7 | 38H | 13 | 68H |
| 8 | 48H | 14 | 78H |
| 9 | 48H | 15 | 78H |
減去 RSP 之值，使其能在堆疊保留參數空間，又能在執行 CALL 前對齊節位址，其實有兩種做法：①可以在進入主程式時，依據最多參數的 API 調整，這樣只需做一次即可；②也可以在每次呼叫 Win64 API 之前調整，而於每次呼叫後銷毀保留參數的空間，這種做法使得呼叫 Win64 API 幾次，就要做幾次。
在 FIRST.ASM 中採用第②種做法。只是呼叫 ExitProcess 之後，程式結束不必銷毀堆疊上的參數。這是因為控制權已交回 Windows，Windows 連 FIRST 的堆疊都會銷毀何況是保存於其內的參數。
14 15 16
17 18 19 20
21 22 23 24
25 26 |
main PROC
xor rcx,rcx
push rcx
mov rdx,OFFSET szText
lea r8,OFFSET szCaption
mov r9,MB_OK
sub rsp,20h ;──────┐
call MessageBoxA ;├─第一次於堆疊保留參數又銷毀
add rsp,20h ;──────┘
pop rcx
sub rsp,28h ;─────┐
call ExitProcess ;──┴─第二次於堆疊保留參數，但因為已結束程式，談不上銷不銷毀
main ENDP |
當然這樣的做法很麻煩，我們可以在 main 程式中，以最多參數的 Win64 API 為準，把 RSP 減去相應的數值即可，這樣只需做一次。
底下我們就來驗證這個想法。輸入底下的程式，將它存入「E:\HomePage\SOURCE\Win64\FIRST\FIRST1.ASM」裡。
1 2 3 4
5 6 7 8
9 10 11 12
13 14 15 16
17 18 19 20
21 22 23 24
25 26 27 28
29 30 31 32
33 34 35 36 |
;第一章已建好了「C:\Users\帳號\MASM64.BAT」，組譯連結方式：
;1.開啟「命令提示字元」
;2.輸入「MASM64」
;3.切換到「E:\HomePage\SOURCE\Win64\FIRST\」子目錄
;4.輸入「ML64 FIRST1.ASM」完成
OPTION CASEMAP:NONE
EXTRN MessageBoxExA:PROC
EXTRN ExitProcess:PROC
INCLUDELIB e:\masm32\lib64\kernel32.lib
INCLUDELIB e:\masm32\lib64\user32.lib
MB_OK EQU 0
LANG_ENGLISH EQU 9
SUBLANG_ENGLISH_US EQU 1
;***************************************************************************************************
.CONST
szCaption DB "第一個Win64程式",0
szText DB "這是用組合語言寫的64位元程式。",0
;***************************************************************************************************
.CODE
;---------------------------------------------------------------------------------------------------
main PROC
sub rsp,28h
xor rcx,rcx
mov rdx,OFFSET szText
lea r8,szCaption
mov r9,MB_OK
mov ax,SUBLANG_ENGLISH_US
shl ax,10
add ax,LANG_ENGLISH
mov WORD PTR [rsp+20h],ax
call MessageBoxExA
xor rcx,rcx
call ExitProcess
main ENDP
;***************************************************************************************************
END |
FIRST1.ASM 中呼叫兩個 Win64 API：①MessageBoxExA、②ExitProcess。前者只有五個參數，後者只有一個參數。所以在第 22 行有「sub rsp,28h」，保留參數於堆疊內。呼叫完畢後，也不須銷毀保存參數的堆疊，反正以後就會用得著。雖然後面的 ExitProcess 只有一個參數，但空著也不會有什麼害處。
除了上面不同之外，FIRST.EXE 與 FIRST1.EXE 還有三處不同：
首先，FIRST 執行的結果是：
，而 FIRST1 執行的結果是：
，很明顯就只有把「確定」按鈕變成了「OK」。
第二：FIRST 呼叫的是「MessageBoxA」，而 FIRST1 呼叫的是「MessageBoxExA」。FIRST1 呼叫的 MessageBoxExA 有五個參數，照前面所提到的，RSP 需要保留給參數的記憶體要有 28H 個位元組，而且能夠成功執行，驗證了上面的講法。
第三：FIRST 中，因為呼叫 MessageBoxA 的 RCX 參數跟呼叫 MessageBoxA 的 RCX 參數一樣，所以呼叫 MessageBoxA 前把 RCX 保存在堆疊裡，到呼叫 ExitProcess 時由堆疊取出。FIRST1 的做法更直接，不保存 RCX，到呼叫 ExitProcess 時，再自行計算。
FIRST1.ASM 大部分都與 FIRST.ASM 相同，只剩下 MessageBoxExA。在此要說明的是，雖然牽涉到字元或字串的 API 有 ANSI 版與寬位元版，但往後都不再說明了，也不再區分了，API 名稱結尾的「A」或「W」也不再提了。
MessageBoxEx 是 MessageBox 的延伸版本 ( 看後面的「Ex」就知道，Ex 代表 extend 的意思 )，其語法是：
invoke MessageBoxEx,\
hWnd,\ ; handle of owner window
lpText,\ ; address of text in message box
lpCaption,\ ; address of title of message box
uType,\ ; style of message box
wLanguageId ; language identifier
前四個參數與 MessageBox 差不多，可以自行查閱 MSDN。小木偶在此說明最後一個參數，wLanguageId。看它的名稱，wLanguageId，就知道「w」代表它的長度是一個字組 ( word )，而後面的「LanguageId」代表語言識別碼，設定此參數可以用不同的語言顯示按鈕上的文字。wLanguageId 是由十位元的主要語言和六位元的次要語言組成的，主要語言在 wLanguageId 的第 0∼9 位元，次要語言在 wLanguageId 的第 10∼15 位元。部分主要語言和次要語言的列表如下：
| 主要語言 | 次要語言 |
| 中文 LANG_CHINESE = 4 | 正體中文 SUBLANG_CHINESE_TRADITIONAL = 1 簡體中文 SUBLANG_CHINESE_SIMPLIFIED = 2 香港中文 SUBLANG_CHINESE_HONGKONG = 3 新加坡中文 SUBLANG_CHINESE_SINGAPORE = 4 |
| 英文 LANG_ENGLISH = 9 | 美國英文 SUBLANG_ENGLISH_US = 1 英國英文 SUBLANG_ENGLISH_UK = 2 澳洲英文 SUBLANG_ENGLISH_AUS = 3 加拿大英文 SUBLANG_ENGLISH_CAN = 4 |
往後撰寫程式時，引進包含檔，就會使用類似 LANG_CHINESE、LANG_ENGLISH 等符號，在包含檔中會用「EQU」假指令宣告 LANG_CHINESE 等於 4、LANG_ENGLISH 等於 9，這樣就能一看到符號就一目了然其意義。
先說明 SHL 指令，它的語法如下：
SHL 目的運算元,1 式(1) SHL 目的運算元,CL 式(2) SHL 目的運算元,立即值 式(3)
SHL 指令是「shift logical left」的意思，是指目的運算元內的每個位元向左移位數個位元，如果只移一個位元，就用式 (1)；如果一次要移好幾個位元，用式 (2)，把要移位的位元數事先存入 CL 裏面。8086/8088 CPU 只能用這兩種方法，較高階的 CPU 可以用式 (3)，要移位的位元數直接以立即值表示。底下舉個例子說明。
右圖是說明 AX 暫存器裏的每個位元向左移一位的情形。AX 暫存器有十六位元，最高位元是第 15 位元，最低位元是第 0 位元。原來的 AX 裡的數值是 994AH，當執行「SHL AX,1」指令時，第 15 位元會被移至旗標暫存器 ( carry flag，簡稱 CF ) 裏，然後第 14 位元移至第 15 位元，其餘依此類推……第零位元移至第一位元，而第零位元則填入 0 ( 右圖中，以粉紅色的 0 表示 )。執行完「SHL AX,1」後，AX 變成 3294H。
如果是多次左移的話，例如 AX 原為 994AH，執行「SHL AX,2」指令，那就是先執行一次左移變成 3294H，再進行一次左移變成 6528H，進位旗標變為最後一次左移的結果，所以是 NC。
SHL 和 SAL ( shift arithmetic left ) 的機械碼一模一樣的，所以是相同的指令。
SHL 有一項特性，非常好用，那就是可以當做乘以 2 的冪方。例如「SHL AX,1」相當於把 AX 乘以 2，「SHL AX,2」相當於乘以 22，「SHL AX,2」相當於乘以 23……以此類推。還是以十進位數值來比喻好了，12 向左移移位，不就變 120，相當於乘以 10；向左移兩位，就變成 1200，相當於成 102。
SHR 是邏輯右移 ( shift logical right ) 的意思，亦即把目的運算元中的每個位元，向右移數個位元。只有移位方向向右以及相當於除以 2 的冪方，這兩點與 SHL 不同，其他特性都一樣，包含最高位元會補上 0。
但是 SAR ( shift arithmetic right，算術右移 ) 卻與 SHR 不同，SAR 指令在移位的時候，最高位元保持原來的值。例如 AL 為「1000 1100」，執行「SAR AL,1」後，AL 變成「1100 0110」，且進位旗標被清除。如果 AL 為「1000 1100」，執行「SAR AL,2」後，AL 變為「1110 0011」，進位旗標被清除。
SHL、SAL、SHR、SAR 四指令執行後，會影響多個旗標，包含進位旗標、同位旗標、零值旗標、符號旗標、溢位旗標五個旗標。
FIRST1.ASM 中的第 27∼29 行是
mov ax,SUBLANG_ENGLISH_US
shl ax,10
add ax,LANG_ENGLISH
這三行是用來產生語言識別碼的，主要語言在 wLanguageId 的第 0∼9 位元，次要語言在 wLanguageId 的第 10∼15 位元。先使 AX
依據 Win64 API 的呼叫慣例，前四個參數依序存放在 RCX、RDX、R8、R9 暫存器中，傳給 Win64 API。如果超過四個參數的話，超過的部分是由堆疊傳遞給 Win64 API，但是實際上的做法是如何呢？請看右圖。右圖是假想堆疊的一部分，其位址也是假想的，但是在呼叫前，也就是即將執行 CALL 指令前，RSP 指向位址最末位為零的記憶體，也就是 WXYZ80 處。
此刻的 RSP 所指的位址，也就是堆疊頂端，其實就是 RCX 參數預定存放位址，RSP＋8H 是 RDX 預定存放位址，其他依此類推。因此第五個參數就要存放在位址是「RSP＋20H」的堆疊裡，第六個參數就要存放在位址是「RSP＋28H」的堆疊裡……其餘依此類推。
能進行運算的 x86 指令，如果需要兩個運算元，例如 ADD、SUB、XOR……等，這兩個運算元的位元數都要相同，例如不能目的運算元是十六位元，而來源運算元是八位元。但有時候，必須強迫讓已定義的變數改變資料類型，以符合另一個運算元。這時候就可以用 PTR 運算子，其用法是：
type PTR expression
type 是改變之後的資料類型，expression 則是變數名稱或是間接定址的記憶體變數。例如底下的例子：
number DQ 589abh
⁝
mov rax,112233h
mov ax,WORD PTR number
一開始定義 number 是四字組變數 ( 64 位元 )，假想程式後來需要把 number 之值移入 AX 裡。但 AX 長度為字組 ( 16 位元 )，因此用「WORD PTR」強迫 number 暫時改成字組的資料類型。這時候要把 number 之數值暫時想成是 89ABH。執行完「mov ax,WORD PTR number」後，只有 AX 之值改變，RAX 其他位元仍不變，所以 RAX 之值變為 1189ABH。
x86 指令可以針對記憶體內的資料做運算，這些指令包含 MOV、ADD、SUB、XOR……等。要對記憶體內的資料進行運算，必須先指定是哪一個位址的記憶體，指定記憶體的位址稱為定址，大致可以分為兩種：①直接定址 ( direct addressing ) 與②間接定址 ( indirect addressing )。
先介紹直接定址。其實說穿了，直接定址其實就是存取變數而已，例如底下的例子：
number DQ 589abh
⁝
mov rax,number
其中的「mov rax,number」就是利用直接定址的方式，把 number 所在位址的記憶體內容，移到 RAX 裡。在前面早已介紹過這種方法，這裡當然不會畫蛇添足，這裡要介紹在 x64dbg 的表示方式。我們知道，ML64.EXE 會計算 number 變數的位址，當要存取此變數時，「直接」依據此位址去存取即可。假設 number 的位址是「13F753010」，在 x64dbg 的反組譯區顯示此指令時，如果以
mov rax,13F753010
表示，那就會讓人誤會是把常數 13F753010 移入 RAX 內，所以 RAX 內的數值變為「13F753010」。這當然是錯誤的，因此 x64dbg 會以一對中括號「[]」將位址括住來表示，像下面的樣子：
mov rax,[13F753010]
因此我們要這樣想，當以中括號括住數值時，此數值是表示位址，而整個式子 ( 就是「[位址]」) 代表此位址內的數值。舉上面的例子，「[13F753010]」代表記憶體位址 13F753010 處的內容，查閱此位址的記憶體，發現其內容為「589AB」，把它移入 RAX 裡面，所以執行完這道指令後，RAX 內的數值就是「589AB」，見右圖。事實上，在撰寫組合語言原始程式時，把
number DQ 589abh
⁝
mov rax,number
寫成
number DQ 589abh
⁝
mov rax,[number]
也是可以的，兩者意義相同。
接下來說明間接定址。剛剛介紹的直接定址中，中括號內的位址不會因為某些狀況改變，是固定的；而間接定址則是牽涉到以暫存器甚至再加上其他數值代替中括號內的位址。這樣的存取方式，CPU 在存取時就必須先查閱暫存器內容，再依此內容決定位址，然後才依據此位址存取。因為多了向暫存器查閱的步驟，所以稱為「間接」。
間接定址又分成許多類：⑴只有暫存器、⑵暫存器加偏移位址、⑶二的冪次方乘以暫存器、⑷二的冪次方再乘以暫存器加偏移位址、⑸兩個暫存器加偏移位址，再加上另一個暫存器，再加上偏移位址。在這裡小木偶只介紹前兩類。要注意的是，在 Win64 中偏移位址預設值是以 32 位元的數值表示，最多不能超過 0FFFFFFFFH，如果超過要在連結時下達「/LARGEADDRESSAWARE:NO」選項。
⑴、第一種是間接定址最簡單的情形，僅僅以一個暫存器代替中括號內的位址，如下面的程式：
mov r9,13F753010H mov rax,[r9]
其中「mov rax,[r9]」就是利用第一種間接定址。CPU 會先察看 R9 之值為何，發現是「13F753010」，就到此位址去，把存放在這個位址的內容移入 RAX 裡面。或者也可以這樣想，把 R9 看成是一個指標，所指向的記憶體位址是「13F753010」，於是把此記憶體內容移入 RAX 內。如右圖所示。
可能會有人覺得間接定址多了一個步驟，豈不麻煩？這當然有好處，如果改變暫存器的數值，所指向的位址就不同，而存取的記憶體內容就會不同。往後如果處理大量資料時，就有可能會這樣使用，例如在第九章中以九十幾個位址組成的陣列，要存取此陣列中的元素就可用這種方法。
⑵、第二種情形的形式在一對中括號內含有一個暫存器，並且加或減一個常數，例如下面程式的第二、三行：
mov r9,13F753010H
mov rax,[r9-8]
mov rcx,[r9+8]
當 CPU 要讀取「[r9+8]」記憶體內的資料時，必須先取出 R9 暫存器之數值，再加上 8，才能得到真正要讀取的位址，再到此位址上讀取數值。例如右圖中，執行完這三道指令後，RAX 為 928H，RCX 為 5F。
第三、四種請參閱第十五章。