Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Read PE info of file thru SMB #94

Closed
t33m opened this issue Oct 7, 2015 · 11 comments
Closed

Read PE info of file thru SMB #94

t33m opened this issue Oct 7, 2015 · 11 comments

Comments

@t33m
Copy link

t33m commented Oct 7, 2015

Hi!

Is it possible using impacket to get PE info (example: version of dll) of a file on a remote Windows share?
If no, may be you can implement this using pefile (https://github.com/erocarrera/pefile)?

Kind regards,
Timur

@asolino
Copy link
Collaborator

asolino commented Oct 9, 2015

I'm assuming you'd like that functionality w/o downloading the file (something you could do with the libraries' present methods).

@t33m
Copy link
Author

t33m commented Oct 10, 2015

Exactly, I know that is possible using pysmb and pefile libs, but this requires transfering file.

@byt3bl33d3r
Copy link
Contributor

@tsmall888 this is pretty trivially done, take a look at the RemoteFIle class here https://github.com/CoreSecurity/impacket/blob/master/examples/secretsdump.py#L228, you would just have to read blocks from the remote file and parse them using pefile

@asolino
Copy link
Collaborator

asolino commented Oct 11, 2015

@byt3bl33d3r I thought about RemoteFile as well actually ;)

Take a look at this code:
https://gist.github.com/asolino/684da226435f2844bc58

I did some tests but results are not that good. First of all, let's look at the class PE constructor:

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

So you either pass a filename (name parameter) or you pass a buffer with the file's data (data parameter).

If you pass a filename, that filename is mmaped and then accessed as a bytearray, the same way as the buffer parameter. For this reason, the RemoteFile class as it is in secretsdump  is not enough. So what I did is to extend that class so you can access the file's contents slicing into its contents:

class RemoteFile:
[...]
    def __len__(self):
        # Get's the file len
        if self.__fileLen is None:
            self.__fileLen = self.__smbConnection.queryInfo(self.__tid, self.__fid)['EndOfFile']

        return self.__fileLen

    def __getitem__(self, index):
        # Get's portions of file
        # Uncomment this if you want to debug what's going on
        #print index
        if isinstance(index, int):
            # Asking for a single byte, odd
            offset = index
            bytesToRead = 1
        elif isinstance(index, slice):
            # Asking many byte, calculating and returning
            offset = index.start
            if index.stop == sys.maxint:
                # We have to read till the end of file
                bytesToRead = self.__len__()
            else:
                bytesToRead = index.stop - index.start


        return self.__smbConnection.readFile(self.__tid, self.__fid, offset=offset, bytesToRead=bytesToRead)
[...]

This allows to do stuff like this:

# Print 4 bytes from file starting at position 4
print remoteFile[4:8]
# Give me the last 2 bytes
print remoteFile[-2:]

which is kind of neat ;)

So once I did that I created a PE class sending this new RemoteFile class as the PE's data parameter and, it actually worked ;).

The problem is due to the way the pefile library is developed, this approach is not efficient, since the library accesses same portions of the file several times and sometimes it asks for almost the whole file (when it does look for strings, for example https://github.com/erocarrera/pefile/blob/master/pefile.py#L2544).

If you want to see it in action, uncomment the print index line so you get all the requests from the library. I think the original file is downloaded several times actually ;). Seems like it is way more efficient to download the whole file once and then pass that file to this library :(

Ideas are welcomed (maybe caching the data being read?), but I think this is it. It was fun to play with it tho ;)

@t33m
Copy link
Author

t33m commented Oct 30, 2015

@asolino great solution!

I had some troubles with pysmb lib. Now I will test your code.

@t33m
Copy link
Author

t33m commented Nov 2, 2015

@asolino, sometimes during long smb connection with retrieving info (remoteFile.open(FILE_READ_DATA)) of many system .dll files I get following error:

[Errno 104] Connection reset by peer

and these messages for all next files

[Errno 32] Broken pipe

Can you check this?

@t33m t33m closed this as completed Nov 2, 2015
@t33m t33m reopened this Nov 2, 2015
@asolino
Copy link
Collaborator

asolino commented Nov 2, 2015

Do you have an example I could reproduce? Both code and target system, and target file.

thanks!

@t33m
Copy link
Author

t33m commented Nov 3, 2015

@asolino yes, something like this https://github.com/tsmall888/PEoverSMB/tree/master.
As a target host I use Windows Server 2012 R2 Standard Evaluation [Version 6.3.9600].

But not always this errors is reproduced.

@asolino
Copy link
Collaborator

asolino commented Nov 3, 2015

I found the problem I think:

Change this line for :

    if bytesToRead > 0:
        return self.__smbConnection.readFile(self.__tid, self.__fid, offset=offset, bytesToRead=bytesToRead)
    else:
        return ''

Also do a git pull 'cause I fixed some issues with SMBConnection.readFile() that are only present with the RemoteFile class you're using.

Give it a try and let me know.

I still think this is not a good approach since it reads the same file several times ;).

asolino added a commit that referenced this issue Nov 3, 2015
…tesToRead parameter

* Before, if `bytesToRead` was greater than the protocol's `MaxReadSize` buffer
(dependant on the server's configuration), it would only read that amount of bytes.
Now it will call `read_andx`() many times until it reached EOF or read all the bytes asked.
* See #94
@t33m
Copy link
Author

t33m commented Jan 12, 2016

@asolino, looks like everything works fine.

@t33m t33m closed this as completed Jan 12, 2016
@asolino
Copy link
Collaborator

asolino commented Jan 12, 2016

thanks for checking this @tsmall888. cheers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants