From this, there are three things that are interesting.
1. The first IF statement, which will determine whether or not decoding happens.
2. The _debugbreak(), which may either help (writer stopping there to get us to look at something) or hinder (simply be annoying)
3. The key print statement at the bottom.
First, I tried running it, with a break point immediately following the if statement (jnz in assembly). This neither hit the breakpoint, nor did it print a key. Therefore, I speculated that we needed to alter the value of the if statement, to invert when it triggered (from if(!statement) to if(statement)). Also, I removed the debug breakpoint, mainly for convenience. The original assembly:
2. The _debugbreak(), which may either help (writer stopping there to get us to look at something) or hinder (simply be annoying)
3. The key print statement at the bottom.
First, I tried running it, with a break point immediately following the if statement (jnz in assembly). This neither hit the breakpoint, nor did it print a key. Therefore, I speculated that we needed to alter the value of the if statement, to invert when it triggered (from if(!statement) to if(statement)). Also, I removed the debug breakpoint, mainly for convenience. The original assembly:
The modified code:
However, when this was ran, there seemed to be no valid output, as the message box appeared empty. After some fiddling around, and help from teammates and coaches, it was found that the key was actually being printed in the message box. Since it started with a string terminator however, it appeared to be empty. Reading it from memory in debugging allowed for the acquisition of the key.
flag{number2isalittlebitharder:p}
- albinotomato
No comments:
Post a Comment