Thread: Programmatically add resources to exe file

Exe & data block generation

It's for C++ but you should get the idea. Read the whole thread.

In C# you use the Platform Invocation Services through PInvoke() to call in WinAPI functions. I'm still learning C# and haven't dabble on this yet. But that's pretty much how you would import these functions.

There's, I believe, plenty of tutorial material on the web. There's also a centralized resource at pinvoke.net: the interop wiki! where you can get the necessary import declarations to your code. For instance, this is the declaration for UpdateResource: pinvoke.net: UpdateResource (kernel32) (btw, if you ever try their little tool for VS2008 and get it to work, let me know. I cannot seem to get it to work)

However, let me tell you I solved the problem by simply appending the data to the executable at runtime. The only thing I needed to make sure was that the data had a recognizable header (of which format I defined myself) I could later use for proper unmarshalling. There was no need to get into the WinAPI and depending on your specifics, hardly you will need to do it under C# either.

Why you feel this is not satisfying?

The information is there along with links to the respective MSDN documentation. Note you will also need BeginUpdateResource and EndUpdateResource. But that's also described there.

As for any other specifics, I don't know. Study the documentation and try stuff. That's the way with the WinAPI, i'm afraid.

IntPtr hUpdate -> handle to a BeginUpdateResource instance.
string lpType -> Pointer to a C-style string with the name of the resource type, or one of the following constants: Resource Types
string lpName - > duh! The resource name
ushort wLanguage -> The language identifier (Language Identifiers (Windows))
IntPtr lpData -> Pointer to the actual resource
uint cbData -> Size in bytes of the resource

Regarding lptype, pass it a c-style string of your own or RT_RCDATA if the resource type is not one of the resources defined in the Resources Types link. Otherwise, the function will try to validate the resource format and will fail.

In C# you use the Platform Invocation Services through PInvoke() to call in WinAPI functions. I'm still learning C# and haven't dabble on this yet. But that's pretty much how you would import these functions.

That's one way of doing it but it is quite clunky. You can also create a C++/CLI ref class that encapsulates some of the API functions you wish to call. The C++/CLI code can talk to both .NET objects and to native objects. This makes it a perfect go-between for native and non-native code.

Once you have your C++/CLI DLL you simply add it as a reference in your C# app and you can now access the code. To communicate the other way around you can add the C# exe or DLL as a reference to your C++/CLI project and access its code by a using statement. Once everything is in place you can freely communicate back and forth between native and non-native and there are no ugly C DLLs and the code to use it is very simple.

If you are going to go this route keep in mind you will have to use .NET data types in your C++/CLI interface to talk to C# and you will use native types that will be converted to .NET types for communication the other direction.

But in C++/CLI you can create any ref class you want and and even return it to C# as a managed pointer (MyObject ^object) provided there are no native objects in it. One big gotcha is you cannot have any STL objects or native data members in the C++/CLI ref class. But this can be worked around easily enough using the PIMPL idiom. There are some other gotchas but overall it's very nice and you can do some very cool things with it. I do not recommend trying to pass native objects to C# or managed objects to native code. Your C++/CLI interface and impl should be the mediator between the two pieces of code. Remember any cool .NET stuff you can access in C# you can also access from C++/CLI. The only difference between the two pieces of code is the syntax of the language that is using .NET. On an interesting side note your C++/CLI DLL can also be accessed from a VB project that is .NET compatible. Essentially any language that supports .NET on the Windows platform will be able to talk to your C++/CLI DLL.

C# <------> C++/CLI <-------> C/C++

Originally Posted by Devils Child

well, i'm not so much into c++ and as you see the code above, i managed to add a resource to the c# exe. unfortunately it seems like PE resources and c#-executable-resources are not the same... resource hacker can't find any c# resources for example...

C# executables are not created with the PE format. When you create a C# binary (exe or dll) you define an assembly. Despite sharing the same file extension with regular PE binaries .net assemblies are vastly different. They are composed of CIL code (and not platform specific bytecode as is the case with your regular PE), plus any metadata necessary to describe its contents and itself.

In order to have access to a .net assembly resources, you'll need to use programs that understand the .net assembly format. The bits of the PE format that remain in a .Net assembly actually could help you locate the resources inside a .net assembly. But its cumbersome. So you can still use a PE reader to find those resources location.

Asmex claims to be able to locate and extract .net assembly resources. Of course, because your resources were inserted through UpdateResource, instead of normal C# language features, I'm unsure as to what the results will be.

...

Meanwhile, I decided to explore a little more about this (thanks Bubba. C++<->CIL seems a much more elegant solution).

This is what came up after only a few seconds searching:
Embedding and Using Resources in C#
If this doesn't answer your problem, I don't know what will.

ok, so it seems i'm not gonna get any further this way. i added a pattern at the end of the file and written the data i nedded after that pattern. not a 100% clean solution, but works.

edit: if the data is too long, it is recognized as TR/Dropper.Gen , which is not good-.-(thats one of the reasons i want to write it into the resource)
idea: maybe add it as PE resource and read it from C# somehow (but how??)

what i also need to do is to change the icon of the executable programmatically, which i tried with the code above but i didn't make any success ;(
my icon appeared in ResourceHacker as a binary file, but couldnt been displayed and neither did explorer do...
so how do i use the fortress we made yet to embedd an exe icon?

did you read the first post? it described that one application must embedd an icon and a file into another application. i managed the file via resources that is beeing read by using a unique search pattern. when just adding stuff at the end of the executable, it is beeing recognized as trojan/dropper.gen... so how do i embedd the icon now?

edit: maybe it's a good idea to just call a specific executable found on the web like

Code:

iconbinder.exe -b test.exe test.ico

does anything like this exists?

Originally Posted by Devils Child

did you read the first post?

I would say he has. But it doesn't seem you have been reading the answers or just don't like to click the links being provided.

The answer to that was already given in the form of a link. Read the thread again.