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.

Sign up for GitHub

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

Jump to bottom

Failing to parse QEMU memory dump note .shstrtab #370

Open
IridiumXOR opened this issue May 24, 2023 · 3 comments · May be fixed by #414
Open

Failing to parse QEMU memory dump note .shstrtab #370

IridiumXOR opened this issue May 24, 2023 · 3 comments · May be fixed by #414

Comments

@IridiumXOR
Copy link

Hi,
if you generate an ELF core file containing the memory dump of VM in QEMU (qemu-system-x86_64 than in console dump-guest-memory FILENAME) and you parse it with a simple Rust program as

use goblin::Object;
use std::io::Read;
use std::fs::File;

fn main() {

    let mut file = File::open("/tmp/elf").map_err(|_| "open file error").expect("Error");

    let mut head = vec![0; 1024*1024*2];
    file.read(&mut head).ok();
    println!("{:?}\n", Object::parse(&head));
}

you get Err(Malformed("Section 1 size (151127112) + offset (11) is out of bounds. Overflowed: false")) but the ELF core is correctly formatted. I suppose the error is a offset-by-one error.
@m4b
Copy link
Owner

m4b commented Jul 5, 2023

interesting; @IridiumXOR would you be interested in working on a PR to fix this? :)

@h33p
Copy link
Contributor

h33p commented Jul 2, 2024

Experiencing similar problem:

Malformed entity: Section 1 size (8724103072) + offset (11) is out of bounds. Overflowed: false

The interesting thing is that it appears that size and offset have their places swapped.

❯ readelf --sections ../win11-for-dump2.elf
There are 2 section headers, starting at offset 0x40:

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .shstrtab         STRTAB           0000000000000000  207ff3fa0
       000000000000000b  0000000000000000           0     0     0
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  D (mbind), l (large), p (processor specific)

@h33p h33p linked a pull request Jul 2, 2024 that will close this issue
Open
@m4b
Copy link
Owner

m4b commented Jul 28, 2024

so while reading the PR for fixing this issue, it was revealed that the primary cause of this was that the full file was not being loaded into memory, so that parsing was out of bounds. Is this also the cause of your failure here in this issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix issue 370 h33p/goblin
3 participants
@m4b @IridiumXOR @h33p