How to Terminate a Terminator

Today we celebrate 30 years from the release of The Terminator. The story of a machine which was sent from the future to kill John Connor before he was even born.
Ever since I watched that movie, I was damn afraid that one day the machine will over rise and kill us all. Arnold is quite a scary dude.

What a tough motherfucker.

Recently I decided to cope with my nightmares, and watch the entire series all over again. But this time I’m doing it not to be scared, but to gather information about future robotics to be ready to fight it when the day will come. As a software guy, I decided to focus on what makes these cyborgs tick. And as far as it goes to the first module they sent back in time, a Motorola 6502 is the main CPU.

In the picture above, we can see the very first picture taken from the eye of the Terminator. We see it got some kind of compass (Just like the iPhone), and it compiles some code.
Wait. What?!
Yes, it compiles some code, from source. It's even got remarks to help us understand the code. It defines some constants and then moves to the next operation.

Now it’s done with compiling, so it checks the checksum, to see that there are no errors or malwares in the binary (On the right). On the left side, we can see a binary dump of the code, what brings

up the inescapable conclusion that this CPU got 16bit address space, so bill gates was right after all, 64k should be enough for anyone.

If anyone wants to go through the process I went by he would probably need the instruction set for this CPU, so here is a link to it http://emudocs.org/CPU%2065xx/6502.txt.
Bottom line, the code seems like some kind of checksum calculator subroutine (I hate this name, why not call it a function, subroutine sounds so old).
Next we get a more readable code, with many comments, lucky for us, this cyborg left us lots of debugging information.

We now know the address in memory of much of the code, what would become handy if we would like to exploit this cyborg.

More code on the bottom, and some data table on the left.

At this point of the movie we see the HID of the cyborg for the first time. We see that it’s got many options to choose from, and it takes it a long time to move around the menu and choose the desired answer. What a UI nightmare. Besides, we see that it uses some kind of ASCII art to display stuff on the right top corner, in higher resolution than before, therefore it’s very hard to read it.

Some OCR app, very cool. From now on, I use CAPTCHs for any private detail that might uncover my true location. I thought that the M6502 can’t do much, but then again, these cyborgs must be very good programmers.

Again code checksum, I think the dog has scared the cyborg, so it went into catatonic mode of rechecking everything.

Same code as before, This must be some kind of code that the cyborg must execute before it can work a gun. We defiantly need to find flaws here.

I’m starting to think that the entire cyborg is made out of two subroutines that just checks for errors on each other. Here we find a new kind of application that is not made of any ASCII-art, and might be scanning for something. It’s hard to see since the resolution is very bad here.

Look at this, a car reversing application. It works very fast and it gives results in no time. It uses many English letters and glowing pictures of what you are supposed to push. We are going to have to put some anti-debugging stuff on all the cars from now on.
That's about it for the terminator in this movie, we still got some pictures from future technology such as choppers.

Again lots of Motorola 6502 code, written in the most wired format I have ever seen.

That's about it with this version of the Terminator.
Next we have to deal with two mother fuckers of the next movie titled The Terminator - Judgment Day. One of the cyborgs is of the same module (T-800), we will soon see that it’s got a much different interface. The other is of a newer model (T-1000), made out of some kind of liquid metal. It's a shame that we don’t get to see any view from the eyes of the new cyborg, so we are going to have some troubles trying to kill it. Lets hope the future won't use this one against us. All of the pictures from this movie are of the T-800 point of view.

It scans to find a proper motor vehicle. No code here, we don’t know what kind of CPU it is running on. But we see it’s got a much better interface than the old model. The resolution is a bit better, and the font is much more human friendly. Although, it's still uses some ASCII-art at the table on the left (the stars that separate the title from the data), and why is it all written in English, Isn’t it supposed to be using some kind of binary language, or is this a debug log used by the developers.

The checksums are still there on the left.

Lots of useless data. I wonder if we can overflow the WGHT details with some fat guy, could be an interesting entry point.

Nice enhancement. And we got some code on the left. If it’s a machine code, then it’s RISC CPU and it’s 24 bits in size, not M6502 as far as I know.

Playing arcades, the 80’s were so much fun.

The end indeed.

Good driving application, would take the beats the Google Car, that's for sure. I wonder what the IMAGE LEVEL data stand for.
Next is a scene that is found on the DVD extra features only, in which we get to see a full reboot of the cyborg, lots of useful information.

The code is a bit strange... It's neither hex encoded nor ASCII.

