.NET Reversing

Various collection of reversing tutorials in video covering various aspects of .NET from Ubbelol.
Name Size Type Modified Attr MD5 Checksum .NET Cracking 101 #1 - Absolute basics.mkv 21.5 MB Matroska 5/10/2017 5:12 AM -a----- 4c70dc7c9f6b47f39a4cde2c2e172ef3 .NET Cracking 101 #2 - WinDbg basics.mkv 55.8 MB Matroska 29/06/2014 6:55 PM -a----- 56b4f7138fe1dbbdac358d6d8ba6fe5b .NET Cracking 101 #3 - Additional techniques.mkv 26 MB Matroska 9/10/2017 2:20 PM -a----- aefe75ee91f2c2df13522e2084797e27 .NET Cracking 101 #4 - ChewBox crackme.mkv 25.4 MB Matroska 10/10/2017 12:51 AM -a----- 4eee0cae85fe1a85257adf09bd432eef .NET Cracking 101 #5 - 0xDEADDEAD Crackme.mkv 42.5 MB Matroska 29/09/2017 3:32 PM -a----- 665c6e1bfaeb0e531c38b033deaf843a .NET Cracking 101 #6 - WinDbg_.NET Seal 2.mkv 31 MB Matroska 7/10/2017 12:02 AM -a----- 0bd46985e743fe5ab1f72ffa30c7d5dc .NET Cracking 101 #7 - AutoJitPatcher by 0xDEADDEAD.mkv 22.6 MB Matroska 10/10/2017 3:24 PM -a----- 96f125c6966155826b44900ae0c10925 .NET Deobfuscation 101 #1 - Symbol renaming.mkv 52.8 MB Matroska 10/10/2017 7:19 AM -a----- d0485addca7d551af4c423b680574570 .NET Deobfuscation 101 #2 - Phoenix Protector.mkv 48.3 MB Matroska 20/10/2017 11:35 PM -a----- 0a557679daf3444daf86099b4516782a Confuser 1.9 Anti-tamper tool.mkv 12.4 MB Matroska 11/10/2017 2:39 PM -a----- 0990b4977988ac8ff99aaf7313e4364e Confuser 1.9 Deobfuscator WIP - YouTube.mkv 10 MB Matroska 30/09/2017 10:11 AM -a----- 761e56dc774e70417a0cd8a46b5d270e uNet example application.mp4 85.3 MB MP4 16/02/2013 3:21 AM -a----- b9cb5dc6717def0802c7a27affc6b02d

The goal of this project is to create a .NET decompiler.
Decompiler is a tool that translates machine code back to source code. That is, it does the opposite of a compiler – it takes the executable file and it tries to recreate the original source code.
In general, decompilation can be extremely difficult or even impossible. Therefore this project focuses on something slightly simpler – decompilation of .NET executables. The advantage of .NET executables is that they consist of processor independent bytecode which is easier to decompile then the traditional machine code because the instructions are more high level and the code is less optimized. The .NET executables also preserve a lot of metadata about the code like type information and method names.
Note that despite its name, the .NET Framework is unrelated to networking or the Internet and it is basically the equivalent of Java Development Kit.
To succeed, the produced decompiler is required to successfully decompile a console implementation of a quick-sort algorithm back to C# source code.

This article is the obvious culmination of the previous effort of writing the Rebel.NET application and the first of a two series of articles about the .NET framework internals and the protections available for .NET assemblies. The next article will be about .NET native compiling. As the JIT inner workings haven't been analyzed yet, .NET protections are quite naïf nowadays. This situation will rapidly change as soon as the reverse engineering community will focus its attention on this technology. These two articles are aimed to raise the consiousness about the current state of .NET protections and what is possible to achieve but hasn't been done yet. In particular, the current article about .NET code injection represents, let's say, the present, whereas the next one about .NET native compiling represents the future. What I'm presenting in these two articles is new at the time I'm writing it, but I expect it to become obsolete in less than a year. Of course, this is obvious as I'm moving the first steps out from current .NET protections in the direction of better ones. But this article isn't really about protections: exploring the .NET framework internals can be useful for many purposes. So, talking about protections is just a means to an end.

