PEtrim problem

[SurProf]

WDK (without hacking of makefiles etc.) produces images with some debug information even in free builds. So it is useful to cut such information from driver images before release. PEtrim seems to be an excellent choice to achieve this.

However, on x86 (pre-Vista at least, I'm developing an XP driver) driver images produced by WDK have actually 0x80 file alignment, which
0. is against Microsoft's latest PE Format Specification (oh, well),
1. causes PEtrim to emit a warning that "alignment may not be valid"
2. results in an unloadable image after PEtrim-ming with /Align=128 (checked OS kernel emits the following line to the kernel debugger
MMCREASECT: invalid BSS/Trailingzero
by the following code according to Windows Research Kernel:

            if (((SectionTableEntry->PointerToRawData !=
                  SectionTableEntry->VirtualAddress))
                            ||
                   (SectionVirtualSize > SectionTableEntry->SizeOfRawData)) {

                KdPrint(("MMCREASECT: invalid BSS/Trailingzero %Z\n",
                        &File->FileName));

).

I took a look at the PEtrim-med image and in fact file pointer to raw data and virtual address are not equal for all sections (including some code sections) but .text, .rdata, .data. Could a bugfix release of PEtrim (PEsuite/PEcompact) consider the additional constraints of Windows image loader to produce loadable images?

Additional info: using 2.96.2student version of PEcompact, additional command-line switch /StripFixups:N. Sample driver image provoking the problem can be provided confidentally on demand.

PS: Why does PEtrim not take the default alignment parameter from the input image? Then if no change is required in file alignment, no such command-line parameter would be needed.

[Jeremy Collake]

Thanks for the report. I'll have to do some work on this, but it should be pretty trivial. I don't know when I'll get around to it, but will try to get to it some time this month. If you want, you can add this to the new public bug and feature tracker I launched yesterday - http://www.bitsum.com/mantis .

[SurProf]

Thanks Jeremy. Let me know if I can help you by doing some trial-and-error tests on the new PEtrim.

Regarding the bug tracker, I understand that one has to sign up separately (the login used for the forum doesn't work) but after the account verification, upon chaning password Application error #2800 occurs ("Invalid form security token. Did you submit the form twice by accident?") and the account isn't usable ("Your account may be disabled or blocked or the username/password you entered is incorrect."). What can be done about this?

[Jeremy Collake]

Hmm, I don't know about the bug tracker, I see the problem you encountered. It doesn't surprise me that there are some glitches, but that looks like a general failure/incompatibility of the Mantis code. I'll have to do some investigation and get it resolved. Perhaps I'll try the latest alpha.

Until I get it fixed, I am going to quit mentioning the bug tracker. I am not entirely satisfied with it anyway. I find it quite cumbersome to work with.

[SurProf]

Any news on the bugfix?

[Jeremy Collake]

I'm sorry, I haven't got to it yet. I've been focused on Process Lasso, but this is still on my todo list. The change will require modifications to my PE Engine, so it has to be done thoughtfully and carefully, and necessitates a bunch of regression testing -- perhaps the biggest reason I've not done it yet ;o. I hope to get to it soon though, sorry for the delay.

[SurProf]

Happy New Year!

Are we facing some kind of livelock here?
Can you tell me some plan when to expect the update?

[Jeremy Collake]

Sadly, at this point in time, I would not expect it ;(. I never have gotten the time or impetus to make this semi-large change to the code. Given my current schedule, I don't foresee doing it anytime in the near future. I'm sorry to have originally said I would.

[SurProf]

Hi Jeremy, thanks for the news even if it is some less good one. I wrote an email to you through this site some time ago but seems it haven't reached you so I'm asking it here now: I don't have much time either but would it be possible for me somehow to contribute to the solution of this problem? As you can see I'm really fond of your tools Thanks.

[Jeremy Collake]

First, sorry I didn't respond sooner here. I don't recall an email, I think I may be missing some of them.. I need to be better filter my inbox.

Anyway, there isn't much you can do to help at this time. PECompact is due for needed maintenance soon, but I've still been busy with a massive overhaul/improvement of Process Lasso. When I get to this PECompact maintenance, I'll absolutely work on the PETrim issue. So, give me some more time, and maybe I can get to this. I anticipate having to do this maintenance some time in the next couple weeks.. pretty much whenever I get so burnt out on Process Lasso that I need a break ;o. Heck, I suppose it could be sooner, but then I also have major web site coding to do.. ugh.

The sad thing is that this change could probably be done pretty quickly, its just that I'd have to really be thoughtful about the changes and regression test them well.

Ugh.. someday man, sorry.

[SurProf]

Till your fix comes I was investigating exactly what debug info is produced in my use-case and I found out that only a single reference to the PDB7.0+ file is kept in the final image.

I expected that your tool would remove that reference, however, apart from the original problem I reported in this topic (i.e. the result of stripping with your tool is an unloadable kernel mode driver image) the name of the PDB file is left intact (only moved with)in the image. The pointer to it (the debug directory entry) is cleared.

The goal of trimming of all debug info, in my opinion, would be not to give any evident clue about the production but if any fragment of the name of the debug info file is retained, the goal is not reached. I therefore propose to fill with zeroes the debug directory itself and all other referenced part of the image from that point recursively as well in future PEtrim releases (besides the already implemented removal of the debug directory entry from the data directories of the image).

[Jeremy Collake]

Yes, PECompact was updated so that it can properly, and entirely, strip or relocate the debug directory, and any references made from the debug directory (a deep copy, or deep strip). However, PETrim was never updated with the debug directory handling code. I will make sure that it is.

[Jeremy Collake]

I have finally got around to catching up on PECompact maintenance.

I've enhanced PETrim so that it properly traverses debug directories and removes them completely, as PECompact already did (depending on config). Fixing issues with physical alignments other than 0x200 is still pending.

I'll be releasing the first v2.99 beta of PECompact soon.