Bingo, now we know the version of the firmware, and we know that it’s possible to upgrade it, maybe to make a nice nanny or a hairdresser out of this terminator. Cyberdyne Systems, lets google that, to see if we have anything to worry about, or anywhere to get a firmware update from.
O no! Apparently there is a company called Cyberdyne Systems, http://www.cyberdyne.co.za/, and they even got a web site. I will drop them an email later to ask for the source code of the Series 800 model T01.

Next is some combat & tactics apps, so be extra careful with that.

That’s a huge potential damage 534053 543596 876 874798 4745757 44

And the alternative power program:

Information about the PCB and internals. It seems like a one layer old type of PCB, not very advanced.

Diagnostics screen, or debugger.

Many analog interferences, must be old CRT technology. Very strange for future technology...

Shuts down just like an old TV set.

Many years later, we got a new movie with again, two cyborgs, but this time we get to see the Point of view of both of them. We will start by examining yet another version of the T-800 Terminator.

It's getting older, but still a good looking by any standard.

The resolution got better. Font is about the same, the information moved to the left side of the display, defiantly a newer version of the interface.

Audio Waveform, must be a new module they got into the code, because this is the first time I see it. The analysis got much more data in it this time, but it seems more like monkey punching on the keyboard data than a machine code.

What's with the small magnifier (bottom left)? It's very good in finding clothes that fit well. I need this machine for the next time I go on shopping.

Not the checksum again!
And what’s with the Z-Buffer, is it like, calculating the distance from the object, is it tries to render some 3d graphics, is it part of the GPU?

Now we are really doomed, finally, after 3 movies they got a color screen! Where did these colors come from all of a sudden?

A big improvement on the UI, everything is set in boxes, and no more silly ASCII-art.

First, create the dialog box to display some information, it takes time...

Then the data appear. Well, the worst it can do is to kill 999 people, let's hope it would spend it on people that I don't like.

A terminator when damaged, starts printing *s and some random parts of the English dictionary. It also gets blurred vision of the data, and many analog interferences. Dude, check the cable, it seems not to be connected.

Never-mind...

I told you not to launch all the applications at once, it makes your your system to faulty.

When a terminator is badly damaged, it starts seeing colors, just like a friend of mine who took some nasty stuff back in Goa India.
Next is the other cyborg which must be the most advanced machine we saw in the entire series.

I give up, take me and do your worst!

It’s got everything one might want with his cyborg a bluish awesome display and a modem-fax.

Was that before or after the Facebook?

It’s hard to read, but the title of the picture on the left says it’s running on auto-pilot, while in fact it’s driving a vehicle.

It’s much better than going on a killing spring of all the people with the same name, as it was done on the first movie.

Double checking.

It has this window that looks like a file icon on the left side, and it seems to be open all the time. Could that be a blind spot for the cyborg.

This cyborg got an endless count of features, it got all the apps found in the App Store and the Play Store combined.

Cool 3d rendering of a car on the right.

Too cool to be true.

