I am looking for a CLI tool that will list all of the DLL files referenced in the Import section of a Windows executable file. Back in the day, Windows shipped with a GUI tool called QuickView that provided this information. However, I need a CLI-based application that will provide this information and preferrably a free / open-source application if possible.
IIRC, dumpbin tool from Microsoft could help. It is shipped with Microsoft Visual C++. The details are in MSDN.
Try dumpbin /IMPORTS <pe_file_to_analyze>.
I guess, the tool is not open source, however. But if it is included in Microsoft Visual C++ Express (not sure about that), you can get it for free.
After asking this question and doing some searching, I concluded that the easiest way to get a program like this was to write one. So I did.
The end result was a program named PEImportList (released under the MIT license). It does nothing more than open a PE executable (x86 only at the moment) and read the import data, printing a list of DLL names to the console.
The code will run on any platform and can be found in this single file here:
https://gist.github.com/nathan-osman/5b25da083ad5c6557e89
Simply invoke the program by passing the executable as a parameter. If you want only the DLL names printed, then stick the -l option in front of the executable parameter.
Related
I'm looking to convert a PS1 file to an .exe file so I can roll it out to less technical users.
I believe it'll be much easier for them if all they need to do is double-click it vs explaining how to run through PowerShell.
How can I achieve this?
Use PS2EXE instead of this online tool that forces you to upload your script and creates a security breach if you have confidential information inside your script.
There is a GUI mode available; to learn more, see the GitHub repository.
You have a few paid and unpaid solutions. I agree with last answer, do not use online tools unless you are sure they are not keeping your code and you trust them.
There are two free ones that come to mind:
PS2EXE-GUI
PS1 To EXE by F2KO (Make sure t it is the local install command line interface, not the web one)
The Paid ones are:
PowerShell Studio
ISE Steroids 2.0 Enterprise
Noted: I think the free ones should be fine for most uses. I do like PowerShell Studio though.
An update to PS2EXE tool (all versions are open-source):
The original script comes from Ingo Karstein, but the development seems to have halted in 2017. You can find his blog here, and his contribution on Microsoft Technet's forums here.
Markus Scholtes has continued the script's development, adding some useful features. You can find his post on Microsoft Technet here, and github repository here.
Powershelling's answer point you to a fork of Markus' project by Stuart Dootson (here and here), which is less maintained. The obvious difference would be the "Added support for scripts that require elevation. This inserts a suitable manifest into the executable produced by the tool. that .exe files built with his version of the script require elevation".
I'd recommend checking out Markus Scholtes' version, but beware (!) (README.md on 3rd Nov 2020):
Attention: Incorrect virus detection of PS2EXE
Some stupid idiot seems to have abused PS2EXE to compile his computer virus script. As a result, a rapidly growing number of virus scanners recognize programs created with PS2EXE as malicious programs and delete them.
There is only one hope to save the PS2EXE project: Please send your (harmless) programs created with PS2EXE via the web forms from the virus scanners' vendors for reporting false positives (I've already done it with some of them, please use only the false positive page)!
If this is not successful, then I will have to quit PS2EXE as nobody can use it anymore.
Thank you for your support
The official way to do this appears to be to use WinDbg. That should be able to give me the information I need, very easily. However, I don't have WinDbg, and my attempts to install it have failed for no known reason. So, is there another way to find my bad line of code? Or, is there a way other than using Microsoft's Windows SDK installer to get WinDbg?
My DLL is an unmanaged DLL (no CLR) built using Visual Studio 2012.
I need to know can I use PowerShell to burn ISO file on windows XP without any other addition software like MagicISO or others? I mean .NET framework is on top of Windows XP.
So if it is possible, then I need to know which commands allows me to do such a job?
Especially I need a command, not a whole script.
It appears this link: Burning and Erasing CD/DVD/Blu-ray Media with C# and IMAPI2 has sample code. It also has a link to the Update required to use this API on XP. Overall, it appears that a SHIM is required and it's all done using a an interop library whose source is included at the referenced link.
first things first:
It was working when I used it last time (which is about more than a month ago).
The Problem is, that no command which is from an extension is working, it seems like no extension is loaded.
Only the default commands do work (like version etc.)
The output of the command "Version" is:
Extension DLL chain:
dbghelp: image 6.2.9200.16384, API 6.1.6, built Sat Nov 20 12:57:48 2010
[path: C:\Windows\system32\dbghelp.dll]
ext: (Not loaded)
wow64exts: (Not loaded)
exts: (Not loaded)
uext: (Not loaded)
ntsdexts: (Not loaded)
It says that no extensions were loaded, but the folder winext does exist in my system32 folder (C:\Windows\System32\winext), where the extensions are located in (as far as I know).
Commands like !gle do not work :/
I really have no Idea what I can do, please help me :)
Does the DBGTOOLS definition in your IDA.CFG point to the x86 WinDBG installation directory?
The following comes from IDA Pro's help:
Windbg debugger plugin has the following configuration options:
- The Debugging Tools folder: This should be configured to point to the same
folder where Microsoft Debugging Tools are installed. The plugin will try to
guess where the tools are, but if it fails, a manual intervention will be
required. If this option is not set, then the plugin will try to use dbgeng.dll
from MS Windows system folder, while normal debug operations will work,
extensions will not.
This information indicates that if IDA Pro is using dbgeng.dll from the Windows system folder, the extensions command (like !gle) will not work.
If you have already setup the DBGTOOLS to point to your WinDbg (x86 version) directory correctly in your /cfg/ida.cfg but IDA Pro is still using dbgeng.dll from your Windows system folder, then probably your IDA context is not configured to analyze the IBM PC processor. This may happen when you launch IDA Pro and click the 'Go' button directly to work on your own and start the WinDbg debugger.
Check the DBGTOOLS in the ida.cfg, you will find it is wrapped by #ifdef __PC__ #endif.
The __PC__ will only gets defined by IDA Pro if you are analyzing a Windows EXE file for example. Give a try to launch the WinDbg from the IDA Pro menu after you have successfully disassembled a Windows EXE file and see what happens.
If this still hasn't been answered your problem is most likely that you didn't uncomment the DBG Tools line in the ida.cfg file.
I just fixed this myself. hope this helps.
Also the other guys are correct as well. make sure you are escaping with double back slashes "\\" and make sure you pointing to the (x86) directory.
I want to run some system commands (to fix things) before running an executable. I have a reasonably locked down (work) Windows XP system and so can't change what a shortcut points to. For my users' convenience, I must keep the same shortcut. However, I am able to swap out the .exe (renaming) and potentially replace it with another .exe (of the same name) which runs my system commands and then runs the original .exe.
What would be the easiest and quickest language/compiler to do this in? Previously, I've done this sort of thing in C (and tried it today in Python using py2exe without much success). Preferably free solutions.
Visual C# 2008 Express Edition is
free
comes with a compiler
outputs exes
C# is a good choice if you have C
experience
.net currently is the "canonical"
Windows platform