erocarrera / pefile Goto Github PK

What steps will reproduce the problem?
Run as follows (you will need notepad.exe in the same dir this is run from or 
any valid pe file (change filename appropriately)):

import pefile
import os
pe=pefile.PE('notepad.exe')
os.system("del notepad.exe")

What is the expected output? What do you see instead?
The following error is printed (by del) and the file is not deleted:
"The process cannot access the file because it is being used by another 
process."

What version of the product are you using? On what operating system?
pefile version: 1.2.10-114
Operating System: Windows XP Professional SP3

Please provide any additional information below.
This may not be an issue, it is similar the problem described in issue 26 but 
in this case it occurs when the pefile module does not except - i.e. 
__parse__() is successful - possibly this is as intended.

To avoid this issue I can call the pefile.PE close fn:
pe=pefile.PE('file.dll')
pe.close()
os.system("del file.dll")

Is this the expected way for pefile to function - i.e. should I be calling the 
pefile.PE close() fn in my script after calling pefile.PE to close the mmap 
handler?  I had a quick look at the pefile examples and don't see the close 
function being called.  Calling close() in my scripts seems a little misleading 
since it doesn't really close the pefile PE object as I'd expect since only the 
mmap handler is closed i.e. this works fine:

pe=pefile.PE('file.dll')
pe.close()
print pe.FileInfo

Alternatively I can add self.close() to the try block in pefile.PE init method:
        try:
            self.__parse__(name, data, fast_load)
            self.close()
        except:
            self.close()
            raise

I don't understand the impact of adding self.close() to the pefile.PE init 
method though i.e. will it affect the functionality of other pefile.PE 
functions that could normally be called after pefile.PE()?

I'd really appreciate your feedback on this before modifying our scripts.

Thank you very much

What steps will reproduce the problem?
1. pe = PE("C:\\Windows\\System32\\catroot2\\edb.log")

What is the expected output? What do you see instead?

There should be no exceptions, but PEFormatError(), in fact:

Traceback (most recent call last):
  File "C:\Temp\pefile_mockup_3.py", line 15, in <module>
    pe = PE(file_name)
  File "build\bdist.win32\egg\pefile.py", line 1754, in __init__
  File "build\bdist.win32\egg\pefile.py", line 1810, in __parse__
UnboundLocalError: local variable 'fd' referenced before assignment


What version of the product are you using? On what operating system?

pefile-1.2.10-139.zip 

Please provide any additional information below.

File C:\Windows\System32\catroot2\edb.log is locked by this system process - 
svchost.exe running under NT AUTHORITY\NETWORK SERVICE account.

What steps will reproduce the problem?
1. Load a PE file.
2. Alter the export table by setting attributes on  elements of
pe.DIRECTORY_ENTRY_EXPORT.symbols
3. Save the PE object to a file

What is the expected output? What do you see instead?

I expected the changes to be written to the file; they weren't.

What version of the product are you using? On what operating system?

Version 1.2.10-63 on Windows XP.

Hi,

I'm with VMware and we are using this module to serve our symbols server. We 
have upgraded to 1.2.10-102 recently, and I noticed you have switched to use 
mmap module to load a file to self.__data__ (you were just reading the file 
.read() in earlier versions). However, line 1731 chokes when the file is empty. 
i.e. when passing 0 to the second parameter to mmap.mmap(), it expects the file 
to be non-zero!!

Traceback (most recent call last):
  File "/build/apps/symindex/lib/repository.py", line 106, in run
    pe = pefile.PE(path)
  File "build/bdist.linux-i686/egg/pefile.py", line 1696, in __init__
    self.__parse__(name, data, fast_load)
  File "build/bdist.linux-i686/egg/pefile.py", line 1731, in __parse__
    self.__data__ = mmap.mmap( self.fileno, 0, access = mmap.ACCESS_READ  )
error: [Errno 22] Invalid argument

please fix it.

This line:

return int (value, 16)

crashes when encountering a comment (line starting with ';') in a UserDB.txt 
file.

