I'm currently trying to finish an assignment for one of my classes that requires a sequence of ten Hexadecimal numbers for it not to blow up. The task is to find these numbers and input them in the correct order to diffuse the so called "bomb". We are given the y86 source code (which coincidentally also contains x86 assembly code).

My question is, are there any general tips for either finding these numbers in the memory or converting parts of the code to C code by just looking at the x86 code? I understand what each individual call is doing I'm just not sure where to start when it involves over 500 lines of assembly code.

I understand it might be difficult to give such general advice, but any help is appreciated. Thanks!

  • If you have the source code you should be able to assemble it and then use a debugger to step through the binary
    – julian
    May 4 '18 at 1:09

there is a web based emulator / simulator for y86 code /js-y86/

you can step through in this

enter image description here

  • So I tried this out and it turns out some of the hex digits in my source code arent accepted by this emulator... I guess I'll going to have to resort to just looking at the code itself.
    – T. Pruden
    May 4 '18 at 22:39

The numbers could be either stored in memory or they could be arithmetically calculated. The former case could occur when they are defined as global constants or when the code generates these values and writes them to memory some time during execution before doing the comparison with the input sequence. In addition, even though a single hexadecimal digit (I assume that by "number" you mean a single digit rather than some unlimited number of digits) requires only 4 bits to represent, there are really many different ways to represent the 10 hex digits. So a 4-byte register might be used to hold a single digit or multiple digits. As you can see, there are many possibilities. So directly looking for the numbers is not the fastest way to figure them out and you're likely to get blown up.

However, the code must contain a sequence of instructions that basically somehow compare the input sequence with the actual numbers. Basically ten (or less) comparisons need to be performed. It's likely that on the first inequality, a jump will be performed to the code that "blows up the bomb". Therefore, I think that you should start by examining all the jne instructions (same in x86). Examine the code around, see if there is a loop structure or some kind of repetitive comparisons. It's also a good idea to look for mrmovl around jne in a loop, indicating that the numbers are being fetched from memory. If that lead you nowhere, then you can examine the code around je or jmp, which could also be used together to construct loops. Note that if you found a suspicious loop, but without mrmovl, then the numbers might be arithmetically calculated in the loop.

This way, even if you were given 10s of thousands of assembly code, there will still be relatively very few jne or je instructions. Examining each of them should take few minutes only.

Now once you find a piece of code that seems to be comparing ten numbers against other 10 numbers, you can trace that back to the entry point of the program to make sure that it is the input sequence that is being compared against and that it is not some bogus piece of code or something else. This process can be made easier by building the control flow graph of the program using some tool. But your code is small enough so you can do it manually I guess.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.