View Full Version : Patching symbian exe

January 11th, 2008, 02:44
Greeting from a newbee...
Using IDA, I disassembled a symbian arm based exe file. some sample result:

.text:0015C4BC BL __cxa_end_catch
.text:0015C4C0 MOV R0, R4
.text:0015C4C4 BL __cxa_end_cleanup

Let say I want to change BL to BE to bypass the checkpoint. The hex sequence value (showed by IDA) is: 53 6C 00 EB 04 00 A0 E1 1F 6B 00 EB 50 6C 00 EB .. so on....

However, using hex editor, I can't find that hex sequence in the same exe file. What's the catch?
Pls help on this...

January 11th, 2008, 03:37
Sounds like a packer/crypter to me...

January 11th, 2008, 07:22
Are you saying that IDA automatically unpack the file? I use IDA standard installation, nothing fancy. The dissassembled file is very clean & easy to follow with bunch of readable strings & functions.
I was suspecting the difference between ARM (which is used in the mobile where the application is hosted) & intel x86 architecture (in which I use the hex editor), but I have no idea about it.
Any idea?

January 11th, 2008, 11:30
Well, I think that the most probable thing is that you've different files open in IDA and in the HexEd, or you've mistyped the string of bytes in the search form. Check the offsets in IDA and in the hex editor.

January 11th, 2008, 13:23
Sorry, I misread your post, and thought you were working on a dump or in an active debugger.

Like Polaris said, I would double and triple check that you're working on the right file, and that the opcode sequence you think those instructions have is correct (opcode display width setting in disassembler, opcode prefixes etc), try to search for smaller parts of the sequence until you find anything, and then go from there.

January 11th, 2008, 14:19
I don't disassemble ARM executables very often but IDA still shows the physical offset on disk at the same time as the virtual offset in the usual status bar at the bottom of the IDA View window.


Patching in IDA and exporting a diff file should also tell you exactly which offsets to patch with an hex editor after.


January 11th, 2008, 16:25
you probably opened two files or misspelled something. Because what you did is correct, conceptually. Anyway to avoid problems just use the IDA option that allows to see the bytecodes beside the instructions. Just go in options -> select the Disassembly tag -> find (on right) the edit field "number of opcode bytes" and set it to 4 (all the ARM instructions have fixed length).

Then beside the instructions you will get the corresponding opcodes, simpler of going all the times back and forward from the hex view.

The file offset ida shows is enough for an hex editor anyway.

January 11th, 2008, 21:23
[Originally Posted by Polaris;71687]Well, I think that the most probable thing is that you've different files open in IDA and in the HexEd, or you've mistyped the string of bytes in the search form. Check the offsets in IDA and in the hex editor.

Triple checked, they're the same file, and I didn't mistype because it's a copy-paste.

[Originally Posted by dELTA;71689]try to search for smaller parts of the sequence until you find anything, and then go from there.

I even stripped it down to 2 hex values only and still no luck.

@all folks
Please take a look at this idb file (disassembled from a freeware):


IDA found some strings which I can't with hex editor.

January 12th, 2008, 00:17
[Originally Posted by treby;71700]
IDA found some strings which I can't with hex editor.

Did you search UNICODE?

January 12th, 2008, 00:42
I search unicode, ascii, and manually..
Maybe you can download it from the link above and check it, I included the exe file.

January 12th, 2008, 09:25
After looking at the file, things are now clear. Basically, your file is compressed. In fact, from Nokia website, you can get the definition of the header of the EPOC v9 file format. I copy it here highlighting an interesting field:


class E32ImageHeader
TUint32 iUid1;
TUint32 iUid2;
TUint32 iUid3;
TUint32 iUidChecksum;
TUint iSignature;
TUint32 iHeaderCrc;
TUint32 iModuleVersion;
TUint32 iCompressionType;
TVersion iToolsVersion;
TUint32 iTimeLo;
TUint32 iTimeHi;
TUint iFlags;
TInt iCodeSize;
TInt iDataSize;
TInt iHeapSizeMin;
TInt iHeapSizeMax;
TInt iStackSize;
TInt iBssSize;
TUint iEntryPoint;
TUint iCodeBase;
TUint iDataBase;
TInt iDllRefTableCount;
TUint iExportDirOffset;
TInt iExportDirCount;
TInt iTextSize;
TUint iCodeOffset;
TUint iDataOffset;
TUint iImportOffset;
TUint iCodeRelocOffset;
TUint iDataRelocOffset;
TUint16 iProcessPriority;
TUint16 iCpuIdentifier;