As for the next movie (that's the 4th one), well, it’s very hard to gather information from this one, because most of the displays looks a little like this:

Or this even this:

There is a small fight going on with a the T-800 in this movie, so we do get a short glance at its new display here:

They finally left the M6502 behind.

They did it again, they changed the UI completely, just when you get used to something, they pull a new version and you have to learn all the shortcuts all over again. The message box seems a little bit similar to the old one, probably some code reusing.

That's about as far as the movies go, but I'm not going to sit back and let them all kill me while there is some much more to learn. Yes, The Sarah Conner Chronicles, which give out many new insights to what might come to hunt us down.

Summer Glau, I love you! Definitely the most beautiful and talented Terminator of them all.

With most enhanced GUI, User interface, Fonts and killing apps.

Termo vision,

And Kendal Safe breaking application.

She is so pretty, I had to put another picture.

Hope this Information would help you survive the next apocalypse which is coming to us on 29/8/1997, wait, what?! Nevermind this information you can forget all about it now...

Cheers,
Assaf

The Making of the Kosher Phone

As seen on POC||GTFO 0x03 and more

All of the research presented in this paper was done by me and two coworkers who preferred to stay anonymous, I write everything as if I did it by myself for clarity and fluency.
To understand what a Kosher phone is, one must first understand what a feature phone (aka dumb phone) is. A feature phone is a phone that is usually sold for a very cheap price (up to 50$) and it lets the proud owner do the following things:

• Make phone calls
• Send SMS
• Send MMS
• Manage a calendar
• Listen to FM Radio
• Play simple games such as Snake
• Browse the internet over GPRS or 3G using a dis-functional web browser.
• Bluetooth communication
• Play ringtones
• Display ugly images as wallpapers
• Take photos using ~2MPixel camera
• Some utilities such as world clock, unit converter and calc

While recently some devices also include:

• Limited Facebook app
• Twitter app
• WhatsApp

A Kosher phone would be an adapted feature phone to the “special” needs of a certain community of the Ultra Orthodox Jews. The community in target asked for a phone that is more dumb than the dumb phone, a phone that suffers from complete retardation. The general idea is that they don’t want to be open to the outside world in any way, but they still want a means to communicate between themselves without breaking the strict boundaries they made. They were looking for phones that can only perform the following tasks:

• Make phone calls
• Manage a calendar
• Bluetooth only with headphones
• Play only a strict list of Hasidic ringtones.
• Some utilities such as unit converter and calc

Besides that, they would be extra happy if they could have:

• Jewish calendar
• Prayers time table

A disclaimer: No one forces this phone on them, they choose to have it on their own will. No government or agency is involved in this, and the only mean of force that drive the people to use this kind of phone is the community they live in.

I choose for start a Nokia phone, as they are considered cost effective for hardware quality and stability. From Nokia I got an approval for the project, but no help whatsoever. They said, I’m welcome to do whatever helps me sell their phones, but this target group is too small for them to put any developing time on it. This is how the journey for the Kosher phone has started.

During my journey I had the pleasure of co-developing of 5 generations of the Kosher phone:

1. Nokia 1208
2. Nokia 2680
3. Nokia 2720
4. Samsung E1195
5. Nokia 208.4

There were a few models in between that didn't get to the final stage either because I failed in making a Kosher firmware for them or because of other reasons that are out of my control.

I won’t describe all of the tricks I've used during the development, because:

1. These phones still make a nice income that I would not want anyone to take away.
2. Not all of it is mine to share.

However, I think the time has come for me to share some of the knowledge I've collected during this project.

It would be too long to cover all of the phones in a single post, so I will start with just one of them, and just a single part that I find most interesting.

Nokia has quite a few series of phones differ in the firmware structure and firmware protection. The main purposes of the protections are to:

• Make it hard for people to play with Baseband firmware and harm the GSM network
• Protect the SIM-lock feature which locks the phone to sim cards from only one provider (Something that became illegal in some countries such as Italy and Israel).

The series are the following categories:

• DCT1 (Digital Core Technology / Data Cellular Technology)
• DCT3
• DCT4
• DCT4+
• BB5 (Base band 5)
• Asha S40 (AKA xGold 213)

In general the DCT1 works with the old analog networks (Usually refer to as 1G), DCT3, DCT4 and DCT4+ works with GSM (2G). BB5 is sometimes 2G and sometimes 3G (I think). And anything that comes after being 3G compliant. It is important to understand the fact that there are different generations of phones because a way to fiddle with the firmware of a phone from one series would usually work with all of the other phones on the same series, while it won’t work with phones from other series.

I’ll start with the DCT4+ phone, the Nokia 1208. Nowadays there are quite a few people out there who know how to patch DCT4+ firmware, but the solution is still not out in the open. One would have to collect lots of small pieces of information from many forum posts in order to get a full solution… Well, not anymore, because I’m going to present here the solution in all of its glory.

A DCT4+ firmware consists of two parts, a flashable part and a non flashable secured part (probably ROM). The flashable part contains the:

• OS, usually referred to as the MCUSW.
• Strings and localization strings, usually referred to as the PPM
• General purpose file system in a FAT16 format. This part contains configuration files, user files, pictures, ringtones, and more. This is where Nokia pushes the phone provider variations. This part is much less protected. It's usually referred to as the CNT or IMAGE.

All of this data is accessible from the software in one flat memory module, meaning that codes that runs on the device can access almost anything that it know where to locate.

At this point I would focus on the OS part, in an attempt to patch it to make the phone Kosher. The OS contains 99% of the code that operates the phone, that's including the implementation of user interface, menus, web browser, SMS managing, communication and anything else the phone does. The only things that are not part of the OS are the code for performing the flashing, the code for protecting the flash and some of the BaseBand these are all found in the ROM part, beside that only 3ed party apps such as games are located outside of the OS, in the CNT part.

Obtaining the binary is not hard, it’s simply available for download from many websites, and from Nokia servers accessible by the Nokia flashing tool Phoenix or by the NaviFirm+ tool. The MCU part (meaning the OS part) comes in the form of a file with the .mcu or .mcusw (MicroController Unit SoftWare) extension.

It starts with the constant byte 0xA2 that marks the version of the file. The file has quite a simple format. From offset 0xe6 everything that follows is encoded as:

1 Byte: Type (Always 0x14)

1 Dword: Address

3 Bytes: Length

1 Byte: Unknown

1 Byte: Xor checksum

Combining all of the data chunks would give us something that starts at address 0x1000000 with the following data:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  AD 7E B6 1A 1B BE 0B E2 7D 58 6B E4 DB EE 65 14  .~¶..¾.ג}Xkהמe.

