Looking for serious developers

[jmarc]

Hi.

I'm looking for serious developers who do their homework and know more than just how to click buttons. It appears to me that this forum is a good place to find those..

My experience is broad and covers almost all big brands. However I was away for about 2 years, and thus missed the most recent changes. Now I'm about to dig into all this again, and would love to communicate with others.

In the past, my work was somewhat isolated. This was bad, because I had to do everything myself. On the other hand it was good, because I was able to do stuff that others couldn't do. I'm not exactly sure what is public knowledge right now and what isn't. But eg I am able to decrypt Nk Flash and FIA, and to boot UPP and cable-unlock 0120 without any Phoenix files, which isn't public knowledge IMHO.

Are you my kind of dude?

Marc

[Crux]

by ur post, i see u are outdated :)

what kind of programer u really need?

[jmarc]

by ur post, i see u are outdated :)

what kind of programer u really need?

Hi Crux..

Please check your private messages, I sent you one a few days ago.

Marc

[XARiUS]

But eg I am able to decrypt Nk Flash and FIA

I would looooove to know this! :)

[gsmsolutionsltd]

@jmarc


What is your new mission...maybe we can help

[jmarc]

@jmarc

What is your new mission...maybe we can help

At the moment I'm updating my knowledge to todays' phones (which seems to be quite easy) and filling the gaps that remain from the past (which is more difficult).

One example is what I call the UPP buskey. It's the value that's stored in flash and has to be copied to the IO space to enable the transparent bus decryption. Obviously it's stored in the UPP hardware for comparision, and the only way I found to get the value is to read it from the flash. That is, when the flash is totally erased, I better have a backup of it. I'd really prefer to read or re-generate this value from hardware, but found no way to do it (yet).

Note that I conduct my experiments with a special piece of native software (not with Phoenix files). That is, I have complete control over the hardware and initialisation. The limiting factor is my knowledge of the hardware, not the software I use.

Do you know what I'm talking about?

[Crux]

thats cool

seems like u know more than me

btw what software are u talking about. what is that

[Mulder3]

So, if i can understood you, you found a way to run a custom-made boot loader on the phone? is that? All boot loaders are encrypted and decrypted in run-time, how to you do that? I Think the phone will refuse to run any code in "plain text"...

[jmarc]

Yes, that's what I do. I boot my own native code to do my analysis. I disassembled the FIA files and regular firmware to find out how to control the hardware. Eg how to configure the chipselects, how to allow flash write access, how to use the CBUS (thanks to the debug messages that NMP left in their firmware), etc.

However, there remain a lot of things that I don't know. Those that are not contained in no FIA or firmware file, and not obvious enough to just try them. The UPP buskey is an example. I think it's the encrypted version of another piece of data (like the UPP serial number), and either stored in some kind of OTP memory, or deducted from the other data at runtime. Might be possible because there exists an ACK bit which has to be polled after loading the key (which indicates processing in hardware or by the DSP). Well I think I have to do a measurement of the processing time to find out more about it.

The DSP is another such thing, I have quite a lot of disassembled firmware code that communicates with the DSP, but it's far from being complete and reproducable. When I boot the phone and try to communicate with the DSP, it doesn't work (there's some initialisation missing, obviously). And also I still didn't manage to download the DSP code for disassembling.

Did anyone of you? Or are there already DSP code patches in newer phones (like there were in DCT3)? I'd love to see them.

[Mulder3]

Can you explaint me what is teh purpose of UPP buskey? is that the "key" that decrypts the code? where is located on the phone the algo that decrypts the firmware? Do you encrypted your boot loader before load it on the phone? How you decrypt the firmware to diassemble? I) would love to put my hands on a decrypted dct4 firmware :) Have you try to dissasemble a symbian firmware? sysmbian firmwares have filesystem, i would be very usefull to understand that file system to be able to exact individual "programs" since the symbian phones are divid in programs so you can diassemble just what you need.

