Appearance in the Swedish news

On Friday the 12th of September there was an article in Sweden about the Swedish nationalist party leader Jimmie Åkesson being a notorious gambler. I noticed that although the journalists claimed they had bank card records, nothing in their reveal proved that. Instead everything in their reveal proved to me that the bank card reference only was a diversion and that a gambling company was the source.

I contacted Sweden's largest daily news paper who initially didn't believe me but after speaking to another IT-security expert accepted my claims and wrote an article about it.

Link: http://www.dn.se/valet-2014/akesson-avslojande-vacker-upprorda-kanslor

Translation of my parts
"According to IT-security expert Siavosh Zarrasvand, who has experience working for both gaming companies and banks, the latter lack the ability to track which employee have accessed what information.
- Their systems aren't built for that and it is harder to tie a specific person to a specific lookup the way banks can do it. I have even been contacted by gaming companies who needed custom keyloggers to monitor the activity of some of their employees.
Both Siavosh Zarrasvand and Kalle Zetterlund point to the fact that revelations regarding the nationalist party leaders gaming habits cannot be known through bank transfer slips but must have come from the gaming companies."

Dennis Yurichev's new RE-beginners book covers it all

I started this blog because I found almost every book teaching assembly, reversing and debugging to be unacceptably inferior. My idea was to teach the mapping between c-code and assembly at compile time with easy understandable tutorials. Due to lack of time that work has been slacking behind a lot.

However, some weeks ago Dennis Yurichev solved the problem for now. His newly released (free) book Reverse Engineering for Beginners is a very good introduction to the compiler processes that map C to assembly.

It start with various instruction sets and covers up to ARM 64. Then moves on to some architecture specifics for ARM, discusses compiler optimization (including instrinsics) and instruction set extensions such as SIMD and FPU. Covers a good deal of debugging techniques as well as SMT-solvers. This is truly a fantastic alternative to the inferior beginner reversing books out there. Quite frankly, the only other books who match this book when it comes to focus on instruction sets and how processors and compilation really work are those written by the excellent russian reverse engineer Kris Kaspersky, like Code Optimization: Effective Memory Usage.

Reversing challenge

We released a beginner reversing challenge at Sensepost today. You can find the challenge at http://sensepost.com/blog/10067.html.

If you struggle I'm sure I can help, just ping me.

Happy hacking!
/Ani

SensePost crash course in x86 assembly

I wrote a crash course in x86 assembly for the malware analysis workshop that we gave during 44con 2013. It can be downloaded from here. The table of contents is as follows:

1.1  Introduction
1.2  Bits, bytes, words, double words
1.3  Registers
1.3.1  General purpose registers
1.3.2  Segment registers
1.3.3  Status flag registers
1.3.4  EIP - Extended Instruction Pointer
1.4  Segments & offsets
1.4.1  The stack
1.4.2  Stack frames
1.4.3  The Heap
1.5  Instructions
1.5.1  Arithmetic operations - ADD , SUB, MUL, IMUL, DIV, IDIV
1.5.2  Bitwise operations – AND, OR, XOR, NOT
1.5.3  Branching – JMP, JE, JLE, JNZ, JZ, JBE, JGE
1.5.4  Data moving – MOV, MOVS, MOVSB, MOVSW, MOVZX, MOVSX, LEA
1.5.5  Loops – LOOP, REP
1.5.6  Stack management – POP, PUSH
1.5.7  Functions – CALL, RET
1.5.8  Interrupts, Debugger traps – INT, trap flag
1.6  Calling conventions
1.6.1  stdcall
1.6.2  cdecl
1.6.3  pascal
1.6.4  fastcall
1.6.5  Others calling conventions
1.7  C to x86 assembly
1.7.1  Single-Branch Conditionals
1.7.2  Two-way Conditionals
1.7.3  Logical operations - AND
1.7.4  Logical operations - OR
1.7.5  Loops
1.7.6  Function calls
1.8  Reverse engineering tools
1.8.1  OllyDBG tutorials
1.8.2  IDA Pro tutorials

1.1 Introduction