What steps will reproduce the problem?
1. Download testfile virtsectbl.exe from corkami or attachment
2. Execute the code pefile.PE("virtsectbl.exe", fast_load=True)

What is the expected output? What do you see instead?

Expected: No exception. 
Instead:
Traceback (most recent call last):
  File "test.py", line 7, in <module>
    pe =  pefile.PE("virtsectbl.exe", fast_load=True)
  File "/usr/local/lib/python2.7/dist-packages/pefile.py", line 1667, in __init__
    self.__parse__(name, data, fast_load)
  File "/usr/local/lib/python2.7/dist-packages/pefile.py", line 1709, in __parse__
    stat = os.stat(fname)
OSError: [Errno 2] No such file or directory: 'virtsectbl.exe'


What version of the product are you using? On what operating system?

pefile 1.2.10-139
Ubuntu 14.04

Please provide any additional information below.

The section table of this file is in virtual space, which is probably causing 
the exception

What steps will reproduce the problem?
1. Take Big Continious SFX ACE Archive digitally signed (1GB size)
2. Use disitool.py that uses pefile.py
3. Call disitool.py delete signed_archive unsigned_archive

What is the expected output? What do you see instead?
The expected output is the unsigned_archive,
instead I see:
Traceback (most recent call last):
  File "app_main.py", line 51, in run_toplevel
  File "H:\disitool.py", line 258, in <module>
    Main()
  File "H:\disitool.py", line 231, in Main
    DeleteDigitalSignature(args[1], args[2])
  File "H:\disitool.py", line 59, in DeleteDigitalSignature
    pe = pefile.PE(SignedFile)
  File "H:\pypy-1.7\site-packages\pefile.py", line 1667, in __init__
    self.__parse__(name, data, fast_load)
  File "H:\pypy-1.7\site-packages\pefile.py", line 1785, in __parse__
    self.__data__[optional_header_offset:],
MemoryError

What version of the product are you using? On what operating system?
Pefile 1.2.10.114
Disitool 0.3
Windows 7 64bit Version 6.1 (Build 7601: Service Pack 1)

Please provide any additional information below.

There is an 1GB size Continius SFX ACE archive EXE file
the file is digitally signed, thus the CRC is invalid

The goal of disitool.py is to remove the digitally sign from the EXE file
To complete this goal it calls pefile.py
For some unknown reasons the MemoryError exception happens

Memory monitoring tools does not report ANY spike of usage of memory,
even with 3GB of free RAM and lots of Swap Space in Windows, the same error 
happens.

The cause of the error is unknown to me. 

What steps will reproduce the problem?
1. Instantiate pefile.PE with a particular exe 

What is the expected output? What do you see instead?

I expect the executable to be loaded.

I get :
  File "remove_invalid.py", line 67, in <module>
    pe = pefile.PE(local_exe_name)
  File "build/bdist.linux-i686/egg/pefile.py", line 1667, in __init__
  File "build/bdist.linux-i686/egg/pefile.py", line 1785, in __parse__
MemoryError

What version of the product are you using? On what operating system?

1.2.10-114 on "Red Hat Linux release 7.3 (Valhalla)" (sic)

Please provide any additional information below.

Sorry, I can't provide the original executable for confidentiality reasons.

PE() creates a mmap file.
The mmap is never closed on python 2.5.x because mmap.mmap is a factory 
function and not a class. The behavior changed in 2.6 and mmap.mmap is now a 
class.
The attached patch does two things:
- first it ensures with a finally that PE.close() is always called
- second it does systematically closing self.__data__ if and only if the mmap 
data where loaded from a file
In fact if I passed a data arg instead of a file, I would not want my data to 
be closed without me knowing it.
a bit hackish but it takes care of the various cases nicely imho.

Thanks for pefile :)

Hello,

I have attached file which get the following error:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "build/bdist.linux-i686/egg/pefile.py", line 1443, in __init__
  File "build/bdist.linux-i686/egg/pefile.py", line 1730, in __parse__
  File "build/bdist.linux-i686/egg/pefile.py", line 2002, in 
