-3
0000000000000a24 <isValid>:
 a24:   83 fe 0c                cmp    $0xc,%esi
 a27:   74 06                   je     a2f <isValid+0xb>
 a29:   b8 00 00 00 00          mov    $0x0,%eax
 a2e:   c3                      retq
 a2f:   80 7f 0b 48             cmpb   $0x48,0xb(%rdi)
 a33:   74 06                   je     a3b <isValid+0x17>
 a35:   b8 00 00 00 00          mov    $0x0,%eax
 a3a:   c3                      retq
 a3b:   b8 01 00 00 00          mov    $0x1,%eax
 a40:   c3                      retq

From what I am understanding, it is comparing a few hexadecimal numbers and assigning some numbers to some variables, but more specifically, what do these branch targets mean?

a2f <isValid+0xb>
a3b <isValid+0x17>

PS. The main goal of my assignment is to reverse engineer a C program from objdump in Assembly to find the correct key to the lock, but this is just asking about the above fragments.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
Martin Tran
  • 7
  • 3
  • How many comparisons is the code making? What values is it returning to the caller? Answers to those questions will provide most of what you're looking for. – larsks Oct 26 '20 at 11:02
  • I am not sure why this is being downvoted when I just asked what are those two lines of code mean. I did not ask anyone to answer this question for me. – Martin Tran Oct 26 '20 at 11:07

1 Answers1

2

more specifically, what do these lines of code mean?

a2f <isValid+0xb> a3b <isValid+0x17>

This is the address where the jump instruction jumps to. a2f is the actual address in hexadecimal. <isValid+0xb> is the disassembler telling you that this address is also 0xb bytes after the start of isValid.

Don't ask me why the disassembler writes 0x before the b but not before the a2f.

Note: a2f is too small to be the actual memory address, so presumably the loader adds this to some starting address when it loads the program. The program is assembled by pretending the starting address is 0, even though it won't be.

user253751
  • 57,427
  • 7
  • 48
  • 90
  • This could be disassembly of a `.o` which does default to 0 base address for the file. Or possibly a Linux PIE (position-independent) executable, although I think PIE disassembly by `objdump` usually default to a fake base of `0x1000` or so. – Peter Cordes Oct 26 '20 at 11:29
  • In objdump output, absolute addresses are implicitly hex (start of each line, and in branch targets); everything else uses C syntax for numbers. I think that's the best way to make sense of the apparent inconsistency. – Peter Cordes Oct 26 '20 at 12:01