Closed neitsa closed 2 years ago
Hi @neitsa
Actually this is not an error. lief.PE.Binary()
is the constructor function for the PE.Binary
object while lief.parse
and lief.PE.parse
effectively parse the given file and provide an instance of lief.PE.Binary
.
Nevertheless, the difference comes from the fact that the lief.PE.Binary()
constructor initializes the lief.PE.Header
(NT Header in CFF) structure right after the DosHeader
while there is actually the DOS Stub that prints "This program cannot be run in DOS mode." in the original ntoskrnl.exe
.
Hi @romainthomas! I really do hope you're doing well :)
Ahhhh OK! That's good to know. Thanks a lot for your quick answer and sorry for the bother.
I'm thinking about adding something to the documentation to that effect, but I'm not sure how to phrase it. Do you think this behavior warrants a mention in the doc though?
Let me know; I'll close the issue in a few days.
Once again thanks a lot!
I updated the doc :)
Thanks a lot Romain! Closing the issue :)
Describe the bug
LIEF reports a wrong value for the
e_lfanew
PE field (from the DOS_HEADER) when instantiatinglief.PE.Binary
directly.To Reproduce
From a windows 10 x64 kernel (10.0.19041.1526).
e_lfanew
value is 0x118 (280):Using
lief.parse
yields a correct result:(as for the error message it might be the same as #560).
Using
lief.Binary
instead, passing the correct type (lief.PE.PE_TYPE.PE32_PLUS
) for the binary, yields a wrong result:I can't really explain the 0n40 (0x28) discrepancy.
Expected behavior
Correct value for
e_lfanew
when instantiating directlylief.PE.Binary
.The LIEF lief.PE.Binary documentation states:
I would have expected the same behavior as using the resulting object returned from
lief.parse()
.As far as understand they should be the same?
Environment (please complete the following information):
Python 3.9.9 (tags/v3.9.9:ccb0e6a, Nov 15 2021, 18:08:50) [MSC v.1929 64 bit (AMD64)] on win32