modding sofware(dct4,wd2,bb5) for free...

[deadspot]

check this link....

http://www.gsmgadget.cjb.net/showthread.php?t=514


http://rapidshare.de/files/20059900/...SETUP.rar.html

enjoy!

[sixtysixthirty]

what kind of modifications can be done!!

Regards,

Fonefusion

[deadspot]

u can edit *#0000#.....

[Al]

Originally Posted by deadspot

u can edit *#0000#.....

For what? All this seems stupid....

[magicmushrooms1]

so this programme can cal the checksums?????

[deadspot]

@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]

Originally Posted by deadspot

@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]

can some one upload to mega upload as i cannot download from rapidshyt

Best Regards!!!!!!!

=====DEAD MAN INC=====

[dead man inc]

Hello Anyone There

[NokDoc]

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]

Thanks for the info NokDoc

Best Regards!!!!!!

=====DEAD MAN INC=====

[magicmushrooms1]

Originally Posted by Al

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]

anyone help me????????????

[NokDoc]

Originally Posted by magicmushrooms1

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]

Originally Posted by NokDoc

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]

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]

Originally Posted by NokDoc

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]

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]

Originally Posted by g3gg0

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]

Originally Posted by magicmushrooms1

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]

Originally Posted by krisha

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]

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]

so fsig: A02C84546C895CF6 is the bit no one can crack??

[krisha]

Originally Posted by EdgeCrusher

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]

ok well leave it with me and ill see what i can do

[g3gg0]

dont see that as an offense, but i'm allergical against posts with more than one question mark in a row

[magicmushrooms1]

Originally Posted by g3gg0

dont see that as an offense, but i'm allergical against posts with more than one question mark in a row

what???????????

LOL

[EdgeCrusher]

Originally Posted by magicmushrooms1

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]

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]

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?