Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ELF: can't load symbols from the linux kernel image #1251

Closed
XVilka opened this issue Aug 27, 2014 · 9 comments
Closed

ELF: can't load symbols from the linux kernel image #1251

XVilka opened this issue Aug 27, 2014 · 9 comments

Comments

@XVilka
Copy link
Contributor

XVilka commented Aug 27, 2014

Here is the image:

http://xvilka.me/vmlinux-3.13.0-24-generic

'is' output is 0 (zero)

@XVilka
Copy link
Contributor Author

XVilka commented Aug 27, 2014

@radare sry, fixed link

@LemonBoy
Copy link
Contributor

The file isn't loaded completely, r_bin_load_io_at_offset_as sets the maximum size to 0x8000000 bytes and just truncates the file if it's bigger instead of returning an error so that the other code path loads it entirely.

@radare
Copy link
Collaborator

radare commented Oct 7, 2014

Funnily, my kernel image is PE

$ r2 -n /boot/vmlinuz-3.14.17_1 
 -- Use '-e bin.strings=false' to disable automatic string search when loading the binary.
[0x00000000]> x
- offset -   0 1  2 3  4 5  6 7  8 9  A B  C D  E F  0123456789ABCDEF
0x00000000  4d5a ea07 00c0 078c c88e d88e c08e d031  MZ.............1
0x00000010  e4fb fcbe 4000 ac20 c074 09b4 0ebb 0700  ....@.. .t......
0x00000020  cd10 ebf2 31c0 cd16 cd19 eaf0 ff00 f000  ....1...........
0x00000030  0000 0000 0000 0000 0000 0000 8200 0000  ................
0x00000040  5573 6520 6120 626f 6f74 206c 6f61 6465  Use a boot loade
0x00000050  722e 0d0a 0a52 656d 6f76 6520 6469 736b  r....Remove disk
0x00000060  2061 6e64 2070 7265 7373 2061 6e79 206b   and press any k
0x00000070  6579 2074 6f20 7265 626f 6f74 2e2e 2e0d  ey to reboot....
0x00000080  0a00 5045 0000 6486 0400 0000 0000 0000  ..PE..d.........
0x00000090  0000 0100 0000 a000 0602 0b02 0214 b094  ................
0x000000a0  3500 0000 0000 50d9 9400 1046 0000 0002  5.....P....F....
0x000000b0  0000 0000 0000 0000 0000 2000 0000 2000  .......... ... .
0x000000c0  0000 0000 0000 0000 0000 0000 0000 0000  ................
0x000000d0  0000 0070 ca00 0002 0000 0000 0000 0a00  ...p............
0x000000e0  0000 0000 0000 0000 0000 0000 0000 0000  ................
0x000000f0  0000 0000 0000 0000 0000 0000 0000 0000  ................

@radare radare modified the milestones: 0.9.9, 0.9.8 Nov 10, 2014
@radare
Copy link
Collaborator

radare commented Dec 1, 2014

This will be probably fixed with the lemon elf parser

@XVilka
Copy link
Contributor Author

XVilka commented Apr 5, 2015

@radare so, ages are passing, what should we do with @LemonBoy elf-ng parser? Abandon it? Rebase an polish one more time? Some 3rd way solution?

@radare
Copy link
Collaborator

radare commented Apr 6, 2015

I have recently started to read rbin again and ive been thinking in some optimizations and stuff to change,

But as i said, changes in rbin require time for fuzzing and covfixing, thelemon parser doesnt gives any benefit to r2 because it is incomplete, it is known to crash with some binaries and most of the bugs cant be prooved because there are no tests.

Both elf parsers can coexist in current r2. I have already suggested several months ago to rewrite that parser with a different name to have both in master for proper testing without loosing features or so.

I already said several times i was not going to switch to a new elf parser before the release. And im not going to change it if simple tests just fail.

His codebase looks cleaner, but its incomplete and have several bugs, which the current one does not.

Also, ive got a huge speedup using sdb in rbin for some tests, and i think that sdb can bring several other benefits to rbin, so both parsers will be deprecated soon or late. (Or just taken as base)

On 06 Apr 2015, at 00:27, Anton Kochkov [email protected] wrote:

@radare so, ages are passing, what should we do with @LemonBoy elf-ng parser? Abandon it? Rebase an polish one more time? Some 3rd way solution?


Reply to this email directly or view it on GitHub.

@radare
Copy link
Collaborator

radare commented Apr 6, 2015

Also, the elf-ng parser cant load a PE file and understand it have a payload in ELF, in fact nobody can do that. Kernels are usually not that easy to handle because of the loader/compressed payloads.

@radare radare modified the milestones: 1.0.0, 0.9.9 Apr 6, 2015
@radare
Copy link
Collaborator

radare commented May 19, 2015

Anyone tried so far with the latest elf parser in r2-git? there have been several related enhacements

@XVilka
Copy link
Contributor Author

XVilka commented Apr 5, 2016

fixed. Though lighter regression test should be added

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants