Jesteś w: Forum > Wiadomości na temat budowy flashy DCT4

Wiadomości na temat budowy flashy DCT4 » ...:Sprzęt:... » Nokia » DCT-4 » [DCT4] Modyfikacje HW i SW » Wiadomości na temat budowy flashy DCT4
Przesunięty przez: Piotrek
2006-04-02, 13:35
Poprzedni temat «» Następny temat
Autor Wiadomość

Telefon: K750i
Operator: Heyah
Pomógł: 18 razy
Dołączył: 11 Maj 2004
Posty: 1889
Skąd: Poznań
Wysłany: 2006-04-02, 13:01   Wiadomości na temat budowy flashy DCT4

Jestem pewien, że g3gg0 tak jak przy projekcie blacksphere używał reverse engineering (inżynieri wstecznej) tak i teraz wykorzystuje te same techniki.

Kilka rzeczy udostępnionych przez g3gg0:
[DCT4] Flash Header Tag ID's
C2 secondary_id
C3 algorithm_id
C8 erase_area
C9 vpp
CA vcc
CB hw_config_byte
CC hw_config_offset
CD secondary_speed
CE algorithm_speed
CF program_speed
D0 secret_info
D1 msg_read_speed
D3 claudia_info
D4 mcu_id_info
D5 vcc_off_time
D9 programming_options
DA fps8_options
DE fps8_timeouts
DF mm_bus_config
E0 mm_open_config
E1 mm_part_config
E3 mm_prog_config

[DCT4] Flash infos - header at around 0x01000000
/* unk - used by malloc/free routines */
0x01000020 4 bytes unk

/* defines flash mode (dejan) */
0x01000024 1 byte

/* MCU checksum - will NOT cause CS in most phones ;) */
0x01000026 2 bytes MCUCHK, same algorithm as DCT3

/* PeaK - netmon displays this in a special page .. why? */
0x01000028 2 bytes "PeaK"

/* FAID */
0x0100002C 12 bytes FAID

/* flash permanent data - used by PMM routines */
0x0100003A 28 bytes - flash permanent data ( IMEI, UEM WD reset pass, tunning params, etc, encr)

FCHK is checked (or at least prepared) by ROMCALL 0x840015

no simple way to bypass this, except finding the correct
calculation algortihm. i guess its done by the SPLock algo
that is in ROM. dont really know what this one does if the
calculation fails. maybe it overwrites some memory in DSP
memory space.
interesting is, that the init routines first set a special
routine as ABORT(?) handler that enters system mode and
calls ROMCALL 0x8001E7 before the 0x840015 is called.
0x0100006C i think there are 8 bytes FCHK (FlashChecksum)
0x01000074 block count of FCHK (8 byte blocksize) min size 2
0x01000078 start address of FCHK and MCUCHK

/* no idea ;) */
0x0100007C empty
0x01000080 empty

/* not sure what this ROMCALL is for */
0x01000084 if set between 0x01000000 and 0x03FFFFFF, given as R0 to ROMCALL 0x840013
0x01000088 given as R1 to ROMCALL 0x00840013

for setting up memory map via ROMCALL 0x840017

addresses in these ranges are mapped out for the hardware
decryptor and directly accessable.
0x0100008C if set start address of uncrypted area 1
0x01000090 end address of uncrypted area 1
0x01000094 start address of uncrypted area 2
0x01000098 end address of uncrypted area 2

[DCT4] FCK bypass?
well, now everyone wants to modify flashfiles.
but be warned, you can only modify the area above 1M (starting from 0x01100000)

else your phone will end up with no network and a poweroff after 1 min :)

the only chance for now is to bypass the FCHK, but first i have to know what algo is used :(
if we knew the algo, or if someone would tell me the checksum of 16 0xFF bytes,
then i could fool the algorithm ;)

or lets say we brute force that checksum...
we give each participant 256 checksums to test...
good idea... anyone can bring up 72057594037927935 guys who help? :)

[DCT4] FCHK bypass brainstorming
yes, i know... the 3rd message today ;)

okay just some thoughts about the FCHK...
if the routine 0x0084015 really does the calc
(this routine calls one at 0x00800XXX which is read protected)
then it either:

- saves data on the stack (very low security)
- saves the data at some internal RAM (higher security)
- keeps the data while calculation in registers (also high security)

in my opinion it doesnt keep data in registers.
i also dont think it saves data on stack, that would be too "insecure".

dont ask me why, but i think during calculation the data is kept
in the on-die RAM at 0x0200 and gets overwritten
after the calculation is done.

so we have to:

- use original flashfile
- modify the timer interrupt to break every some cpu clocks (possible?)
- inject code into the timer interrupt to check registers/PC and the RAM area and save data about the calced stuff
- if the correct checksum was found in registers/ram, save that address and capture
that data for a modded flash with pointer to FF bytes

ouch... much work ^^

[DCT4] some interrupts
fiq 0x00 - MDI (DSP)
fiq 0x06 - FBUS
fiq 0x07 - FBUS
fiq 0x08 - FBUS
fiq 0x09 - DMA

int 0x00 - MDI (DSP)
int 0x01 - MDI (DSP)
int 0x02 - DMA
int 0x03 - UEM
int 0x09 - STI (Serial Terminal Interface) ?
int 0x0A - UPP (?)
int 0x0B - UPP (FIQ?)
int 0x0C - UPP (FIQ?)
int 0x19 - UPP (timer?)
int 0x0E - UEM
int 0x13 - UEM
int 0x18 - UEM
int 0x1E - ABORT

[DCT4] some GENIO's of 6610
0x00 - VEN of LP3985 Voltage Regulator
0x03 - FM Radio Clock
0x04 - LCD Reset
0x05 - RF TXPower
0x06 - RF Reset
0x07 - RF TXA
0x08 - RF TXL 1 & FM Radio Enable
0x09 - RF Mode
0x0A - RF EXTANT & IR Module SD Pin
0x0B - RF BANDSEL & FM Radio SClk
0x0C - RF AData & FM Radio SData
0x0D - RF RXGain
0x0E - Audio Router Enable
0x0F - Audio Router Clock
0x10 - Audio Router Data
0x17 - WP of flash
Pł - Płodzimy kuszące pomysły, - poczytaj o najlepszych światowych kampaniach reklamowych.
Wyświetl posty z ostatnich:   
Odpowiedz do tematu
Nie możesz pisać nowych tematów
Nie możesz odpowiadać w tematach
Nie możesz zmieniać swoich postów
Nie możesz usuwać swoich postów
Nie możesz głosować w ankietach
Nie możesz załączać plików na tym forum
Możesz ściągać załączniki na tym forum
Dodaj temat do Ulubionych
Wersja do druku

Skocz do:  

Podobne tematy
Temat Autor Forum Odpowiedzi Wysłany
Brak nowych postów Nie na temat kokodek Kosz 0 2010-01-09, 12:11
Brak nowych postów [Nokia E63] Opinie na temat modelu beka1990 Nokia 0 2010-03-23, 14:19
Brak nowych postów Kilka pytań na temat HTC Tytn II Dames Inni Producenci 0 2011-02-09, 17:28
Brak nowych postów life timer w dct4 kocik1993 DCT-4 8 2011-05-29, 18:13
Brak nowych postów n82 nie tak z klawiatura ciezki temat _Brutus BB5 10 2011-11-09, 18:25