parse_data_directories
  File "build/bdist.linux-i686/egg/pefile.py", line 3006, in 
parse_import_directory
  File "build/bdist.linux-i686/egg/pefile.py", line 3136, in parse_imports
UnboundLocalError: local variable 'name_offset' referenced before 
assignment

Best regards,
Kirill Yakovenko

I originally posted this as a comment in the wiki, but was wondering if
this would be a better place.


The ability to match PE signatures is definitely a useful addition to the
great library that is pefile, however, I believe that UserDB.txt only
includes all external PEiD signatures and thus using this file would miss
out on the 600 sigs that PEiD detects internally. 

Am I missing something? Is there a comprehensive UserDB.txt file floating
around out there - or are these internal signatures held under lock and key?

Thanks.

What steps will reproduce the problem?
1. Load the file
2. alone PE.DIRECTORY_ENTRY_RESOURCE to find the string
3. change the sting from entry: *.directory.strings[0]
4. pe.write(filename)

What is the expected output? What do you see instead?
the resource should be changed according the write()'s __doc__
but nothing happends

What version of the product are you using? On what operating system?
the lastest version:pefile-1.2.10-107

Is pefile unable to do such a thing or I missed some key point?

[deleted issue]

Hey folks, 

I ran into some issues parsing the EAT of some files with pefile 1.2.10_89. 

$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pefile
>>> pe = pefile.PE("driver.804d7000.sys")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.6/dist-packages/pefile-1.2.10_89-py2.6.egg/pefile.py", line 1631, in __init__
    self.__parse__(name, data, fast_load)
  File "/usr/local/lib/python2.6/dist-packages/pefile-1.2.10_89-py2.6.egg/pefile.py", line 1921, in __parse__
    self.parse_data_directories()
  File "/usr/local/lib/python2.6/dist-packages/pefile-1.2.10_89-py2.6.egg/pefile.py", line 2234, in parse_data_directories
    value = entry[1](dir_entry.VirtualAddress, dir_entry.Size)
  File "/usr/local/lib/python2.6/dist-packages/pefile-1.2.10_89-py2.6.egg/pefile.py", line 3131, in parse_export_directory
    name_offset = self.get_offset_from_rva( symbol_name_address ),
  File "/usr/local/lib/python2.6/dist-packages/pefile-1.2.10_89-py2.6.egg/pefile.py", line 3618, in get_offset_from_rva
    raise PEFormatError, 'data at RVA can\'t be fetched. Corrupt header?'
pefile.PEFormatError: "data at RVA can't be fetched. Corrupt header?"

I can parse the EAT of the same file just fine with pefile 1.2.10-85.

$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pefile
>>> pe = pefile.PE("driver.804d7000.sys")
>>> for exp in pe.DIRECTORY_ENTRY_EXPORT.symbols:
...     print exp
... 
<pefile.ExportData instance at 0xb70cb1ec>
<pefile.ExportData instance at 0xb70cb20c>
<pefile.ExportData instance at 0xb70cb24c>
[...]

I attached the file for your testing. Its a dumped copy of the nt module from 
an XPSP3 memory dump. So since it was dumped from memory, it makes sense that 
some fields may be corrupt, but the EAT should be fine since 1.2.10-85 and 
other tools like CFF Explorer can parse it without issues. 

In the attached file exe aptly named file.exe (this is a cygwin-compiled 
version of the "file" command) the version info (as you would see these on 
windows file properties pop-up, version tab) are not to be seen in the dump at 
all.

The expected output would include:
Internal name, Language, Legal Trademarks, License, LibToolFileVersion, 
Original File Name, etc...

The same applies to the dll provided.

In contrast the version info are found allright on a more "modern" .net 
assembly dll.

Also rescle seesm to be able to this (from the doc, I could not try it) 
http://code.google.com/p/rescle/

What steps will reproduce the problem?
1. mmap not closed and file handle to the parsed file is retained.

What is the expected output? What do you see instead?

Not to leak file handles.  I solved it by have a close() api I would call that 
would close the handle if the binary was mmaped:

  def __init__(self, name=None, data=None, fast_load=None):

        [...]

        self.__mmapped = not data


    def close(self):
        if self.__mmapped:
            self.__data__.close()



See attached patch.

What version of the product are you using? On what operating system?

1.10.2-102 on windows 7.

Please provide any additional information below.

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

Hello guys,

There are memory leaks during processing some files.
I use the following simple script for test.

import pefile
p = pefile.PE('/home/kirill/14439bcfb9c3a6087d67ea6c18b9516a.exe', 
fast_load=True)
p.parse_data_directories([0,1])
del p

It takes about 350Mb on Ubuntu (32bit) and about 850Mb on Debian (64bit) and I 
can't erase the memory in the future.
I use '1.2.10-76'

Best regards,
Kirill Yakovenko

Are there any plans to port this to python 3?
There aren't any good python 3 pe parsers out there, so this will be a great 
help

What steps will reproduce the problem?
1. Load a 64-bit PE file 
2. Enumerate the import section
3. Address of each import will be off by 4 * thunk offset

Check out the 64-bit version of cmd.exe that comes with Windows 7 to see what I 
mean. The import address for GetProcAddress actually gets mapped to HeapAlloc 
without properly shifting the offset. :)

What is the expected output? What do you see instead?
The expected output is obviously the correct address. What we get is usually 
another function or an invalid offset, e.g. HeapAlloc instead of GetProcAddress.

What version of the product are you using? On what operating system?
1.2.10 r107 on Windows 7 64-bit using Python 2.7.1 64-bit.

Please provide any additional information below.
This is pretty easily fixed. In parse_imports, just add something like this:

        if self.PE_TYPE == OPTIONAL_HEADER_MAGIC_PE:
            ordinal_flag = IMAGE_ORDINAL_FLAG
            imp_offset = 4
        elif self.PE_TYPE == OPTIONAL_HEADER_MAGIC_PE_PLUS:
            ordinal_flag = IMAGE_ORDINAL_FLAG64
            imp_offset = 8

Then fix the assignment to imp_address:

        imp_address = first_thunk + self.OPTIONAL_HEADER.ImageBase + idx * imp_offset

All fixed! I've tested this against cmd.exe and some other 64-bit binaries I'm 
working on, so YMMV-- this will probably require more testing.

Attached is the patch to restore compatibility of pefile.py with python 2.2. It 
works for us on pyinstaller.

The patch is trivial. It only emulates type enumerate.

We used the latest release 1.2.10-63.

When changing the flags in pefile.SectionStructures structure 
(IMAGE_SCN_MEM_WRITE in my case) the information isn't written to the file.


