What I'm trying to do is to sign my compiled executable's first 32 bytes with a version signature, say "1.2.0" and I need to modify this signature in runtime, keeping in mind that:
this will be done by the executable itself
the executable resides on the client side, meaning no recompilation is possible
using an external file to track the version instead of encoding it in the binary itself is also not an option
the solution has to be platform-independent; I'm aware that Windows/VC allows you to version an executable using a .rc resource, but I'm unaware of an equivalent for Mac (maybe Info.plist?) and Linux
The solution in my head was to write the version signature in the first or last 32 bytes of the binary (which I didn't figure out how to do yet) and then I'll modify those bytes when I need to. Sadly it's not that simple as I'm trying to modify the same binary that I'm executing.
If you know of how I can do this, or of a cleaner/mainstream solution for this problem, I'd be very grateful. FWIW, the application is a patcher/launcher for a game; I chose to encode the version in the patcher itself instead of the game executable as I'd like it to be self-contained and target-independent.
Update: from your helpful answers and comments, I see that messing with the header/footer of the binary is not the way to go. But regarding the write permission for the running users, the game has to be patched one way or another and the game files need to be modified, there's no way to circumvent that: to update the game, you'll need admin privileges.
I would opt for using an external file to hold the signature, and modify that with every update, but I can't see how I can guard against the user spoofing with that file: if they mess up the version numbers, how can I detect which version I'm running?
Update2: Thanks for all your answers and comments, in truth there are 2 ways to do this: either use an external resource to track the version or embed it in the main application's binary itself. I could choose only 1 answer on SO so I did the one I'm going with, although it's not the only one. :-)
Modern Windows versions will not allow you to update an installed program file unless you're running with administrator privileges. I believe all versions of Windows block modifications to a running file altogether; this is why you're forced to reboot after an update. I think you're asking for the impossible.
This is going to be a bit of a challenge, for a number of reasons. First, writing to the first N bytes of the binary is likely to step on the binary file's header information, which is used by the program loader to determine where the code & data segments, etc. are located within the file. This will be different on different platforms (see the ELF format and executable format comparison)--there are a lot of different binary format standards.
Assuming you can overcome that one, you're likely to run afoul of security/antivirus systems if you start modifying a program's code at runtime. I don't believe most current operating systems will allow you to overwrite a currently-running executable. At the very least, they might allow you to do so with elevated permissions--not likely to be present while gaming.
If your application is meant to patch a game, why not embed the version in there while you're at it? You can use a string like #Juliano shows and modify that from the patcher while the game is not running - which should be the case if you're currently patching anyways. :P
Edit: If you're working with Visual Studio, it's really easy to embed such a string in the executable with a #pragma comment, according to this MSDN page:
#pragma comment(user, "Version: 1.4.1")
Since the second argument is a simple string literal, it can be concatenated, and I'd have the version in a simple #define:
// somehwere
#define MY_EXE_VERSION "1.4.1"
// somewhere else
#pragma comment(user, "Version: " MY_EXE_VERSION)
I'll give just some ideas on how to do this.
I think it's not possible to change some arbitrary bytes in the executable without side effects. To overcome this, I would create some string in your source code, like:
char *Version = "Version: AA.BB.CC";
I don't know if this is a rule, but you can look for this string in your binary code (open it in a text editor and you will see). So, you search and change this bytes for your version number in the binary file. Probably, their position will vary each time you compile the application, so this it is possible only if that location is not a problem for you.
Because the file is being used (it's running), you have to launch an external program that would do this. After modifying the file, this external program could relaunch the original application.
The version will be stored in your binary code in some part. Is that useful? How will you retrieve the version number?
Related
I am making a suite of 64-bit plugin DLLs for a Windows host application using Visual Studio/C++, and from the current version onward, the setup.exe that they come in creates a single shared user-writable folder under ProgramData in which I cache all sorts of (non-user specific) data files. Older versions didn't have that folder yet.
However, the distribution of my plugin binaries is often out of my hands too. They are repackaged by a 3rd party bundle which can only do dumb file copies of the DLLs (so no real setup.exe functionality I need like creating folder + set permissions). And since my binary DLLs are all 100% self-contained, users also historically have a hand of just copying the DLLs around to other machines as they see fit, but that ofc also lacks the new folder setup phase.
I am looking into a workaround to have my DLLs create the folder at runtime if it is missing. I know I can't elevate the host process in-place whenever I want, but I thought of the following ways:
Have an extra "FixSetup" entry point in my DLL, and when the need arises, start an elevated RunDLL32.exe and let it use this entry point in my DLL.However, I see all sorts of people all over the place talking about RunDLL being as good as deprecated and advising against using it, but then again that was already since Windows XP and it's still with us. I also hear of RunDLL having it's own runtime context which can change with every Windows release (like switching to high-DPI aware when that came available), and that it thus is a 'hostile' environment to run in (read it on Raymond Chan's blog IIRC). Should I really be afraid of using it, or is my use case so simple it can barely break? (no GUI, just a wrapped CreateDirectory call)
Create a small "FixSetup.exe" which just does the folder creation, package it into my DLL's resources, and extract-to-temp + run-elevated it at runtime.While this would bloat my DLLs (depending on how small I can get the .exe), I feel like it's also a more fragile + convoluted solution than 1. above (with file extraction and all; prob. best to sign the utility exe too to keep HIPS / antivirus from acting funny etc?).
Alter my DLLs so that they're actually .exes in disguise which happen to export the host-expected DLL entry points, so that I can call them directly (elevated).I know there are some major caveats here (like conflicts between the C runtime being included in DLL or non-DLL mode, Visual Studio prob. not approving of these shenanigans, etc.), and honestly I already feel I need a shower just after talking about this one. So while theoretically maybe feasible, it is my last resort.
Does anyone have any advise on my uncertainties above? Or maybe an even better suggestion?
EDIT
I've already managed to get option 1. working, and while it works seamlessly there's one drawback I spotted: the UAC prompt (understandably) asks whether the user wants to run RunDLL32.exe, signed by Microsoft. This might confuse/scare people no end (that is: if they even read these prompts...). I'd rather have the UAC prompt asking about MyPluginSetup.exe signed by MyCompany, so now I'm more inclined to go with option 2. instead.
I want to build an C#/Wpf Packer.
I am using a C++ application which will start the packed/crypted C# application.
Currently I have to build this C++ app everytime I want to release my Main-App.
(C#/Wpf-App is included as external Array of Bytes)
Now I want to build a simple tool to do this work, but I dont want to build the "launcher" all the time!
So my idea is just to modify the launcher.
For that I need a way to modify this executable and I need to be able to use this modified data inside the launcher, like it would be compiled.
I dont want to reserve a static sized array inside the launcher, cause I dont know what could be the biggest data-size.
There are different ways to do that. Unfortunately none of them is straightforward nor standard except one: use a makefile that automatically builds the launcher. IMHO, unless you have special requirements such as building the launcher on a system with no development environment, it is probably the most simple and robust way.
As you explicitely ask for other solutions, I will give 2:
on Windows, you could store the c# app as a resource. Once that's done, you can use a resource editor to change it on the fly or build a custom editor using the WinAPI functions BeginUpdateResource, UpdateResource and EndUpdateResource. You later load the resource with LoadResource in the launcher.
you could make the laucher program know its real size and just seek behind that size and load what follows as the C# app. To build it, you just need to copy the actual C++ executable and whatever you want it to process. The hard part here is that there is no portable way to identify the size or the end of an executable at compile time. You could try a two pass build:
first pass, you set the size to an arbitrary value. You build and look at the real size
second pass, you set the size to what has been observed in first pass. As you only modify a size_t value, the size of the executable should not change. But I strongly urge you to control that size twice. Repeat if it is not the same (it could happen if the compiler was too clever and merged identical constants).
But as I already said, my choice would be to use a makefile to automatically generate the launcher each time the C# app is rebuilt
I've changed the file "handle.c" in winceos\COREOS\nk\kernel.. and need to build according to take the changes into the core.dll for nk.bin
is there any build order to follow to avoid to build the hole solution?
First, let me say that making that change where you did is a bad, bad idea. Never change the public or private trees directly. If Microsoft issues a QFE that changes that code, when you apply the QFE, your changes will be overwritten and without warning. Always clone the code and change the clone.
As far as making kernel changes without having to rebuild the entire project, the answer is no, you can't. Changes in the code potentially change addresses, and a vast amount of the OS is fixed up with those addresses during the build process. You'll have to rebuild the entire thing after a change like that (as opposed to, for example, drivers which you can build individually without rebuilding the entire OS).
thanks for your answer.
what I found now by trying myself is yes, it's possible by doing "build & sysgen" of "winceos" folder under PRIVATE.
The change execution on kernel code was just adding a RETAILMSG to see the HANDLE count.
The file handle.c create handle table and give handles. There is a number of commands creating/allocating handle. I do not really know, by which handle requests the kernel calls handle.c(??), but it "can" for some developers be usefull to be able to manuplate it??
But in summary, doing "build & sysgen"+"MakeRunTimeImage" makes the changes on kernel valid.
I did it on "PRIVATE/winceos", but perhaps it's also possible by doing iy more locally, for example on PRIVATE/winceos/COREOS/nk/kernel folder. I didn't tried it ;)
Is there a way to get all opened file handles for a process and arrange it by time files were opened? We have a project, which requires exactly this - we need to determine which files are opened by a Dj software, such as Traktor or Serato. The reason we need to know its order is to determine, which file is in the first deck, and which is in the second one.
Currently we are using Windows internal APIs from the Ntdll.dll (Winternl.h) to determine a list of all opened files for a process. Maybe that's not the best way to do it. Any suggestions are highly appreciated.
We relied on an observed behavior of that APIs on certain OS version and certain Dj software versions, which was that the list of all opened files for a process never get rearranges, i.e. adheres an order. I know that's a bad practice, but it was a "should be" feature from the customer right before the release, so we had to. The problem is now we have a bug when those handles are sometimes randomly rearranged without any particular cause. That brakes everything. I thought maybe there would be a field in those win structures to obtain file's been opened time, but seemingly there are no such things. Docs on that APIs are quite bad.
I thought about some code paste, but it's a function 200 lines long and it uses indirect calls from the dll using function pointers and all structures for WinAPIs are redefined manually, so it's really hard to read it. Actually, the Winternl.h header isn't even included - all stuff is loaded manually too, like that:
GetProcAddress( GetModuleHandleA("ntdll.dll"), "NtQuerySystemInformation" );
It's really a headache for a cross platform application...
P.S. I have posted a related question here about any cross-platform or Qt way to get opened file handles, maybe that stuff will be useful or related.
if it's just to check the behavior in other OS for debug purpose, you can use the technique of creating process in debug mode and intercept in the order all events of dll loading, here's a good article talking about that.
I have a VS2010 project which is a windows application that acquires data from a particular bluetooth device. All I want to do is alter my acquisition thread to send the data it acquires using OSC.
I spent a long time trying to use a library called LIBLO but it appears to function using POSIX style asynchronicity. I spent even more time trying to make pthreads-win32 work for me so that I could still use this library but still had no luck.
I switched to trying to use the OSCPACK library which I could not get to compile using the batch file included in the release. I was eventually able to get my VS2010 project to recognise the library but all I get now are linker errors (LNK2019 and LNK2001). The relevant directories are listed in "Additional Include Directories" in the project properties. I know this should be something easy to fix but after a day of frustration I am at my wits' end. I am used to working with xcode in osx so find it difficult to accomplish anything in VS2010. Do I need to give additional instructions to the linker?
can anyone either suggest a simple, prebuilt OSC library compatible with windows/VS or how I can fix my problem with unresolved externals?
OSC is a very simple protocol, especially if you only need to send outgoing OSC messages and don't care about receiving (and parsing) incoming OSC messages. One thing you can do is simply read the spec and look at some examples and write your own function that adds OSC data into a byte buffer in the prescribed format. That's only a few hours of work to do. Then it's just a matter of sending that char buffer out over a UDP socket, which is also quite straightforward to do. Depending on your needs, that might be easier that trying to integrate with a third-party OSC library (which I agree can be frustrating, especially under Windows).
Another possibility is to use OSCPACK, but instead of trying to build it separately and then link to the resulting DLL/LIB file, simply copy the necessary OSCPACK .c files directly into your own project's source tree and compile them in to your executable the same way you compile your own code. That will avoid any annoying build/link issues that can come with trying to get two different build systems to work together, and it also gives you full control over your (bastard) copy of the OSC code... e.g. if you want a particular function in OSCPACK to work differently, you can simply modify your copy of that function. (If you do that, be sure to make it obvious that the code is no longer 'stock', to avoid confusion... and of course try not to modify it in such a way as to break protocol compatibility with other OSC-using software)