Hi there, this is just a help tutorial about the tool {smartkill}, which was developed by tKC and me. It helps you get into apps protected with {smartassembly}. I will use it on tKC's latest CrackMe (#9) to show you some of its possibilities.
But this tutorial will also show you some important things, you should know about .NET Reflector !
Used tools:
{smartkill} v0.3
WinHex
.NET Reflector
NOTE: Be sure to get the latest update of .NET Reflector ! For example today was an update, which fixed an Anti-Reflector-Trick used by newer {smartassembly} versions ^^

In patching .Net, you could disassemble/decompile the executable with ildasm and when done patching you would assemble/compile it again with ilasm. In this tutorial I will show you how to patch the executable with hex editor.

I will try to be as descriptive as possible and since this is my first graphic article, bear with me.

There are 2 ways to get this program registered, however I shall opt for the tougher one as it will describe more changes and hence we will get acquainted with the language.

Load the application into Lutz Reflector. The approach remains the same as in Win32 platform. We first get to the probable function and modify it to our needs.

.NET Reverse Engineering Tutorial 1
Quote This target is protected by a license check. We are greeted at the beginning with a nag asking for the license file. As a trial user you would get one. The scope of this tutorial isn’t to make the program act like a full version, but rather patch around the nag at startup.
.NET Reverse Engineering Tutorial 2
Quote We will load up the victim into Reflector and look for anything that might interest us. The good thing about .NET assemblies is that what you see is the source for the actual program. Like in C++ you have {if,else} statements, for loops, the same goes for .NET. If you closely inspect the code in Reflector we see this occur. Anyways, let us proceed with the paper on .NET assembly.
 

.NET Reversing Paper 1
Quote In this particular paper I will intend to teach you as much as I can about howto reverse any type of .NET targets as good as humanly possible. But first you should take a few hours to teach and learn yourself at least 1 of the many .NET languages which are avail. today.

I myself recommend either Visual Basic .NET or Visual C#! Anyhow, if you have no knowledge in basic reverse code eningeering from before this is then no paper for you to read! Yes, it may seem too some that .NET reversing is easier than "normal" reversing but thats of course very wrong!
.NET Reversing Paper 2
Quote This program uses RSA-1024 as its main protection on the serial part, and our goal is today to keygen this piece. However, if you have any earlier experience with RSA you probably know that RSA-1024 most likely cannot be factorised, so we need to patch the public key (and to those who thinks of a wiener attack, forget it the key is too strong).

Now, obfuscation shall not stop us! Hehehe, its not that hard to read between the lines.
 

.NET Reversing Tips - Chapter 1
Quote In this series of tutorials we will be targeting .net applications. If you search the web you will find [if you are lucky] few tutorials on this topic, although the .net technology has been around for a while now but the number of applications devloped with it is still nothing compared to those developed with [old] languages like C++ or Delphi or VB.
.NET Reversing Tips - Chapter 2
Quote Entrypoint method is first method called on your .net application startup, and it's very Important to be able to locate it in reflector or Ildasm, in a simple .net application it may Look like this:-

Public Shared Sub Main()
Application.Run(New MainForm)
End Sub

The importance of this method is that you can start tracing the program actions from the beginning until you reach the protection scheme which is usually checked on Startup!

The second thing you can benefit from this Method is identifying the MainForm Class which will be used as a main form for the targeted application, If you see the Application.run method wandering around then you must keep an eye on the passed Arguments to this function.
.NET Reversing Tips - Chapter 3
Quote I hope you have read the 2 previous tutorials and liked them too! This is a quick tutor and it's to give you an idea about patching in .NET applications.

This tutor depends on the Opcodes table in Chapter I, so please make sure you have the Opcodes table since we will use it later.
.NET Reversing Tips - Chapter 4
Quote Hello there, as you can see we will try to crack a collection of .Net crackmes every time, and the level of difficulty will increase with time, because this is our first tutor, professional crackers may find it silly and very easy but like I said before it's for newbies.

This is our first example; you will find it with tutorial if you are lucky! Run the crackme and try to analyze it first.
.NET Reversing Tips - Chapter 5
Quote Hello every one, this is a new tutor for cracking .net assemblies, Today I have chosen to tell you about a commercial product called .NET reactor, The only difference between this software and all the other protection systems for .net executables is that it uses old packing techniques to protect your assembly and that's why I have chosen it.
.NET Reversing Tips - Chapter 6
Quote This time we are unpacking, the target is an unpackme written by Rendari, thanks for him for this nice challenge, actually I want to thank my friend UFO-PU55Y for sending me this one, he told me that it has been hanging since summer without solution, so I will try to share with you the technique I used to solve it.
 

