howto modifying resource on an existing assembly (.exe) ??

  • Thread starter Thread starter # Cyrille37 #
  • Start date Start date
C

# Cyrille37 #

Hello,

I would like to write a little C# program that store some text inside a
resource, without a external file storage.
For example :
- an auto extracting zip file
- or a auto decrypt gnupgp file.

I'm trying to add a resource to an existing assembly, but I failed.
I've only found how to create a new assembly, but not change a existing one.

Any idea ?

Thanks a lot,
cyrille
 
Hi,

During compilation of your assembly you can specify the resource to embed using the command line compiler of your language.

If you're using VS.NET you can add a file to your project and in solution explorer select the file, open the properties window and
choose "embedded resource".

If you can't recompile the assembly you can try using the Assembly Linker tool with the /embed switch. I'm not sure if this tool
only works with modules, however, but it would be worth a try.

%windir%\Microsoft.NET\framework\{version #}\al.exe

Assembly Linker on MSDN:
http://msdn.microsoft.com/library/d.../html/cpgrfAssemblyGenerationUtilityAlexe.asp

Worse case scenerio, you might be able to use ildasm.exe to reverse engineer your assembly and then use ilasm.exe with the
appropriate switches to recomiple while embedding your files. I wouldn't recommend this, however, unless you don't have access to
the source code, nothing else works for you and you absolutely must embed those files.

GL
 
Dave Sexton a écrit :
Hi,

During compilation of your assembly you can specify the resource to embed using the command line compiler of your language.

If you're using VS.NET you can add a file to your project and in solution explorer select the file, open the properties window and
choose "embedded resource".

If you can't recompile the assembly you can try using the Assembly Linker tool with the /embed switch. I'm not sure if this tool
only works with modules, however, but it would be worth a try.

%windir%\Microsoft.NET\framework\{version #}\al.exe

Assembly Linker on MSDN:
http://msdn.microsoft.com/library/d.../html/cpgrfAssemblyGenerationUtilityAlexe.asp

Worse case scenerio, you might be able to use ildasm.exe to reverse engineer your assembly and then use ilasm.exe with the
appropriate switches to recomiple while embedding your files. I wouldn't recommend this, however, unless you don't have access to
the source code, nothing else works for you and you absolutely must embed those files.

GL
Click to expand...

Thanks for your idea.

But I would like to make something like Winzip-Auto-extract.exe or PGP-Self-decrypt.

So I would not want to use external application like a linker.

Only one .exe file that store the program and the data (resource). When data
changed, the .exe is updated. I think I cannot modify the loaded .exe, but I can
make a copy of it to apply resource changes.

Cyrille
 
Hi,

I think that I've misunderstood your intentions.

Are you saying that you want a program to monitor changes to the source files of your embedded resources and re-embed them without
recompiling?

I'm not sure I see the point, exactly.

--
Dave Sexton

# Cyrille37 # said:
Hi,

During compilation of your assembly you can specify the resource to embed using the command line compiler of your language.

If you're using VS.NET you can add a file to your project and in solution explorer select the file, open the properties window and
choose "embedded resource".

If you can't recompile the assembly you can try using the Assembly Linker tool with the /embed switch. I'm not sure if this tool
only works with modules, however, but it would be worth a try.

%windir%\Microsoft.NET\framework\{version #}\al.exe

Assembly Linker on MSDN:
http://msdn.microsoft.com/library/d.../html/cpgrfAssemblyGenerationUtilityAlexe.asp

Worse case scenerio, you might be able to use ildasm.exe to reverse engineer your assembly and then use ilasm.exe with the
appropriate switches to recomiple while embedding your files. I wouldn't recommend this, however, unless you don't have access to
the source code, nothing else works for you and you absolutely must embed those files.

GL
Click to expand...

Thanks for your idea.

But I would like to make something like Winzip-Auto-extract.exe or PGP-Self-decrypt.

So I would not want to use external application like a linker.

Only one .exe file that store the program and the data (resource). When data
changed, the .exe is updated. I think I cannot modify the loaded .exe, but I can
make a copy of it to apply resource changes.

Cyrille
 
Dave Sexton a écrit :
Hi,

I think that I've misunderstood your intentions.

Are you saying that you want a program to monitor changes to the sourcefiles of your embedded resources and re-embed them without
recompiling?

I'm not sure I see the point, exactly.
Click to expand...

Do you know about some program like WinZip ?
Winzip can make a self-extract archive like the user got a .exe that contains
the data (original file) and the extract program. when it execute the .exe data
are extracted to their original form.

I would like to make a program like the Notepad which store the typed text in
it's .exe file, like I've got only one file (the .exe) which is storing the
program (notepad) and the stored text.

I hope to be clear enough, my english is so bad ;o{
Regards,
cyrille
 
Hi,
Do you know about some program like WinZip ?
Winzip can make a self-extract archive like the user got a .exe that contains the data (original file) and the extract program.
when it execute the .exe data are extracted to their original form.
Click to expand...

Yep. Self-extracting WinZip archive.
I would like to make a program like the Notepad which store the typed text in it's .exe file, like I've got only one file (the
.exe) which is storing the program (notepad) and the stored text.
Click to expand...

Ok. So you want a compiled program that runs a notepad-like interface, but when the user saves the file you want to embed it
directly into the running program's assembly manifest.

To be honest, I doubt that's possible and I really don't see the benefit anyway. Would you like to elaborate on why you require
this functionality?
 
Dave Sexton a écrit :
Hi,


Yep. Self-extracting WinZip archive.


Ok. So you want a compiled program that runs a notepad-like interface,but when the user saves the file you want to embed it
directly into the running program's assembly manifest.

To be honest, I doubt that's possible and I really don't see the benefit anyway. Would you like to elaborate on why you require
this functionality?
Click to expand...

It is much like a exercise and a challenge ;o)

I like to use Locknote (http://sourceforge.net/projects/locknote) to store
sensible information on my desktop. But use it to send secure data via email it
makes some to large mail, locknote is about 300 ko.

If I can make the same with .Net it will be very smaller. Very bigger when
executing but very smaller when flying over Internet.

That's why ... Not very impressive but a challenge ;o)

After spending hours on google I did not find howto do ... on the contrary, I've
found some message which say that is not possible...

Thanks for your interest !
Best Regards
Cyrille
 
Hi,

I have an idea!

Save:

1. User closes program (auto-save). (I don't think my idea will work if the program must remain open while saving)
2. Interface is hidden, but the program remains open while it completes the save operation
3. The program copies itself to the temp directory (starting to sound like a virus :)
4. It then saves the open file to the temp directory as well
5. The program runs al.exe with the /embed switch on the file and it's own copy; output to the temp directory
6. The program writes a small tool (.exe) to the temp directory, runs it using System.Diagnostics.Process.Start, and exits.
7. The tool replaces the program with the output from al.exe (if al.exe generates multiple artifacts, then instead you might have to
use my ildasm-ilasm option that I mentioned in my OP)
8. The tool runs the copy of the program using System.Diagnostics.Process.Start, supplying a startup argument to indicate that it
must complete the save operation
9. The copy of the program, executed with a special startup argument, does not display an interface
10. The copy of the program deletes all of the temporary files and exits

Open:

Load file from assembly manifest.


Hey, if you try that and it works let us know!

GL

--
Dave Sexton

# Cyrille37 # said:
Hi,


Yep. Self-extracting WinZip archive.


Ok. So you want a compiled program that runs a notepad-like interface, but when the user saves the file you want to embed it
directly into the running program's assembly manifest.

To be honest, I doubt that's possible and I really don't see the benefit anyway. Would you like to elaborate on why you require
this functionality?
Click to expand...

It is much like a exercise and a challenge ;o)

I like to use Locknote (http://sourceforge.net/projects/locknote) to store
sensible information on my desktop. But use it to send secure data via email it
makes some to large mail, locknote is about 300 ko.

If I can make the same with .Net it will be very smaller. Very bigger when
executing but very smaller when flying over Internet.

That's why ... Not very impressive but a challenge ;o)

After spending hours on google I did not find howto do ... on the contrary, I've
found some message which say that is not possible...

Thanks for your interest !
Best Regards
Cyrille
 
Dave Sexton a écrit :
Hi,

I have an idea!

Save:

1. User closes program (auto-save). (I don't think my idea will work if the program must remain open while saving)
2. Interface is hidden, but the program remains open while it completesthe save operation
3. The program copies itself to the temp directory (starting to sound like a virus :)
4. It then saves the open file to the temp directory as well
5. The program runs al.exe with the /embed switch on the file and it's own copy; output to the temp directory
Click to expand...

Argh !
You introduced a dependency !

the challenge is only ONE file.
 
Hi,

al.exe ships with the framework, and .NET is already a dependency!

--
Dave Sexton

# Cyrille37 # said:
Hi,

I have an idea!

Save:

1. User closes program (auto-save). (I don't think my idea will work if the program must remain open while saving)
2. Interface is hidden, but the program remains open while it completes the save operation
3. The program copies itself to the temp directory (starting to sound like a virus :)
4. It then saves the open file to the temp directory as well
5. The program runs al.exe with the /embed switch on the file and it's own copy; output to the temp directory
Click to expand...

Argh !
You introduced a dependency !

the challenge is only ONE file.
 
Dave Sexton a écrit :
Hi,

al.exe ships with the framework, and .NET is already a dependency!
Click to expand...

You mean al.exe is shipped with the user's .Net version, the redistributable
version, not the SDK version ?
 
Hi,

My mistake. It doesn't ship with the framework redistributable.

Oh well. I guess it's not possible then unless you feel like coding the linker's functionality into your program ;)

--
Dave Sexton

# Cyrille37 # said:
Hi,

al.exe ships with the framework, and .NET is already a dependency!
Click to expand...

You mean al.exe is shipped with the user's .Net version, the redistributable
version, not the SDK version ?
 
I would like to write a little C# program that store some text inside a
resource, without a external file storage.
For example :
- an auto extracting zip file
- or a auto decrypt gnupgp file.

I'm trying to add a resource to an existing assembly, but I failed.
I've only found how to create a new assembly, but not change a existing
one.
Click to expand...

Use standard Windows API with pinvoke.

Updating:
- BeginUpdateResource, UpdateResource, EndUpdateResource
Enumerating:
- EnumResourceLanguages, EnumResourceNames, EnumResourceTypes
(and the Ex versions for Vista)
Accessing:
- FindResource, FindResourceEx, LoadResource, LockResource, SizeofResource
 
Hi Mihai,

Will those API functions work on the managed assembly that is executing them?
 
Hi Mihai,

Will those API functions work on the managed assembly that is executing
them?
Click to expand...
Most likely not. You cannot expect to be able to change a running executable.
And I think changing executables is a bad idea in general.
It might trigger a ton of antivirus warnings (or might just be quietly
prevented).
And with Vista (when the normal user is not Admin) is going to be even more
difficult.
 
Hi Mihai,

Well the OP is unclear, but if you read the thread you'll see that the author requires to be able to modify the executable and wants
the complete program to only consist of one file. It's not looking good right now.

Any other ideas?
 
Hi Mihai,

Well the OP is unclear, but if you read the thread you'll see that the
Click to expand...
author requires to be able to modify the executable and wants
the complete program to only consist of one file. It's not looking good right now.

Any other ideas?
Click to expand...

Not really.

It might get away with some fancy tricks (for example a.exe makes a copy of
itself to tmp.exe, start tmp.exe with some switch or task file, telling it
what to do, and ends. Then tmp.exe can change a.exe, then start a.exe again,
end itself, and a.exe deletes tmp.exe)
This is complicated, but might work.

But the AV / Vista problems are still there, and there is no solution for it.
And I think this is a good thing.
Self-modifiable executables and, in general, exe changing other exe,
are dangerous beasts, and I cannot see a real use good enough to
counter-balance all the dangers.

A self-extracting exe, for deployment, yes. But a self-modifying one?

Anyway, let see what the original poster has to say :-)
 
Mihai N. a écrit :
author requires to be able to modify the executable and wants

Not really.

It might get away with some fancy tricks (for example a.exe makes a copy of
itself to tmp.exe, start tmp.exe with some switch or task file, tellingit
what to do, and ends. Then tmp.exe can change a.exe, then start a.exe again,
end itself, and a.exe deletes tmp.exe)
This is complicated, but might work.

But the AV / Vista problems are still there, and there is no solution for it.
And I think this is a good thing.
Self-modifiable executables and, in general, exe changing other exe,
are dangerous beasts, and I cannot see a real use good enough to
counter-balance all the dangers.

A self-extracting exe, for deployment, yes. But a self-modifying one?

Anyway, let see what the original poster has to say :-)
Click to expand...

Hi,

I no more argument ... You've right.
By the way. I give up my challenge.

Thanks a lot for your contribution ! It was nive to read you while trying. You
were like my coach !
;oP

Have nice time,
Regards
Cyrille
 
I no more argument ... You've right.
By the way. I give up my challenge.

Thanks a lot for your contribution ! It was nive to read you while trying. You
were like my coach !
;oP
Click to expand...

No argument :-)
And sometimes it does not matter if you finish something or not,
the trip is more important :-)
Thank you :-)
 
Back
Top