Using magic attribute in struct field

[yeongjet]

My Codes:

#[derive(Debug, BinRead)]
#[br(little)]
pub struct ImageDosHeader {      // DOS .EXE header
    #[br(magic = b"MZ")]
    e_magic: u16,                     // Magic number
    e_cblp: u16,                      // Bytes on last page of file
    e_cp: u16, 
    ...
}
...
fn main() {
        let imageDosHeader = ImageDosHeader::parse("D:\\sample.exe");
        println!("{:?}", &imageDosHeader);
}

The binary data in the sample exe file:

4d5a90000300...

The output is:

ImageDosHeader { e_magic: 144, e_cblp: 3, e_cp: 0, e_crlc: 4, e_cparhdr: 0, ...

The field e_magic is assgined with 0x90 not 0x5a4d. In order words, seems like that magic attribute doesn't work in struct field, but the doc says it supports for all, I want to keep e_magic in struct, what should I do?

[csnover]

Hi, thanks for your question! The magic directive always consumes the matched value. From the docs:

When a magic number is matched, parsing begins with the first byte after the magic number in the data.

Since the magic value must be a constant, storing what is matched is a waste of memory. However, if you really want to store a value and then assert that it matches some thing, you can do that using the assert directive instead.

[yeongjet]

I forgot to explain why I need to store this magic number, sorry. The reason is that the ImageDosHeader struct comes from IMAGE_DOS_HEADER in Windows SDK(winnt.h), it's an accepted standard, I want keeping the structure fully. @csnover @kitlith

IMAGE_DOS_HEADER:

typedef struct _IMAGE_DOS_HEADER {      // DOS .EXE header
    WORD   e_magic;                     // Magic number
    WORD   e_cblp;                      // Bytes on last page of file
    WORD   e_cp;                        // Pages in file
    WORD   e_crlc;                      // Relocations
    WORD   e_cparhdr;                   // Size of header in paragraphs
    WORD   e_minalloc;                  // Minimum extra paragraphs needed
    WORD   e_maxalloc;                  // Maximum extra paragraphs needed
    WORD   e_ss;                        // Initial (relative) SS value
    WORD   e_sp;                        // Initial SP value
    WORD   e_csum;                      // Checksum
    WORD   e_ip;                        // Initial IP value
    WORD   e_cs;                        // Initial (relative) CS value
    WORD   e_lfarlc;                    // File address of relocation table
    WORD   e_ovno;                      // Overlay number
    WORD   e_res[4];                    // Reserved words
    WORD   e_oemid;                     // OEM identifier (for e_oeminfo)
    WORD   e_oeminfo;                   // OEM information; e_oemid specific
    WORD   e_res2[10];                  // Reserved words
    LONG   e_lfanew;                    // File address of new exe header
  } IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;

The WORD here is unsigned short(u16) actually. So, for keeping this struct in rust, using u16 for the e_magic field would be better? @kitlith

[yeongjet]

The second reason is that some analyze tools needs to display magic number, like PE-bear:

I may not hard code 5A4D if I were that software developer (image that several file types are supported, but their magic number are different). @csnover @kitlith

[csnover]

The reason is that the ImageDosHeader struct comes from IMAGE_DOS_HEADER in Windows SDK(winnt.h), it's an accepted standard, I want keeping the structure fully.

Keep in mind that the reason the Win32 API looks like that is because it is the easiest way to do it in C, not because it’s some standard. Rust has different capabilities, and I would not recommend trying to bring old C practices to Rust.

The second reason is that some analyze tools needs to display magic number

I apologise, I don’t understand how this is relevant to a Rust parser?

image that several file types are supported, but their magic number are different

By definition, there is no other magic than "MZ" for a DOS header. Other executables types with different magic have different, incompatible, structures.

The idiomatic way to handle your use case with binrw is as @kitlith mentions and is how others do it and is what I would recommend to do. But it is up to you, the various options have been given. Good luck!

[yeongjet]

Thank you for your explanation, it has benefited me greatly. In fact, I have just started learning Rust and there are many areas that I may not fully understand yet. @csnover

[yeongjet]

Also thanks @kitlith , the options you provided are very helpful to me.