Now, if we look at what is the explanation of that field, you can read:

iCompressionType, is the UID of the library used to compress the executable file. It is 0 if the executable is not compressed or KUidCompressionDeflate (=0x101F 7AFC) if it is compressed with Deflate algorithm.

Now, if we open the file with an hexeditor, guess what we do see?

0x1C: FC7A1F10

So now you know what is happening: basically IDA's EPOC v9 loader knows the file format and unpacks automatically the file for your disassembling pleasure.

Have fun!

January 12th, 2008, 10:58
First read this:

Then this:


(look for "imgdump (including deflate code) is included" on the page)

Let us know how it goes.

January 12th, 2008, 13:55
Good find Polaris! Shows the benefits of starting with the "basics."


January 13th, 2008, 22:12
Thanks folks! I'll do my homework to patch it..

January 25th, 2008, 13:51
Hi all,
Why does no body post anymore to this topic? do i miss something?

So the exe file is packed/compressed. This prevents us from seeing the same hex data in a hex editor as in IDA debugger when we debug our EXE file which we extracted from the sis package. After reading on fro the links given in this topic I have found petran.exe a tool used to do somethings with the EXE file, and one option is to "nocompress". The petran application comes standard with any Symbian OS SDK. Try to download a SDK and install it. After installing the SDK petran is found in: "C:\Symbian\9.3\S60_3rd_FP2_Beta\epoc32\tools\petran.exe" (standard installation folder). Then open command (start -> run -> cmd.exe) and type <path to petran> -nocompress <path to exe file extracted from sis package>. (see its parameters by only typing the path to petran)
For example: "C:\petran.exe -nocompress C:\testapp.exe" (use convient directorys offcourse instead of typing the whole path to the SDK tools).

Now the file to be "nocompressed" is updated and the hex values in the hex editor are the same as in IDA.
I have also included a assembly analysation of petran.exe using OllyDbg. I have highlighted the use of the compression integer 101F7AFC there mentioned by Polaris earlier.
Is this helping to you all?

Grtz Devoney
--< Share your Knowledge >--

January 25th, 2008, 14:05
oh yeah it should sure be helpfull to some one playing with symbian


C:\DOCUME~1\ADMINI~1\Desktop\petran>petran.exe -v "Copy of petran.exe" foo.exe >

C:\DOCUME~1\ADMINI~1\Desktop\petran>dir /b
Copy of petran.exe



PETRAN - PE file preprocessor V02.01 (Build 576)
Copyright (c) 1996-2007 Symbian Software Ltd.

E32ImageFile 'foo.exe'
V2.01(576) Time Stamp: 00e137cc,6c6f7f00
EPOC Exe for X86 CPU
Flags: 22000000
Priority Foreground
Image header is format 2
Image is compressed using the DEFLATE algorithm
Uncompressed size 00015db0
Image FPU support : Soft VFP
Pageability : Default
Secure ID: 00000000
Vendor ID: 00000000
Capabilities: 00000000 00000000
No Exception Descriptor
Export Description: Size=000, Type=00
Export description consistent
Module Version: 1.0
Imports are PE-style without redundant ordinal lists
Uids: 00000000 00000000 00000000 (00000000)
Header CRC: 59142023
File Size: 00015db0
Code Size: 00014d14
Data Size: 00001000
Compression: 101f7afc
Min Heap Size: 00001000
Max Heap Size: 00100000
Stack Size: 00002000
Code link addr: 00400000
Data link addr: 00414d14
Code reloc offset: 00000000
Data reloc offset: 00000000
Dll ref table count: 0
Offset Size Relocs #Relocs
Code 00009c 014d14 +00977e (entry pnt)
Data 014db0 001000
Bss 04af84
Export 014d5c 000054 (21 entries)

Code (text size=00011470)
000000: 08244c8b 0c24448b 7c8b5756 148d0c24 8bca3b01 07b70ff1 0f531c73 c9331eb6 .L$..D$.VW.|$....;......s.S...3.

thanks for a good first post

January 25th, 2008, 19:50
I have analyzed petran.exe in OllyDbg. I have highlighted the flow of the program while it is busy decompressing the file of interestusing the compression integer 101F7AFC (which was also mentioned by Polaris who got it from a Nokia site and in the report produced by petran.exe shown by blabberer).
I think this analysation can come in handy when Nokia starts using a different compression integer because I show where the program uses this integer.

January 26th, 2008, 04:39
Welcome to the board Devoney, and thanks for the good info.

Nice analysis also, but it wasn't really necessary, since the source code for PETRAN is available.

You will find the source code, the binaries and more info in PETRAN's entry in CRCETL:


January 26th, 2008, 05:15
Gee, ... thanks...
Did not know it was already known on this forum that petran existed... Also because nobody replied anymore to this topic and I was experiencing the same problems as the topic start. Thanks for the update about petran! Going to save its source with the rest of my tools for analyzing S60 3rd binaries.

Do you might know how where to place binaries to be able to test with the EPOC emulator, the one that simulates a symbian phone? the emulator itself works but I dont know where the emulator gets its installed applications from, which directory?

Thanks for the reply

January 26th, 2008, 05:27
Hey Devoney, we did not know about PETRAN, I just researched it a bit after your tip (and subsequently added it to CRCETL).

I sadly don't know the answer to your question, but the forum thread referenced from the CRCETL entry, and also other threads on that forum, might very well contain that answer I think.

January 26th, 2008, 13:45
I use the emulator that comes with the Symbian SDK. After installing the SDK the emulator can be found under: C:\Symbian\9.3\S60_3rd_FP2_Beta\epoc32\release\winscw\udeb\epoc.exe
Appereantly these two directories emulate the C and D drive on the phone:

One site states the applications to emulate must be placed in:

I have tried it but it did not work...
Its a pitty because sending it to the phone over and over again while debugging costs a lot of time... It already costs alot of time with the unpacking, decompressing, not being able to patch with IDA, so patch with Hex editor and then test....

If anyone can help me on this one thanks!
And its great that you placed the tool on your site!

January 27th, 2008, 10:58
Why do you have to recompress the file after patching it? If you just decompress it first of all, and then load it in IDA, you should both be able to patch it in IDA, and not have to re-compress it before each test run, right? Or what am I missing here?

January 28th, 2008, 05:29
I dont know how to patch in IDA for even Win32 executables... :P (I am ashamed) But when I want to save the file IDA says the operation can not be executed because the file format is unknown... And ofcourse running the ARM processor binary in IDA on Windows is not doable without a emulator. I have not tested it yet but (without the emulator) the only way to test the path would be to get it on the phone, which I dont know to do manual so I have to bring it back to its original state: compressed in a *.sis file.

If you have any tips, for example how to patch with IDA then they are all welcome of course. (Though I have seen some "patchlike" options in the edit menu)

January 28th, 2008, 12:36
Hey Devoney, the following thread should hopefully describe IDA patching to a sufficient degree:


One of the "common" ways of using IDA for patching is to use its patch feature, as discussed above, then export a DIF file for the patched IDA database, and then use any DIF patcher program to apply the DIF file patches to the real executable.

Regarding your other questions, I sadly don't know enough about Symbian stuff to answer them. Anyone else?

January 28th, 2008, 14:16
If you check the RCE Video Portal, I made a video about patching in IDA and Black Magician has made another one to show how to use remote debugging on a phone or emulator via ActiveSync.

Like dELTA, I'm not a phone nut either but this might help.


January 30th, 2008, 09:36
Thanks for the help! I will check out the patch tuts soon. Not now I am at work . For as far I know activesync is a microsoft software product to establish a connection between Windows Mobile devices and a Desktop computer. But I will check it out eitherway because that info is welcome to!

Thanks so far,
if I manage to succesfully patch a Symbian S60 3rd *.sis file I will write a tutorial and post it here. Dont expect to much, I aint that much of a "cracker"

Grtz Devoney

January 30th, 2008, 16:19
You're right, it wouldn't work with ActiveSync in this case.

Shub-Nigurrath's "Primer on reversing Symbian S60 applications" might give you a hand too with some examples.


February 1st, 2008, 03:34
Thanks for the tip about accessroot, I think it is a good resource. Didn't have time to check it out yet though. I will reply if I discover something essential. TiGa are you also registered at www.reversing.be ? I think I have seen your nickname somwhere else.

Actually my goal with all this patching is "cracking" Net S60 from RedFiveLabs so it isnt an evaluation version anymore. They are developing a framework for Symbian which supports the integration of .Net applications of Windows Mobile on Symbian S60. They need feedback and people who try the application to report errors and experiences etc. So far it is free of charge (of course) but I think they want to make it commercial in the end. And at a certain date the evaluation version of the program stops working because it expires then.

Grtz Devoney

February 1st, 2008, 14:30
I think you know me from crackmes.de

Well, good luck and don't hesitate to ask question or share your findings.