00000010  42 30 95 44 99 18 18 38 DB 00 FF FF FF FF FF FF  B0•D™..8.

00000020  FF FF FF FF F8 1F 8B 22 50 65 61 4B FF FF FF FF  ר.‹"PeaK

00000030  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 

00000040  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 

00000050  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 

00000060  FF FF FF FF FF FF FF FF FF FF FF FF F8 C4 AA C3  רִ×ֳ

00000070  85 CF C6 E7 00 04 8A 5F 01 00 01 00 00 00 00 00  ֶֿ...ח..._........

00000080  00 00 00 00                               ...

Note that some of the 0xff bytes are just missing data because of the way it is encoded. The first data chunk belongs to address 0x1000000 but it’s just 0x2c bytes long and the next data chunk starts at 0x1000064. The binary that follows byte 0x1000084 is encrypted, and is auto decrypted by hardware. I know that this is done at the hardware level because:

1. I can see what bytes are actually sent to the phone during flashing, and
2. There are few places in memory such as the bytes from 0x1000000 to 0x1000084 that are not encrypted. After I’ll manage to open the encryption I would find that In some places in the code these bytes are accessed simply by adding 0x8000000 (I’m not missing a zero) to the address, which is a flag to the CPU that says that this data is not encrypted, so don’t decrypt it.

Now an interesting question that comes next is what is the encryption, and how can I reverse it to patch the code. My answer is going to be quite disappointing, I found out what encryption is it by gluing pieces of information that are published on the Internet. If you want to know how the guys on the Internet found what it is, remember that I want to know it too. My guesses are either:

• Someone leaked it from Nokia
• Someone reversed it from the silicon, with a process usually called Silicon Reverse Engineering
• The encryption was implemented in ARM code in the unflashable array (Very unlikely), and that was recovered in a method I would describe later in this post.
• It was reversed mathematically from samples. I think the mechanism has a problem in which some bytes with the same value at the same array and with the same distance from each other might be encrypted into the same value, which can give information that could be used to deduce parts of the mechanism mathematically.
• Or any combination of the options above.

------- UPDATE -------

Apparently the reversing of the encryption and encoding was done by:

• G3gg0 who is also responsible for the amazing tool Trix (http://www.g3gg0.de/wordpress/)
• nok5rev
• And Krisha

More information about how it was done, and the original source code is found on the following link: http://www.gsmfreeboard.com/showthread.php?t=119075&highlight=DCT4Crypter 

-----------------------------

That came out not as clear as I expected...

The ROM contains a relatively small amount of code, but as you could probably understand by now, I don’t have this part. The only thing I care about from this code is one function that does the following two things:

• Validating first 1MB of the MCU code.
• If and only if the validation succeeds it activates the BaseBand (Any GSM communication)

Meaning that if something in the first 1MB of the MCU code is patched, the validation found in the ROM would fail and the phone won't communicate with anything. This won’t interrupt anything else at phone so it would keep running, but the user interface would display no signal sign. The validation function in the ROM is invoked from the MCU code, so the function call can be patched out, but again, it would make the phone not a phone as it won’t be able to make any phone calls. It might sounds like this is what the customer is looking for but it’s not, phone calls are still Kosher if they are not done on Sabbath. Note, that Bluetooth communication is still functional, and can be instrumented to become an easy to access debug interface.

Another validation that is found in the MCU code is a common 16bit checksum, that is done less for security reasons, but to check the phone for flashing errors or flash corruption. The right checksum value is found somewhere in the first 0x100 bytes of the MCU. This checksum is easily fixed with any hex editor. If the check fails the phone shows a “Contact Service” message, and shuts down.

At this point I don’t know much about what kind of validation is done on the first 1MB, I just have a few samples of official firmwares that pass the validation. Every sample has a function that residents in that 1MB of code and validates the rest of the code. If that function fails, meaning if I patch something in the code coming after the first 1MB, it immediately reboots the phone. The funny thing is, that the CPU is so slow, that I can actually get a few seconds to play with the phone before the reboot takes place. Again patching out this check equals no signal.

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  AD 7E B6 1B 23 10 03 40 C6 05 E4 01 20 A2 00 00  .~¶.#..@Æ.ä. ¢..

00000010  00 00 00 00 00 00 00 00 00 00 00 FF FF FF FF FF  ...........ÿÿÿÿÿ

00000020  FF FF FF FF F8 1F AA 02 50 65 61 4B FF FF FF FF  ÿÿÿÿø.ª.PeaKÿÿÿÿ

00000030  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

00000040  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

00000050  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

00000060  FF FF FF FF FF FF FF FF FF FF FF FF C0 52 90 D4  ÿÿÿÿÿÿÿÿÿÿÿÿÀR.Ô

00000070  4A E4 5C 8F 00 02 00 00 01 00 01 00 00 00 00 00  Jä\.............

00000080  00 00 00 00 FF FF FF FF FF FF FF FF 01 CE 00 00  ....ÿÿÿÿÿÿÿÿ.Î..

00000090  03 00 00 00 00 04 CC A2 00 04 CC A3 FF FF FF FF  ......Ì¢..Ì£ÿÿÿÿ

000000A0  00 00 F1 EF 89 33 EB 2D 1F 09 3B DA C7 C0 3D 9F  ..ñï‰3ë-..;ÚÇÀ=Ÿ

000000B0  BB D3 29 98 01 C8 BC B0 06 6E A8 11 0E D1 69 67  »Ó)˜.ȼ°.n¨..Ñig

