Some Assembly Required 3
Last updated
Was this helpful?
Last updated
Was this helpful?
The new WebAssembly base64 string is as follows: AGFzbQEAAAABEwRgAABgAn9/AX9gAAF/YAJ/fwADBQQAAQIDBAUBcAEBAQUDAQACBjcJfwFBsIoEC38AQbAIC38AQasIC38AQYAIC38AQbAKC38AQYAIC38AQbCKBAt/AEEAC38AQQELB6cBDQZtZW1vcnkCABFfX3dhc21fY2FsbF9jdG9ycwAABnN0cmNtcAABCmNoZWNrX2ZsYWcAAgVpbnB1dAMBCWNvcHlfY2hhcgADA2tleQMCDF9fZHNvX2hhbmRsZQMDCl9fZGF0YV9lbmQDBA1fX2dsb2JhbF9iYXNlAwULX19oZWFwX2Jhc2UDBg1fX21lbW9yeV9iYXNlAwcMX190YWJsZV9iYXNlAwgK2QQEAgAL5wIBKn8jgICAgAAhAkEgIQMgAiADayEEIAQgADYCGCAEIAE2AhQgBCgCGCEFIAQgBTYCECAEKAIUIQYgBCAGNgIMAkADQCAEKAIQIQdBASEIIAcgCGohCSAEIAk2AhAgBy0AACEKIAQgCjoACyAEKAIMIQtBASEMIAsgDGohDSAEIA02AgwgCy0AACEOIAQgDjoACiAELQALIQ9B/wEhECAPIBBxIRECQCARDQAgBC0ACyESQf8BIRMgEiATcSEUIAQtAAohFUH/ASEWIBUgFnEhFyAUIBdrIRggBCAYNgIcDAILIAQtAAshGUH/ASEaIBkgGnEhGyAELQAKIRxB/wEhHSAcIB1xIR4gGyEfIB4hICAfICBGISFBASEiICEgInEhIyAjDQALIAQtAAshJEH/ASElICQgJXEhJiAELQAKISdB/wEhKCAnIChxISkgJiApayEqIAQgKjYCHAsgBCgCHCErICsPC0wBC39BACEAQbCIgIAAIQFBgIiAgAAhAiACIAEQgYCAgAAhAyADIQQgACEFIAQgBUchBkF/IQcgBiAHcyEIQQEhCSAIIAlxIQogCg8LnQEBEX8jgICAgAAhAkEQIQMgAiADayEEIAQgADYCDCAEIAE2AgggBCgCDCEFAkAgBUUNAEEEIQYgBCgCCCEHQQUhCCAHIAhvIQkgBiAJayEKIAotAKuIgIAAIQtBGCEMIAsgDHQhDSANIAx1IQ4gBCgCDCEPIA8gDnMhECAEIBA2AgwLIAQoAgwhESAEKAIIIRIgEiAROgCwiICAAA8LCz0CAEGACAsrnW6TyLK5QYufkIxixcOViDTIk5KIP8GSx9s/yJ7HiTHGxcmLNsbGwJAAAABBqwgLBfGn8Aft
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 .
We can decompile the to actual c code using wasm2c, which is also included in . wasm2c () creates harder to read long c code that will actually run while wasm-decompile () creates easier to read c-style pseudocode.
We can use git diff or 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.
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 because it shows a clear array of hex bytes while the shows a slight mess.
The key is: 0xf1, 0xa7, 0xf0, 0x07, 0xed.
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.
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 (). This is the reverse of the key found in the code in step 6.
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 ().
picoCTF{8aae5dde384ce815668896d66b8f16a1}