I've been getting in to reverse engineering a bit and have come across a piece of software that I'm unsure how to start on. The software is launched by a batch file (which also calls a second batch file) before it calls the executable. If I load the batch file in to x64dbg I get a PE file error which is expected. But I can't run the executable directly as I get a missing dll error. Any idea how I might get around this to get started? Cheers.
I ended up using Ollydbg instead as it seems to load batch files.
For future references, you can copy the dll(s) to the directory the PE is in. Not sure what software this is, but the downside I can see is possibly running into dependency hell? You won't really know until your executable stops complaining about missing dll's.
Related
I'm trying to get my head around a DLL load library problem. The Windows Dynamic-Link Library Search Order is supposed to be
Memory
Known DLL's
Application Directory
System Directory
...etc,
as discussed at https://learn.microsoft.com/en-us/windows/desktop/dlls/dynamic-link-library-search-order and at many other places.
When I run a Windows Executable (Desktop Application) from a Batch file, does it inherit the 'application' folder from the Batch File? (Because I'm running out of other explanations)
Nope, you can't consider a batch file an application at all.
It's more like a script, as it needs to be run through an actual application/executable program (like the DOS runtime, or CMD on Windows)
You can setup environment variables much like in old DOS times (if you need to define a Paths variable) through sysdm.cpl, but I'm not sure that would help for DLL searching
I'm debugging test.exe which reads a file "data.txt" that is present in the same directory as that of the exe. The program works fine when run directly. But when being debugged under winDBG, the CreateFile WinAPI in the code fails with err#2 (Unable to find file). I saw a related thread about a similar issue when debugging with VS - there the solution was to place the data file along with the source/headers. That solves the VS issue, but does not help this WinDBG issue.
Has anyone faced this issue before? Please let me know if you are aware of a solution.
If you use relative file paths, then the working directory of your process will affect how they are converted to absolute paths.
When test.exe is launched in Windows Explorer, its working directory is the folder that contains it. In that case the data file in the same folder can be found correctly.
When you use WinDbg to launch test.exe, unless you explicitly set working directory to the one you want, WinDbg will use its own folder. No doubt that leads to the issue you meet.
http://en.wikipedia.org/wiki/Working_directory
can someone help me with this error!
"The PROGRAM CANT START because OPENGL.DLL is missing from your system."
I already put the h. and .dll files in the specific directories. i'm working on a 64 bit window 7. microsoft visual c++.
Most systems already have OPENGL.DLL in the Windows System directory.
The way to diagnose this error is to run Dependency Walker (download here).
Run it and open up your .EXE file - and it will tell you specifically what DLL it can't locate, or which is loaded but is not compatible.
OPENGL.DLL
You are sure about that name. Wasn't it opengl32.dll?
I already put the h. and .dll files in the specific directories
Never(!) do this with opengl32.dll. This is a system DLL and must not be overridden by shipping one own's with the program. If you do this, you may very likely end up with not getting HW acceleration.
I had a similar issue and discovered that I had deleted the following line before pasting the test code:
#include "stdafx.h"
Make sure you have the line as above before pasting the test code.
Maybe you could go to one of your friends , and copy this .dll file from his system dictionary
I look at a lot of small Java programs. It would be convenient if I could set up a directory (or directory structure) on my Mac where any time I add a .java file, javac automatically runs and attempts to compile that file. I've briefly looked into Automator actions, but found nothing that fits the bill. Then I got to thinking: on my PC, I would use the .Net FileSystemWatcher class and write the code myself. But before I try that on my Mac with Mono, I want to ask the community for other ideas. Any advice is appreciated. Thanks.
In JDK6 you can programmatically compile, so you could write your own program to do this, which may be slightly better than doing it in mono.
So you would just have a program that is always running, it looks for either any new files or a file that has been changed since the last check and then just compiles them, and you may want it to pass information to a dashboard window when there are errors, and perhaps some status info so you know it is working.
http://binkley.blogspot.com/2005/09/programmatically-compiling-java-in-jdk.html
If you have all the .java files available at the start, you could write a shell script to compile them all in one run -- in different directories if you need to.
If you explained why you would want this, maybe I/we could be more helpful.
I have a Windows service application on Vista SP1 and I've found that users are renaming its executable file (while it's running) and then rebooting, thus causing it to fail to start on next bootup because the service manager can no longer find the exe file since it's been renamed.
I seem to recall that with older versions of Windows you couldn't do this because the OS placed a lock on the file. Even with Vista SP1 I still cannot copy over the existing file when it's running - Windows reports that the file is in use - makes sense. So why should I be allowed to rename it? What happens if Windows needs to page in a new code page from the exe but the file has been renamed since it was started? I ran Process Monitor while renaming the exe file, etc, but Process Mon didn't report anything strange and just logged changing the filename like any other file.
Does anyone know what's going on here behind the scenes? It's seem counter intuitive that Windows would allow a running process' filename (or its dependent DLLs) to be changed. What am I missing here?
your concept is wrong ... the filename is not the center of the file-io universe ... the handle to the open file is. the file is not moved to a different section of disk when you rename it, it's still in the same place and the part of the disk the internal data structure for the open file is still pointing to the same place. bottom line is that your observations are correct. you can rename a running program without causing problems. you can create a new file with the same name as the running program once you've renamed it. this is actually useful behavior if you want to update software while the software is running.
As long as the file is still there, Windows can still read from it - it's the underlying file that matters, not its name.
I can happily rename running executables on my XP machine.
The OS keeps an open handle to the .exe file,. Renaming the file simply changes some filesystem metadata about the file, without invalidating open handles. So when the OS goes to page in more code, it just uses the file handle it already has open.
Replacing the file (writing over its contents) is another matter entirely, and I'm guessing the OS opens with the FILE_SHARE_WRITE flag unset, so no other processes can write to the .exe file.
Might be a stupid question but, why do users have access to rename the file if they are not suppose to rename the file? But yeah, it's allowed because, as the good answers point out, the open handle to the file isn't lost until the application exits. And there are some uses for it as well, even though I'm not convinced updating an application by renaming its file is a good practice.
You might consider having your service listen to changes to the directory that your service is installed in. If it detects a rename, then it could rename itself back to what it's supposed to be.
There are two aspects to the notion of file here:
The data on the disk - that's the actual file.
The file-name (could be several or none) which you can give that data - called directory entries.
What you are renaming is the directory entry, which still references the same data. Windows doesn't care about your doing so, as it still can access the data when it needs to. The running process is mapped to the data, not the name.