2

I am running on 64-bit Windows 7 and am using radare2 to attempt both static and dynamic analysis of a binary executable. The issue is that I cannot seem to find the entry point of where the program proper begins. I am still very new to radare2 and reverse engineering in general, so all of the techniques I currently know of have failed to determine this.

My questions are:

  1. How can I find the entry point of this binary? (and, in general, any binary)
  2. Why is there no apparent main symbol?
  3. Why do the checks in afll fail? (see below)

I have documented my attempts (in chronological order), below:


I use radare2 to open the binary in debug mode (via -d), like so:

$ radare2 -d bin.exe
Spawned new process with pid 6204, tid = 6408
r_sys_pid_to_path: Cannot get module filename.= attach 6204 6408
bin.baddr 0x00400000
Using 0x400000
Spawned new process with pid 5764, tid = 1936
r_sys_pid_to_path: Cannot get module filename.asm.bits 32

Radare2 enters at address 0x772201c4 and I then run aaa:

[0x772201c4]> aaa
←[32m[x]←[0m Analyze all flags starting with sym. and entry0 (aa)
TODO: esil-vm not initialized
←[32m[x]←[0m Analyze len bytes of instructions for references (aar)
←[32m[x]←[0m Analyze function calls (aac)
←[32m[x]←[0m Use -AA or aaaa to perform additional experimental analysis.
←[32m[x]←[0m Constructing a function name for fcn.* and sym.func.* functions (aan)
= attach 6204 6408
6204

All of the checks appear to fail, so I attempt to display the address of the entry point, via iM, to no avail:

[0x772201c4]> iM

[0x772201c4]>

There is also no listing for sym.main with afll either:

[0x772201c4]> afll
address     size  nbbs edges    cc cost   min bound range max bound   calls locals args xref frame name
=========== ==== ===== ===== ===== ==== =========== ===== =========== ===== ====== ==== ==== ===== ====
0x772201c4   41     1     0     1    4 0x772201c4    13 0x772201d1     2    2      0    0    24 fcn.eip
0x7723df5c   69     1     0     1   29 0x7723df5c    69 0x7723dfa1     0    5      0    1    28 fcn.7723df5c
0x7723dfa1   20     1     0     1   14 0x7723dfa1    20 0x7723dfb5     0    1      0    1     0 fcn.7723dfa1
0x7724989f   69     4     5     3   23 0x7724989f    18 0x772a034a     0    0      1    1     4 fcn.7724989f
0x772498ba   28     1     0     1   22 0x772498ba    28 0x772498d6     2    1      2    1    24 loc.772498ba
0x772498db   54     2     1     0   24 0x772498db    54 0x77249911     4    1      2    1    16 fcn.772498db
0x77266fa6   66     4     5     3   48 0x77266fa6    66 0x77266fe8     5    1      1    1    48 fcn.77266fa6

Very confused, I try pdf, and get only three lines of assembly mnemonics:

[0x772201c4]> pdf
            ;-- eip:
/ (fcn) fcn.eip 41
|   fcn.eip ();
|           ; var int local_4h @ esp+0x4
|           ; var int local_8h @ esp+0x8
|           0x772201c4      89442404       mov dword [local_4h], eax
|           0x772201c8      895c2408       mov dword [local_8h], ebx
\       ,=< 0x772201cc      e9e9960200     jmp loc.772498ba

Edit 1: Following Megabeet's advice, this is my output:

$ radare2 bin.exe
[0x00404161]> ie
[Entrypoints]
vaddr=0x00404161 paddr=0x00004161 baddr=0x00400000 laddr=0x00000000 haddr=0x00000118 type=program

1 entrypoints

[0x00404161]> ood
Spawned new process with pid 4776, tid = 4528
r_sys_pid_to_path: Cannot get module filename.File dbg://bin.exe  reopened in read-write mode
= attach 4776 4528
Spawned new process with pid 5720, tid = 4780
r_sys_pid_to_path: Cannot get module filename.Unable to find filedescriptor 3
Unable to find filedescriptor 3
4776
[0x772201c4]>
  • I don't know radare2, but it could be that one of those functions is main but you just don't have symbol names available? With MSVC tools you can find the entry point with dumpbin /headers, although that's actually some code supplied by the C runtime that initialises state and then calls main, not main itself. – Rup Feb 8 '18 at 5:59
3

How can I find the entry point of this binary?

There's a special radare2 command for this, ie:

$ r2 /program_name
 -- Change the registers of the child process in this way: 'dr eax=0x333'
[0x00400530]> ie
[Entrypoints]
vaddr=0x00400530 paddr=0x00000530 baddr=0x00400000 laddr=0x00000000 haddr=0x00000018 type=program

1 entrypoints

The command iM will show you the Main() function if it was detected by radare2. Notice that Main() =! Entrypoint.

Why is there no apparent main symbol?

There might be several reasons why radare2 failed to detect main. With strip binaries it is harder for the RE framework to detect it since it lacks the symbols. You can start from the entrypoint and go with the flow of the program until' you reach main.

Why do the checks in afll fail?

Well, since radare2 failed to detect the main function, it wasn't able to rename the function to main. Probably, the main function was detected by radare2 as a regular function and it should be in the table you attached.


On a personal note, make sure to use the latest version of radare2 from git. The project is actively developed and improvements are added every day. Including better detections for symbol like main().

  • Thanks for the info, I didn't know about ie before, but when I attempt it on this binary it claims there are 0 entrypoints - how is that even possible? – jmcph4 Feb 8 '18 at 7:13
  • What is the output of r2 -v? Also, you get 0 entrypoints even with rabin2 -e program_name? – Megabeets Feb 8 '18 at 7:21
  • Output of r2 -v is radare2 2.2.0 1 @ windows-x86-32 git.2.2.0 commit: db3d717c39b8ab6b317d229d2a8539dff11918f2 build: Sun 12/24/2017__18:05:13.43 and rabin2 -e bin.exe yields 1 entrypoint for some reason: vaddr=0x00404161 paddr=0x00004161 baddr=0x00400000 laddr=0x00000000 haddr=0x00000118 type=program. – jmcph4 Feb 8 '18 at 9:24
  • So here's your entrypoint. Try open the program with r2 not in debug mode (r2 program). Then, ie should show you this entrypoint. You can also check for the flag "entry0" which flags the entrypoint (f~entry). To open in debug mode from within radare2 shell you can use ood`. Moreover, in debug mode, radare2 automatically stops at the entrypoint of the program. – Megabeets Feb 8 '18 at 9:29
  • Due to limitations of comment formatting, I have edited my original question with the new output. At this point, I suspect it is some deeply-rooted compatability issue with either radare2, MinGW, or something else entirely. – jmcph4 Feb 8 '18 at 10:09

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.