Fix get_memory_mapped_image copy much header data

[qux-bbb]

Before this changing, some non b"\0" data will be copied to the header.
After this changing, the header will be clear.

[erocarrera]

I want to understand better what is the reason for this change? does it mirror the behavior of the OS or is it simply to keep it "clean" of the values outside the header?
I have the recollection (but I have not verified it) that the OS does not clear the values when mapping the file into memory. pefile attempts to mirror that behavior.

[qux-bbb]

This change want to mirror the behavior of the OS.
The OS just maps PE file to memory. For mapped header, it does not contain latter data.
But before this commit, pefile will map latter data to header in memory.

[erocarrera]

This change does not correctly handle the mapped data so far.

[qux-bbb]

Maybe I should find a sample to prove it.

[erocarrera]

Hello, that would be great. It's always good to have cases for the test suite.
But I was talking more about the PR, the code appears to simply take the header and add the padding, disregarding any other previous data what might have been added while processing sections and already in mapped_data.

[qux-bbb]

Because I think that if padding_length < 0, then this is a header section. Isn't it?

[erocarrera]

Just changing the initial contents of "mapped_data" should lead to the behavior you desire. I've made the change in commit 14a4c71. What do you think?

[qux-bbb]

14a4c71
That is a good change. Thank you! You can close this issue.
What I cannot understand is that Is there other situation about "padding_length < 0"?

[erocarrera]

Yes, out of curiosity I ran over all the files I use for my tests and there are a few with negative padding_length, both when encountering the first section and with later sections as well. It's mostly the case with malware or slightly malformed files.