Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I have a DLL file and I want to execute it on Windows. I obtained this DLL file from a challenge site which alleges the DLL should be executed independently.
To run the functions in a DLL, first find out what those functions are using any PE (Portable Executable) analysis program (e.g. Dependency Walker).
Then use RUNDLL32.EXE with this syntax:
RUNDLL32.EXE <dllname>,<entrypoint> <optional arguments>
dllname is the path and name of your dll file, entrypoint is the function name, and optional arguments are the function arguments
You can execute a function defined in a DLL file by using the rundll command. You can explore the functions available by using Dependency Walker.
While many people have pointed out that you can't execute dlls directly and should use rundll32.exe to execute exported functions instead, here is a screenshot of an actual dll file running just like an executable:
While you cannot run dll files directly, I suspect it is possible to run them from another process using a WinAPI function CreateProcess:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx
DLLs are shared libraries which are used by other windows programs while EXEs are the files which are actually executed and are linked to DLL files so that they can use DLLs. Both are of same format, PE(portable executable or format of machine code in windows in simple words).
In other words EXEs contain the entry point(main) and the DLLs contain the library functions.. You cannot execute a file which just contains library functions you can just use them via other programs.
But still there are programs like rundll32.exe which provides that entry point and some minimal framework required by DLL functions to be called.
The point that I want to make is, you can never execute a DLL file you can just use it's code by providing an entry point through an EXE or some other program.
You can't "execute" a DLL. You can execute functions within the DLL, as explained in the other answers. Although .EXE files and .DLL files are essentially identical in terms of format, the distinguishing feature of an .EXE is that it contains a designated "entry point" to go and do the thing the EXE was created to do. DLLs actually have something similar, but the purpose of the "dll main" is just to perform initialization and not fulfill the primary purpose of the DLL; that is for the (presumably) various other functions it contains.
You can execute any of the functions exported by a DLL, assuming you know which one you want to execute; an EXE may contain a whole lot of functions, but one and only one is specially designated to be executed simply by "running" it.
To Run a .dll file..First find out what are functions it is exporting..Dll files will excecute
the functions specified in the Export Category..To know what function it is Exporting refer "filealyzer"
Application..It will show you the export function under "PE EXPORT" Category..Notedown the
function name--
Then open the command prompt,Type Rundll32 dllname,functionname
(dllname--name of your dll)
(Functionname-- name of the function you found under the PE Export)
Note:Makesure that your command prompt location is your dll file location
It should be mentioned that since it is entirely possible to run DLL's just as any other executable, it has long been considered a security issue. As such, there have been a number of security improvements and registry hacks (sorry no longer have ref-links) that prevents running DLL's from regular user space without extra privileges.
As a good example. I recall making these hacks, but since I no longer remember what exactly I did. I can no longer run any DLLs from normal user shell environment, even though starting various Win apps from GUI works just fine.
That said, one should definitely read "Dynamic-Link Library Security" and "Best Practices to Prevent DLL Hijacking".
.DLL files are not executable in the sense that .EXE/.COM/.BAT files are executable, so I'm not sure what you mean.
You can use the Dependency Walker application that comes with the Windows SDK to interrogate a .DLL and see what functions are exported by the file.
The following series of steps might be helpful:
Open Windows Explorer
In the top-left corner, click "Organize"
select "Folder and Search Options"
Switch to the "View" tab
Scroll down and uncheck "Hide file extensions for known file types"
Click OK
Now find the dll file
Right-click on it and select "Rename"
Change the extension(what comes after the last .) and change it to .exe
Related
I'm struggling to find any method that works with current Unity.
This for a conventional Windows build (not a Windows Universal via VS).
So, there's the separate data, dll, etc files of a build: how to create a civilian-usable "single exe" for Windows, with current Unity??
As said afaik this was actually always the case.
See e.g. Windows standalone Player build binaries to see a list of resulting output of a build. It exists back until version 2017.2.
So the short answer is:
It is how it is. You will always get multiple files and the data folder as output.
What you can do however is using a pack tool which simply packs all your folder content into one single exe file.
One example is Appacker
=>
BUT unfortunately there is one known issue: Windows Defender recognizes it and every exe created with it as malware. The reason for that is actually mentioned by the author in the link
Spoiler: A self-extracting .exe file? Windows Defender hates that trick!
So either with this tool or any similar one there is no real way around that except you need to trust the tool and your users need to trust you ^^
(The icon is also only used for the process window, not for the exe file itself ^^)
The long and correct way would probably be to create an actual installer for your final app which is then allowed to extract all the files to a certain location.
So in the end the user anyway will again have an exe and according data and dll files e.g. in the Programs folder but get a registered shortcut to the Start Menu which is just how any other application on Windows usually works like.
Just to add to the answer.
In 2020 if it's a game you should just use Steam. Making auto-update way easier for your users.
https://partner.steamgames.com/doc/gettingstarted
Everytime i dot source a file in PowerShell it opens a copy of the file in notepad.
Exe:
.\MyScript.ps1
The script runs fine - its just really annoying having these pop up all the time. Is there a way to suppress this?
I'm on windows 7 x64 and using the latest version of PowerShell.
Ex2: This is still launching notepad.
cls
Set-Location "\\PSCWEBP00129\uploadedFiles\psDashboard\"
. .\assets\DCMPull\Powershell\SqlServerTransfer.psm1
. .\assets\DCMPull\Powershell\RunLogging.psm1
You cannot dot source PowerShell files with the .psm1 file extension. One option is to rename them to .ps1.
Alternatively (and, in my opinion the better approach), you can load the PowerShell modules using Import-Module <module.psm1>. Just note that the behavior of Import-Module is different from dot sourcing it. Dot sourcing runs the script in the current scope and also persists all variables, functions, etc.in the current scope. Import-Module does not do that.
Although not very common, you can also export variables from modules with Export-ModuleMember.
Adding to Raziel's answer, there's a lot of thought that went into only being able to dot source files with .ps1 extension, and otherwise why it tries to run it as a system executable. Here's a snippet from PeterWhittaker on GitHub:
. ./afile would only execute something if there's either an
extension-less but executable aFile in the current dir, or a
(not-required-to-be-executable) afile.ps1 file, with the former taking
precedence if both are present; if the file exists, but is neither
executable nor has extension .ps1, it is opened as if it were a
document.
. <filename> with <filename> being a mere name (no path component) by
(security-minded) design only ever looks for a file of that name in
the directories listed in $env:PATH (see below), not in the current
directory.
I encountered exactly the same situation : If the point source imports the .psm1 file, the file will be opened directly instead of importing the code in the file.
Because the function of point source import is only valid in the file with suffix of.ps1, if the suffix does not meet the requirements, it will not be regarded as path, but as a code , so it is like running the corresponding string directly, and the effect is naturally to open the file.
So,this phenomenon is not aimed at .PSM1,if you change the extension to TXT, it will have the same effect. It will have the same effect for any file whose suffix is not .PS1.
You can bypass this problem by creating symbolic links or hard links!
In PowerShell 7, it's easy to create links using New-Item.
A little background
I'm working on a project that requires me to use an old (from 2006) large system of MatLab scripts. The script exists in an archive folder on a cluster but I need it to run fully from my cluster folder. I've got it mostly running from my personal folder but not entirely. It runs perfectly but there is a Python script that is called somewhere that doesn't exist in my personal directory.
What I want to do
Since the MatLab code I'm running includes many different script files, which themselves call even more script files, poring through them to find information about the Python script would be very very time consuming.
Therefore, I would like to be able to tell MatLab to not go to specific folders when calling a script, but instead, return an error. For example, if a scripted is called in the directory /notmyfolder, I want it to return an error.
Is this possible?
I'm confused as to how PowerShell modules work.
I have downloaded and copied a module from a blogger. I've unblocked and extracted the .zip to %USERPROFILE%\Documents\WindowsPowerShell\Modules\SomeModule
In this folder is a .NET assembly that the module uses, but doesn't not contain compiled CmdLets. Instead, the commands are functions in a .psm1 file and a .psd1 file describes the manifest.
If I open PowerShell, the functions are available and work but I want to add my own function, so I have added it, however I cannot see it. I've restarted all PowerShell instances, removed the module and imported it again.
As a test, I renamed an existing, working function. Interestingly, after remove and import the function disappears instead of adopting its new name. If I rename it back (just a single character change) and remove/import then it appears again.
I use help blahblah to list all commands in a set, since they all have the same prefix. The manifest exports all (*) functions. Clearly I don't understand how these type of script modules work, the functions are all listed even after I run Remove-Module! I've written a compiled module before in C# and that worked as expected.
What's going on? Why does renaming a function cause it to vanish? Thanks.
Found it. This line appears in some stuff I overlooked in the .psm1 file.
Export-ModuleMember X, Y, Z
So, I guess the manifest can overrule this or replace the need for it in a script? Who knows. Anyway, hope this helps someone.
If I compile a script for distribution as a standalone exe, is there any way I can store settings within the exe itself, to save having to write to an external file? The main incentive for this is to save having to develop an installation process. I only need to store a few bytes.
Also, can resources such as images be compiled into the exe?
Using alternate data streams opens up a can of worms so i wouldn't go that way. Writing back config data into the exe itself won't work as the file is locked for write access during execution.
What i usually do is to store config data under %A_AppData%\%A_ScriptName%\%A_ScriptName%.ini
When the script starts i use IniRead which also provides a default value if the key isn't found - which is the case the script is executing for the first time.
The complementing IniWrite's in a OnExit subroutine/function will create the ini file if necessary.
This way no installation is needed and the config is stored in the proper, familiar place.
The autohotkey forum has dealt with this question before.
In that case, the user didn't want extra files -- period.
The method was to use the file system to save alternate data.
Unfortunately I can't find the post.
A simpler method is to use fileinstall command.
When the script is compiled, the external file is stored within the exe.
When the script executes the same command as an exe, the file is copied to the same
directory as the running script. It is a simple yet effective 'install'.
With a little testing for the config file, the fileinstall command can be skipped.
Skipping the fileinstall could allow changes to be made to the configuration after 'installation'
I have not tried saving settings within the compiled exe file, but I have included resources. I'm not sure which version of AHK you're using or how you are compiling, but I can right-click my scripts to compile. There's an option to compile with options, where you can include resources in your compiled exe.Compile with options