I have a few questions regarding the structure of a Portable Executable.
Now, I found a great start through a couple of well written articles both here and here; however, I still do not quite have my answer.
I believe, and please, correct me if I'm wrong here, that data in a certain section of the PE structure is what's loaded and run by the operating system. For example, take the .text and the .data sections.
Based on what I've read, the .data section holds instrunctions of some sort, while the .text section holds the actual data to be run.
I'm curious to know whether or not it's possible to store a file's data in the .text section, and dynamically move it over to the .text section which would then automatically (load/launch/run) the file's data which is now in the .text section.
If you are confused about what I'ma asking, allow me to paraphrase.
Where (in what section) is the main data of a file stored?
How would I go about moving data between sections in C#? I'm assuming I'd have to use pointers for this.
Am I correct in thinking that such a functionality would even work?
Am I correct in thinking that such a functionality would even work?
No :)
It's not clear to me at all what you want to accomplish - you sound like you're talking native PEs because .NET PEs don't really have anything other than data in the PE.
In any case, the PE is mapped by Windows while the module (EXE or DLL) is loaded, so you can't really modify it on the fly.
For native code PE or PE+ files these questions would be answered a lot different, and these things would be plausible.
However, for a .NET assembly encapsulated in a PE, things change a lot. The PE/PE+ is just a storage container barely referenced by the OS loader.
You can load into memory an assembly and execute it, so therefore what you propose is theoretically possible. HOWEVER, it has nothing to do with moving code from one section of a PE to another.
You would dynamically allocate read+write virtual memory, write your code to it, change the attributes to read+execute (adding execute, removing write), then invoke the appropriate .NET assembly loader code. Lookup the various Invoke methods for that.
Related
When troubleshooting our applications, in many situations I cannot be sure what branch the assemblies originally come from, due to an imperfect release cycle and human error.
(We have quite a lot of different bugfix/feature/test/release branches etc. in our TFS).
The PDB-files can help sometimes, in a test environment at least, but sometimes they're missing or outdated / belong to assemblies from another branch.
So, I was trying to think of a way to include the source branch information inside the assembly directly.
Surprisingly, I could not easily find a straight forward way online to accomplish this.
My answer below explains my approach. I would be happy about feedback or alternative solutions.
In short: I created a custom attribute that I put intoAssemblyInfo.cs. Inside the attribute's constructor, the server path for the current assembly is queried from TFS and compiled into it.
It's basically a combination of the following:
Can I add custom version strings to a .net DLL?
How do I get the path of the assembly the code is in?
Get TFS mapped folder of a local sub folder of the solution?
(Note: I cannot post the actual source code due to company restrictions, but I think it's pretty straight forward.)
To get the attribute's value later is unfortunately not as easy as getting the version number from the DLL-file's properties, but at least it is possible now to get the information I need with minimum effort. (I use a small PowerShell script for that.)
One of my colleague asked me a question:
"I want a small portion of the c# dll (probably a helper function he
may ask) to be used in my project, do i need to use whole package? But
seems like to be it's size is high. so will it make any issues related
to performance?"
But i said NO. The reason for my answer was:
"Suppose we are building a web application contains of 200 pages and
everything will be finally converted to a single dll. Do you survive a
page / portion of dll for each request? No! we built as a single
assembly(application) and use. The same answer applied here".
Am i right? or is really making any difference?
Every library packed as a component to survive for a different purpose of a different need. How come a performance issue will come over?
Is there any article says about loading big assembly and response time?
It's better to have a single large DLL than many smaller DLLs - the size of the DLL doesn’t really matter. The cost of loading a large DLL is basically equal to loading a small DLL.
We have a program that is used in one specific industry and has strings that are specific to that industry. We now have the situation where it can be used in another industry and we want to customise the strings for that industry without duplicating our code base.
The problem space appears very similar to localisation. Are we going to have a separate resource assembly for each industry? If so when would we choose which assembly to use, could we do this at install time or would it need to be at compile time?. How do we keep the separate resource assemblies synchronised, so that the same keys to messages appear in each one?
What is the best way to do this?
Let me re-phrase it: you have an industrial application which could be used in various industries and the only things that are different are resources (that is strings, layout, maybe images and sounds). The other code stays the same.
In such case your problem is not just similar it is actually identical to Localization. And as such you can use Satellite Assemblies.
Now, it is up to you if you want to package such created applications separately or distribute one application with both problem spaces.
The first seem more realistic scenario to me - you would need to decide on which .resx file to include at compile time (i.e. during project preparation you would overwrite existing resources with problem-space resources and then proceed with compilation, that should give you different flavors of your application; I would also modify their names in such case).
The latter would require you to manually instantiate ResourceManager at runtime to read from valid satellite assembly - it could be based on some configuration file. It means more work (you would need to actually modify your code) and you will end up distributing both flavors of your application at once, that is you won't have control over how your customers will use it. From the business perspective it could be a little dangerous.
EDIT (Note to self: read whole question carefully)
Somehow I managed to miss install time vs. compile time. I believe compile time is the answer because of the same reason I gave in config-driven switch section: you would package the resources and you won't have any control on how customers use it. Some clever guy would figure it out, that is for sure.
I would recommend having a properties file with key value pairs. Where you currently have industry specific strings, replace them with calls to the properties file. Obviously you would cache these strings in some container. I don't know the C# container - Java would use java.util.Properties.
aerospace.props:
INDUSTRY_NAME=aerospace
INDUSTRY_START_YEAR=1903
manufacturing.props:
INDUSTRY_NAME=manufacturing
INDUSTRY_START_YEAR=1600
I want to run a thread that checks the memory image of the current executable, for protection reasons. Any ideas how to do CRC on the current memory executable (WinAPI or .NET way)? My app is written in .NET.
Signing your assemblies will give you as good verification as you can get with relation to verify CRC of .Net assembly (see Rodrigo's answer).
If you are worried that someone will patch assembly at runtime you probably worried too much. It requires better understanding of runtime to in memory patch IL for a method that is already JIT'ed compared to simply disassembling your .Net code and fixing it up (including removal of your CRC checks).
If you doing it more for fun than you shoud be able to find base address where assembly is loaded and compute CRC of some sort... or see if pages are marked as modified...
I think that's going to be quite difficult in .NET. When an executable is loaded, it can potentially be split up and loaded into several different regions in memory. You'll need to acquaint yourself with the Window's Executable format:
http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx
as well as the Windows executable loading process.
You'll might also want to concern yourself with depenency dlls as well. You'll be making so many native calls, that you might want to consider doing this in C.
Not much of an answer, I'm afraid.
Any runtime check you do will have the following drawbacks:
False positives. Because this is .NET, you cannot assume the runtime doesn't modify your in-memory code. You may detect a hack where there is none.
Any run-time check you make will be no more secure than the code you are trying to protect. This includes any runtime mechanism you create in your app such as periodic CRC checks, sentinel processes, or even checking with a server where the request can be faked.
You will decrease performance in your legitimate application, where the pirated version will run better without all these checks
You will do nothing to solve patching your EXE.
I understand that you are just trying to make it as hard as possible, even though it's not 100% uncrackable. But the solutions you propose (and likely any solution you can implement yourself) will do extremely little to thwart any average cracker.
Because this is such a demanded feature though, I would look for 3rd party solutions where they have put forth the effort for a sophisticated solution which can be updated as cracking techniques evolve. I cannot recommend any personally though.
I am not aware of a way to do this in .NET.
If you are interested in protecting you executables, you can generate a new key with sn and add it to AssemblyInfo.cs, so that if the application is modified at least it will not run.
Jon Skeet's Miscellaneous Utility Library contains a method to compute the Adler32 checksum on a stream. Its usage would be:
MiscUtil.Checksum.Adler32.ComputeChecksum(stream);
As for creating a memorystream out of the assembly that is currently running... I don't know if that is even possible (or advisable).
How do I protect the dlls of my project in such a way that they cannot be referenced and used by other people?
Thanks
The short answer is that beyond the obvious things, there is not much you can do.
The obvious things that you might want to consider (roughly in order of increasing difficulty and decreasing plausibility) include:
Static link so there is no DLL to attack.
Strip all symbols.
Use a .DEF file and an import library to have only anonymous exports known only by their export ids.
Keep the DLL in a resource and expose it in the file system (under a suitably obscure name, perhaps even generated at run time) only when running.
Hide all real functions behind a factory method that exchanges a secret (better, proof of knowledge of a secret) for a table of function pointers to the real methods.
Use anti-debugging techniques borrowed from the malware world to prevent reverse engineering. (Note that this will likely get you false positives from AV tools.)
Regardless, a sufficiently determined user can still figure out ways to use it. A decent disassembler will quickly provide all the information needed.
Note that if your DLL is really a COM object, or worse yet a CLR Assembly, then there is a huge amount of runtime type information that you can't strip off without breaking its intended use.
EDIT: Since you've retagged to imply that C# and .NET are the environment rather than a pure Win32 DLL written in C, then I really should revise the above to "You Can't, But..."
There has been a market for obfuscation tools for a long time to deal with environments where delivery of compilable source is mandatory, but you don't want to deliver useful source. There are C# products that play in that market, and it looks like at least one has chimed in.
Because loading an Assembly requires so much effort from the framework, it is likely that there are permission bits that exert some control for honest providers and consumers of Assemblies. I have not seen any discussion of the real security provided by these methods and simply don't know how effective they are against a determined attack.
A lot is going to depend on your use case. If you merely want to prevent casual use, you can probably find a solution that works for you. If you want to protect valuable trade secrets from reverse engineering and reuse, you may not be so happy.
You're facing the same issue as proponents of DRM.
If your program (which you wish to be able to run the DLL) is runnable by some user account, then there is nothing that can stop a sufficiently determined programmer who can log on as that user from isolating the code that performs the decryption and using that to decrypt your DLL and run it.
You can of course make it inconvenient to perform this reverse engineering, and that may well be enough.
Take a look at the StrongNameIdentityPermissionAttribute. It will allow you to declare access to your assembly. Combined with a good code protection tool (like CodeVeil (disclaimer I sell CodeVeil)) you'll be quite happy.
You could embed it into your executable, and extract and loadlibrary at runtime and call into it. Or you could use some kind of shared key to encrypt/decrypt the accompanying file and do the same above.
I'm assuming you've already considered solutions like compiling it in if you really don't want it shared. If someone really wants to get to it though, there are many ways to do it.
Have you tried .Net reactor? I recently came across it. Some people say its great but I am still testing it out.
Well you could mark all of your "public" classes as "internal" or "protected internal" then mark you assemblies with [assembly:InternalsVisibleTo("")] Attribute and no one but the marked assemblies can see the contents.
You may be interested in the following information about Friend assemblies:
http://msdn.microsoft.com/en-us/library/0tke9fxk(VS.80).aspx