OK so that title sucks a little but I could not think of anything better (maybe someone else can?).
So I have a few questions around a subject here. What I want to do is create a program that can take an object and use reflection to list all its properties, methods, constructors etc. I can then manipulate these objects at runtime to test, debug and figure out exactly what some of my classes / programs are doing whilst they are running, (some of them will be windows services and maybe installed on the machine rather than running in debug from VS).
So I would provide a hook to the program that from the local machine (only) this program could get an instance of the main object and therefore see all the sub objects running in it. (for security the program may need to be started with an arg to expose that hook).
The "reflection machine" would allow for runtime manipulation and interrogation.
Does this sound possible?
Would the program have to provide a hook or could the "reflection machine" take an EXE and (if it knew all the classes it was using), create an object to use?
I know you can import DLL's at runtime so that it knows about all sorts of classes, but can you import individual classes? I.E. Say I have project 'Y' that is not compiled to a DLL but I want to use the "reflection machine" on it, can I point at that directory and grab the files to be able to reference those classes?
EDIT: I would love to try and develop it my self but I already have a long list of projects I would like to do and have already started. Why reinvent the wheel when there is already a great selection to choose from.
Try looking at Crack.NET. It is used to do runtime manipulation and interrogation on WPF/WinForms but the source is available and might be a good start if it already doesn't meet your needs.
It sound as if Corneliu Tusnea's Hawkeye might be close to what you're looking for runtime interrogation of objects/properties/etc. He calls it the .NET Runtime Object Editor. I'm not sure if the homepage I linked to above or the CodePlex project is the best place to start.
It's a bit out of date now, I think, but there's an earlier version of it on CodeProject where you can see the source code for how and what he did.
Powershell actually does nearly all of this, if I properly understand what you are saying.
See this answer on how to build a "reflection engine".
All you need to do is to drop that set of machinery in the your set of available
runtime libraries and it does what you want, I think.
(It might not be as easy as I've made it sound in practice).
My guess is you'll also want a runtime compiler, so that you can
manufacture instrumented/transformed variants of the program under inspection
to collect the runtime data you want. You may find that such
machinery provide static analysis results that let you avoid
doing the runtime analysis in many cases.
Related
I am embedding IronPython into my game engine, where you can attach scripts to objects. I don't want scripts to be able to just access the CLR whenever they want, because then they could pretty much do anything.
Having random scripts, especially if downloaded from the internet, being able to open internet connections, access the users HDD, or modify the internal game state is a very bad thing.
Normally people would just suggest, "Use a seperate AppDomain". However, unless I am severely mistaken, cross-AppDomains are slow. Very slow. Too slow for a game engine. So I am looking at alternatives.
I thought about compiling a custom version of IronPython that stops you from being able import clr or any namespace, thus limiting it to the standard library.
The option I would rather go with goes along the following lines:
__builtins__.__import__ = None #Stops imports working
reload = None #Stops reloading working (specifically stops them reloading builtins
#giving back an unbroken __import___!
I read this in another stack overflow post.
Assume that instead of setting __ builtins_._ import__ to none, I instead set it to a custom function that lets you load the standard API.
The question is, using the method outlined above, would there be any way for a script to be able to be able to get access to the clr module, the .net BCL, or anything else that could potentially do bad things? Or should I go with modifying the source? A third option?
The only way to guarantee it is to use an AppDomain. I don't know what the performance hit is; it depends on your use case, so you should measure it first to make sure that it actually is too slow.
If you only need a best-effort system, and if the scripts don't need to import anything, ever, and you supply all of the objects they need from the host, then your scheme should be acceptable. You can also avoid shipping the Python standard library, which will save some space.
You'll want to check the rest of the builtins for anything that might talk to the outside world; open, file, input, raw_input, and execfile come to mind, but there may be others. exec might be an issue as well, and as it's a keyword it might be trickier to turn off if there are openings there. Never underestimate the ability of a determined attacker!
I have embedded Iron Python in apps before and shared similar security concerns. What I did to help mitigate the risk was to create special objects just for the scripting run-time that were essentially wrappers around my core objects that only exposed "safe" functionality.
Another benefit from creating objects just for scripting is that you can optimize them for scripting with helper functions that make your scripts more terse and tidy.
Appdomain or not, there is nothing stopping somebody from loading an external .py module in their script.... Its a price you pay for the flexibility.
Is it possible to create an app in C++ or C# so I can patch a exe file for copy protection purposes?
So if a user has an account on my website with the software tied to it, I can require them to enter a key which is checked with the database and then execute or show an error.
When I say "patch", I mean applying to an already built/compiled exe. Thanks for the help. :)
Its easily possible, many packers and protection systems like Themida do this, however, things like this can be easily cracked, thus you need to evaluate the effort vs reward required for someone to hack your program.
However, to directly answer your question, your best bet is to hook the code entry point defined in the PE and have it redirect to your checker (OS dependant). UPX is an opensource executable packer, and should provide a good base to use or point of reference asa it hooks the entry of the executable to run the unpacking engine. You can also find a few articles on packers and protectors here.
Depending on how complicated your copy protection is, "patching" may be in the simplest case just boiled down to writing a few bytes at selected offsets in the protected EXE file. This project may be interesting.
I have a C# WPF application. It is designed to work on any and all files. Right now, it accepts 'input' by means of commandline arguments as well as drag and drop to a control in its main window. However, ideally I want people to rightclick any file/multiple files and have them be able to simply click 'Awesomify this'. (That's not the real name. :P)
I've got some experience with context menus from years ago, so all in all, it isn't too current. As such, I am looking for advice on the best way to implement this feature. All examples following are based on what I see using W7.
Generally, I understand there's basically two ways: pure registry, and registry + COM object.
The former has a certain elegance to it, since I don't want anything special; however, from what I can tell by documentation, these menu items always clump up at the same place as the primary file actions (Open, Preview, Print). However, I'd like my item to appear lower on the totem pole. If I look at my personal contextmenu for a random file, I'd want it to be at the 'spot' UltraEdit and Malwarebytes Anti-Malware stick themselves. Sticking my entry under HKCR\*\shell\AwesomeTest gets me my item, but no matter what I pick for the Position, I get two different extremes I don't like: Top puts it above the default item, Bottom puts it right above Properties. I want it inbetween Share with and Restore previous versions, which where most general-purpose tools seem to find a home.
Some more registry digging seems to point out the apps I wish to mimic use the COM object route. And that would bring me (I believe) back to native code. Which would then bring with it all the hells of 32-bit and 64-bit development I am trying to avoid.
Is there anything I am missing? Likewise, other than the MSDN page regarding context menu handlers which I have looked through and found to be rather unhelpful (as it seems to skim a lot without diving into the more precise details regarding placement and such), are there any good sources regarding this problem?
Another thing I've not been able to figure out just yet is how I can properly add IDropTarget support to my .NET WPF application yet, so information on that would also be welcome.
If anyone has an instant answer, well that would be nice, but I am mainly trying to find the right path to take without wasting several days on the paths that are dead-ends. Which there seem to be a lot of. :(
IContextMenu::QueryContextMenu(). Shell extensions are in the domain of C++, very unpleasant in C#, .NET 4.0 required. A sample project that uses it is here.
I would like to build an application framework that is mainly interpreted.
Say that the source code would be stored in the database that could be edited by the users and always the latest version would be executed.
Can anyone give me some ideas how does one implement sth like this !
cheers,
gabor
In .Net, you can use reflection and CodeDOM to compile code on the fly. But neither approach is really very simple or practical. Mono has some ability to interpret c# on the fly as well, but I haven't looked closely at it yet.
Another alternative is to go with an interpreted .Net language like Boo or IronPython as the language for your database code.
Either way, make sure you think long and hard about the security of your platform. Allowing users to execute arbitrary code is always an exercise fraught with peril. It's often too tempting to look for a simple eval() method, and even if one exists, that is not good enough for this kind of scenario.
Try Mono ( http://www.monoproject.org ). It supports many scripting languages including JavaScript.
If you don't want to use any scripting you can use CodeDOM or Reflection (see Reflection.Emit).
Here are really useful links on the topic :
Dynamically executing code in .Net (Here you can find a tool which can be very helpul)
Late Binding and On-the-Fly Code
Generation Using Reflection in C#
Dynamic Source Code Generation and
Compilation
Usually the Program uses a scripting language for the scriptable parts, i.e. Lua or Javascript.
To answer your technical question: You don't want to write your own language and interpreter. That's too much work for you to do. So pick some other language, say Python or Lua, and look for the documentation that lets your C program hand it blocks of code to execute. Of course, the script needs to be able to do something, so you'll need to find how to expose your program's objects to the script. Also, what will happen if a client is running the program when you update its source code in the database? Should the client restart? Are you going to store the entire program as a single row in this database, or did you want to store individual functions? That affects how you structure your updates.
To address other issues with your question: Why do you want to do this? Making "interpreted language" part of your design spec for a system is not often a good sign. Is the real requirement something like this: "I update the program often and I want users to always have the latest copy?" If so, there are other, better ways to go about this (just give us your actual scenario and requirements).
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