這是一道wasm的逆向題。
先分析給的js文件
存在一個check函數裏面調用了wasm.check，傳入了兩個參數一個是flag，一個是flag的len。接下來就要對wasm進行分析。
先使用開源項目wabt將hxp.wasm文件反編譯成C文件hxp.c
項目地址:wabt
但是這c語言還是比較難理解，用gcc將其其編譯成x86架構下的目標文件。
gcc -c hxp.c -o hxp.o
先丟到ida中靜態分析。發現了check函數。
裏面還有一個hxp2019_check函數跟進去。這個返回值v6不是0就是1剛好和js裏的返回值對應了，這應該就是check_flag的函數，查看哪裏對v6進行了修改。
這邊有個比較，將v8和內存中某處的值進行比較。v8應該是用戶輸入的flag，那麼內存中的值是什麼，在查看程序中的字符串時有所發現。
查看引用。
發現了和上面內存地址很相近的地方，這塊地方存儲的是“hxp{}e_seem/agibtrn/ewmsu_rdrxtr_wbe_hkm.oaeyirncm”但是這明顯也不是flag，但是看上去已經很接近了，應該是經過了什麼變換，感覺應該很簡單了，但是分析半天沒分析出來咋變的（我太菜了）。回到hxp2019_check函數，上面真的看不太懂，只能碎片化分析。
這裏是對輸入flag長度check。
這裏是對flag前4個字符進行check。
這個猜測是計算偏移的，但是嘗試的時候怎麼試都不太對，無奈進行動態分析。
開個apache，把文件目錄放到/srv/http下（arch系統），然後修改httpd目錄。用firefox動態調試。
跟到check函數
這是check長度的。
這是check前4個字符的。
這裏發現那串字符串變換的代碼，分析了下運算iter先和1337相乘再和內存中某值進行異或，等下不就是這個嗎。
然後查了下運算優先級，發現乘法運算優先級比異或高，我？？？爲什麼會有這種錯覺，算了就當學了波動態調試吧，唉。
把內存數據提取一下，一行就解決了。
這題可以作爲一個wasm入門題來做，學習了一波靜態分析和動態分析。