Reproduce:
load exe
change IMAGE_SCN_MEM_WRITE flag in .text section (tho it shouldn't matter)
write file to disk
check flags -> same as before

Would be great if one could get all the information that PE.dump_info() produce 
but returned as a Python dict.

1.
pefile crash when we use pefile.PE(filename)
because that time, the memory only 2G total, but the file size if large than 2G 
(some is large 4G)
so, the pefile is crash

2.
if you want to delete the file (os.remove(filename)), it crash again !
the file will not be deleted until the whole python script is terminated.
because the pefile crash in line 1554, and then, the file is opened, and the 
file handler is not closed, that is, the file is used now......


reason:
pefile line 1554:
self.__data__ = fd.read()

solutions
1:
it would be in try... except...

2:
check memory size which is will be used is larger than the file size

3:
file map (mmap in linux)

What steps will reproduce the problem?
1. 'stringfileinfo_struct' is None sometimes. 
This happens for some PE files with no version information, but run just
fine. (other PE viewers work fine too)  

What is the expected output? What do you see instead?
We would expect pefile to load the file normally. But we see a traceback.

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
line 1341, in __init__
line 1630, in __parse__
line 1902, in parse_data_directories
line 2287, in parse_resources_directory
line 2491, in parse_version_information
AttributeError: 'NoneType' object has no attribute 'startswith'  

What version of the product are you using? On what operating system?
__revision__ = "$LastChangedRevision: 68 $"
OSX 10.5.8 , Python 2.5

Please provide any additional information below.
add an extra check for NoneType on stringfileinfo_string before using it. 
2 places - line nos 2491,2614 on revision 68. 

temporary fix : line 2491 on revision 68:
if stringfileinfo_string and
stringfileinfo_string.startswith(u'StringFileInfo'):

line 2614 on revision 68:
elif stringfileinfo_string and stringfileinfo_string.startswith(
u'VarFileInfo' ):

While parsing the attached file pefile is using over 4gb of memory and running 
out of memory on my system
Code example:

import pefile
fname = "huxley.dll"
pe=pefile.PE(fname)


Running it on windows.

It's 12mb compressed so here is a place to download it:
https://dl.dropboxusercontent.com/u/44015435/huxley.7z

What steps will reproduce the problem?
1. pip install --upgrade -v -v -v pefile

Installed version (1.2.10-114) is most up-to-date (past versions: 1.2.10-114, 
1.2.10-63, 1.2.10-60, 1.2.10-56, 1.2.9.1, 1.2.9)

What is the expected output? What do you see instead?
I expected the newest version of pefile to be available through pip: 
pefile-1.2.10-139

What version of the product are you using? On what operating system?
Linux, Python 2.7

Please provide any additional information below.

What steps will reproduce the problem?
1. Parse a pe file
   pe = pefile.PE(path)
2. Edit a version string value:
   pe.FileInfo[0].StringTable[0].entries['FileVersion'] = '2, 0, 0, 0'
3. Write out a file:
   pe.write(filename='temp.exe')

What is the expected output? What do you see instead?

Looking at the properties of the exe in Windows Explorer, I see that the
FileVersion is unchanged.  I believe this is because the write() method
just serializes structures and the FileInfo dictionary is parsed out of
structures.

What version of the product are you using? On what operating system?

pefile 1.2.8 under Python 2.5 on Windows XP SP2

Please provide any additional information below.

In general, a pe.setVersion('w.x.y.z') method would be very useful.  I've
implemented the VS_FIXEDFILEINFO part of it, but am stuck on the FileInfo
part.  I could of course edit the StringFileInfo structures directly, but
that would require a lot of code duplication from parse_version_information()

My goal is to replace http://www.elphin.com/products/stampver.html with a
simpler tool that supports 64-bit PE

What steps will reproduce the problem?
1. pe=pefile.PE(myfile)
2. pe.FileInfo[0].StringTable[0].entries['FileVersion']
3. From the resulting output increase the value in FileVersion
e.g. if output was u'1.0.0.1' increase to u'1.0.0.100'
4. pe.write(myfile)
5. del pe
6. repopen myfile
7. pe.FileInfo[0].StringTable[0].entries

What is the expected output? 
The FileVersion is updated to u'1.0.0.100' and the other values (Company name 
etc) remain the same

What do you see instead?
The StringTable is corrupted

Extra Info.
If you dont increase the size of FileVersion during the update then the write 
is successful

What version of the product are you using?
pefile.py -> pefile.py-102

On what operating system?
Linux




Please provide any additional information below.

For the Visual Basic programs where the VarFileInfo is first and then
StringFileInfo, the VarFileInfo is incompletely parsed (it has no Var member). 

What steps will reproduce the problem?
1. pe.dump_info() for a MS Visual Basic program with version information
(imports MSVBVM60.dll)
2. The Var info is not printed (no Translation section, although it is
present in the file)

What is the expected output? What do you see instead?

[VarFileInfo]
Length:                        0x44      
ValueLength:                   0x0       
Type:                          0x0       

[StringFileInfo]
Length:                        0x12C     
ValueLength:                   0x0       
Type:                          0x1       

  [StringTable]
  Length:                        0x108     
  ValueLength:                   0x0       
  Type:                          0x1       
  LangID: 041004B0

    ProductVersion: 1.00
    InternalName: test
    FileVersion: 1.00
    OriginalFilename: test
    ProductName: test

There is no [Var] section but it should have existed.

What version of the product are you using? On what operating system?

Python 2.6 (Windows) ; pefile pefile-1.2.9.10-63

What steps will reproduce the problem?

1. Create PE-file with one of section having zero SizeOfRawData field and 
non-zero Misc.VirtualSize field. Or simply try to get any file compiled with 
Delphi (the '.tls' secion in these files fits to such requirement).

2. Load pe-file maked on step (1) and execute this code: 

   dword = pe.get_dword_at_rva(rva)
   print(dword)

   where rva is a beginning of the section that having zero SizeOfRawData and non-zero Misc.VirtualSize.

What is the expected output? What do you see instead?
Expected output is 0, but I see None.

What version of the product are you using? On what operating system?
pefile v1.2.10-123 on Windows 7 Professional x64 SP1.


Please provide any additional information below.
In attach the script and .exe showing that problem.

P.S. Sorry for bad English.

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

I am trying to change the data in sections but does not seem to be working.
If I do:
pe.sections[3].data = "any thing"

#this willl print "any thing"
#print pe.sections[3].data

but when I do the write:
pe.write(filename=newfile.exe)

It does not seem to write the change and both the old file and the new one have 
the same content. Is there any idea of why this is happening?

Thanks

What steps will reproduce the problem?
1. Call set_bytes_at_rva with an invalid RVA

What is the expected output? What do you see instead?
It would expect to see an legitimate exception thrown. Instead, the code 
executes "raise False" which throws a TypeError because raise takes an object 
that inherits from BasicException.

What version of the product are you using? On what operating system?
1.2.10-102 on windows and linux

i'm trying to use pefile to script check a list of binaries and determine which 
are packed.
Unfortunately, i have some problem withe some files that provoke a crash of my 
script and 
pefile.

here is my script : 

import peutils
import pefile
import glob

sig = peutils.SignatureDatabase('peid_userdb.txt')
dir = glob.glob('path/to/bin/directory/*')
for file in dir:
   ispe = "Yes"
   try:
        pe = pefile.PE(file)
   except pefile.PEFormatError:
        print "Not a PE"
        ispe = "No"
   if ispe != "No"
       mathes = sig.math_all(pe, ep_only = True)
       print matches


for most of my file i get "Not a PE" or the packer listed. But i have some 
files that crash the script 
before the except and i still get this error : 
""Traceback (most recent call last):
  File "./script_peid.py", line 19, in <module>
    pe = pefile.PE(file)
  File "/pefile-1.2.10-56/pefile.py", line 1302, in __init__
    self.__parse__(name, data, fast_load)
  File "/pefile-1.2.10-56/pefile.py", line 1591, in __parse__
    self.parse_data_directories()
  File "/pefile-1.2.10-56/pefile.py", line 1858, in parse_data_directories
    value = entry[1](dir_entry.VirtualAddress, dir_entry.Size)
  File "/pefile-1.2.10-56/pefile.py", line 2801, in parse_import_directory
    import_desc.ForwarderChain)
  File "/pefile-1.2.10-56/pefile.py", line 2895, in parse_imports
    if iat and ilt and ilt[idx].AddressOfData != iat[idx].AddressOfData:
