I'm trying to solve a reverse engineering challenge (http://crackmes.cf/users/beatrix/beaba/) and am having trouble with the obfuscation. Below is a piece of code that gets executed almost immediately after having reached the entry point. After having reached the call instruction, it seems that the call is calling the second byte of the second instruction listed below.

0000000000403789 | E8 01 00 00 00           | call beaba.40378F
000000000040378E | 04 E8                    | add al,E8
0000000000403790 | 01 00                    | add dword ptr ds:[rax],eax 
0000000000403792 | 00 00                    | add byte ptr ds:[rax],al
0000000000403794 | D0 83 44 24 08 12        | rol byte ptr ds:[rbx+12082444],1
000000000040379A | 83 04 24 0A              | add dword ptr ss:[rsp],A

After decoding the bytes starting from the second byte of the second instruction, it translated to this:

e8 01 00 00 00          call   0x6
d0 83 44 24 08 12       rol    BYTE PTR [rbx+0x12082444],1
83 04 24 0a             add    DWORD PTR [rsp],0xa
c3                      ret

This seems to be a local call I thought, I wasn't sure, which calls the function starting from the sixth byte after the call instruction (again, I'm not sure), which would mean that it calls the instructions starting from the byte with value 0x12. This translated to:

00 00                   add    BYTE PTR [rax],al
00 f4                   add    ah,dh
83 44 24 08 12          add    DWORD PTR [rsp+0x8],0x12
83 04 24 0a             add    DWORD PTR [rsp],0xa
c3                      ret

However, this is not so practical to do if this were to go on for 100 times.

Now my question is: is this the correct way to analyze a program, or are there better/more efficient methods? I'm using x64dbg to analyze it and after the program starts calling overlapping instructions and then pauses at a certain instruction, maybe because that's the first instruction that does not overlap and it breaks.

  • 1
    x64dbg uses x64dbg as its disassembly backend. You can check out the project and maybe use python to script such a solution which will recursively parse call to detect code sections. – sudhackar Jan 22 '18 at 10:32
  • Actually x64dbg uses ZyDis as the disassembly backend now. See x64dbg.com/blog/2017/10/18/goodbye-capstone-hello-zydis.html – mrexodia Jan 23 '18 at 0:28
  • If you plan to implement your own analysis this blogpost might be helpful: x64dbg.com/blog/2016/07/27/Control-flow-graph.html – mrexodia Jan 23 '18 at 0:29
  • are you sure execution reaches this call i see an exception being generated prior to this call so you may need to look into the handler you may need to read about pdata , unwindinfo ,exception handling in x64 if you are using windbg .fnent will be your friend – blabb Jan 24 '18 at 6:53

Advanced disassemblers solve this problem by performing a recursive traversal of the binary, i.e., they also look at possible jump/branch targets and disassemble from that location - even if the original linear scan indicated that the branch target was inside an instruction.

OllyDbg as well as IDA Pro support recursive traversal. However, OllyDbg support for x64 seems to be still in development and x64 support is not included in the free (as beer) version of IDA Pro.

See this article for more details.

| improve this answer | |

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.