I'm trying to learn the basics of dll injection, so I created a really simple hello-world type DLL and an injector based off of code I found online. I wasn't able to find anything that works out of the box, so I had to make a few adjustments.
Injection Code, DLL Code
I'm running these on 64-bit windows. I'm compiling with Visual Studio 2010. The injector is a win32 console app, and the dll is win32 as well. I'm trying to inject my code into an existing notepad process (also 32-bit). All of this is running on Windows 7 x64.
When I run the injector, it fails every time at CreateRemoteThread, with GetLastError returning 5 (i.e. ERROR_ACCESS_DENIED). I've confirmed that the dll path is correct (although changing it to a bogus path gives the same behavior), and I've confirmed that the path is getting written to notepad's memory at the correct address using Cheat Engine. I'm having a difficult time with this because I'm not sure how to debug the problem further.
What could be causing CreateRemoteThread to fail?
The problem is that notepad.exe is a 64-bit process in 64-bit windows, and I was trying to inject with a 32-bit process.
I also come up with the same problem. My situation is this:
My system is 64-bit and the notepad is also 64-bit.
But the injector is the 32-bit process.
My solution is to replace the 64-bit notepad with the 32-bit notepad in the system directory.
Related
I'm facing such a problem. I've built a Windows kernel mode driver using WDK11, and, in order to pass Windows 11 WHQL, I need to use new memory allocating function ExAllocatePool2. The problem is, this driver will fail to load on Windows 7.
You know, Win7 does not have ExAllocatePool2, just like a user-mode EXE cannot find a new-era API in a system DLL on an older Windows OS, so the EXE fails to run.
For a user mode EXE, I can use LoadLibrary and GetProcAddress trick to dynamically detect that new-era API is not available at runtime, so that I can fall back to call older API.
I think the same idea applies to kernel mode, using RtlIsNtDdiVersionAvailable to probe for OS version, then call best available API from the system. But how to do real runtime dynamic linking to desired API?
Or, if there is a way to tell the system to ignore ExAllocatePool2 resolving errors when loading my .sys, the question is considered resolved as well.
In one word, the requirement is, I want to have a single binary to support all of Win11/Win10/Win7, and use new APIs on new OS.
I have a simulink model (2016b with MC 2013 C/C++ and Mingw-64 compilers) that I'd like to generate a standalone executable for windows-64 bit.
I was able to run the grt executable but due to the fact that I need to read a mat file runtime as opposed to compile time, I am using rsim code generation for this purpose, however the executable that gets generated appears to need quite a bit of .dll, I provided the dll it was asking for however, the application still unable to run. This is the error that results
The application was unable to start correctly 0xc000007b. Click OK to
close the application
What am I missing ?
Your main program is compiled for x64 (64-bit) target, but the dll you provided is compiled for x86 (32-bit) target. Or vice versa.
If it is Mingw-64 stuff, you should be able to obtain all (or most) of them by using the official online installer. Link is here.
My problem might seem specific, but in fact it is probably very general: How to publish a Console Application that uses 3rd party references?
I am using Visual Studio 2015 to make a Console Application called Gdx2PostgreSql programmed in Visual Basic. The application is reading data in a Gdx-file (output from a GAMS program, www.gams.com) and writing the data to a PostgreSql database. The interface to PostgreSql is handled by NpgSql, www.npgsql.org. NpgSql is referenced as
\\dtu-storage\hela\Documents\Visual Studio 2015\Projects\GDX to PostgreSQL 2\packages\Npgsql.3.1.7\lib\net451\Npgsql.dll
The program functions correctly when it is executed in Debug mode inside Visual Studio.
I have to be able to run the program from the command prompt in a CMD window. Moreover, I have to be able to run the program by spawning from a GAMS program using the GAMS syntax
Execute 'Gdx2PostgreSql "FileName.gdx" "CaseName"';
I have published the program and run the setup file installing the program. But when I run it in a CMD window I get the error:
'Gdx2PostgreSql' is not recognized as an internal or external command, operable program or batch file.
I get the same error message when spawning from my GAMS program.
Being rather desperate I have tried renaming the file setup.exe in the Publish-folder to Gdx2PostgreSql.exe. When I use this file I get:
Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Npgsql, Version=3.1.7.0, Culture=neutral, PublicKeyToken=5d8b90d52f46fda7' or one of its dependencies. The system cannot find the file specified.
That is, NpgSql is not known to the program.
As I see it, I need to have one EXE-file that holds all what is needed - especially because my program should be able to run on other PCs, too.
Can anyone help me make my program Gdx2PostgreSql function?
Finally, I should mention that I have made other programs reading Gdx-files and using NggSql to write to PostgreSql. These programs function correctly, but they are Windows Forms Applications – and not Console Applications.
Console applications aren't really any different from winforms applications - you have to distribute the EXE along with any DLLs it depends on - in the same directory. As mentioned in the comment, after building your program you should be able to find everything you need under bin/Debug (or Release).
Regarding why your Gdx2PostgreSql isn't being found, that's likely a problem of path - try running your program with an absolute path, or cd'ing into bin/Debug (or Release) before executing it.
usually I deploy my Java apps as a bundle which contains the JVM, so there's no need to install a JVM on the system.
Btw: This is no jnlp applet, this is a normal Swing Application.
I did this using ant's fx:deploy. This already works for 64bit systems.
My problem is, that I want to deploy this application to a 32bit system and don't get it to work.
Here's what I did:
I've set up a clean Windows 7 (32bit) instance and installed a 32bit JVM. Now i ran my ant script to build a bundled Java app and it built a App.exe.
But when I tried to start this exe by double clicking, I get the following message box
If I click OK, I get another message box
After this the app is terminated.
I did not find anything searching the web relating to bundling for 32/64 bit systems.
So I would be very glad if someone can point me in the right direction.
Many thanks in advance!
Greetings, -chris-
Looks like a known bug fixed for an upcoming JavaFX version (currently known as 2.2.40):
RT-25715 The Windows launcher generated by the packager fails to load msvcr100.dll on 32-bit OS
RT-22610 .exe created by fx:deploy can't be executed due to missing msvcr100.dll
On the bug case, the user mentions a work-around:
If I give a try to the workaround documented in RT-22610, which is to copy runtime\jre\bin\msvcr100.dll side to my application's launcher binary, it fixes it.
I think the bug is fixed in JDK 8, so another possible work-around is to download a JDK 8 early access release and use the packaging tools from there to package a Java 7 application (though I have never tried that and am not sure if it would work).
Just a small modification to #jewelsea's Fix:
copying msvcr100.dll into the app/ folder instead putting it right next to the exe also works, and at least it is somewhat hidden away then.
If you're generating an MSI you can hack the WXS file used by WIX to automatically copy msvcr100.dll into the app folder. Making FX Deploy verbose will tell you where it's putting the temporary WXS file you can copy and modify and use to override the WXS like you would the program icon for example.
I have a .NET project that's always been built/run by/on 32 bit machines. I got a new a 64 bit computer and am trying to tackle the task of getting it working there. The build script is in nant, and at one point we compile some boo code using the nant task. The boo code references our core DLL, which is built from c# source earlier in the build process.
I've tried two things: build it to run in 32bit mode and build it to run in 64bit mode. By using corflags on several programs (including booc), I was able to build the project built in 32bit mode, but ended up with a bunch of downstream issues at runtime. So I need to get it built in 64bit mode, which I think is preferable anyway.
According to the nant/booc source code, the booc nant task calls the booc.exe in-process using the CLR's Process class, so (I think) it should inherit 32bitness or 64bitness from the parent process. That doesn't reflect what I'm seeing, though.
Here's what I've done:
Used the 64bit version of powershell to invoke nant
Specified platform="x64" on my tasks. I feel like I shouldn't have to do this because anycpu should be fine, but it seems to make a difference.
Here's the error I'm getting:
[booc] Compiling 5 files to 'C:\dev\build\MyProjectBoo.dll'.
[booc] BCE0106: Failed to access the types defined in assembly 'MyProject, Version=5.5.0.0, Culture=neutral, PublicKeyToken=null' - (C:\dev\build\MyProject.dll):Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
[booc] is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)
[booc] is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)
[booc] .
[booc] 1 error(s).
Which means, according to the booc source code, "I tried to reflectively list the types in your referenced assembly but failed". I don't know if that means, "I think I'm 32bit but these are 64bit dlls" or what, and I'm very confused.
Any ideas on how I can get this to work?
Update after some work, I've discovered that the issue has nothing to do with boo. I wrote a quick c# program that reflectively loads the dll and it breaks in the same way. So for some reason, no matter what I set as the platform (x86, x64 or anycpu), I can't load it reflectively on an x64 machine. So not really boo's fault. So I'm going to dig into this and repost if I have a better question.
Newer Update
Turns out that one of my main DLL's third party dependencies insists on being in a 32 bit environment, even though it isn't built with corflags. This causes assembly.GetTypes() fail in 64 bit mode.
The problem is dependencies on third-party DLL's that require 32 bit mode, which is possible even if they don't have corflags set.