View Full Version : modding sofware(dct4,wd2,bb5) for free...
deadspot
10-05-2006, 10:53 AM
check this link....
http://www.gsmgadget.cjb.net/showthread.php?t=514
http://rapidshare.de/files/20059900/MODDS_DCT4_WD2_BB5_SETUP.rar.html
enjoy!
sixtysixthirty
10-05-2006, 11:13 AM
what kind of modifications can be done!!
Regards,
Fonefusion
deadspot
10-05-2006, 12:25 PM
u can edit *#0000#.....
u can edit *#0000#.....
For what? All this seems stupid....
magicmushrooms1
10-05-2006, 04:56 PM
so this programme can cal the checksums?????
deadspot
11-05-2006, 03:49 AM
@al
in my opinion u can personalized ur phone model name , date and model code...whats wrong with this program maybe it will the start of new modding of dct4 phones
@al
in my opinion u can personalized ur phone model name , date and model code...whats wrong with this program maybe it will the start of new modding of dct4 phones
The only one thing stops DCT4 modding now, it's 8bytes of Flash Signature. If you'll know how to calculate them - that will be really cool :)
dead man inc
11-05-2006, 10:08 AM
can some one upload to mega upload as i cannot download from rapidshyt
Best Regards!!!!!!!
=====DEAD MAN INC=====
dead man inc
13-05-2006, 10:08 AM
Hello Anyone There
NokDoc
13-05-2006, 12:28 PM
Hi Mr. Dmi,
I think U not want that.
Atm noone is able to decode a bb5 file.
Besides the flash checksum what Mr. Al is talking about.
Factors that make me decide this tool is just a big fake.
NokDoc
dead man inc
13-05-2006, 02:14 PM
Thanks for the info NokDoc
Best Regards!!!!!!
=====DEAD MAN INC=====
magicmushrooms1
23-05-2006, 12:32 PM
The only one thing stops DCT4 modding now, it's 8bytes of Flash Signature. If you'll know how to calculate them - that will be really cool :)
this 8 bites of signature - does any body have it to post up here or even send to me???
magicmushrooms1
23-05-2006, 10:19 PM
anyone help me????????????
NokDoc
24-05-2006, 03:58 PM
anyone help me????????????
Hi,
Somewhere I read that it was about 2 times a 4 byte value stored at location 0100.006C, although I'm not quite into this (dct4) myself.
Doesn't Mr. G3gg0's website mention something about this checksum?
NokDoc
magicmushrooms1
24-05-2006, 05:21 PM
Hi,
Somewhere I read that it was about 2 times a 4 byte value stored at location 0100.006C, although I'm not quite into this (dct4) myself.
Doesn't Mr. G3gg0's website mention something about this checksum?
NokDoc
???
i may e-mail him
NokDoc
24-05-2006, 06:00 PM
Hi,
All that's known bout Flash Signature: http://g3gg0.de/
>> i may e-mail him
Maybe no need, he will read this thread too.
Also at his site is the possibility to add comments to the subjects he explains there.
Just for clarification, this calculation isn't solved yet, it is only being explained there.
NokDoc
magicmushrooms1
24-05-2006, 06:19 PM
Hi,
All that's known bout Flash Signature: http://g3gg0.de/
>> i may e-mail him
Maybe no need, he will read this thread too.
Also at his site is the possibility to add comments to the subjects he explains there.
Just for clarification, this calculation isn't solved yet, it is only being explained there.
NokDoc
yeah - jus ti know a man who writes software for tanks and he said to get as much info as possible and he will have a look at it and see if he can help.
g3gg0
25-05-2006, 01:09 AM
hi
that checksum described on my page and mentioned by al is the FSIG (we call it like that ;) )
it seems to be a checksum over the whole flash on newer phones to prevent modification.
on older phones it just covered the first megabyte and left the chance to modify some parts of the flash.
if someone changed just one bit in the flashfile, the invalid FSIG will cause the
same problem as if the FAID was wrong on DCT3 devices.
greetz,
g3gg0
magicmushrooms1
25-05-2006, 08:10 AM
hi
that checksum described on my page and mentioned by al is the FSIG (we call it like that ;) )
it seems to be a checksum over the whole flash on newer phones to prevent modification.
on older phones it just covered the first megabyte and left the chance to modify some parts of the flash.
if someone changed just one bit in the flashfile, the invalid FSIG will cause the
same problem as if the FAID was wrong on DCT3 devices.
greetz,
g3gg0
ok well what the best thing to do????
can you post the checksum here, so i can give it to my friend to look at??????
krisha
25-05-2006, 11:25 PM
ok well what the best thing to do????
can you post the checksum here, so i can give it to my friend to look at??????
no problem, here is my fsig: A02C84546C895CF6 :)
and now ?
btw. it's a nice program, but you can do it with g3gg0/nok5rev crypter and a hex editor in 5 minutes also... even if you're not familiar with nokia modding ;)
magicmushrooms1
26-05-2006, 08:20 AM
no problem, here is my fsig: A02C84546C895CF6 :)
and now ?
btw. it's a nice program, but you can do it with g3gg0/nok5rev crypter and a hex editor in 5 minutes also... even if you're not familiar with nokia modding ;)
thanks for that - i know nothing about modding????
what is fsig: A02C84546C895CF6 ????????????
if i give this to my friend will he know what its about?????
EdgeCrusher
26-05-2006, 09:14 AM
The fsig, as Mr. g3gg0 said, is the checksum. Mr. krisha posted the checksum of his flash file, in hex :). Checksums are used in programming -of course, I'm going to explain it in very basic terms since I'm a little illiterate in this and my english skills are not as good as I'd like- to check the integrity of data contained. The checksum is corroborated, and if it fails, the phone understands that the data is corrupted.
An analogy would be the MD5 checksum corroboration. When you download an ISO of an OS, say, Linux, at the download location it says "MD5 checksum: [signature]". Once you have downloaded, you must do an MD5 checksum on the ISO, and it should give you the same [signature] as the one you saw at the download site (hence the corroboration). In case it fails, you have a corrupted file. Nero, for example, does more or less the same when it verifies the recording of a cd. It generates an MD5 checksum of the data in your HD, and then another of the data in the cd. It compares them, and if they differ, the record is failed -or corrupted-. The whole idea of the checksum is to preserve data integrity.
Mr. g3gg0 said it very clearly. Since the checksum now covers all the data contained, changing a single bit will make that the checksum fail, thus the phone will reject the data.
The problem is what to do with that checksum that Mr. krisha gave you ;)
Cheers
Edge
magicmushrooms1
26-05-2006, 01:08 PM
so fsig: A02C84546C895CF6 is the bit no one can crack??
krisha
26-05-2006, 05:37 PM
The problem is what to do with that checksum that Mr. krisha gave you ;)
exactly :)
my fsig is a checksum over the first 1MB of the flash (3100 v5.91).
if you want to do some research check g3gg0's website and get some flashfiles.
with only one fsig and no data, you definately can't do much :)
and every flashfile has a own fsig.
magicmushrooms1
26-05-2006, 05:46 PM
ok well leave it with me and ill see what i can do
g3gg0
26-05-2006, 06:26 PM
dont see that as an offense, but i'm allergical against posts with more than one question mark in a row ;)
magicmushrooms1
26-05-2006, 11:39 PM
dont see that as an offense, but i'm allergical against posts with more than one question mark in a row ;)
what???????????
LOL
EdgeCrusher
29-05-2006, 08:27 AM
so fsig: A02C84546C895CF6 is the bit no one can crack??
Not exactly. The fsig is clear, it does not need to be cracked I believe. The idea of modding firmware is to be able to change something in the file. The main problem is that the fsig, or data checksum -that now covers the entire amount of data- doesn't allow this.
The issue -for the little I could understand from Mr. krisha and Mr. g3gg0, is findig how the checksum is done, in order to be able to change something in the firmware file without making it generate an invalid checksum. Or, find any way to change something without generating an invalid checksum, say making the checksum generation procedure to "jump" the modificated part or whatever you can think about -of course, I'm talking from ignorance, I have not a single idea how this works.
As Mr. krisha said, with one fsig (I guess it'd mean "firmware signature", or something like that... ) and no data, there's almost nothing that can be done. To find a pattern, you'd need -or anyone that wants to do that- a lot of firmware files with their respective fsigs, and a good amount of time to read a lot of zeros and ones lines... and the skills to understand what they say.
I hope this explained in common mortal words more or less the problem!
Cheers
Edge
g3gg0
29-05-2006, 02:29 PM
as i stated on my site, the checksum calculation aswell the "bad guy" routine are BOTH
in on-die ASIC and are not readable, debuggable or modifyable.
we know that the checksum calculation itself is done in hardware.
the ROM routine just writes the whole flash into IO addresses and after
that was done, some magic gate will open when the fsig and the written flash match.
that magic gate will enable something in the transmitter IC or so.
the writing routine in ROM is *not* readable, so i cant reproduce its procedere.
also the FSIG routine in ROM is only allowed to get run once after powerup what
makes "debugging" harder
n4bee
24-08-2006, 06:43 AM
Wouldn't it be useful to have electrical access to all/certain MAD I/Os? That
way you could dump the whole communication between MAD and transmitter
during/after a flash process and compare a successful with an unsuccessful one.
If you know someone who is good at soldering it would perhaps be possible to
make a little PCB that is soldered between the system board and the MAD
package. This PCB would be a little bit bigger than the BGA area and make
certain signals accessible at the sides.
What do you think?
Powered by vBulletin® Version 4.2.0 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.