How to Extract Data of ELF file (Executable of C program)?

Question

Edit: Still No answer works, the output is:

401bc0 3d2a323d 333a7b3d 3a3a               =*2=3:{=::

I tried =*2=3:{=:: as password but it's wrong (note working with little endian)

I don't agree with the provided answer and most importantly don't get it why what I did is wrong, I am checking an executable file (from C) that's in ELF format.

Now, I know that the following array of chars of size 10 contains a secret password and I want to find it.

Plus, I know it's located at address 0x401bc0.

char foor [10] = {0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, };

So, I opened the elf file, counted 0xbc0 bytes (which is equal to 4660) and started writing the first 10 I see (Why I counted only 0xbc0? because according to my second output using readelf command I saw that section Load starts at 0x400000 in memory and its offset is 0x0 in my file) , I got:

char foo[10] = {0xC3, 0x82, 0x66, 0xC6, 0x92, 0xC3, 0xB9, 0x03, 0x0F, 0xE2,};

But it's wrong, why is that?

How do I know, well when I convert this array of chars to a string and type it as an input to my program it says the password is wrong.

My ELF file (sorry if it's too long): https://justpaste.it/51sbe

plus I got this:

readelf -l prog.html

Elf file type is EXEC (Executable file)
Entry point 0x4004fc
There are 9 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x0000000000400040 0x0000000000400040
                 0x00000000000001f8 0x00000000000001f8  R E    0x8
  INTERP         0x0000000000000238 0x0000000000400238 0x0000000000400238
                 0x000000000000001c 0x000000000000001c  R      0x1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
                 0x0000000000001d14 0x0000000000001d14  R E    0x200000
  LOAD           0x0000000000001e10 0x0000000000601e10 0x0000000000601e10
                 0x000000000000022c 0x0000000000000230  RW     0x200000
  DYNAMIC        0x0000000000001e28 0x0000000000601e28 0x0000000000601e28
                 0x00000000000001d0 0x00000000000001d0  RW     0x8
  NOTE           0x0000000000000254 0x0000000000400254 0x0000000000400254
                 0x0000000000000044 0x0000000000000044  R      0x4
  GNU_EH_FRAME   0x0000000000001bcc 0x0000000000401bcc 0x0000000000401bcc
                 0x000000000000003c 0x000000000000003c  R      0x4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RWE    0x10
  GNU_RELRO      0x0000000000001e10 0x0000000000601e10 0x0000000000601e10
                 0x00000000000001f0 0x00000000000001f0  R      0x1

 Section to Segment mapping:
  Segment Sections...
   00     
   01     .interp 
   02     .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame 
   03     .init_array .fini_array .jcr .dynamic .got .got.plt .data .bss 
   04     .dynamic 
   05     .note.ABI-tag .note.gnu.build-id 
   06     .eh_frame_hdr 
   07     
   08     .init_array .fini_array .jcr .dynamic .got 
student@ubuntu18:~/Desktop/HW3$

That's not how [Executable and Linkable Format](https://en.wikipedia.org/wiki/Executable_and_Linkable_Format) files work. — Some programmer dude, May 27 '21 at 19:36
And besides, `0x401bc0` is equal to decimal `4201408`, not `4660`. — Some programmer dude, May 27 '21 at 19:37
Not to mention the post of the the text executable content isn't meaningful. The character encoding (whatever it is) renders it unusable to use further. If this is a binary file extraction exercise, just open the file, then `fseek()` 0x401bc0 bytes from the beginning and read the next 10 bytes. It is doubtful you could write anything there that would be meaningful as the actual password would have been encoded before being saved and decoded for comparison to user supplied passwords. Entering something in those 10 chars would likely not match the same 10 entered as the password. — David C. Rankin, May 27 '21 at 19:41
Use `objdump -s` to get a hex dump of the binary and find the relevant bytes. — fuz, May 27 '21 at 19:44
`objdump` is a part of the GNU binutils. It should already be installed on you Linux system. — fuz, May 27 '21 at 19:46
Look at the `GNU_EH_FRAME` `PhysAddr` which ends 3-bytes after your offset. That would suggest you consider No. 3 in the answer from @Clifford. The page [Executable and Linkable Format](https://en.wikipedia.org/wiki/Executable_and_Linkable_Format) may help. It provides a good summary of the ELF contents and sections. See also [ELF program header segments sizes and offsets](https://stackoverflow.com/a/22031121/3422102) — David C. Rankin, May 27 '21 at 19:57
@fuz I got: "401bc0 3d2a323d 333a7b3d 3a3a =*2=3:{=::" but still it's wrong — , May 27 '21 at 20:44
@DavidC.Rankin: 0x401bc0 is typical for a *virtual address* in `.text` or `.rodata` in x86-64 Linux ELF executables, not a file offset at all. Although since memory mapping is page-aligned, the file offset probably has the same low 12 bits (although the ELF program headers will show the actual virt -> offset mapping). Anyway, `0xbc0` is `3008` (decimal) so 4660 still doesn't make sense. Yeah, we can see from the readelf output that address is part of the `R E` (read + exec) mapping, so I guess it predates the GNU `ld` change to link .rodata into a separate non-executable segment. — Peter Cordes, May 28 '21 at 00:15

score 1 · Accepted Answer · answered May 27 '21 at 20:53

1

I think your arithmetic has gone wrong.

The first LOAD segment is loaded at address 0x400000 and has size 0x1d14, so it indeed includes the 10 bytes starting at 0x401bc0, at offset 0x401bc0 - 0x400000 = 0x1bc0 into this segment. The segment starts at offset 0 in the file, so you need to look at offset 0x1bc0 in the file, not offset 0xbc0. And 0x1bc0 is decimal 7104.

(And 0xbc0 in decimal is 3008, not 4660. A good fact to memorize for mental arithmetic is that 0x1000 = 4096 is one page. So 0x1bc0 must be between 4096 and 8192, and likewise 0xbc0 must be less than 4096. That's how I could tell at a glance that something was wrong with your math.)

answered May 27 '21 at 20:53

Nate Eldredge

48,811
6
54
82

Hi, This doesn't work too, I copied the first 7116 bytes from the file and pasted it here (to convert to hex) https://onlinestringtools.com/convert-string-to-bytes then I took the bytes 7104-7113 (where I started counting from 0) then converted those bytes to string but the answer is wrong too. – May 27 '21 at 21:08
I got those bytes: bf e2 80 b0 c3 82 66 c6 92 c3 which translate to: ¿Ãf which is wrong – May 27 '21 at 21:09
Sorry, posting these files as "printable" characters is useless. As Clifford says, we need to see a hex dump of the whole thing, or a downloadable binary. Make sure to check whether the tool you're using displays offsets in decimal or hex. – Nate Eldredge May 27 '21 at 21:11
So in other words I can't use copy paste? btw I followed the other answer where it says: "Use objdump -s to get a hex dump of the binary and find the relevant bytes." but the answer is wrong too – May 27 '21 at 21:13
No, you can't copy-paste binary data. – Nate Eldredge May 27 '21 at 21:15
I got: " 401bc0 3d2a323d 333a7b3d 3a3a =*2=3:{=:: " so the password is 401bc0 3d2a323d 333a7b3d 3a3a but I convert it to string which is: "=*2=3:{=::" and still wrong answer. – May 27 '21 at 21:16
what you wrote gives: "=2*=={:3::" which is wrong too – May 27 '21 at 21:19
why? in hex every 2 chars are 1 byte the pass is 10 bytes and there are exactly 20 bytes here – May 27 '21 at 21:21
yes I know, so we need to read pairs from bot to top which gives: 3a3a3d7b3a333d322a3d which is still wrong... – May 27 '21 at 21:23
@mosh: Look, please show the entire line of output from `objdump -s` which starts `401bc0`. Then maybe we can see what we're actually talking about. – Nate Eldredge May 27 '21 at 21:26
I already wrote in 2 comments before this one :) – May 27 '21 at 21:28
@mosh: There ought to be more of the line following `3a3a`. – Nate Eldredge May 27 '21 at 21:30
How to format in comments like you write in gray? – May 27 '21 at 21:31
and why you need what is after 3a3a? we already have 10 bytes... – May 27 '21 at 21:33
Oh I see, the segments overlap. So in fact `3a 3a` probably are the last two bytes. If that's not the answer you're looking for, then I'm afraid I am out of ideas. You might check to make sure you are submitting the answer in the proper format for whatever is checking it, or talk to whoever set this problem to see if there might be a mistake somewhere. – Nate Eldredge May 27 '21 at 21:34
Can we move to chat for 1 min? – May 27 '21 at 21:35
@mosh: Enclose text in back ticks `\`foo\`` to get it set in monospace. See https://stackoverflow.com/help/formatting for help on Markdown formatting. – Nate Eldredge May 27 '21 at 21:35
Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/232974/discussion-between-mosh-and-nate-eldredge). – May 27 '21 at 21:35
1

For future readers: deleted some previous wrong comments. `objdump -s` apparently displays big-endian dwords, even on a little-endian system. I didn't know that. – Nate Eldredge May 27 '21 at 21:58

How to Extract Data of ELF file (Executable of C program)?

1 Answers1