You may wonder why I have chosen this topic, why write a tutor on .net components?
Technically a .NET component is not different from an executable assembly, I mean that both are compiled to MSIL and you can usually view the source in Reflector and other tools, but when it comes to commercial components you have to understand that more and more complicated protection schemes are being implemented to protect them, and after analyzing many products I found so many points that all these components share to protect themselves.
The second reason that pushed me to write this tutor is that I couldn't find any papers on this topic and that's because many crackers are still not interested in this platform yet and I really don't know why!
Today I have chosen a real target and remember that this is only the first tutor on this topic so don't expect it to be very hard, so this is just an introduction, and later I will demonstrate harder targets.

Decompilation is the process of converting executable binary code ready for execution on a physical or virtual machine into comprehensible high-level language code.
Typically compilation has been to the instructions executed by the CPU of the target architecture, e.g. x86, ARM etc. Another possibility is to compile to an intermediate 'virtual machine', which then interprets each instruction one at a time or compiles it to the underlying machine code in a process known a Just In Time compilation (JIT). One of the earliest examples of this is the O-code machine, developed by Martin Richards in the late 1960s to give platform independence to BCPL. The most prevalent example of this sort of virtual machine in existence today is the Java Virtual Machine (JVM), written by Sun Microsystems to execute intermediate code compiled from their Java language.
When a program is compiled to the machine instructions of the underlying architecture, it becomes very difficult for someone to understand the code if they only have the binary — this is after all the whole reason compilers exist. Decompilation is the process of converting a binary back to some high-level language, although not necessarily the same language that the code was compiled from. Compilation almost always loses information such as local variable names and explicit identification of control structures. As well as this many compilers perform optimisations which cause the compiled code to bear even less resemblance to the original code. For example, loop unrolling is a technique used to remove the number of branches a program must make.

A strong name is made up of information used to identify an assembly and includes the assembly's text name, four-part version number, culture information (if provided), a public key, and a digital signature stored in the assembly's manifest that contains the assembly's metadata and is embedded in one of the files of the assembly.
By including a strong name in an assembly, the common language runtime (CLR) can be assured that two assemblies with the same strong name are indeed identical in all respects. In other words, strong names provide unique identification of an assembly to the CLR. In addition, adding a strong name ensures binary integrity by allowing the CLR to perform verification when the assembly is loaded to determine that it has not been tampered with since it was compiled.

This will be a kind of “saga” of papers that will talk essentially talk about dot NET oriented reverse engineering, we are already on the stable version 4.5 (4.5.50709) / 15 August 2012 of Microsoft .NET Frameworks for Visual Studio 2012 and distributed with Windows 8, Windows Server 2012, but we still not seeing enough papers about reversing applications developed using dot NET technology. I’ll try to fill this lack of papers, and this first article is supposed to be a part of an upcoming others that would explain some basics and clarifying dot NET architecture to the extent of making some few concepts clearer for reverse engineers. 
Before starting, I strongly recommend you to take few hours teaching and learning yourself at least one of the dot NET languages and I recommend either Visual Basic .NET or C#, it may seems to some that reversing dot NET programs is way easier then reversing “traditional” programs which is in my point of view wrong. 
The concept of dot NET can be easily compared to the concept of JAVA and Java Virtual Machine, at least when talking about compilation, unlike most of traditional programming languages like C/C++, application developed using dot NET frameworks are compiled to a Common Intermediate Language (CIL or Microsoft Common Intermediate Language MSIL) - which can be compared to bytecode when talking about Java programs - instead of being compiled directly the native machine executable code, then the Dot Net Common Language Runtime (CLR) will translate the CIL to the machine code at runtime. This will definitely increase execution speed but has some advantages since every dot NET program will keep all classes’ names, functions’ names variables and routines’ names in the compiled program, and this, from a programmer’s point of view is such a great thing since we can make different parts of a program using different programming languages available and supported by frameworks.

Sometimes after you manual unpack a .NET program when you run the program will complain that some dlls are missing, we simply get .NET dlls using a .NET Generic Unpacker (also we could dump the memory of them from Olly) while native dlls are still missing.
This tutorial will teach you how to dump native dlls from any .NET packed program.
The basic rule: we should stop when the dll is under memory and we should dump the dll before is executed the entry point of him; is not absolutely necessary to stop exactly at entry point of dll.

This easy tutorial will teach you how to unpack various DotNet packed files.

