3

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.

Improve this question
4
  • 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, 2018 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, 2018 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, 2018 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, 2018 at 6:53

1 Answer 1

Reset to default
3

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 and acknowledge that you have read and understand our privacy policy and code of conduct.

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