IndexError: list index out of range
""

i don't really understand what happening, so i someone can help me ...

i'm running un Ubuntu 8.04 with Python 2.5.2
i also try the new version of pefile-1.2.10-60 but still have the same error.

I leave here a example of file that crash my script. According to Kaspersky, it 
is packed with UPX

What steps will reproduce the problem?
1. a = pefile.PE('DHTMLED.OCX')
2. a.dump_info()

What is the expected output? What do you see instead?
As  FileVersion we expect 6.1.0.9212, i got instead 6.01.9212

What version of the product are you using? On what operating system?
1.2.8 on Ubuntu 7.04

Please provide any additional information below.
I attach the pe file to reproduce bug.

1. Instantiate a PE object on an exe file known to have version info, call
it "pe" for convenience
2. do a "dir(pe.FileInfo[0])" or "dir(pe.FileInfo[1])"

There should be a "StringTable" or "Var" attribute listed, depending on
whether the Key is "StringFileInfo" or "VarFileInfo".

Neither attribute appears to exist.

This was in an attempt to obtain the file version info, which is still
available through the "pe.FIXEDFILEINFO" attribute. 

The issue was encountered using pefile 1.2.10-60 with Python 2.5.1 on
Windows XP.

Please provide any additional information below.

What steps will reproduce the problem?
1. PE library catches almost all memory and sometimes it leads to program
crash.
2. This happens for some PE files, one of them I have attached. WARNING!
This file is malware.