WDSM32 was one of the most popular tools for cracking in the past, after you decide to crack something you disassembled its code in WDSM32 to search for strings like "Registration successful" or "Invalid serial number !" and then you try to nop or inverse the right bytes to get the job done..
Unfortunately this tool is now history, since all the .net programs are interpreted and not compiled, you can no longer use the old techniques to or tools to crack something written with this new technology. All .net applications require the .net runtime [.NET Framework] to be installed on your machine in order to be able to run them, unlike for instance Delphi executables which you can run without any runtime needed to be installed on your pc, the .net runtime works like java virtual machine which is needed to run java executables on your PC.

As you know, the main purpose of using packers was to decrease the size of executable files, but nowadays most of packers are protectors too! For 32bit packed executables, reversers usually use OllyDbg to unpack them, but OllyDbg is only able to debug 32bit PE files. So what we can do in case of .NET targets? In this short article you'll see how to unpack .NET EXEs in few steps using great OllyDbg. Believe me, it's piece a cake.

I'm glad I'm here again and I hope you enjoy this new tutor, as you can see this is not a reversing tutor, we are not cracking anything today, as a change we will talk a technical problem regarding .NET applications, If you ever wrote an application using .NET platform then you must have noticed that these applications tend to consume a considerable amount of RAM!
To prove this fact you can simply create a do-nothing application in .NET and just run the application, now go to Windows task manager and find your application and check the amount of RAM taken by your do-nothing Application, usually this type of applications require from 15 to 20 Mb of RAM!, this is not good compared to a Delphi executable which takes about 3 to 5 MB of RAM.
I've recently written a memory manger class for my applications and it you have to do is to create a new instance of MemoryManager class in your main form and it will do the job, It's built on a very simple idea and it takes advantage of the OnIdle event in the .net application, the OnIdle event is raised regularly whenever your application is not busy for a while, the MemoryManager class will dramatically reduce the amount of memory used by your
application by automatically releasing the memory no longer needed, which will free up more RAM for other applications.

Here's my another basic .NET reversing tutorial. Actually one of my friends asked me about this CrackMe which is made by XOR06, so I tried to create a tutorial. Why I called this interesting, because of the way it checks for the serial key.

A strongName consists of the assembly's identity—its simple text name, version number, and culture information (if provided)—plus a public key and a digital signature. It is generated from an assembly file (the file that contains the assembly manifest, which in turn contains the names and hashes of all the files that make up the assembly), using the corresponding private key. Microsoft® Visual Studio® .NET and other development tools provided in the .NET Framework SDK can assign strong names to an assembly. Assemblies with the same strong name are expected to be identical. (Microsoft MSDN).
In this article you'll see how to remove StrongName (simply SN) in .NET EXEs and DLLs. Also you'll learn something about cracking IL codes.

Reversing .NET - Part 1 - Introduction
Quote Every few years, something new hits the streets. The latest craze is .NET. Microsoft's been plugging it like crazy, essentially claiming it to be the best thing since sliced bread. Some programmers have started to develop on it which in turn means reverse engineers have been wondering about what goes on underneath the hood. So far there has been a lack of good information on the subject, and this paper is meant to fill that void.
Reversing .NET - Part 2 - Byte Patching
Quote Having covered the basics in the previous chapter, we now know how to look inside a .NET program. This is all we need to do for some very basic protections, like the hardcoded serial crackme we looked at. A lot of times, however, we will need to do more than just look. We will need to change the program as well. This is known as patching (as you might well know), and is useful for both cracking and other reverse engineering (adding functionality for example). There are some difficulties in doing this, namely finding the right place in the file and figuring out what bytes to put there. The target for this chapter has once again been made by x-Bi0dESC and can be found in the attachment that comes with this paper.
Reversing .NET - Part 3 - Advanced Patching
Quote The time has come to leave the baby steps behind and get busy with more complicated (and thus realistic) problems. This chapter will demonstrate some more advanced patching techniques you will encounter in real situations. Our example target will be the third reverseme created x-Bi0dESC to help with this course. Because the subject involves more advanced patching, the Reflector tool will no longer suffice (it is really not suited for use in patching, but more for understanding a program), instead we will switch to using IDA for analysis. IDA is a powerful disassembler that will give us a lot useful information (like the location in file, the code bytes representing instructions, and a lot of other advanced analysis information.
 

The purpose of this tutorial is to learn how to reverse a .NET application, which is also protected by a license file check.