I am debugging Challenge 6 from the 2014 FlareOn challenges. For incorrect imput it displays the "bad" message. Running /i bad returns 0x004f3bf2 hit0_0 "bad". ps @ 0x004f3bf2 returns bad as expected. My problem is that if I try to find reference to this memory address, axt @ 0x004f3bf2, radare2 does not return anything, but the address is surely referenced:

pd 1 @ 0x43710c
0x0043710c      bff23b4f00     movl $0x4f3bf2, %edi        ; "bad" @ 0x4f3bf2

I have written a simple application containig const char* bad="bad"; printf("%s\n", bad);. In this case using the steps from above radare2 correctly identifies the line calling printf.

1 Answer 1


This is because radare2 doesn't come with analysis by default, moreover, it doesn't have (yet?) great analysis capabilities. The reason why (beside the lack of time/interest/contributors of course) is explained in the previous link.

Also, please note that the string isn't referenced: during the disassembly, radare2 will detect strings and tell you about them, but this doesn't mean that it will add them to its internal database.

  • I have read the article and I need further reading to understand the different configuration variables. Currently I have e file.analyze=true in my .radare2rc file. What I do not understand, why I get no result for axt @ 0x004f3bf2 in the challenge (www.flare-on.com/files/C6.zip), while doing the same steps in a simple helloworld applocation I get back the instruction which prepares the printf, with other words uses the address where the string is.
    – robert
    Jan 21, 2016 at 8:02
  • Because radare2 analysis is not super-great.
    – jvoisin
    Jan 21, 2016 at 18:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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