沒見過debug還這麼麻煩的。。。。
龍雲堯個人博客，轉載請註明出處。
CSDN地址：http://blog.csdn.net/michael753951/article/details/70307683
個人blog地址：http://yaoyl.cn/rfidshi-yan-er-zong-jie-2/
在實驗過程中，需要不斷翻閱實驗課PPT之《03 電子錢包的安全管理》，《實驗3文檔》，CSDN大佬呂浪的課程總代碼，以及他的博文Java card開發系列文章。
然後再自己不斷重寫代碼，理解整個實現過程，才能對這個課程實驗有較爲深入的瞭解。
代碼在未徵得本人同意之前，請勿直接Ctrl+C，Ctrl+V，謝謝。
正式實驗
實驗分析
首先我們要知道本次實驗中需要修改哪些函數，實現那哪些功能。
首先我們在PPT中知道本次實驗的主要目的是：
- 過程密鑰的生成
- 消息驗證碼MAC或交易驗證碼TAC的生成
再看詳細內容，我們大概可以捋清如下關係：
- 過程密鑰的生成
- 輸入數據包括“僞隨機數+電子錢包聯機交易序列號+8000”
- 子密鑰指的是圈存或消費密鑰
- 祕鑰8字節長密鑰
- 祕鑰生成過程由3次完成
- 子祕鑰左半部分加密
- 子祕鑰有半部分解密
- 子祕鑰左半部分加密
- MAC_TAC的生成
- 數組初始化爲0
- 數據末尾填充0x80
- 數組補0x00直到數組長度爲8的倍數
- 數組分割成數據塊
- 按照PPT**《03 電子錢包的安全管理》P13**的過程，生成MAC或者TAC
在有了大概思路以後，我們開始閱讀源代碼。經過簡單尋找，我們發現本次實驗涉及的代碼大多集中在PenCipher.java中。
基本的構造函數和對稱加密des的運算函數，這部分函數在ppt上都有解釋，推薦把ppt代碼複製上來方便閱讀和理解。
這幾個函數就是我們本此實驗需要填寫的函數了。第一個gen_SESPK是過程祕鑰生成函數，後面3個都是MAC或者TAC生成中需要使用的函數。
開始打碼
前面的分析中，我們已經對本次實驗有了大致的瞭解，接下來就是開始打碼的過程了。
過程祕鑰的產生
我們在PPT《03 電子錢包的安全管理》中已經知道了過程祕鑰分爲3步，分別是子祕鑰左半部分加密，子祕鑰右半部分解密，子祕鑰左半部分解密。在仔細查看gen_SESPK函數傳入參數的各種意義，以及cdes函數的參數意義以後，我們就可以調用cdes實現3步產生祕鑰了。
MAC或者TAC的產生
接下來是異或操作函數，根據TA的提示，一個簡單for循環搞定。
根據提示，pbocpadding也可以很簡單的實現。這個地方本來想寫一個new新開空間的，因爲數組在填充的時候可能會爆空間。但是在完成代碼以後，發現結果總是不正確，最終發現有可能是因爲在函數棧中聲明的空間，在return之後，棧裏的空間也被回收掉了，導致data實際上沒有完成新開空間的操作。所以無奈註釋掉，然後之後在debug的時候，故意給data開闢很大的空間以免爆空間。
填充完成以後，就可以按照PPT《03 電子錢包的安全管理》P13的過程，生成MAC或者TAC了。這個部分要注意的是最後寫回mac的時候，只用取前4位就行，因爲mac的響應報文中，只有4個byte，而加密完生成的數組有8bytes，不控制長度就會爆掉。
到這裏，整個實驗二就結束了。在填寫完代碼之後整個思緒都變得異常清晰，嚴格按照PPT中的流程，我們就能夠填寫完本次實驗的代碼，整體並不難。通過實驗其實可以發現，網上流傳的實驗課完整代碼並不十分簡潔，不少地方有冗餘。（事後諸葛亮2333）
驗證實驗
本次實驗需要使用Dex.exe進行驗算結果。
因爲實驗中不能直接使用printf進行debug，所以我們只能手動利用ISOException.throwIt進行debug，或者利用rfid卡的寫會操作，將結果直接作爲寫回，在控制檯上打印出來。
因此，我們就需要修改Purse的process了。
使用某一個ins，控制將mac生成，並且寫回。需要注意的是，我們不能一開始就直接寫回加密生成的mac值，如果直接執行就會寫回0x6D00（INS value not supported）。
這個地方坑了我很久。所以我們需要在process中使用條件控制，讓我們能夠先執行上次實驗中，創建purse等操作，才能進行本次實驗的加密生成mac地址並且寫回操作。
因此我們首先執行purse_script（我的實驗一的腳本文件），文件生成完成以後，我執行/send 80620000073fffffffffffff隨便進行測試一下。算法生成的結果如下圖所示，爲0x795DB66C。注，其中9000是正確執行返回的結果。
祕鑰爲自定的0x1212121212121212，data爲自定的0x2222222222222222（測試data只有8個0x22,之所以在代碼中有16個22，是因爲後面8個0x22純粹用來湊數，以開闢一個足夠大的數組以免爆炸。）初始向量在gmac4中已經定義爲0x1111111111111111。
將這些參數在Dex.exe中計算（數據需要手動添加80和其他00），計算結果爲0x795DB66C0F3467BB。我們知道在取mac地址的時候，我們爲了防爆（溢出），將結果的前4個byte取出放進mac，所以前四位爲0x795DB66C，和我們的代碼一致。
故而我們認爲，本次實驗成功。