[jmarc]

> Can you explaint me what is teh purpose of UPP buskey? is that the "key" that decrypts the code?

Yes. I think it is an encrypted table. Each phone has a different key but they all result in the same table after decryption. The table, once initialised, is then used as key for the bus decryption. It also contains some kind of consistency check so that invalid (eg random) keys can be rejected.

> where is located on the phone the algo that decrypts the firmware?

In the UPP bus interface hardware.

> Do you encrypted your boot loader before load it on the phone?

Sure, otherwise it wouldn't execute.

> How you decrypt the firmware to diassemble?

The easiest way is to download it from the phone as seen by UPP, so the phone itself does the decryption. Given a matching ciphertext / plaintext pair, I can also encrypt any plaintext under the same key. I didn't investigate that any further, but I might try tonight. I did this a long time ago and don't recall all the details.

> I) would love to put my hands on a decrypted dct4 firmware Have you try to dissasemble a symbian firmware?

No.

> sysmbian firmwares have filesystem, i would be very usefull to understand that file system to be able to exact individual "programs" since the symbian phones are divid in programs so you can diassemble just what you need.

I don't know how symbian stores the files. However, the normal DCT4 also have a filesystem and I know how it works (enough to read write modify and delete files). If symbian works with files larger than 64k then it obviously has to use a different filesystem. The one I know can be recognized by lots of ocurrances of "f4 xx xx xx 55 ff ff ff".


Having answered your questions, is there anyone who can help me with mine?

[Crux]

u should take a look at www.blacksphere.tk
take a look here http://zope.achterklap.nl:8080/nokia/sub_100hardware
and here http://zope.achterklap.nl:8080/nokia/sub_200nokiaos

there's everything u talk about there, as far as i know

even inicialization stuff.

send me pm with ur mail, icq or msn please


u will be surprised with all information in www.blacksphere.tk

all creditz for that goes to wumpus and g3gg0 (i hope i didnt forget anyone) :d

[NickRivers]

Jmarc, pls check your pm.

[Mulder3]

Well, i can´t help you with your questions, the only thing i know abot DSP is that you can´t update DSP firmware, but you can add something like a "plug-in" to DSP via codebloks that hook in DSP firmware.
can you send me some info about the dct4 filesystem? Or explaint wat methot you use to encrypt your boot loader? I really want to analyse/reverse-engineer a symbian firmware

Send me a mail: [email protected]

[wumpus]

Great, this sounds like some kind of blacksphere project for DCT4. Disassembling the DCT3 phones was really thrilling for me.

DCT4 would be cool to port MADos to, as those phones have polyphonic sound and color screen. Woohoo..

