這是一道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入門題來做，學習了一波靜態分析和動態分析。

總結

以上是生活随笔為你收集整理的【Re】36C3CTF xmas_future的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。