View Full Version : Reversing the algo's used for encrypting the IMEI
Could anyone share some info on algorithms used in Siemens for encrypting the IMEI?<br />Something about the memory architecture of C166 processor used inside the handies?<br />What is the structure and differences between EELITE & EEFULL?<br />Any help and info will be appreciated! ;-)<br />I'm working on reverse engineering the software in Siemens S35 and if somebody wants to help, please contact me!?
If you look at the thread called "Siemens map creator source" you will find a link to a file containing Pascal source for generating this data for various Siemens phones.
Although certain parts of the calculations are being carried out in the dongle, there is enough information in that file to create working maps for the C30 and C/M/S35. The program "ZeeSiemensG3" also contains a working map generator for the C/M/S35, although this is only available as object code (and it's not initially obvious that the program is a map generator, since it reads the IMEI from the phone, and always writes it back).
If you want real kudos, then reverse the x45 phones - there is currently no information available on the algorithims used in these.
If you're going to be reversing any sort of microcontroller code, then get a copy of the IDA dissassembler - I think the "pro" version supports the C166. If you can afford it, I strongly recommend buying the program, since their support is excellent (and, obviously, only available to people that have given them money <img src="smile.gif" border="0"> ).
I have no idea what the memory layout is, but would suspect that getting either the Egold or C166 manuals and looking at the reset routines would give you a reasonable idea (since normally one of the first things to do is to set up the memory/chip select control registers).
Regards,
Pete
Hey Trimesh ...
:-) Do not forget A3x, A40, SL45 ...
C45 algorithm is lite version of a3x ...
Regards: Victor
Thanks for the information, TriMesh! <br />In fact I was looking for EGold manual for a while but didn't find anything suitable - just the plain C166 guides. And I'm looking for it, because I use IDA to disassemble the microcontroller code and need some additional info regarding memory layout and structures used - for example EELITE and EEFULL blocks?<br />I've already read the source published by Max and it is excellent source of information but as you mentioned some of the algo's are hidden in the dongle ;-) <br />So I want to find out where in the microcontroller code these algo's are implemented (and not only for x35, but for x45 as well ;-))
Hi, Victor
[quote]Originally posted by Victor:<br /><strong>Hey Trimesh ...
:-) Do not forget A3x, A40, SL45 ...</strong><hr></blockquote>
I was going to look at the A3x phones, but stopped for a couple of reasons.
1) I don't have a phone to test things on, and don't want to get a reputation as someone who releases phone killer sw <img src="smile.gif" border="0"> <br />2) You were already working on it, and clearly had a considerable head start. Since you are actually selling the softs, and I'm just doing this as a hobby I wouldn't want to step on your toes.
[quote]<strong>
C45 algorithm is lite version of a3x ...
Regards: Victor</strong><hr></blockquote>
But the C45 seems to have some additional IMEI dependent blocks that the other phones don't (although the code to generate these seems to be entirely contained in Maxim's source).
Maybe I'll have to find one of the A3x phones <img src="smile.gif" border="0">
Regards, Pete
c45 imei ...
only changed short and long keys ...
I assume by "short and long keys" you mean the lookup tables used for transposing the nibbles in the data, and the tables of XOR values used for each round? I noticed that they were different, but the Pascal code also has an additional data structure (CodE2) that's filled with dongle supplied data, and quite a lot of extra mangling in CreateIMEISpecificBlocksC45() - which is only called for this phone type.
Of course, this could be obfuscation - although it would seem strange just doing it with one sort of phone - I can see I'm going to end up having to pull the phone firmware apart <img src="smile.gif" border="0">
Regards,
Pete
Do you know whether the C25/C28 handies are using the same algorithm as x35 ones or not?<br />I have found inside the microcontroller code the same tables for performing so called tricky calculations (thanks to Max ;-). So I wander is there some map generator for these older models floating around?
Regards to all reversers out there ;-)
Does anybody know what is the memory layout in Siemens x35?<br />It has 16MB address space and I've found that the core code is mapped to the last 4 Megs (0xC00000-0xFFFFFF). But there are references inside the code to lower segments. Some of them apparently are data segments but there are also calls to some code residing outside the last 4 Megs, especially from segment 0xf0 (for example calls 1,0x0208).<br />I need some little help about the memory mappings if somebody can and want to share this info?
Processor contains ROM ... with primitive routines inside ...
u need also dissasemble RAM
Thanks, Victor!<br />I suppose that ROM area is mapped to 0x010000-0x017FFF, right? Will you tell me how I can get this ROM area to disassemble it?<br />And also what do you mean to disassemble RAM - is some part of the code copied there and then run from RAM?
:-) ... from 000000 to 1f0000 ...
must make big file RAM + ZEROES + BINFILE OF FLASH ... and then start dissasemble
Thanks again :-)<br />Do you have some useful tool for dumping the RAM area you are talking about (000000-1f0000)? <br />May I use the Andromeda flash reader 3.0a to download this RAM area?<br />And one more time I want to ask about Siemens C25/C28 - is it using the same algo's for encoding the blocks 76,5008,5009,5077 with IMEI and phone id? I have one dead C28 v61 and want to make some investigation and reversing to bring it to live eventually ;-)
Yes i have but is builded by me for internal my use .. Sorry i canot give to you but is easy to build this toool.
Andromeda will not help to you.
regards: Victor
thewizard
01-19-2002, 16:23
About read ROM C45<br />You cant read TRUE RAM/ROM in boot mode<br />all this datas is fake.
You need read RAM in normal or test Mode.
Regards<br />The Wizard
To Victor:
Are you using the BFB protocol for reading the memory from the mobile? And if yes, where can I find some more information about this protocol? I've already some knowledge about it by reversing some of the tools out there, but their authors must have some more info on that indeed ;-))<br />I don't want to mess with your business and am curious just for myself about the internals of the protection scheme used by Siemens :-)
Thanks and regards!
thewizard
01-20-2002, 22:50
This commands for read RAM in normal mode is forbidden in C45. You need patch flash ...
regards
wizard is verry verry right... <img src="smile.gif" border="0">
Ok, but for the time being I don't need to read RAM from C45, only from x35 (or x25).<br />Is it possible to be done in normal mode via BFB protocol?<br />And should I read the whole 16M addressable space?
yes! read without problems ...
Ok, thanks again, Victor!<br />May I ask you just one more question - where in the addressable memory space the EEPROM area is mapped to? <br />And also could you help me with the syntax of one particular BFB command - for reading EEfull blocks (14 08 1c 14 xx xx yy yy zz zz chksum)? <br />I'm interested particulary what is the meaning of yy yy ;-))
[quote]Originally posted by The_Wizard:<br /><strong>About read ROM C45<br />You cant read TRUE RAM/ROM in boot mode<br />all this datas is fake.
You need read RAM in normal or test Mode.
Regards<br />The Wizard</strong><hr></blockquote>
This is not true, you can read good data from Bootmode process, but you mus hav goo boot loader. I have not ! I find !
OrbiTel
To Victor:<br />I am almost ready with my memory dumper ;-)<br />But I'm still waiting for a little more help regarding the memory layout, e.g. where EEPROM area is mapped inside the addressable memory space (000000-FFFFFF)?<br />Would you be so kind to give me a clue? :-)<br />And also about the syntax of ReadEefull command (the problem is how to read blocks that are longer than the maximum of 31 bytes per request?) I suppose that yy yy is the offset from the beginning of the block but if you could confirm that it would be great ;-))<br />Thanks!
Originally posted by papajoe
To Victor:<br />I am almost ready with my memory dumper ;-)<br />But I'm still waiting for a little more help regarding the memory layout, e.g. where EEPROM area is mapped inside the addressable memory space (000000-FFFFFF)?<br />Would you be so kind to give me a clue? :-)<br />And also about the syntax of ReadEefull command (the problem is how to read blocks that are longer than the maximum of 31 bytes per request?) I suppose that yy yy is the offset from the beginning of the block but if you could confirm that it would be great ;-))<br />Thanks!
x35_Flasher (http://gin.hit.bg/gsm/x35_Flasher.rar)
+could you/someone send me newer bfb95eg.dll or equiv?
cheerz,
Anton
if anyone want it just email me atipe@wanadoo.es
Originally posted by TriMesh
If you look at the thread called "Siemens map creator source" you will find a link to a file containing Pascal source for generating this data for various Siemens phones.
-- some text skipped ---
Please give a link to pascal soures.
Thanks
comunicatel
07-12-2002, 15:51
and what about S40.
It uses this subroutine
Procedure TIForm.CreateIMEISpecificBlocksS40(IMEI: String; ID: String);
Begin
Idx := 0;
ConvertToPhoneID(ID);
ConvertToC30BCD(IMEI);
EncriptC30HiddenBlocks($08, $000A, Def00, 00);
EncriptC30HiddenBlocks($08, $06E6, Def0C, 18);
EncriptC30HiddenBlocks($1C, $0CFE, Def22, 02);
EncriptC30HiddenBlocks($3C, $0D20, Def40, 00);
EncriptC30HiddenBlocks($0C, $0D60, Def10, 00);
EncriptC30HiddenBlocks($28, $0D70, Def2E, 02);
EncriptC30HiddenBlocks($40, $0D9E, Def44, 00);
EncriptC30HiddenBlocks($FC, $07FE, DefFF, 00);
EncriptC30HiddenBlocks($FC, $08FE, DefFF, 00);
EncriptC30HiddenBlocks($FC, $09FE, DefFF, 00);
EncriptC30HiddenBlocks($FC, $0AFE, DefFF, 00);
EncriptC30HiddenBlocks($FC, $0BFE, DefFF, 00);
End;
AS U can see Its simillar to C30 calculation of specific blocks
Henrich SGU
07-12-2002, 15:56
U have tested this subroutine on S40 ?
So coding algo is similar ....
Sergey[Power User]
07-13-2002, 09:10
Originally posted by Nutzo
Hi,
since nobody wanted to help, I did it myself.
So to jump to conlusion:
to unlock "new" C/M/S35s you need to XOR the
phoneid (Cod18) with 0xCA, 0xFE, 0xAF.
All the other things are totally the SAME.
Cheers,
Thanx...
P.S.which addresses of this code in firmware?
p.s. Could anybody help me to create dumper for
lower memory addresses? Is that a "simple" Egold
flasher which simply reads the lower "flash" memory map?
(of course only on C35). Another thing. Could anyone point
me to an address where I could find the infamous sub
which handles reading request on C45 (i.e. what must
be patched so that to be able to read the lower addresses)?
Pretty please. If someone helps me I can send him the
sources of my program called kSie (after kNok) which
has several unlocking method in it (C35, C45, "new" C35).
What do you mean saying "lower addresses"?Internal ChipSet ROM?External RAM? (they're really at lowest addresses).Anyway,I think it is a good idea to unassemble Max-RFon boots from his flashing SW.They're SMALL and using them it is possible to grab int.ROM/RAM/FLASH/... etc:)
Hint: one boot seq used for C\M\S35,S40,etc... only 45 series different.
(I think it will be not so hard to modify this boots to make your custom tasks you need... they're quite small and easy to uderstand)
maybe nutzo wanna from 0 to 1f0000 ... this is RAM area
nutzo contact me...
Sergey[Power User]
07-14-2002, 08:14
Originally posted by Victor
maybe nutzo wanna from 0 to 1f0000 ... this is RAM area
nutzo contact me...
Hmm.... 80c16x starts from iROM at 000000h
(this is chipset internal ROM of course,it checks for "red button","100% empty flash",etc,also at latest addreses of iROM there is "ROM-BIOS" with some comon procedures like memcopy-they're located here for SPEED:acces to iROM is 32bit while ALL other is 16 bit max.) then iROM later moved to 010000h(80C16x can do this trick).Typically in all init's(boots,chipset ROM->Firmware,...) I seen RAM at 000000h->010000h(I'm not sure if it 32Kb or 64,not tested yet by me),then iROM at 010000h->020000h(really looks like iROM not 100% filled by code and has free space).
(0...200h vectors,after 200h usual big RAM,often used by boots for their big main "application")
P.S.It is possible to grab this area in boot-mode by freely available sw;)
(Of course there is not so hard to write prog which using Max-RFon's boot sequence "3+1" ;) )