The hardest part of learning x86 assembly in 2013 is finding good tutorials. As the popularity of low level languages decreases the incitement to create fresh up to date tutorials is limited. At the same time x86 assembly is critical in many security related fields such as malware analysis, vulnerability research and exploit development. 

This document was created to address the lack of tutorials in a fast, pedagogical and cheap manner. While it is not a complete introduction, it addresses enough to prepare careful readers with the necessary knowledgebase to be able to decipher non-obfuscated assembly. And it does so within less than thirty pages. 

For pedagogical reasons focus is kept to what the reader assumedly knows about C or C-based languages (like Java or C#). Hopefully this minimizes the confusion that usually appears when people are trying to learn a stack based language for the first time.


Enjoy and let me know if you have any questions.
// Ani

Reading instructions to learn x86 assembly in 2013

To be able to recognize C code structures in assembly you need to know assembly. The hardest part of learning assembly in 2013 is actually to find good reading material. I know because I spent two years teaching myself assembly and I read a lot of utterly useless books, for example the 1.700 page long book from Randal Hyde called “The Art of assembly”. Below I present a handpicked list of reading material, starting from beginner to advance.

1.     Lena151 assembly guide. This is actually one thing that is good with Lena’s tutorials as it shows you the most basic parts and is only 20 pages long!

2.     The 200 first pages of the old book “Assembly Language Step-by-Step: Programming with DOS and Linux” by Jeff Duntemann. This is a must read. If you don’t read this, you’ll extend the learning curve by years. The way Duntemann ties assembly programming to the inner workings of computer systems and CPUs is just amazing.

3.     The following chapters in Eldad Eilams book “Reversing – Secrets of Reverse Engineering”. Read these chapters in the order I present them

1.       Appendix A – Deciphering Code Structures

2.       Appendix B – Understanding Compiled Arithmetic

3.       Chapter 2 – Low Level Software

4.       Chapter 3 – Windows Fundamentals

That makes about 250 pages in Eldad’s book and you should quite honestly never waste your time by reading the rest of his book as he dives into hands on approaches but uses terrible reverse engineering examples.

4.     All chapters in “Part 2 – Advanced Static Analysis” from the book “Practical Malware Analysis” by No Starch Press.

1.       Chapter 4 – A Crash Course in x86 Disassemby

2.       Chapter 5 – IDA Pro

3.       Chapter 6 – Recognize C Code Constructs in Assembly

4.       Chapter 7 – Analyze Malicious Windows programs

The four mentioned chapters take up less than 100 pages of the book. Practical Malware Analysis is however a great book written by some of the best in the industry and should be read cover to cover later on but for a beginner these chapters are enough.

That is the reading suggested for newbies in both reverse engineering and assembly. If you want to be a more advanced reverser there is some more reading that really needs to be done.

5.     Wrox Professional Assembly Language - A great book. Covers most features you already read about a little deeper. Great to read for repeating and fortifying your knowledge base.

6.     Intel Software developers manual is around 4000 pages of which the majority is must read. I have read the following parts

1.     Volume 1, “Basic architecture” explains the basics of Intel CPU’s. It lets you know more about features such as MMX instruction set extensions. This part is a little more than 500 pages and contains 15 chapters. Again, it is an introduction and basics volume, the more advanced version is Volume 3, “System Programming Guide”.

2.     Volume 3, “System Programming Guide” is an absolute must, especially for reversers. It is critical for a reverser to know the protection system (ring 0 to 4), Interrupt and exception handling, Debugging instructions, Virtual Machine control instructions and so on. This volume is around 1600 and it is very good to read it cover to cover at least once.

No doubt you will find very skilled reverse engineers or programmers who will tell you they never read any of these documents and especially not Intel Software Developers Manual. Most reversers only use it when they need to look up opcodes or which flags are set by which instruction.

But many of these people have picked up the same knowledge from other sources during a lifetime of programming, or they simply lack this knowledge.

These days the rapid development of IT forces newbies to take shortcuts. The world needs more and better reverse engineers now, not in twenty years. If you follow these reading suggestions, you decrease your learning time into 1-1,5 years.

Happy hacking!
/Ani

Why the Lena151 tutorials wont teach you reverse engineering - and what you should do instead

When starting a reverse engineering class I usually ask:
- How many of you have ever done any reverse engineering?

And usually, all the hands in the room are raised, so I continue and ask:
- So, if I give you a simple binary you’ll be able to tell me which compiler I used within ten minutes just by looking at the disassembly, not using any tools?

As an answer, nine out of ten hands drop. When I ask the remaining hand whether or not he will be able to take a simple binary and give me back a C file that, when compiled, matches the original binary bit for bit, he’ll retreat too.

I have been thinking about why this happens. Thinking back to myself, I started learning reverse engineering by reading the Lena151 tutorials. I thought they were awesome until Daeken told me that was an awful approach to learn reverse engineering.

At first I didn’t understand why they were so bad. After all, Lena’s tutorials had taught me how to crack my first software. But since Daeken is such an experienced reverse engineer, I took his advice without question and started writing C programs that I reverse-engineered statically instead.

A while back, a friend of mine who wants to get going on reverse engineering told me he had downloaded the Lena151 tutorials and was about to get started. I told him he shouldn’t and gave him the exact same advice I got from Daeken some years back, because I really agree with him. But I couldn’t explain to my friend why he should do as I said.

I’ve come up with an analogy that I think anyone getting into reverse engineering should read and understand. If you do this and follow the advice, you won’t be one of those raised hands who will drop immediately when the follow-up question is asked. Your hand will stay raised.

The analogy

Pretend I give you a car without a brand and tell you to reverse engineer it for me. One way you could do this is by sitting in the car and press different buttons while documenting what happens. You could take a ride with it, maybe tank it full and document how far you get, how fast it can go and how good the brakes are. You open the front or the back and examine changes while you press buttons or pedals. You crawl under it and repeat what you’ve done to document and examine it from another angle.
I bet, in the end of the day, you’ll have a pretty good grasp of the limits of that car. You could probably even write a specification for somebody that would like to build a car with the same limits and benefits.

So, have you reverse engineered it? Hell no!

- Let’s dig deeper, you tell yourself. You find a manual for the car and read it. Then you google for the engine model and learn some basic electronics. Great, you now know how to hot-wire the car. Finally you google the lock type and find out how to break it. Voila, you know exactly how to steal the car.

And yet, you still haven’t reverse engineered anything. You’ve done simple behavior analysis and behavior modification at most. This is what the Lena151 tutorials are all about, behavior analysis and behavior modifying, or as we hackers call it “cracking”.

What actually needs to be done to reverse engineer the car is that you need to be able to tell me how the electronics in it work and how they are put together. You need to be able to tell me why they are put together the way they are and how a change on the system will impact the entire system. You need to be able to tell me which fabric or brand the engine is from by analyzing the electronic in it. When you have enough information to tell me how to build a fabric that will squeeze out cars like that, with the exact same engine and the exact same electronics, you’ve actually reverse engineered the car.

Translated to the world of software, this means you need to understand the following:

x86 assembly (electronics and wires in the car analogy)
How operating systems work and how they manage memory (the engine of the car)
The compiling process from C-code to assembly (this is equivalent to knowing how a car-fabric is assembling a car)
The life of a binary (equivalent to everything that happens in the car from the key-switch to the off-switch)

Then you’ll need to know the file format of binaries in your targeted system, but that is minor knowledge that you’ll be able to pick up quickly once you know the rest.

See the difference between reversing and cracking? While one of them is about understanding the features of the target the other one is about re-creating the process that created the target.

This is why Daeken’s advice works. When compiling your own C-code and examining it in IDA Pro you take your first steps to learn how compilers create binaries and why. The Lena151 tutorials have not a single line about compiler technology or how operating systems manage memory.

Most people, whether they learned “reverse engineering” from Lena’s tutorials or by their own, are confusing reverse engineering with behavior analysis and behavior modification. The later ones are great skills to have and very essential for software professionals. They just are not the same as reverse engineering. I think that is the reason why so many raised hands drop when asked to reverse engineer a simple binary.