I have inherited a project from a previous developer. All the ASP .NET code behind files are contained within a .dll and the original files are unavailable. Is there any reliable decompiler out there that produces fairly readable code? I've heard mixed responses while browsing other forums - some say there are applications that will decompile .dll files, others say they just produce practically unusable assembly code. Thoughts?
Thanks!
You could try Red Gate's Reflector with the FileDisassembler plugin. Also your heritage seems a little strange. What did the previous developer do with the source code? Didn't he use source control, performed backups? The usability of the source code produced by disassembling a .NET assembly will depend on whether the person that wrote the source code obfuscated it when compiling.
You cannot produce maintainable, properly-designed source code by reverse-engineering a DLL. With clever hacking, you'll be able to alter it to do specific things. Typically, you'll find tutorials on how to bypass licensing/registration checks. (Some of them for stealing my software!)
But your effort will be probably 10x harder than if you had the source code. IMO, you're probably better off treating it as a black box, studying the inputs/outputs, behavior, design documents (if any), etc.. Reverse-engineer REQUIREMENTS from what you see the DLL doing and what the host application needs to do with it. And then get funding/approval for a new project to build a new one. With source code!
Otherwise, your "inheritance" is a liability that you should quickly distance yourself from.
Edit: I missed the part about .net. I don't know much about that, your mileage may be better than a native binary.
--
Chris
I use jetbrains dotpeek
Sometimes you just have to decompile
Related
I'd like to know whether it's possible to encrypt the compiled code in a Unity3D build in a way that de-compiling dlls won't give access to the legible source code to a potential hacker.
Cosmore pointed out in this post that it's possible to
'encrypt the assembly dlls and modify the mono loader (libmono.so)'
My question is, has anybody done this? If so, how? And can it be done on Windows, Mac and Linux builds?
If this is not possible, is there another way?
But the hacker should be capable to run the build (ie. play the game)?
Then in principle it's not possible. While you can encrypt the code, you have to also provide the key, so people can play it (decrypt).
So you are just adding one more layer of obfuscation for hacker. A seasoned hacker will simply disassemble the dll loader and put a breakpoint to a place where the content is decrypted already, and dump that for further tinkering.
That said, not every hacker is a seasoned hacker, and few layers of (unexpected) obfuscation may turn them away. So practically some encryption/obfuscation is done by some people, even if in principle it's hopeless.
I spent some time to learn C++/CLI, I feel it is powerful .Net language specially in interoperability concept. I think it will be great step if this language will extend its interoperability to include asp.net, till now the recent version doesn't support asp. But I don't know if there is a plan to do that in future version. Is there any reason that made the last version of C++/CLI can not deal with asp like C# or VB?
C++/CLI was never meant as a general-purpose language. It pretty much exists just for interoperability purposes.
If you have a C/C++ library that you want to use in your .Net application (be it your own code or something like WinAPI), C++/CLI is a good way to either create a managed wrapper for that library or to completely write the whole application, if that's not that much work.
Other than that, you should probably use C# (I think it doesn't make much sense to learn VB.NET if you already know C++). Other alternatives are F# if you think your application would benefit from a functional style. Or IronPython (or IronRuby) if you think you would benefit from dynamic typing.
And of course, you can mix the languages if part of the application would be better in one of them and other part in different one.
Another reasons against using C++/CLI at all are its weak support in VS (no IntelliSense) and the ability of C# to interoperate with native DLLs using P/Invoke.
To reiterate, use C++/CLI if you need to interoperate with native DLLs or already written C/C++ code. For other tasks, you should probably use C#.
The Visual C++ compiler does not support partial class, that is, until C++/CX come along with the help of WinRT projection. The one-obj-file-per-cpp tradition is hard to break.
Without the partial class feature, form designers need to edit the same file you are working on. That means parsing a file with a lot of irrelevant text, dealing with macros, etc, and most importantly avoiding bugs that would replace your important code as designer-generated. I can't think of many teams want to deal with that, especially for small teams like the Settings editor.
Besides, C++ parsers are slower than those for simpler languages. For web designers, if switching to a similair language can get a faster designer and compiler, why not?
I'm not sure if there's any reason ASP.NET does not natively support C++ inline within aspx files besides the development team didn't think it was worth the cost (I'm assuming this is what you mean).
You should be able to implement code behinds in C++, however. This should get you 95% of the way there, although you'll still need to code your pages in C# or VB.NET.
http://www.codeproject.com/KB/mcpp/helloworldmc.aspx (not my article, just a reference)
For open source projects, it's sometimes difficult to find clear build instructions. As a user, I sometimes have to figure out a build process for a piece of software, but then have no obvious way to make that information widely available. What are good ways to release that information?
Someone please make this a community wiki.
The first place I tend to look is in a readme file at the root of the source tree.
Another option, of course, is, if there's a documentation page for the project (and shouldn't there be?) you could have a document there that is specifically about building.
One thing I've always wondered about is how software patches work. A lot of software seems to just release new versions on their binaries that need to be installed over older versions, but some software (operating systems like Windows in particular) seem to be able to release very small patches that correct bugs or add functionality to existing software.
Most of the time the patches I see can't possibly replace entire applications, or even small files that are used within applications. To me it seems like the actual binary is being modified.
How are these kinds of patches actually implemented? Could anyone point me to any resources that explain how this works, or is it just as simple as replacing small components such as linked libraries in an application?
I'll probably never need to do a deployment in this manner, but I am curious to find out how it works. If I'm correct in my understanding that patches can really modify only portions of binary files, is this possible to do in .NET? If it is I'd like to learn it since that's the framework I'm most familiar with and I'd like to understand how it works.
This is usually implemented using binary diff algorithms -- diff the most recently released version against the new code. If the user's running the most recent version, you only need to apply the diff. Works particularly well against software, because compiled code is usually pretty similar between versions. Of course, if the user's not running the most recent version you'll have to download the whole thing anyway.
There are a couple implementations of generic binary diff algorithms: bsdiff and xdelta are good open-source implementations. I can't find any implementations for .NET, but since the algorithms in question are pretty platform-agnostic it shouldn't be too difficult to port them if you feel like a project.
If you are talking about patching windows applications then what you want to look at are .MSP files. These are similar to an .MSI but just patch and application.
Take a look at Patching and Upgrading in the MSDN documents.
What an .MSP files does is load updated files to an application install. This typically is updated dll's and resource files, but could include any file.
In addition to patching the installed application, the repair files located in C:\WINDOWS\Installer are updated as well. Then if the user selects "Repair" from Add / Remove programs the updated patch files are used as well.
I'm thinking that the binary diff method discussed by John Millikin must be used in other operating systems. Although you could make it work in windows it would be somewhat alien.
My company has a common code library which consists of many class libary projects along with supporting test projects. Each class library project outputs a single binary, e.g. Company.Common.Serialization.dll. Since we own the compiled, tested binaries as well as the source code, there's debate as to whether our consuming applications should use binary or project references.
Some arguments in favor of project references:
Project references would allow users to debug and view all solution code without the overhead of loading additional projects/solutions.
Project references would assist in keeping up with common component changes committed to the source control system as changes would be easily identifiable without the active solution.
Some arguments in favor of binary references:
Binary references would simplify solutions and make for faster solution loading times.
Binary references would allow developers to focus on new code rather than potentially being distracted by code which is already baked and proven stable.
Binary references would force us to appropriately dogfood our stuff as we would be using the common library just as those outside of our organization would be required to do.
Since a binary reference can't be debugged (stepped into), one would be forced to replicate and fix issues by extending the existing test projects rather than testing and fixing within the context of the consuming application alone.
Binary references will ensure that concurrent development on the class library project will have no impact on the consuming application as a stable version of the binary will be referenced rather than an influx version. It would be the decision of the project lead whether or not to incorporate a newer release of the component if necessary.
What is your policy/preference when it comes to using project or binary references?
It sounds to me as though you've covered all the major points. We've had a similar discussion at work recently and we're not quite decided yet.
However, one thing we've looked into is to reference the binary files, to gain all the advantages you note, but have the binaries built by a common build system where the source code is in a common location, accessible from all developer machines (at least if they're sitting on the network at work), so that any debugging can in fact dive into library code, if necessary.
However, on the same note, we've also tagged a lot of the base classes with appropriate attributes in order to make the debugger skip them completely, because any debugging you do in your own classes (at the level you're developing) would only be vastly outsized by code from the base libraries. This way when you hit the Step Into debugging shortcut key on a library class, you resurface into the next piece of code at your current level, instead of having to wade through tons of library code.
Basically, I definitely vote up (in SO terms) your comments about keeping proven library code out of sight for the normal developer.
Also, if I load the global solution file, that contains all the projects and basically, just everything, ReSharper 4 seems to have some kind of coronary problem, as Visual Studio practically comes to a stand-still.
In my opinion the greatest problem with using project references is that it does not provide consumers with a common baseline for their development. I am assuming that the libraries are changing. If that's the case, building them and ensuring that they are versioned will give you an easily reproducible environment.
Not doing this will mean that your code will mysteriously break when the referenced project changes. But only on some machines.
I tend to treat common libraries like this as 3rd-party resources. This allows the library to have it's own build processes, QA testing, etc. When QA (or whomever) "blesses" a release of the library, it's copied to a central location available to all developers. It's then up to each project to decide which version of the library to consume by copying the binaries to a project folder and using binary references in the projects.
One thing that is important is to create debug symbol (pdb) files with each build of the library and make those available as well. The other option is to actually create a local symbol store on your network and have each developer add that symbol store to their VS configuration. This would allow you to debug through the code and still have the benefits of usinng binary references.
As for the benefits you mention for project references, I don't agree with your second point. To me, it's important that the consuming projects explicitly know which version of the common library they are consuming and for them to take a deliberate step to upgrade that version. This is the best way to guarantee that you don't accidentally pick up changes to the library that haven't been completed or tested.
when you don't want it in your solution, or have potential to split your solution, send all library output to a common, bin directory and reference there.
I have done this in order to allow developers to open a tight solution that only has the Domain, tests and Web projects. Our win services, and silverlight stuff, and web control libraries are in seperate solutions that include the projects you need when looking at those, but nant can build it all.
I believe your question is actually about when projects go together in the same solution; the reason being that projects in the same solution should have project references to each other, and projects in different solutions should have binary references to each other.
I tend to think solutions should contain projects that are developed closely together. Such as your API assemblies and your implementations of those APIs.
Closeness is relative, however. A designer for an application, by definition, is closely related to the app, however you wouldn't want to have the designer and the application within the same solution (if they are at all complex, that is). You'd probably want to develop the designer against a branch of the program that is merged at intervals further spaced apart than the normal daily integration.
I think that if the project is not part of the solution, you shouldn't include it there... but that's just my opinion
I separate it by concept in short