000000C0  A4 A3 9A A5 BF 7B 27 5A E6 C7 61 2D F7 B8 70 9C  ¤£š¥¿{'ZæÇa-÷¸pœ

000000D0  D4 1C 09 96 AF 5B F2 05 20 92 49 DF D5 0B FC DE  Ô..–¯[ò. ’IßÕ.üÞ

000000E0  A8 30 B7 39 34 59 13 7D E7 BD 72 3F C7 CF B3 5A  ¨0·94Y.}ç½r?ÇϳZ

000000F0  60 2C 5E 7D 63 17 56 C4 9F 6C C5 1A 01 BF B5 CF  `,^}c.VÄŸlÅ..¿µÏ

00000100  EA 01 FF BE 00 FE 6A 84 EA 50 20 20 20 20 6A 04  ê.ÿ¾.þj„êP      j.

00000110  2D CF 20 20 20 20 6A 01 9D 7C 20 20 20 20 6A 01  -Ï      j..|    j.

00000120  B3 C8 20 20 20 20 6A 01 A5 C2 20 20 20 20 6A 04  ³È      j.¥Â    j.

16-bit checksum - “Contact Service” message + Shutdown if it fails.

If changed - I get no signal.

Bytes that I can change as much as I want, probably some version info and public key of something.

Going deeper: To attack this protection I had to reach a better understanding of all of the different integrity checks. I don’t have the binary for the check performed on the first 1MB, so I reversed the check performed on the rest of the binary in an attempt to find some mistake. Using find crypt IDA script I found few implementations of SHA1, MD5 and other hashing functions that could be used and should be used to check binary integrity. I found a function that gets arguments of the type of the hash, starting address, length and returns a digest of that data. Following the xrefs of that function brought me to the following code:

The digesting function is “hashInitUpdateNDigest_j” of course. The SHA1_check_related address had the following data in it:

This is SHA1 digest of other arrays of binary, in chunks of about 0x2b0000 bytes. All of the data from 0x1000100 to 0x1100100 is protected by the ROM. The data from 0x1100100 to 0x13affff digest to EE41347A8C88F02F563BB973040E12338C03AFFA under SHA1. So I guessed that this function is the validation function that uses SHA1 to check the rest of the binary.

Later on in the same function I found the following code:

This function is performing the comparison of the calculated hash to the one in the table, if it mismatches it calls the hashMismatch function and then to the reset function with error code 4.

The hashMismatch function looks as followings:

Meaning it is a call to a function from another library, that is too far to jump using Thumb mode, so ARM mode is used to perform the call.

Therefore what I got is a code that is secured and is well checked by the ROM, which implements SHA1 check on the rest of the code, and when the check fails, it uses the code that it just failed to verify to alert the user that there is a problem with the binary.

See it is located in the 5th MB part of the binary!

From here the solution was as simple as writing a small patch that fixes the “binary mismatch” flag and jumps back to place right after the check.

How could such a fail happen to a big company like Nokia? Well, there are quite a few good explanations for that:

1. It could be that they really wanted to give the user some indication about the problem, or that they had to invoke some cleanup function before shut down, and by mistake, the relevant code was in another library that got linked to higher addresses and no one thought about it.
2. It is possible that this is a back door someone at Nokia left for himself (Only a speculation, I base it on a gut feeling and nothing else).
3. Everything was well checked on Debug build, but when they moved to Release, something went differently in the link and again they didn’t notice it.

Anyhow, this is my preferred approach for patching the flash, although, using this method I can’t patch the first MB directly, only what comes after, good enough for my tasks.

However, if it’s not enough, some guys reversed the 1st MB check for some of the phones and made it public. Though the function they published is only good for some modules, and not for the entire series.

Again the question of how? Well, it’s possible that it was silicon reverse engineering, but there’s rumored to be another method. The idea is that through JTAG debugging, one could single-step through the program and spy on the Instruction Fetch stage of the pipeline in order to recover the instructions from masked-ROM.  Replacing those instructions with a NOP before they reach the WriteBack stage of the pipeline would linearize the code and allow the entire ROM to be read by the debugger while the CPU sees it as one long NOP sled.  As I’ve not tried this technique myself, I’d appreciate any concrete details on how exactly it might be done.

Anyhow, now that I have a way to patch the firmware, I had lots of patches to make in order to make this phone Kosher. I had to reverse the menu functions entirely, which was quite a pain. I had to reverse the methods for loading strings in order to have a better way to find my arms and legs around this big binary file. Some of the patching was a bit smoother than others. For instance, after removing Internet options from all of the menus I wanted to be extra careful in case I missed a secret menu option, that the Internet won’t work. To disable the internet one might suggest searching for TCP implementation, but that's too much work, and it might harm IPC. One can also suggest searching for things like default gateway and set it to something that would never work, but again this is too much work. What I did was, searching for all the places where the word “GET” all capitals is found in the binary. Luckily I had just one match, and I patched it to “BET”, so from now on, no Internet server would ever answer requests. Moreover,To be on the extra, extra safe side I’ve also patched “POST” to “MOST”, lets see them downloading porn with that.

Other fun parts were making the Bluetooth connect to only audio devices, which took lots of reversing and learning the Bluetooth protocols.

In my next post stay tuned for the file system of the phones and ways to make them misbehave.

POC:

You can see on the video that the firmware was patched, because the code *#0000# for getting the firmware version has been changed to *#0001#. The fact that the phone receives a phone call indicates that I’ve overcome all of the protections.

Python scripts coming soon…

Cheers,

Assaf

Search for search with Search

I've tried, just for the fun of it, to search for the word "search" on different search engines to see what would come up. I was expecting Bing, Yahoo and all of the others to point me to Google right away, but surprisingly, it wasn't the case. Here are the results:
First goes Bing: (Click the image for full size)

You can see Metasearch as the first result and Yahoo as the second. Google came third. I knew Bing sucks, but at least it didn't suggested itself, so it got a bit of self awareness.
So lets check this Metasearch Bing was suggesting.
Metasearch seems to redirect me to DuckDuckGo:

DuckDuckGo is a nice search engine that combines a few others and hides your meta data from the search engine. It suggested Google in the first place... But lets save this one for last. Second place came Dogpile, another meta search engine. Bing came up third.
Dogpile:

It suggested yet another Meta search engine on the first place Search.com. This time Yahoo came second... yeah I remembered Yahoo used to be a search engine.
Search.com

Even worse than the fact that Yahoo is on the first place, Google is on the bottom of the page..
Well, lets see if Yahoo is really worth the TCP connection...

Good job, Yahoo!
If you've been around the net from the early days, you must remember Hotbot. Apparently it still exists. Although no other search engine directed me there.

These results are just copied from Yahoo, aren't they :/
Ok, before I move to the grand master Google itself, lets see what does China say. After all 1 billion Chinese can't be wrong. So to Baidu we go.

Surprisingly, Baidu promotes itself (Or more surprisingly the others don't). Yahoo comes second, and Google is somewhere on the bottom (Not even in the picture).
As for Google:

Surprise, surprise!
Google counts Yahoo as qualified for "search".
Shame on you, Google!

Looking Into the Eye of the Bits - The video

I've just done uploading to Youtube my old talk about memory analysis. Please let me know what you think. This is my first attempt in creating a video tutorial, and I would love to get some feedbacks jsut to know if it is good, if there is anything I could do better or if I should never do it again.
English version:

Hebrew version:

Problems with software reverse engineering

A dark times to us all reverse engineers, especially the software kind. During my ~ten years of practice in the area, I’ve found out that today we have less tools for the task than what we had five years ago. Sure, nowadays IDA has a decompiler and some kind of a Python integration, but we all miss tools that served us for so long such as SoftICE and the Zynamics bindiff.
In this blog post I would like to tell my humble opinion on the subject.
Lets say a person, who I’ll refer to as the user, is given a one million pages long book (Font size 7). The user is being asked the simple question of “Does Alice ever meet Bob in this story?”. The user can read all million pages or die trying, in order to answer the question. But if the user had a digital copy of the book he could have searched for all of the places in the book where the word Alice and the word Bob are found not more than two pages apart. If the user had a Python interface to all the information found in the book, he could have used RegExp or some kind of lexical Python modules to maybe look for the word “meet” in all variations such as “meeting”, “met” or so on. Moreover, he could have found a way to figure out if there is a nickname for Alice such as “The Bitch”, and to automatically add this nickname to the search.
The way I see it, the current status of software reverse engineering is much closer to the hard copy book search task, than the digital one, and much further away from a decent Python interface.

The most commonly used tool IDA is giving the user a huge textual dump of disassembly, with some basic blocks, functions and higher level of understanding, where the highest level it gets is with the decompiler in which the user gets a C like code to read. I agree that it is easier to read C code than Opcodes but not by far. The user would never be able to read all the text for even the simplest program such as the Ms-Minesweeper. To produce this kind of text dump IDA had to had some kind of “understanding” of what each and every opcode is doing. I call this “opcoding doing” the opcode side effects. For instance, the side effects of the “ADD EAX, EBX” opcode would be reading EBX, EAX and writing to EAX and EFLAGS. IDA got this precious knowledge of side effects but it doesn’t let the user access it. I think this is the biggest point of failure in the understanding of what reverse engineering should look like.
Lets consider an example of creating a crack for a simple serial protected tool. The approach usually is of using a debugger to break on some known related API such as the GetDlgItemTextA or MessageBoxA to get to the point where the username is read or a wrong key message is displayed. Replacing this part of the task with a search of all functions in the code that are one or two steps away from both of these APIs, slicing with all the functions that contain the XOR opcode with two different operands, and some other characteristics relevant only to those kind of functions, would most likely produce a very short list of potential functions. When analyzing the functions, it is probably using many other functions that the user doesn’t care about, while only few of them are relevant to the serial validation. Displaying a list of all functions that are accessible from a certain function and filtering only the ones that might make an access to the buffer that is pointed by EDI or so, would make the job of the reverser much more effective.
The text of the opcodes is hardly ever what the reverser really cares about, he just wants to know what are the side effects of a function are, whether it changes EAX or not, whether it makes a copy of the buffer or not. The decompiled code is nice, but considering the fact that it’s not possible to recompile this code, why write it in C and not as an equations or list of arithmetic operations.
The reversing tool should be a much dummer tool that just creates the access point to as much information as available, the analysis should be done later on with scripts and plugins. The analysis that is done on a malware is not the same one that is done on a DRM product and is not the same one that is done on recovering algorithm.
However, putting all that aside, we have to have undo functionality. The lack of the undo function in IDA represents not only the fact that the tool is incomplete, it represents the fact that tool was made with small projects in mind, while sometimes the reversing work is something that is done over a long period of time. Symantec, Kaspersky and others told it took them a few months work of more than one reverser to get a basic understanding of the Stuxnet, which as far as I know, had very little anti-debugging tricks to it. IDA is not made for collaboration or long time research.

I would love to hear more opinions about this subject, and what people think should be done about it.

Cheers,
Assaf

Map-Hack Tutorial

Map-Hack is a cheat for strategy games such as Warcraft or Starcraft, Dice n’ Slice games like Diablo or 3d shooters games like modern warfare. The cheat as most cheats is done in order to give an unfair advantage to the player who uses it. In case of Warcraft a map that usually looks like the one in the top left corner:



under cheating condition, would look like this:



or even better, like this:



Zoomed in:



The idea behind it, is to give more information on the map than what is found in the regular game play. Information like which gold mines are wealthier, and which enemy creatures are deadlier.
To create this kind of cheat one would have to go through two phases:

1. Research, in which you need to figure out how and where the map data is stored in memory, and how to find where it is stored every time the game restarts.
2. Developing, in which you write a code or a script to change the map data in real time.

In this tutorial I would only display the research phase up to the point of proof of concept.
To perform this research I need an Interactive Python Interpreter. This would bring up the question of which version of Python should I use.

• Games are for Windows. So I'm gonna use Python for Windows (Better use the one from Python.org than Active-State Python).
• I'm about to research a 32bit process so it is better, although not a must, to use 32bit Python.
• The tool-chain I wrote is not ported to Python 3.x just yet, because I'm lazy, so Python 2.7 or 2.6 would have to serve me this time.
• As for the Interactive Interpreter, I prefer the Dreampie.

The tool-chain is an external module, which helps in the task of memory research. The module is called NativDebugging, and is freely available at the following SVN: http://dreampie.sourceforge.net/. Install from source simply by:

python setup.py install

Or just get the installer from http://www.4shared.com/file/jE4xjHDb/NativDebugging-10win32.html? .
My NativDebugging module can be used as is, but it has extra GUI features if the PyQT module is found, so download it from:
http://www.lfd.uci.edu/~gohlke/pythonlibs/#pyqt
and double click to install.

Now that I have got the entire environment set, let's get the party started. Let's start with something easy that everyone likes: Minesweeper (AKA: Winmine).



Important note: Use the old version of the minesweeper as many internal structures are different in the new Windows Vista version that looks like this:



I start by launching the game, and getting its' process id. There are many ways to get the process id, either to use the task manager or with the following command line:

tasklist /Fi "IMAGENAME eq winmine*"

Or from Python using the NativDebugging module.

>>> from NativDebugging.Win32.MemoryReader import *
>>> findProcessId('winmine')
[('winmine.exe', 376L)]
>>>

Next I want to tell the NativDebugging module what is the target.

>>> m = attach(376)
>>> 

I need to get details about where in the 4GB virtual address space memory is allocated. The m.getMemoryMapByQuery method suits for the job.

>>> memMap = m.getMemoryMapByQuery ()

This operation might take some time, depending on how much memory is really used by the target process.
I start the search of the place in memory where the board of the game is set, using the technique called differential search. Differential search is a search in which one starts with a picture of all the memory, and slowly filters out things that are not what he is looking for, until he is left with a single result. In this example I'm looking for the top left square of the board. Setting up a new search is done as following:

>>> from NativDebugging.Win32.DifferentialSearch import *
>>> ds = DifferentialSearch(memMap, m)
>>> 

Now I simply, change the value of the square by uncovering it



Next I filter out any memory address that  has not been changed:

>>> ds.removeUnchangedMemory()

The first filter can take up to few minutes, again depends on how much memory is used by the target process. If I wait for a little while, some of the memory would change by itself, so I can remove any memory that changed:

>>> ds.removeChangedMemory()

I continue by causing more changes to the first square and invoking the removeUnchangedMemory method.
To check how many potential memory addresses are left the "len" method on the DifferentialSearch object can be used. Filtering process is repeated until only one or two places in memory are left.
If you are following the process to this point, and all was done correctly your Python Interpreter should now look something like this:


(Click on the picture to enlarge it)

Now I can get the address that was found simply by looking at the DifferentialSearch object or by retrieving its' data in index 0.

>>> ds
0: 0x01005360: 10404040
>>> ds[0]
16798560L

I save the address that was found in a new var to be used latter:

>>> board = ds[0]

The memory can be examined in various ways, here are few examples:



One can also try to write over the memory to see how the game behavior is changing.
The most useful way to look at memory dumps of maps is using the mapDisplay method, which hopefully, would show up in a new QT window as following:



All of the display parameters are accessible from both the GUI and the python object that was created with the creation of the display. I now play with the line size until the following result is reached:



Can you tell where all the mines are placed?

The interesting part in case of minesweeper is that, the map is always found in the same place in memory, so if I start a new game, and update the data (using w.updateData()), I might get something like:



In real games, the principle is quite the same, though it takes more time. The main difference is that the map is usually allocated dynamically so one would also have to find a global pointer to it, to be able to locate the map in memory quickly. I have an example of the same process done on the WarCraft II strategy game, but this blog post is long enough as it is. So maybe next time.

Future TODOs:

• I believe that the search function could be much faster, I would love to have some help in optimizing the code.
• The GUI has lots of room for improvements.
• I need to write an installer, and to create a Python 3.x branch.

Cheers,
Assaf