With JustDecompile, Telerik's free .NET decompiler, you can easily recover lost source code or peer into assemblies to discover the root cause of an external bug. The same engine that powers JustDecompile is also used in Telerik JustCode, a Visual Studio add-in designed to enhance developer productivity. In this webcast, you will learn how to use JustDecompile and JustCode for decompilation scenarios you are likely to encounter in the office.
4. Agenda
Part 1 - Discussion Part 2 - Products
What is a Decompiler? JustDecompile – StandAlone
Legality Demo
Prevention JustCode – Visual Studio
Common Scenarios Demo
Bonus
Part 3
Q&A
5. What is a Decompiler?
Removing some misconceptions
6. Decompiler
Performs the reverse operation of a compiler
Translates assemblies back into source code
Source code produced is a representation, not the original
7. It is not Reflection
Reflection allows you to observe and modify a program’s
structure and behavior at runtime
Used to inspect types and members without knowing names at
compile time
Allows for instantiation and method invocation without hard-
coding names
8. It is not Disassembling
Disassemblers translate machine code to assembly language
In .NET, translating byte code to common intermediate language
(CIL) can be considered disassembly
This is one step in the decompilation process
ildasm.exe is an example of a .NET disassembler
10. Copyright
Most software is covered by copyright laws
Copyright owners have exclusive rights to make copies
Decompilation can be necessary, and it is allowed in the US and
Europe with some limitations
If there are any doubts, consult a lawyer in your jurisdiction
11. United States
"where disassembly is the only way to gain
access to the ideas and functional elements
embodied in a copyrighted computer program
and where there is legitimate reason for seeking
such access, disassembly is a fair use of the
copyrighted work, as a matter of law."
-Sega v. Accolade
12. Europe
Covered under the 1991 Software Directive, Article 6
• Must have a license to the program
• Must be necessary for software interoperability
• Must be confined to relevant elements for interoperability
• Information obtained may not be used for other purposes or
shared
13. Bottom Line
Have a good reason
Check the laws for where you live
Be good
15. Nothing’s 100%
If it was designed to run, the means by which it runs can be
obtained
These techniques will only stop the casual reverse-engineer and
the curious
16. Provide Good Documentation
Provide documentation essential for interoperability
Prevent bugs: test thoroughly
These steps will provide legal cover in some jurisdictions
24. Code Standardization
Performed as part of a build step, check-in, or during system
migration
This is generally bad
Tools exist for this particular need
25. Discover Effects on Code
Compilers change your code to IL constructs. In C#, optimization
can affect the output
IL Weaving
30. Assembly Lists
Create and maintain
separate lists of assemblies
Useful when working on
different projects
31. Navigation
Standard Searching
Navigation Tree Find Usages
Information Panel Go to Type
Code Panel Go to Symbol
Navigation Buttons Full Text Search
32. Navigation Tree
Contains loaded assemblies
Add assemblies via Open
button or drag and drop
Drill into assemblies to get
references, resources, namesp
aces, types, and members
43. Create Project
Decompile and output a full assembly in one step
Was one of the highest requested features
Select an assembly and choose Create Project
from tools or context menu
Fulfills Lost Source Code scenario
46. What is JustCode?
JustCode is a Visual Studio add-in for faster, smarter coding. It
works with Visual Studio 2005, 2008, and 2010. It also works in
Visual Studio 11 Beta
Supports: C#, VB.NET, JavaScript, CSS, HTML, Razor, XML, XAML
Works with cross-language solutions
47. Overview of JustCode
Code And More!
Analysis Unobtrusive
Navigation Runs out-of-process
Generation Extensible
Formatting Unit Test Runner
Templates Refactorings
Cleaning
48. Decompiler
The same engine in
JustDecompile is in JustCode
Completely integrated
decompiling in Visual Studio
Simply navigated to a type
contained in an assembly
49.
50. Code Standards
JustCode enables you to handle the Code Standardization
scenario without decompiling
Create solution options and share them. Code style options
available for all languages supported by JustCode
Code cleaning should be used as well. This is extensible; you can
add your own code cleaning steps
52. Learn more about JustCode
Visit telerik.com/justcode
Watch the videos “10 ways JustCode makes Visual Studio better”
Download a 60 day free trial of JustCode
54. What is JustTrace?
Optimize .NET application performance and memory
Includes tracing, sampling, and memory profilers in one easy-to-
use package
Supports local and running .NET applications, Silverlight and
Windows Service applications, and local IIS and ASP.NET web
sites
55. View Source
View source command
available in performance
profiles
Currently only shows code
reconstructed from .pdb files
On the roadmap: including the
JustDecompile engine
56. Learn more about JustTrace
Visit telerik.com/justtrace
Find instructional videos at tv.telerik.com
Download a 60 day free trial of JustTrace
57. Thank You
• Download JustDecompile today : telerik.com/justdecompile
• Remember, it’s free for everyone, free forever!
• To make a feature suggestion: justdecompile.uservoice.com
Hello! Welcome to the One Engine Two Tools webcast… or as I like to call it: one engine to rule them all! This is a joint webcast with MSDN and Telerik, and I would like to give a big shout out to the MSDN team for putting this webcast together! Today we’re going to be talking about decompilation in .NET with tools from Telerik.
Before we begin, introductions are in order. My name is Chris Eargle, an evangelist for the Just line of products at Telerik. I am also on the INETA Board of Directors, and I run a .NET user group in Columbia, SC. I have over a decade of software development experience. As you can see from my photo, I don’t like take myself too seriously.
I am very active in .NET communities, frequently speaking at user groups and conferences, and you can find me on twitter @kodefuguru, or email me after the show at chris.eargle@telerik.com. Also, be sure to check out my blog. At kodefuguru.com, I post articles to help you become a .NET Ninja.
I’ve split the agenda into the three parts.In the discussion section, you will learn what a decompiler is and what it isn’t. I will then talk about the legality of decompilation in the US and Europe. I am not a lawyer, but I am asked that question fairly regularly. So, I looked up some of the facts to help you understand what is considered fair game for decompilation and what isn’t. My best advice is if you have any doubts about an action’s legality, contact a lawyer in your jurisdiction.Since people are going to reverse-engineer your application whether it’s legal or not, I introduce you to some of the means in which you can protect your intellectual property. Finally, we will go over some of the scenarios where decompiling an assembly is desired.The products session is primarily focused on JustDecompile. I will take you through the ins and outs of its features so you can effectively use this awesome, free tool. JustCode employs the same decompilation engine as JustDecompile. I will show you how this works (it’s incredibly easy) and a better way to solve one of the decompilation scenarios from the first section. I have included a bonus section for a feature announcement that ties in with this topic.Finally, you will be able to ask me questions during this webcast, and I will answer them in the Q&A segment.
The namesays it all… it decompiles. You see, we compile software written in a high-level language to assemblies, and decompilers do the reverse. However, there exists a few misconceptions about what decompilers do. This section is intended to clear things up.
When you compile code in a .NET language, it is first converted into common intermediate language whose acronym CIL is pronounced sill. This is then assembled into bytecode resulting in an assembly. This process can result in process or library assemblies, what you’re used to seeing as .exe and .dll files. Upon execution, assemblies are passed into the common language runtime and translated into machine code with the just-in-time compiler. However, you can generate an image of the assembly for a specific processor using the native image generator, or ngen.exe. This image is placed in the native image cache. If it is incompatible with the current environment, the CLR reverts back to using the JIT.The decompilation process first reverts the CIL bytecode back into the CIL language. Then it is analyzed to find common patterns and idioms to produce matching source code in the chosen .NET language. Of course, the produced source code is not exactly the same as the original. Some metadata is lost in the compilation process, some language constructs compile to matching CIL constructs, and some compilers optimize the output. The original source code is not obtained, but rather a representation is produced.
One misconception I often encounter is that reflection is the same thing as decompilation. Reflection can be used to obtain information about an assembly, types, and members. It can also instantiate objects and execute methods on objects, and you don’t even need to know the names. The System.Reflection.Emit can obtain the IL for a method signature, and a popular library called Cecil can be used to modify the code and save it back to disk.The important distinction is that neither reflection nor IL emission completely perform the decompilation process since it does not translate to a higher-level language.
Disassembly in .NET is the process of converting the CIL byte code into its human-readable form. Some like to calldecompilers disassemblers, but disassembly is just one step in the process. If you are interested in this part of the process, Microsoft has included an IL disassembler in the Visual Studio SDK.
The question of legality comes up quite often, and many of you may be wondering about this as well. None of you want to be sued for programming, right? First, let me again express that I am not a lawyer, and this is not legal advice. This is simply information commonly available on the web.
There are issues with trade secrets and software patents, but every piece of software that is not in the public domain is copyrighted. This includes open source software whose licenses extends certain rights and obligations to the user. Copyright wouldn’t mean much if it didn’t prevent other people from copying your work. But as many of you are aware, software can be copied many times by a system. For example, copies are made in memory when you run a program, and backup software will often make backup copies of software as well. Therefore, most software is covered under a license to grant rights to perform these actions.Because of the manner in which software is used, many countries have made laws to the effect that copies necessary for running or backing up software do not violate their respective copyright laws. Many countries have also found that decompilation is allowed or necessary, particularly for the purposes of interoperability with other software.Again, if you’re trying to keep things on the up and up, contact a lawyer to ensure you are operating within the bounds of the law.
A court case in the United States called Sega versus Accolade established that decompilation can be necessary and a right. My personal interpretation is that you can decompile a program if you have legitimate need to figure something out and you’ve found no other way to obtain the information.
Europe, on the other hand, has established more restrictive regulations concerning decompilation. The program must be licensed to you and you must be decompiling specifically for the purposes of interoperability. You are not allowed to poke around other parts of the system out of curiosity, and you cannot share this information with the world.If you read technical blogs, you may have noticed that many people, including those in Europe, are decompiling and sharing useful information. I suppose this comes down to companies have legal recourse but not acting on it if the information shared was beneficial.
The bottom line on the legal issue is this. Have a good reason to decompile the software if you do not own the softwareor otherwisehave a license to decompile it. I am not able to cover the entire world; we don’t have time for it and some of the information is difficult to obtain. So, be sure to do your research!Finally, don’t do things you know are wrong or illegal. This includes circumventing security or stealing trade secrets.
No matter what you do, somewhere out there will attempt to decompile your project. Another common question out there is how to prevent this from occurring.
The truth is, that nothing is 100%. If someone wants it bad enough, they can find a way to reverse-engineer it. We must narrow the scope to making it more difficult to do so, in both legal and technical terms.
Providing proper documentation is the first step. It’s difficult to argue in court that you had a legitimate need to decompile the code if everything the person needed was available in the documentation. Of course, buggy software could be considered a legitimate need, so this should minimized as much as possible. This means unit testing, integration testing, load testing, functional testing, etc. If you take these steps, it will provide you some legal cover if someone misuses your software.
You can ward away the casual by obfuscating your assemblies. I say assemblies because obfuscating your code is a terrible idea. This process works by changing the CIL to have legitimate but obscure constructs that may not be normally produced by standard .NET compilers. They also rename non-public members to reduce one’s ability to determine the member’s functional purpose.There are many tools that will do this for you, and I’ve provided a link to the Visual Studio Gallery. Alternatively, you can search for the term in Visual Studio’s extension manager. Some are free, but many cost money.The downside to using obfuscation is its effects on reflection. If you are using reflection within your projects, you may want to experiment with the tools first to ensure your assemblies were not ill-effected.
Adecompiler is simply a tool: it can be used for good, or it can be used for evil. Here are a few scenarios that regular developers may end up using decompiler.
Decompiling for interoperability is expressly allowed under many laws and can be essential for a product’s success. I consider issues that make a project not meet specifications an issue of interoperability as well. A couple of years ago, I needed to serialize objects into a non-standard representation of xml to meet a vendor’s requirements. I made it work, but it was extremely slow. In the end, I decompiled System.Xml and found internal classes that would do the work I needed, faster. I then wrote a wrapper and used reflection to access the class.
Oftentimes, fixes for your project are due before a patch can be released by a particular vendor. In some cases, the vendor may be unresponsive or claim that the bug is feature. In any case, you have a deadline and may need to decompile an assembly to find a fix. I did this once during a COBOL.NET integration. The requirement was to output the files to a certain format which was supported by the COBOL.NET compiler but unsupported in the project file. I was tasked with finding a solution to this problem, but it wasn’t available at the time from the vendor. There were several ways I could have approached the issue, but I decided that surely if it’s in their compiler they simply didn’t expose the values. So, I looked into their msbuild assemblies and found that this was actually the case. Using this information I found by decompiling, I was able to find the appropriate values to put in the project’s property groups to meet my task’s requirements.
Despite being one of the best practices out there, the only form of version control for some companies is a network drive. Even worse, at some companies, source code is only stored on developers’ machines! If you are in this situation, I encourage you to find some form of version control and require your developers to store their projects there. Despite this, it could become necessary to recover source code from an assembly. For example, the server with the version control software fails, the building burns to the ground, laptops weren’t allowed, and remote backups were not stored or were bad. Sounds extreme, but sometimes bad things happen. It’s more likely the case that source code for an assembly was lost during a version control migration, or a developer quit who was not using the company’s version control system for essential, one-person projects.
Not all companies last, and their failure can come as a blow if you were relying on their products. Intellectual property is often auctioned off in bankruptcy proceedings, but it is likely you will never get another update. If updates are needed and finding a comparable product is not an option, retrieving source code will be essential.
There are .NET language translators available; we even have one for free at telerik.com, but maybe they’re not getting the job done with your particular code base. You can compile the project in one language and retrieve the relevant representation in another language.
Some try to enforce code standards by compiling and decompiling projects. This is generally a bad idea. You lose a lot of metadata in the process, and there are tools out there to do this for you. I suppose the reason some people do this is that it’s much faster, but I don’t think it’s worth what you lose in the process.
If something unintended is happening, you may need to decompile your assembly to see how your code was changed. This is especially true if you’re doing aspect-oriented programming with a product that uses IL Weaving.
One of the defining traits of a software developer is curiosity about how things work, which makes this the most common reason people decompile programs. It is also the most legally dubious of the “good” reasons to decompile a program.
JustDecompile is a .NET assembly browsing and decompilation tool developed by Telerik. We have years of experience in code analysis and productivity tools, and this was a perfect fit in our Just line of products. Best of all, it is free!
Yes, it is absolutely free. We guarantee that it will be free for everyone, free forever. The product was in beta for nearly a year, then we released it a couple of months ago with a brand new decompilation that provides more flexibility and power in decompiling .NET languages. This was a great tool to use in its beta releases, but the new engine will allow us to add far more functionality than previously possible. Be sure to keep an eye on our releases to take advantage of all the upcoming features. Don’t worry, the software will notify you when updates are available. I should also mention that JustDecompile contains no time bomb; you can continue to use any version indefinitely.
Remember the scenario of translating languages? JustDecompile currently supports code representation in Visual Basic, C#, and Intermediate Language. You can also suggest support for other languages, and they may be added in future releases.
If you have used decompilers in the past, you know that eventually your assembly list becomes unmanageable. JustDecompile supports multiple assembly lists, enabling you to create project specific lists. This removes much of the clutter when using JustDecompile for different projects.
There are many components to the navigation system for JustDecompile, and I find it best to assign usage to two categories. The first is the standard navigation you will use to browse and decompile assemblies. The second are the features that enable you to search for specific items.
The navigation tree contains the core method by which you browse assemblies. To bring an assembly into this tree, simply drag and drop it onto the tree’s surface or use the Open button. One feature I find extremely useful is that it tells you which version of the .NET framework is used next to the assembly’s name. Expanding an assembly will give you allow you to browse references, resources, namespaces, types, and members.
Beneath the tree is an information panel containing information such as the platform target and architecture, and where the assembly is located. This is context system. If you select the filename’s node, it will give also provide information such as the fully qualified name, which contains items such as the public key token.
To the right of the tree is the panel where code or resources is displayed.
It can be frustrating when you navigate to an item and then need to return to the referring location. There’s no need to browse the entire tree hoping to remember the particular item you were on; we store your navigation history and allow you to navigate forward or backwards using the navigation buttons.
While browsing the tree, simply select a type or member with your mouse while holding down control. This will find all of the selection’s usages in every loaded assembly.
If you’re looking for types related to certain functionality, press ctrl+alt+t to bring up the go to type dialog. In the image, I looked for every type containing the term Uri. This is also handy if you can’t remember a type’s full name.
Symbols are synonymous with identifiers, so this search is a broader form of Go to Type. Use it to find items such as types, methods, or even private member variables. This search is contained within the same dialog as Go to Type, but you can specifically bring it up using ctrl+alt+s.
Finally, the full text search allows you to search for any text within the assembly. It is recommended that you stick with a small list or a selected assembly, as it can be time consuming with a large assembly list. Again, this is in the same search dialog as Go to Type and Go to Symbol, but it can be accessed with that familiar keychord, ctrl+f.
JustDecompile opens and expands a Silverlight XAP file as easily as it does assemblies. This includes Silverlight applications for the Windows Phone. You don’t need the XAP file on your local system, however. Click the Open button and select XAP URL. JustDecompile will then retrieve the XAP file at that location and open it.
We have a few settings, but the one I find most useful is to show compiler generated types and members. The compiler often generates these artifacts, and sometimes I like to see what happened behind the scenes. For example, if you use a closure in your lambda expression, a capture class is generated.If you don’t like the default representation of the code, you can easily change the code panel’s color and font settings.
Many of the features in JustDecompile are decided by you, the user. Go to justdecompile.uservoice.com, or click the Suggest Feature button. You can then vote on ideas or suggest your own. I took a screenshot of the two highest voted features. We’ve already started on creating a plugin API, and we have Assembly Editing in the plan.
One of our most requested features in the past was the ability to export an assembly to a full project. To do this, select an assembly and either right-click and choose Create Project, or select Create Project from the Tools menu.
That was a lot of talking about JustDecompile. Let’s take a look at it in action.
Next, we’re going to talk about decompilation in Visual Studio using Telerik JustCode.
Visual Studio is rather large, and it has many features. If you want to know how a new .NET developer feels, open up Adobe Premiere. However, once you get used to it you may find yourself wishing there were even more features available! So, we created JustCode to enhance Visual Studio so you can focus on writing code. If you’re a C# or VB developer, this is a great tool to have… and it’s even better if you’re a web or xaml developer.
This is simply an overview of what you get out of the box with JustCode. The reason I started using before I joined Telerik is that it’s unobtrusive; it stays out of my way. It performs on-the-fly code analysis according to your rules to inform you of coding or styling errors. Fixing and refactoring code is a breeze as well. Since I don’t like dealing with standalone unit test runners, it was really nice to have a built-in runner that works with a multitude of frameworks. Finally, it is extensible, so if you’re looking for a rather unique refactoring, navigation, or code fix, you can create it.
Before JustDecompile became a standalone product, we were busy creating a decompilation engine for our Visual Studio add-in, JustCode. We decided that the standalone would be a great tool, so we began building JustDecompile around the same engine. The difference is that JustCode seamlessly integrates decompiling from within Visual Studio. To see this in action, simply navigate to a type contained in an assembly. JustCode decompiles the type directly on the screen.
Here’s a screenshot of this in action. I selected iCalendar which is contained in an open source library by DDay Software obtained from NuGet. Then it was simply a matter of using JustCode’s visual aid or pressing F12 to go to iCalendar’s definition. The metadata was opened up, and JustCode decompiled it.
Remember how I said using decompilation to achieve code standardization isn’t typically the best choice? One reason is that JustCode will do that for you; there’s no need to decompile. You can even create standards for a particular solution and check it into source control for all developers to use. JustCode also has code cleaning, which is like a super format document command. Only this one has many more options and you can do it solution-wide. Code cleaning is also extensible, allowing you to add even more options in how the code is presented.
Let’s take a look at decompiling in JustCode.
If you want to learn more about JustCode, visit telerik.com/justcode. There’s plenty of information there, including a link to the video series “10 ways JustCode makes Visual Studio better.” This wouldn’t help at all if you couldn’t try it out, so we offer a 60-day free trial.
I tweeted yesterday that I was going to announce a new feature during this webcast. The bonus section is subtitled “One Engine Three Tools” for a reason. It is on our roadmap to use the decompilation engine in JustTrace!
What’s that you say? Telerik JustTrace is our tool to help you find memory and performance issues. You can profile a multitude of application types, and you have your choice of three different profilers. Our tracing profiler is the most accurate performance profiler. The sampling profiler is similar, but it has a minimal impact on the application. Then there’s our memory profiler which will help you find memory leaks.
When profiling for performance, you have the option to the view the source code of the application. However, this only works if the debugger files are available. When we add the decompilation engine, you will be able to view the source code without debugger files, which will in turn help you find performance problems stemming from third-party libraries. This helps fills the interoperability scenario that is causing performance issues for your application.
To learn more about JustTrace, visit telerik.com/JustTrace. We offer a 60-day trial of this as well, and we have videos on tv.telerik.com.
If you’re interested in JustDecompile, visit telerik.com/JustDecompile. This page has more information and links to the FAQ and the forums. This is also where you can download your free copy! Also, be sure to visit our uservoice site to find out about upcoming features and suggest your own!Thank you for watching the One Engine Two Tools presentation, and thanks again to MSDN for putting all of this together. It’s now time to move into the Q&A segment.