Demystifying dot NET reverse engineering: Introducing Round-trip engineering. Introduction After covering the basics of dot NET reverse engineering in first articles (refer to the references), it’s time to go more in depth of the dot NET MSIL assembly language. The purpose of this article is not to teach you programming using this language. I’ll try to clarify more the IL code you saw until now, how to deal with it using some “new” tools, but also presenting the technique of “round trip engineering” which is not a dot NET specified technique, and see how we can be creative and use this in our reverser’s point of view advantages.
In this article I’ll present you IL assembly much more in depth and how we can deal with two synchronized tools to remove the first protection of a Crack Me I made for this purpose. Definition of “Round trip engineering” The IL assembler and disassembler were first made as strict internal tools used to facilitate the development of the Common Language Runtime. The subject’s core Step 1: Disassembling Understanding Form_Load() Method: Demystifying dot NET Reverse Engineering: Advanced Round-trip Engineering. Before going through this article, I highly advice you to read all previous ones in the series since I will not re-explain some techniques and re-describe some tools previously presented.
Here, I will assume that you understood the basics and everything that was presented prior: Article 1: Demystifying Dot NET Reverse Engineering- Big IntroductionArticle 2: Demystifying dot NET Reverse Engineering – Introducing Byte PatchingArticle 3: Demystifying dot NET Reverse Engineering- Advanced Byte PatchingArticle 4: Demystifying dot NET Reverse Engineering- Introducing Round-trip Engineering Summary This article is only a part of a whole, and it aims to go deeper into IL assembly language exploited in reversing non-obfuscated (until now) dot NET assemblies and modules. (Managed dot NET applications are called assemblies and managed dot NET executables are called modules; a managed dot NET application can be a single module assembly or a multi-module assembly) Serial check analysis .maxstack 4 And:
Demystifying Dot NET Reverse Engineering, Part 1: Big Introduction. This, and all upcoming parts, are made with a strict and pure educational purpose just to gain insights into dot NET programs. What you’re going to do with this and all upcoming parts is your own responsibility. I will not be held responsible for your eventual action and use of this. All techniques used in this and all upcoming parts have been used only to demonstrate theories and methods described. The scope of this paper and all upcoming parts as well as any other paper written by me (Soufiane Tahiri) is of sharing knowledge and improving reverse engineering techniques. And please note that disassembling and / or reversing software is prohibited by almost all international laws, if you like software then please BUY IT. Introduction This will be a kind of “saga” of papers that will talk essentially talk about dot NET oriented reverse engineering. The concept of dot NET can be easily compared to the concept of JAVA and Java Virtual Machine, at least when talking about compilation.
Demystifying dot NET reverse engineering - PART 2: Introducing Byte Patching. For part 1 of this series, please click here. Introduction We covered in the first part the very basics regarding dot NET programs, how they are compiled (which we will see again a little bit more in depth) and how we can see inside them using Reflector. We saw how easy is to bypass protections based on hardcoded serials or passwords, this was really very basic and almost always we have to do more to go in depth of real programs protections. Practicing reverse engineering in general, and not only when we talk about reversing dot NET programs, is not only about getting serials or passwords; reverse engineering is the art of playing with bytes, it’s about changing bytes to alter functionalities, to disable or to enable some of them, in some cases it’s used to add some entire functionalities, and this is not always a simple task.
To do this, mastering assembly is a must, and not only this, but finding in the program the right place and figuring out what bytes to change. Compiling dot NET else. Demystifying dot NET reverse engineering - PART 3: Advanced Byte Patching. Introduction In the first two parts, we saw some basics that will let you reverse-engineer some dot NET applications; we covered the concepts of dot NET compilation, we presented Microsoft Common Intermediate Language, we analyzed some low-level code using code reflection, and we saw a nonexhaustive list of IL instructions with their functions and their byte representations. We also covered the basics of byte patching, how to find the location of bytes we want to change in a hexadecimal editor, and how to change them. In this part of our dot NET reverse engineering series I will introduce you to some advanced byte patching as well as a concept of a basic aspect of license check protection and how we can reverse-engineer it (as requested by readers).
We will introduce new tools as well, and see how we can deal with them. The deal In this practice, I have tried to respond to a few questions and suggestions regarding the two first parts. Referring the list above, we get: 166F?? Figure 5.