Some Assembly Required 3

Problem

http://mercury.picoctf.net:60154/index.html

Solution

1. The new WebAssembly base64 string is as follows: AGFzbQEAAAABEwRgAABgAn9/AX9gAAF/YAJ/fwADBQQAAQIDBAUBcAEBAQUDAQACBjcJfwFBsIoEC38AQbAIC38AQasIC38AQYAIC38AQbAKC38AQYAIC38AQbCKBAt/AEEAC38AQQELB6cBDQZtZW1vcnkCABFfX3dhc21fY2FsbF9jdG9ycwAABnN0cmNtcAABCmNoZWNrX2ZsYWcAAgVpbnB1dAMBCWNvcHlfY2hhcgADA2tleQMCDF9fZHNvX2hhbmRsZQMDCl9fZGF0YV9lbmQDBA1fX2dsb2JhbF9iYXNlAwULX19oZWFwX2Jhc2UDBg1fX21lbW9yeV9iYXNlAwcMX190YWJsZV9iYXNlAwgK2QQEAgAL5wIBKn8jgICAgAAhAkEgIQMgAiADayEEIAQgADYCGCAEIAE2AhQgBCgCGCEFIAQgBTYCECAEKAIUIQYgBCAGNgIMAkADQCAEKAIQIQdBASEIIAcgCGohCSAEIAk2AhAgBy0AACEKIAQgCjoACyAEKAIMIQtBASEMIAsgDGohDSAEIA02AgwgCy0AACEOIAQgDjoACiAELQALIQ9B/wEhECAPIBBxIRECQCARDQAgBC0ACyESQf8BIRMgEiATcSEUIAQtAAohFUH/ASEWIBUgFnEhFyAUIBdrIRggBCAYNgIcDAILIAQtAAshGUH/ASEaIBkgGnEhGyAELQAKIRxB/wEhHSAcIB1xIR4gGyEfIB4hICAfICBGISFBASEiICEgInEhIyAjDQALIAQtAAshJEH/ASElICQgJXEhJiAELQAKISdB/wEhKCAnIChxISkgJiApayEqIAQgKjYCHAsgBCgCHCErICsPC0wBC39BACEAQbCIgIAAIQFBgIiAgAAhAiACIAEQgYCAgAAhAyADIQQgACEFIAQgBUchBkF/IQcgBiAHcyEIQQEhCSAIIAlxIQogCg8LnQEBEX8jgICAgAAhAkEQIQMgAiADayEEIAQgADYCDCAEIAE2AgggBCgCDCEFAkAgBUUNAEEEIQYgBCgCCCEHQQUhCCAHIAhvIQkgBiAJayEKIAotAKuIgIAAIQtBGCEMIAsgDHQhDSANIAx1IQ4gBCgCDCEPIA8gDnMhECAEIBA2AgwLIAQoAgwhESAEKAIIIRIgEiAROgCwiICAAA8LCz0CAEGACAsrnW6TyLK5QYufkIxixcOViDTIk5KIP8GSx9s/yJ7HiTHGxcmLNsbGwJAAAABBqwgLBfGn8Aft

2. Let's decompile it by first converting it to wasm using write_wasm.py in ../Some Assembly Required 2 and then using wasm-decompile. The decompiled c-like code is in wasm-decompile-output.c.

3. We can decompile the compiled wasm to actual c code using wasm2c, which is also included in WebAssembly/wabt. wasm2c (Documentation) creates harder to read long c code that will actually run while wasm-decompile (Documentation) creates easier to read c-style pseudocode.

4. We can use git diff or diffchecker.com to compare the new wasm with the wasm from the previous challenge. We see the addition of a new variable, called key, and some changes at the end of the copy_char.

5. The encrypted flag is: 0x9d, 0x6e, 0x93, 0xc8, 0xb2, 0xb9, 0x41, 0x8b, 0x9f, 0x90, 0x8c, 0x62, 0xc5, 0xc3, 0x95, 0x88, 0x34, 0xc8, 0x93, 0x92, 0x88, 0x3f, 0xc1, 0x92, 0xc7, 0xdb, 0x3f, 0xc8, 0x9e, 0xc7, 0x89, 0x31, 0xc6, 0xc5, 0xc9, 0x8b, 0x36, 0xc6, 0xc6, 0xc0, 0x90, 0x00, 0x00. This value is from the wasm2c output file because it shows a clear array of hex bytes while the wasm-decompile output file shows a slight mess.

6. The key is: 0xf1, 0xa7, 0xf0, 0x07, 0xed.

7. If we analyze the c and c-like code, we will discover that the flag is xored with the reverse of the key. I'm not sure why the key needs to be reversed, but it could have something to do with big endian and little endian since wasm is close to machine code.

8. An alternative way to find the key is as follows: We know from step 6 that the key is 5 bytes. We also know that the flag starts with picoCTF{. Thus, we can xor the start of the flag (picoC) with the encrypted flag 0x9d, 0x6e, 0x93, 0xc8, 0xb2 to find that they key is: 0xed 0x07 0xf0 0xa7 0xf1 (CyberChef Recipe). This is the reverse of the key found in the code in step 6.

9. Now that we have the key and encrypted flag, we can simply decode the encrypted flag as hex and then xor the encrypted flag and key to decrypt the flag (CyberChef Recipe).

Flag

picoCTF{8aae5dde384ce815668896d66b8f16a1}