I've got a compiled resource file (.res). I need to read it, in C#, so that I can modify it programatically. note that this is not a .resx file or .rc file; the file is compiled, not text-based.
So far I tried looking at LoadLibrary, LoadResource, etc. in the Win32 API, but it seems that these functions only work on executables (.exe, .dll), and not resource files.
I've tried loading the file with BinaryReader, but of course I can't make much sense of the resultant byte array.
I thought of trying to use Marshal.PtrToStructure but I haven't got an idea what the structure of a res file is. I've got the structure of the RESOURCEHEADER, but I couldn't understand how to use it (I admit I've got very little native-code experience).
Could anybody please help me figure out how to successfully read and update the version info in the .res file?
Very good question; I couldn't find a good answer using existing functions either. Fortunately, it seems that the RES file format is relatively simple, and is documented here:
http://msdn.microsoft.com/en-us/library/ms648007(VS.85).aspx
You should be able to scan the RES file for the version resource, and then update the appropriate fields. Remember that the resource header is DWORD-aligned.
My only other suggestions would be to use LoadLibraryEx and see if you can load the RES file as a datafile somehow. But it sounds like you've already tried that. If you did succeed though, you might find this topic interesting - it's an example of how to copy resources between two modules:
http://msdn.microsoft.com/en-us/library/ms648008(VS.85).aspx
I doubt it will work though. I loaded RC.EXE in Dependency Walker to see if it was using any interesting APIs for building RES files. I did not find any, so I can only assume that RC.EXE directly writes out the RES files.
Related
Recently I did an experiment with one of my c# .NET compiled exe by renaming the extension to .txt.
When viewed in the Notepad, I was able to see all my source code in English Language which made me confused if I was looking at a .cs file or a .exe file.
After this event I realized that anyone who has this exe can copy all the codes an re-compile them into a clone with some hidden additional codes (or malwares) that could harm my reputation among users.
However I know a little about obfuscation which can rename all methods and properties into a non-human readable format, still I would like to ask here, isn't an exe program supposed to be (only) in a computer readable binary format (as I have learnt in school)? Why is there a need of obfuscation additionally? Is this problem only limited to exe which has a CLR header? Should I consider creating applications on other languages like C, if I want to make it hard to decompile?
Please Answer...
Edit:- Most of the codes can be seen in this area and I am unaware of what part of the source code it consists of.
Edt:- Also when I do the same with an exe that is compiled using Visual Foxpro (where Encrypted is checked in Project Properties), not even a single readable text is seen except some assembly infos. What encryption technique is used in it, can we use it (or like that) in dotnet (free or paid)?
Source - https://www.tek-tips.com/viewthread.cfm?qid=286147
I was always pretty impressed by those programs that you could install by executing one installer file, which would then extract all the other required files to run the actual program.
And even now im still wondering how you would code a program that extracts files that are literally still inside the program ( so not in some kind of zip) , i've seen tons of installers for games who have this. I need this cause I want to extract a file on the right moment without giving the person who uses the program the ability to delete the file before its extracted, this may seem vague, but I hope i've informed you enough.
I'm just going to say that building an installer is difficult.
I'd recommend using NSIS: http://nsis.sourceforge.net/Main_Page
As for creating a file the user can't access, create a temp file with the correct read/write permissions, extract the data to the temp file, then copy the file where it needs to go.
Extract happens without the user interfering, and copy protection is handled by the OS.
What about changing the build action for the file you want to hide to Embedded Resource, or something like that that compiles the file inside the dll/exe?
Executable program is just file, So you can append any data at you executables. (works for my c++ compiled program)
$ cat executables some_blob_data > new_executables
Since argv[0] of main() is name of your file, you can use this to acess data in this file itself (works for c or c++ and likley for other languages to)
A really simple way to do this is to use your archive tool or one of the dozens of already made installers. WinRar, WinZip and most others allow the creation of self extracting exe files. I know you've said that is not what you want but if you make sure to make it auto exec your installer app and remove all of the temporary files when you're done it really can be very fool proof and professional looking. Obviously, the various installer applications are able to do what you're wanting.
If you really want to do this yourself the easy solution is going to most likely be dependant on your IDE software and language. The generic answer is that you'll need a compression library which can accept a stream as input. Then you'll want to make your actual files into resources inside your installer app. At that point it's just a matter of telling the compression library to read from a stream which is pointed at the resource. How that is done varies greatly from language to language.
Short version:
I want my program to be able to (read-only-)access its own source code during runtime. Is there a way to automatically package the source code into the dll during compilation?
Long version:
The background is that when an exception occurs, I want to automatically create a file containing some details of what happened. This file should, among other things, include the source code of the function that caused the problem. I want to send this file to other people by email, and the receiver will most likely not have (or not want to install) Visual Studio, so anything using symbol servers and the likes is out of question. It needs to be a plain text file.
Ideally I would somewhere find the related source code files and just copy out the relevant lines. You can safely assume that as long as I have a folder containing the entire source code, I will be able to locate the file and lines I want.
The best idea I could come up with so far -- and I have not looked into it in much detail because it seems messy to no end -- is to modify the MSBuild files to create a .zip of the source during compilation, and require .dll and .zip to reside in the same folder.
Most of the similar-sounding questions on stackoverflow that I found seem to deal with decompiling .dll files, which is not what I want to do. I have the source code, and I want to ship it together with the .dll in a convenient way.
Update: The really long version
Seems some people are seriously questioning why I would want to do that, so here's the answer: The main purpose of my software is testing some other software. That other software has a GUI. For an easy example, let's say the other software were the standard Windows calculator, then my testcase might look something like this:
calculator.Open();
calculator.EnterValue(13);
calculator.PressButtonPlus();
calculator.EnterValue(38);
calculator.PressButtonEnter();
int value = calculator.GetDisplayedValue();
Assert.That(value == 51);
calculator.Close();
These tests are intentionally written in a very human-readable way.
What I want to do when a problem occurs is to give the developer of the calculator a detailed description of how to reproduce the problem, in a way that he could reproduce by hand, without my software. (In this example, he would open the calculator, enter 13, press plus, and so on.)
Maybe another option would be to have each function calculator.Something() write out an information line to a log, but that would a) be a lot more work, b) only include the test run up to the point where it aborted, and c) bear some risk that writing the line is forgotten in one function, thereby giving an incorrect representation of what was done. But I'm open to other solutions than copying source code.
Take a look at this question: Do __LINE__ __FILE__ equivalents exist in C#?
C++ offers macros (__LINE__, __FILE__, and so on) that replace with the representing information during compile time. This means if you write something like this:
throw new CException(__FILE__);
it will compile to something like this:
throw new CException("test.cpp");
resulting in a hardcoded value. The C# compiler does not offer those macros and you are forced to use reflection to get the information about where the exception has been thrown. The way you can do it is described in the question linked above.
If you are not able to supply .pdb symbols then the default behaviour of Exception.ToString() (or StackTrace.ToString()) will not return you the line number, but the MSIL offsets of the operation that failed. As far as I can remember you can use the Stack Trace Explorer of ReSharper to navigate to the representing code (Not 100% sure about that, but there also was a question here on stackoverflow that mentioned this fact).
You can include copies of the source files as resources.
In the project folder, create a subfolder named Resources. Copy the source files there.
Create in the project a resource file, and then include the source copies you made into it.
Setup a pre-build event to copy the actual source files to Resources folder, so you always have updated copies. In the example I created, this worked well:
copy $(ProjectDir)*.cs $(ProjectDir)Resources
In your code, now you can get the content of the files like this (I suppose the name of the resources file is Resource1.resx:
// Get the source of the Program.cs file.
string contents = Resource1.Program;
The project ended up like this:
Yes, I also recommend packing up the sources in a .zip or whatever during MSBuild, and packaging that .zip with your application/dll. In runtime, when an exception occurs, you get the file and method name like Aschratt describes, extract the file from the .zip and find the method in it.
I have an executable embedded into my app resources. ATM I use assembly reflection to extract the executable to its own file and then start the executive using process,START(). Is it possible to run the embedded executable straight from a stream instead of writing it to file first? Could someone please show me the most efficient way to do this please.
Here's what I gather from your question, and your comments:
You want to know if it is possible to execute an executable embedded into your program, without extracting it to disk first
Your program is a .NET program
The executable you want to execute is not a .NET program
The answer to that is: yes
However, the answer to that is also it is very, very, hard
What you have to do is, and note that I do not know all the details about this since I don't do this, but anyway:
Load the executable code into memory
Remap all addresses in the binary image so that they're correct in relation to the base address you loaded the executable at
Possibly load external references, ie. other DLL's that executable need
Remap the addresses of those references
Possibly load references needed by the just loaded referenced DLL's
Remape those dll's
Repeat 3 through 6 until done
Call the code
I'm assuming your question is "can I do 1 and 8", and the answer to that is no.
if it's a .net executable, you should be able to load it into an appdomain and start it that way:
http://msdn.microsoft.com/en-us/library/system.reflection.assembly.load.aspx
Very simple actually:
byte[] bytes = File.ReadAllBytes(path);
a = Assembly.Load(bytes);
Now instead of reading the bytes from a file, read it from the resource and you're done. Actually there is a very good article on that: Dynamically Loading Embedded Resource Assemblies
If you don't want it on a hard drive, you could possible look at saving it to a ram-drive and then run it from there.
It can be done without your native EXE having to touch the disk.
See here....it shows an example of a "process" image being embedded as a Resource. It's read into memory, and then CreateProcess and a number of other things are done to build a valid running "process".
http://www.rohitab.com/discuss/topic/31681-c-run-program-from-memory-and-not-file/
Alright, so I'm working on programming my own installer in C#, and what I'd like to do is something along the lines of put the files in the .exe, so I can do
File.Copy(file, filedir);
Or, if this isn't possible, is there another way of doing what I am attempting to do?
I wouldn't code my own installer, but if you truely want to embed files into your assembly you could use strongly typed resources. In the properties dialog of your project open up the "Resources" tab and then add your file. You'll then be able to get the file using:
ProjectNamespace.Properties.Resources.MyFile
Then you'll be able to write the embedded resource to disk using:
System.IO.File.WriteAllBytes(#"C:\MyFile.bin", ProjectNamespace.Properties.Resources.MyFile);
Honestly, I would suggest you NOT create your own installer. There are many many issues with creating installers. Even the big installer makers don't make their own actual installers anymore, they just create custom MSI packages.
Use Mirosoft Installer (MSI). It's the right thing to do. Make your own custom front-end for it, but don't recreate the already very complex wheel that exists.
UPDATE: If you're just doing this for learning, then I would shy away from thinking of it as "an installer". You might be tempted to take your "research" and use it someday, and frankly, that's how we end up with so many problems when new versions of Windows come out. People create their own wheels with assumptions that aren't valid.
What you're really trying to do is called "packaging", and you really have to become intimately familiar with the Executable PE format, because you're talking about changing the structure of the PE image on disk.
You can simulate it, to a point, with putting files in resources, but that's not really what installers, or self-extractors do.
Here's a link to Self-Extractor tutorial, but it's not in C#.
I don't know enough about the .NET PE requirements to know if you can do this in with a managed code executable or not.
UPDATE2: This is probably more of what you're looking for, it embeds files in the resource, but as I said, it's not really the way professional installers or self-extractors do it. I think there are various limitations on what you can embed as resources. But here's the like to a Self-Extractor Demo written in C#.
I'm guessing here, but if you are trying to store resources in your application before compilation, you can in the Project Explorer, right click a file you would like to add, chose properties and change the type to Embedded Resource.
You can then access the embedded resources later by using the instructions from this KB:
http://support.microsoft.com/kb/319292
in case you simply want to store multiple files in a single file storage (and extract files from there, interact etc.) you might also want to check out NFileStorage, a .net file storage. written in 100% .NET C# with all sources included. It also comes with a command line interpreter that allows interaction from the command line.