Something new I’m going to try on both of my blogs. At the end of each week I will do a weekly roundup of links to posts and articles I found interesting.
Hack Yourself- How much sleep do you need?
Sans – Obfuscated Javascript Redux
50+ Personal Development sites you’ve never even heard of
The Black Market Code Industry
What I’ve been Doing on My Summer Vacation
Ive been taking it easy this week, I’ve been hit with some type of bug and can’t seem to get rid of it. I’ve also been working on expanding business so I haven’t had much attention on the blog.. Sorries!
Over at EH.net there was some chatter about a webcast presented by Core, featuring Ed skoudous. Ok, cool I read one of his books, but the selling point of the webcast was
“Do you know how to create an automated, iterative reverse DNS lookup tool in a
single Windows command? How about a ping sweeper in a single Windows command?
A password guesser?”
For the record, I didn’t attent because I read that and was like wtf, I hope that isnt going to be the focus of the webcast. After all, I feel as though that block should be common knowledge. Then I started reading the eh.net forum and realized not many people have the command line f00. So, I want everyone to purchase this book:
http://search.barnesandnoble.com/Microsoft-Windows-Command-Line- Administrators-Pocket-Consultant/William-R-Stanek/e/9780735620384/? itm=1
this book will provide you so much more info than any Administering Windows Server book will ever give you. Remember, when you are popping shells you don’t have a gui… Unless you use the VNC payload, or crakc a password and Term serv in… But wheres the fun in any of that?
So let’s get started shall we? The first topic is reverse dns, which chrisg answered no and yes to in the forum over at eh.net. He knows how in bash, but not in windows…. Ok, lets see
———————————————————————
nope but i can do it in bash…
| Code: |
|
——————————————————————–
First, I wouldnt even bother with this.
| Code: |
|
That’s besides the point, we are talking about windows!
| Code: |
|
NEXT!!!!!!!
ping sweep
one of two ways
with a target list:
generate a target list:
| Code: |
|
without target list :
| Code: |
|
what about a larger network?
| Code: |
|
next up is a password guesser
this one is easy!
| Code: |
|
There’s your Windows cmd line f00 for the day
After reading the last post we have some general idea’s of what we are looking for, let’s look at using dumpbin and pefile to analyze a file and see if we can determine the presence of a packer.
For the sake of the post/ learning I have copied notepad.exe from c:\windows\system32 to a local working directory. I have downloaded the latest copy of UPX and packed the notepad file using the command line:
upx -9 -o noteupx.exe notepad.exe
Doing this allows us to compare and contrast differences as we look at the packed file. This will enhance your learning experience. Afterall, if you don’t know what the data should look like, how will you be able to tell if something is not right.
Dumpbin comes with Microsoft Visual c++. The utility provides information about the format and symbols provided in an executable, library or DLL file. A full description of dumpbin can be found here. http://support.microsoft.com/kb/177429.
Using the /imports option we can dump a list of imports for our file.
We see that our file has hardly any imports. Looking at the original file, we dump the imports and we see quite a few imports in the file. Going back to the last blog post, We know a lack of imports is indicative of a packer.
Utilizing strings from sysinternals, or on a Linux machine we find that the original PE file has quite a few strings in it. When we dump the strings on the packed file however, we find what appears to be mostly garbage data. Strings can be used simply by typing the following on the windows or Linux command line.
strings
Next we want to take a look at the sections. We know what sections should be there, but we don’t know if they will be. After all if the PE is Packed, there is a chance the packer changed the section names. Using Dumpbin we can obtain a list of the sections names. On the command line we simply type
dumpbin /HEADERS noteupx.exe
We recieve some output as follows:
We see that within out headers we have a few sections with weird names. First section that comes to our attention is UPX0, The Second is UPX1. The .RSRC section is our Resources Section and we would expect that to be there. If you are following along with the notes on PE format, you will note that the UPX sections are obviously different from what we would expect. A little googling will reveal that UPX (although we already knew that) is the name of a packer that is very common.
With the information we just obtained we could easily go on to Tuts4you.com and grab a tutorial on unpacking UPX. Of course, for UPX there are some automated utilities that will help in unpacking the PE for you.
Moving on, let’s look at pefile. Pefile is a “multiplatorm python module to read and work with PE files….” pefile is hosted on google code and can be located at http://code.google.com/p/pefile/. To install pefile simply download the code, browse to the directory on the windows command line and execute the setup.py file by running python setup.py install. From here on out we will be writing some code in python to utilize pefile. All our python scripts will start with
import pefile
Lets use pefile to look at our sections:
import pefile
import sys
file = pefile.PE(sys.argv[1])
for section in file.sections:
print(section.Name, hex(section.VirtualAddress),
hex(section.Misc_VirtualSize), section.SizeOfRawData)
When run against each of our PE files, we recieve a nice dump of the sections along with their virtual addresses, sizes and the size of the raw data. From the screen shot below, you can see the differences not only in the section names, but also the sizes.
Next we will use pefile to take a look at the imports of the PE. Like the previous example this one is pretty simple to code up and works very well.
import pefile
import sys
file = pefile.PE(sys.argv[1])
for entry in file.DIRECTORY_ENTRY_IMPORT: print entry.dll for imp in entry.imports: print 't', hex(imp.address), imp.name
running our code against both executables again reveals what we figured it would. The packed PE has very few imports, the unpacked PE on the other hand scrolled off the screen with all the imports.
This post was a rough introduction to Pefile and dumpbin. You can do a lot of cool stuff with Pefile and I recommend you go check out the wiki and play around with it a bit. http://code.google.com/p/pefile/w/list
Round 2 of Notes on PE Format
http://msdn.microsoft.com/msdnmag/issues/02/03/PE2/
Portable Executable Sections
EXPORTS SECTION:
When an executable exports data it makes functions and variables available to others.
-Exported functions and variables are known as symbols.
-Each symbol has an ordinal Number and an ASCII name.
-Lookups by ordinals are faster, and the ASCII names are just for convenience.
IMAGE_EXPORT_DIRECTORY
Exports directory points to 3 arrays and a table of ASCII strings.
-Only required array is the EAT (export Address Table), which is an array of function pointers that contain the address of an exported function.
-When calling a function the ordinal value of the function is looked up.
-Using the ordinal value as an index into the export address table it resolved the relative virtual address (RVA) of the function. Adding the RVA to the load address of the DLL yields the actual address of the function.
IMPORTS SECTION:
IMAGE_IMPORT_DESCRIPTOR – Anchor of imports section
Data directory entry for imports points to an array of these structures.
Each Import has one descriptor structure.
Each descriptor points to two identical arrays
-Import Address Table(IAT)
-Import Name Table (INT)
-Both arrays have elements of type IMAGE_THUNK_DATA.
-Each element corresponds to one imported function from the executable.
-In the executable the thunk_data structure contains either an ordinal value or RVA to an IMAGE_IMPORT_BY_NAME structure.
IMAGE_IMPORT_BY_NAME structure is just a word, followed by a string naming the imported API
-The word value serves as a hint to the loader for what the ordinal might be.
When the windows Loader brings in the executable it overwrites the IAT with the actual address of the imported function.
The INT is identical to the IAT but the key difference is the INT is not overwritten by the loader. Why then have two identical arrays? So the original information can be retrieved later on.
A few Notes on the MSDN Article “An In-depth look into the win32 Portable Executable Format“, which is considered in the RE Community one of the best articles to day on the PE Format.
Data structures on disk are the same in memory
The Windows Loader decides what sections to map into memory
Higher Offsets in the file coorespond to higher offsets in memory
However, offsets on disk image may differ from memory image
When a Portable Executable is loaded into memory it is known as a module.
A Module represents all code, data and resources that is needed by a process.
Api functions for Modules : IMAGEHLP.DLL
To avoid hardcoding memory addresses in Portable Executables and RVA is used
A Relative Virtual Address is an offset in memory relative to where the portable executable was loaded.
When you use code or data from another dll you are importing it.
The windows Loader takes care of loading all imported functions (via populating the IAT)
Within a portable executable file there is an array of data structures one for each imported DLL.
Each data structure gives the name of the imported dll and points to an array of function pointers.
This array of function pointers is what is known as the Import Address table (IAT)
Notes on the IAT:
The Import Address Table is a table of external functions that an application wants to use.
As an example the function Sleep() in found in kernel32.dll
The Import Address Table contains the location in memory of an imported Function
The Application uses the IAT to find other dll’s in memory.
When code is compiled, the IAT contains NULL memory pointers for each function. Then the executable is started the windows loader finds the correct address and overwrites the NULL Pointers.