Too bad I don't have a DCT4 phone and don't have much time for this anymore either :(

But I'm really interested in the progress of this.

BTW: The DSP stuff sounds much like the DSP in DCT3. This one also has codeblocks as 'patches' and 'hooks' for the main DSP firmware.

Does it use MDI as CPU<->DSP protocol?

Well good luck.

[Mulder3]

I don´t know if it uses MDI or not? But something says me that it uses... Mabe jmarc can answer that question... I cannot decrypt the dct4 files, so i really don´t know... I think that DCT4s are like DCT3s in terms of programming, the ony diference is ony the security on the phone... (I am only especulating...)

[jmarc]

I don´t know if it uses MDI or not? But something says me that it uses... Mabe jmarc can answer that question... I cannot decrypt the dct4 files, so i really don´t know... I think that DCT4s are like DCT3s in terms of programming, the ony diference is ony the security on the phone... (I am only especulating...)

Yes there is an MDI which is one of the bigger code modules (~1800 lines). I didn't analyse it fully, but when browsing through it I identified several functions. There are probably more..

0xXXXXXXXX ; mcu2dsp erste funktion von hw_mdi.c
0xXXXXXXXX ; uword = mcu2dsp_GetMboxFree(*apidef); kleiner max_m2d_mbx_size;
0xXXXXXXXX ; mcu2dspAllocateMbox(*struct{*apidef,*msg}) msg[8]=typ msg[9]=typ msg[a]=size msg[c]=?
0xXXXXXXXX ; mcu2dsp wieder mbx alloc failed
0xXXXXXXXX ; mcu2dsp alloc und int

0xXXXXXXXX ; dsp2mcu_GetMbxFree
0xXXXXXXXX ; dsp2mcuInc(*apidef, uword increment_count);
0xXXXXXXXX ; dsp2mcu_Read(apidef, *dst, len); len in words

0xXXXXXXXX ; mcu2dspInc0x0c(*apidef, uword increment_count);

0xXXXXXXXX ; mcu2dsp_WriteMsg(apidef, *msg, len); len in words

0xXXXXXXXX ; hw_arm_cpsr_get();
0xXXXXXXXX ; hw_arm_cpsr_put(ulong);
0xXXXXXXXX ; hw_arm_stack_set(ulong);
0xXXXXXXXX ; ulong = hw_arm_stack_get();

0xXXXXXXXX ; *msg GetMsg(); kann auf literale zurueckgeben (wie frueher)

0xXXXXXXXX ; set ctrl_wd_index(apidef, ctrl_wd_index);
0xXXXXXXXX ; set au_ctrl_index(apidef, ?, ?) mfams
0xXXXXXXXX ; mcu2dsp copy r2 worte von *r1++ to *r0++

0xXXXXXXXX ; swr(apidef,enum); liest aus apidef->0x28 verschiedene felder

0xXXXXXXXX ; hw_mdi_pdram_bank_switch(device 3-4, bank 2-8);
0xXXXXXXXX ; einzige funktion mit pdram_bank_switch(3,8 und dann 4,8);

[Crux]

what program u used to get that info

[Mulder3]

That´s a what i call a Reverse-engineer... How do you know that the file is named "hw_mdi.c" ? Or you have some leaked source from Nokia R&D dept.? LOL :)

[jmarc]

That´s a what i call a Reverse-engineer... How do you know that the file is named "hw_mdi.c" ? Or you have some leaked source from Nokia R&D dept.? LOL :)

Nokia was kind enough to leave debug messages on, like

Assertion failed, (mcu_in_offset < apidef->max_m2d_mbx_size), file hw_mdi.c, line 764

But boys, this becomes pathetic. Please write something interesting.

The software I use is ADW, Crisp, and a set of selfmade tools. I often read that people use IDA but I personally hate it (although I have a legitimate license).

[Mulder3]

I can´t write anything to help you... sorry... Maybe you can explaint how to encypt/decrypt flashes to us, so we can analyse the firmware, i´ts a bit dificult to say you something because i can´t decrypt it, or at least, maybe you can send us some firmware decrypted.

[dav2000]

Hi.

I'm looking for serious developers who do their homework and know more than just how to click buttons. It appears to me that this forum is a good place to find those..

My experience is broad and covers almost all big brands. However I was away for about 2 years, and thus missed the most recent changes. Now I'm about to dig into all this again, and would love to communicate with others.

In the past, my work was somewhat isolated. This was bad, because I had to do everything myself. On the other hand it was good, because I was able to do stuff that others couldn't do. I'm not exactly sure what is public knowledge right now and what isn't. But eg I am able to decrypt Nk Flash and FIA, and to boot UPP and cable-unlock 0120 without any Phoenix files, which isn't public knowledge IMHO.

Are you my kind of dude?

Marc

Marc, please check your PM...

regards,

[Mircea Vasiliu]

From the info you have it's not you that is outdated, it's us. Since we're not able to decrypt the flashes we can't study them. :sad: No study = no information.

If you managed to find some people to help you that's good. If not then either you'll have to wait until we catch up with you or you have to "invest" in the future and give us some more details.

BR,
Mircea