What is the expected output? What do you see instead?
No output.

What version of the product are you using? On what operating system?
'1.2.10-63'

Hello!
I have tested you library on a large number of files. In some of them I had
the following exception


Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/lib/python2.6/site-packages/pefile-1.2.10_63-py2.6.egg/pefile.py",
line 1443, in __init__
  File "/lib/python2.6/site-packages/pefile-1.2.10_63-py2.6.egg/pefile.py",
line 1730, in __parse__
  File "/lib/python2.6/site-packages/pefile-1.2.10_63-py2.6.egg/pefile.py",
line 2002, in parse_data_directories
  File "/lib/python2.6/site-packages/pefile-1.2.10_63-py2.6.egg/pefile.py",
line 2400, in parse_resources_directory
  File "/lib/python2.6/site-packages/pefile-1.2.10_63-py2.6.egg/pefile.py",
line 2604, in parse_version_information
AttributeError: 'NoneType' object has no attribute 'startswith'

I have attached sample file. 
WARNING! This file is malware.

What steps will reproduce the problem?
1. just read the Safari.dll file under Ubuntu:
pe = pefile.PE(pe_file_path, fast_load=False)
2. then read the import table information:
if hasattr(pe, 'DIRECTORY_ENTRY_IMPORT'):
        for entry in pe.DIRECTORY_ENTRY_IMPORT:
            print entry.dll
            for imp in entry.imports:
                print '\t', hex(imp.address), imp.name, imp.ordinal, entry.dll
3. I wish to get all the symbols, its address and its ordinal.

What is the expected output? What do you see instead?
Wrong output:
WS2_32.dll
    0x1052b548 None 8 WS2_32.dll
    0x1052b54c None 9 WS2_32.dll
    0x1052b550 getaddrinfo None WS2_32.dll
    0x1052b554 None 57 WS2_32.dll
    0x1052b558 None 14 WS2_32.dll
    0x1052b55c freeaddrinfo None WS2_32.dll
    0x1052b560 None 15 WS2_32.dll
Expected output:
The symbol name should be not none, since I can read them via IDAPro. 
And I found that if there is no ordinal associated with the symbols, then 
pefile can print it right, but for the symbols with ordinal, the pefile just 
cannot find its name. This is a little wired.

What version of the product are you using? On what operating system?
pefile version: pefile-1.2.10-114 and pefile-1.2.10-121
OS:Ubuntu 12.04

Please provide any additional information below.
None.

What steps will reproduce the problem?

1. Build a list of 100+ files
2. Put them all to process by verifying if they are a PE file or not (using 
pefile.PE class)
3. Try to change the extensions of all those files right after verify if is is 
a PE file. In my case, the file will be locked.

What is the expected output? What do you see instead?

Expected output: File extension changed sucessfully.
Instead, I get a locked file and I'm not able to make any modification in the 
file.


What version of the product are you using? On what operating system?

Version: pefile-1.2.10-139.zip
OS: Windows
Python 2.6

Please provide any additional information below.

After a few moment, the file is able to be modified again.
Im running with exactly 246 files and in a certain step I verify if all of them 
are a PE file.
Something like this:

def IsExecutableFile( SrcPath ):   
    try:
        pefile.PE( SrcPath, fast_load = True )
        return True
    except:
        return False

