search

nanonyme / pefile

Automatically exported from code.google.com/p/pefile
Other
0 stars 0 forks source link

write() VS_VERSIONINFO bug #39

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?

get a file containing FileInfo, a StringTable with 'LegalCopyright'

pe=pefile.PE(r'test.exe')
pe.FileInfo[0].StringTable[0].entries['LegalCopyright']='this is a string 
longer than the entry '*10
pe.write(r'test_.exe')

this will corrupt resources, or the entire exe if the resource directory 
doesn't come last
problem is during writing of VS_VERSIONINFO
the length of key should be checked before writing this, but I think it's a 
better idea to completely ignore writing of this
other resources aren't written in this method

Original issue reported on code.google.com by simonz...@gmail.com on 25 Jun 2012 at 7:54

GoogleCodeExporter commented 9 years ago 
pefile will not rearrange any structures/headers if data of different lengths 
is written. It does allow to overwrite the values, which often comes handy.
Currently there are have no plans of having pefile regenerate the PE to account 
for changes in field/structure sizes.

Original comment by ero.carr...@gmail.com on 26 Jun 2012 at 7:46

GoogleCodeExporter commented 9 years ago 
no that's not what I meant, what I meant is exactly what you said, pefile isn't 
doing what you said, if a different string length is put in this will corrupt 
the pe, only when the strings are too long not if they are too short, this is a 
bug in the code
there should be checks preventing this from happening
try my example out

Original comment by simonz...@gmail.com on 27 Jun 2012 at 2:43

GoogleCodeExporter commented 9 years ago 
Thanks for bringing this up. I see how that might be a problem.
The correct behavior would be to rearrange the file so it all fits when adding 
both, longer and shorter data. Given that pefile doesn't attempt to produce 
correct PEs I don't see checks as the ones you proposed to provide much value. 
I don't want people to start relying on pefile to compose PEs ;-) . It's 
complex enough to parse all its idiosyncrasies that I don't want to have to 
deal with composition of correct PEs.
Actually, I've personally found useful having no such checks when I've needed 
to modify the PE without adhering to structure/header boundaries.
Nonetheless, if you still feel this is a serious problem for your use-case, I 
will take a look at patches.

Original comment by ero.carr...@gmail.com on 27 Jun 2012 at 8:37