After verifying all those files, I try to change the file extension and I get 
that error

ERROR_SHARING_VIOLATION
32 (0x20)
The process cannot access the file because it is being used by another process.

Thanks
Filipe

in pefile, we get fixedfileinfo_offset like this.
        fixedfileinfo_offset = self.dword_align(
            versioninfo_struct.sizeof() + 2 * (len(versioninfo_string) + 
1),
            version_struct.OffsetToData).

But i think this may be wrong, fixedfileinfo_offset is the offset to the 
beginning of VS_VERSIONINFO and round to a 32-bit boundary. 

however, pefile project calculates the offset on this way:
version_struct.OffsetToData plus versioninfo_struct.sizeof() + 2 * (len
(versioninfo_string) + 1) and round to a 32-bit boundary then substract 
version_struct.OffsetToData. under some conditions, this will get a wrong 
result.

VS_FIXEDFILEINFO dwSignature doesnt equals to 0xFEEF04BD no longer.

in the meantime, i submit a file to illustrate this bug.
If we use pefile to get VS_VERSIONINFO ,the result is wrong.

Is it possible to unpack PE-files packed with Upack with this tool?

What steps will reproduce the problem?
1. Create a folder called crap
2. Extract corrupted file into the crap folder
3. Run py.scan.py (attached)

What is the expected output? What do you see instead?
I expect file to be listed as corrupted, but instead it is stored for analysis

What version of the product are you using? On what operating system?
pefile-1.2.10-139
Python 2.7.6

File is definatelly corrupted
Could you please check if something can be done to detect that ?

Thanks
Momchil

pefile is very powerful, the header info, version info, but where is
"DigitalSign"?

Good morning Mr Carrera.

I've used pefile for several weeks, and I am surprised
to discover that this useful tool is not able to get
the names of functions imported by their ordinal. Then
I decided to write a few lines of code, and to suggest
you to check it and add it to the existing version.
I hope you will have time to take a look at it, I would
be very pleased to use this new feature in the next
release (considering that I need it for my work). :)

Thank you very much.

Mr Romain CARRÉ
Computer Scientist in France
[email protected]

PS : attached resource :
- a shell script to patch the existing version of pefile.py
- the diff file containing information to patch pefile.py
- the html version of the diff file, for you to understand easier

You can also find all that files at : http://cyberax51.free.fr/pefile/

def adjust_VirtualAddress( val, alignment ):
    # Alignment should, at least, be page-sized
    if alignment < 0x1000:
        alignment = 0x1000     # It's a BUG!
    if val % alignment:
        return alignment * ( val / alignment )
    return val

For example, try to parse ntoskrnl.exe ( Windows kernel ) - It has aligment 128 
bytes for sections.

I has commented this lines: 
#    if alignment < 0x1000:
#        alignment = 0x1000   
for getting list of import for ntoskrnl.exe

I've found some broken link on your Project Home:
http://code.google.com/p/pefile.
This is links to pyemu project: 
pyemu: download, whitepaper.

https://www.openrce.org/repositories/browse/codypierce
http://164.106.251.250/docs/netsec/bh2007/Pierce/Whitepaper/bh-usa-07-pierce-WP.
pdf


What steps will reproduce the problem?
1. Go to page http://code.google.com/p/pefile in browser
2. Click to link `pyemu: download` or `pyemu: ... whitepaper`

Reproduction steps ("d:\temp" is non-empty directory):
import pefile
pe = pefile.PE(r"d:\temp")

Result:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "~\pefile.py", line 1667, in __init__
    self.__parse__(name, data, fast_load)
  File "~\pefile.py", line 1718, in __parse__
    fd.close()
UnboundLocalError: local variable 'fd' referenced before assignment

Environment:
 * pefile 1.2.10-114
 * Python 2.7.1 (r271:86832, Nov 27 2010, 17:19:03) [MSC v.1500 64 bit (AMD64)] on win32
 * Win2k8 R2 SP1