Simple Unlocking:
www.uniquephones.com
|
März 31, 2007
yeah, u've seen it.
i added google AdSense banner to the left column of my page.
the reason?
well, like everyone i need some money to live...
i dont do that just for fun ;)
thanks :)
[more] Comments (0)
|
März 30, 2007
okay, PPModify is now working as intended :)
its able to dump all languages of recent PPM files.
but i still have to check if its also working fine for
older PPM types, like the 8310, 6310 or even
6210/7110 PPM's.
for the DCT4 types i see a chance that it will
work out of the box. but the DCT3 types might
have some things different,
(i hope PPModify plugin will not crash ;) )
ah yes, i even added recompression of the text
strings in the language chunks. and i was
astonished, how good my routine was :D
some strings were compressed better than nokia did.
wow!
well, but in average it took about 60 bytes (!)
more space after i recompressed the whole PPM
TEXT section.
and there is still some space for optimizations... [more] Comments (1)
|
März 19, 2007
the last weeks i worked on TriX_PPModify and
TriX_XML which turn TriX into a tool that
is able to dump DCT4 PPM files into a XML
structured tree and vice versa.
there are still some bugs regarding text
compression. i realized that when changing
strings of compressed traditional chinese
PPM chunks.
it also still misses the recompression of strings
using the original token tables. i never studied
compression algorithms... hm :)
but well, i think these are problems which i can
solve by myself. but if someone is willing to
help with that stuff, i wont reject that ;D
now sitting in "Computer Networks" lesson.
tiring -.-
[more] Comments (0)
|
Januar 6, 2007
today i were able to initialize the flashcrypt routine by bruteforcing the address ;)
now i'm able to read out the decrypted flash contents like once dejan did on 8310 - just with prodigy and TriX.
but its sooooo f*cking slow :-/
that 16M flash IC will take about 10 hours - ouch!
[more] Comments (2)
|
Januar 6, 2007
yesterday i came back from skiing.
a week of snow, mountains and fresh air...
sometimes u need that badly ;)
[more] Comments (1)
|
Dezember 31, 2006
okay finally i was able to upload at least the original nokia loaders to the phone.
sometimes (1 on 10 times) it really works :)
if it not works, the it is either the defective 6230
that just refuses to start up or the prodigy.sys v1.0.0.208
locking up my machine. v1.0.0.184 would work fine,
but its not able to upload the newer flash loaders.
took me quite some time to figure out these
three things ;)
so i need a 6230 or any other TIKU device.
someone has one over? :)
[more] Comments (0)
|
Dezember 28, 2006
yeah... u know i'm dumb.
i'll forget everything right after i did it - and so i
have to write down everything i find out.
well, lets remember some TIKU stuff ;)
INTERRUPT VECTOR at 0x00000000
00000000
18F09FE5
18F09FE5
18F09FE5
18F09FE5
00000000
18F09FE5
18F09FE5
funny, the flashfile says
18F09FE5
18F09FE5
18F09FE5
18F09FE5
18F09FE5
00000000
18F09FE5
18F09FE5
that means 4 bytes at 0x00000000 (RESET VECTOR) are read protected.
so is the ROM around 0x0C000000 since it also reads back as 00's
now the interesting stuff is to find out the flashcrypt init routine.
how did dejan do that? :-/
Edit:
ah the 2nd loader (te_2nd.fia) checks 0x4000 bytes
of memory at 0x0A000000
thats not much... is it internal UPP memory? [more] Comments (0)
|
Dezember 13, 2006
today is "glühweinparty" in our FH (university of applied sciences)
that means, after one has voted the
the student's representants, he gets as much
gluehwein/glogg for free as he can drink.
yeah...
why dont they do this for parliamentary elections also? [more] Comments (0)
|
Dezember 12, 2006
today i added some primitive project handling
functions for the upcoming project feature in TriX.
hmh well... noone except krisha, me and albert
is using that tool ;)
who cares. i'll keep developing it :) [more] Comments (3)
|
Dezember 9, 2006
i just resumed my computer from standby mode
successfully (9 of 10 times it locks up -.-) and wanted
to read my new emails then it suddenly powered off.
okay, switch off the power supply and repower.
FLASH! a 1 second flickering light was brightening
the computer case oO
after repowering the computer again, everything worked...
i hate such days -.-
[more] Comments (0)
|
November 26, 2006
TriX v0.6b (still beta state) is released:
g3gg0.de/~geggo/dct4/trix/TriX_v0.6_complete.zip
new:
- included a simple ARM debugger script (menu etc)
- reworked interface a little bit (no entry dialogs anymore)
- many fixes in internal C compiler
- crash fixes in ARMulate
- added "Help->Command Reference" which shows you all available function calls ;)
enjoy :)
Edit:
the use of "short and pregnant" is not correct, sorry ;)
but... just search in google for that (including the "s)
also see www.wiwo.de/pswiwo/fn/ww2/sfn/buildww/id/127/id/173722/SH/0/depot/0/index.html ;)
[more] Comments (0)
|
November 4, 2006
due to some build failure, the plugin DisARM wont
run on every machine. It depends on the MSVC
runtime you've installed.
just redownload it from the location posted last
time and you have the latest, working one ;)
[more] Comments (4)
|
November 3, 2006
TriX is available in a beta_0.5 release on CVS:
cvsroot: :pserver:public@g3gg0.de:2401:/root
password: behave!
well, since many people are not familar with CVS,
so here is a compiled WIN32 version with some examples:
g3gg0.de/~geggo/dct4/trix/TriX_v0.5_complete.zip
[more] Comments (0)
|
November 2, 2006
okay..
the last days (and weeks) i added some new stuff to TriX.
the first one was an ARMada plugin.
with that plugin you can inject the ARMada-code snippets
into the currently loaded firmware or program.
a nice-to-have feature ;)
the next plugin i added was ARMulate, a fully ARM-compatible
emulator to step and execute the loaded firmware
or even symbian executables.
of course that emulator provides not even one Symbian-related
OS functions! it's "just" able to execute ARM statements.
if you want to emulate Symbian executables you have
to set breakpoints onto the import jumps and then emulate
the executed call.
if you're skilled, you can maybe emulate the key calc routine
in a symbian app and calculate your own key.
and that works! ;)
for easier debugging i added the DisARM plugin which will
disassemble a statement. its just like "24 00" -> "MOV R4, 0x00".
last but not least, i integrated a Symbian .app file reader/writer (EPOC E32).
now you can load an .app file into "memory space", emulate some part
of it with ARMulate, patch it and write it back.
it works fine for S60 2nd Gen executables (OS 6.1-8.1) but is
not compatible (yet) to 3rd Gen (OS 9.1) .EXE's just because of the
Deflate/Huffman compression used in the code.
if i knew how the compressed data is formatted, i would be able to
integrate this new format also.
so if you have experience with compression algorithms and think
you can help me decompressing (and re-compressing) Symbian EXE's,
please contact me :)
my email address is _geggo_@_g3gg0_._de_ (wihtout _'s) [more] Comments (0)
|
September 1, 2006
i updated TriX to allow exporting of segments.
nothis important... just a nice-to-have feature [more] Comments (2)
| |
|
Juni 3, 2006
Saying that Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders [more] Comments (2)
|
April 28, 2006
well...
do you remember the times when everyone in the forums begged for that crappy SPlock algos? unlockers were payware, noone ever wanted to give out any source...
mysterious guys came up with the algo written in pascal, giving everyone what they wanted.
..."the secret n*kia splock algorithm"
yeah.. that started (afair) with DCT-3 and was not better with DCT-4!
and now?
there was so much trouble, war, flames and bad blood just because of these released secret algorithms. PHP pagges appeared, killing some people's unlock-key market. applications were released for free, even some for mobile phones (Symbian, MADos, JAVA)
i remember a post on forums that said:
"the algorithm was in front of you for years..."
i think he meant some binaries that got read out of 10k$ devices paying 20k$ just for the flash-reading using 200k$ hardware...
...did he really?
if i tell you now, the algo always was free?
and you can download it since 1994?
and - beside of a little change in key generation - is even standardized?
heh.. so much trouble and begging just for a free algorithm, badly coded and rewritten 20 times. if the guys who initially reversed the algorithm worked a little bit cleaner, they had seen that n*kia uses (as i ever expected) a standard algorithm...
i wondered (yeah, the first time.. really..) what algo they are using....
...it took me 1 hour to find the algorithm that was used for SPlock.
a good friend then confirmed this one using the TDS-6.bin that was floating around.
SPlock algorithm == SAFER-K64
(http://www.users.zetnet.co.uk/hopwood/crypto/scan/cs.html#SAFER-K)
this good friend then also started to check what algorithm may be used for MSID/FAID encryption
your guess....?
...right.
it took him also just some minutes to find a 96-bit block cipher.
of course plus some time to check the small changes in key generation.
MSID/FAID crypt == 3-Way
(http://www.users.zetnet.co.uk/hopwood/crypto/scan/cs.html#3-Way)
i think its funny :)
everyone uses the mystical "SPlock" algorithm but noone ever said or even knew its real name.
btw: the guy who confirmed the SAFER/3Way algorithms is now going to make a "correct" src, which covers DCT3/4's splock key generation - as it was meant by nokia.
okay its already late :)
n8
EDIT:
oh yes.... some video that i recorded.
it shows a modded 6610-firmware which displays the ARM CPU registers while running the protected ROM code. this way krisha and i am trying to reverse whats going on in the ROM while setting up FSIG.
g3gg0.de/~geggo/dct4/nhl4_stepper_vid.zip [more] Comments (3)
|
April 26, 2006
to prevent confusion, a friend told me to rename
FCHK to FlashSignature which is a better name.
since DCT3's FCHK and DCT4's checksum differ so much, it's really better to call it FlashSignature.
thanks for the hint :)
FlashSignature = FSIG [more] Comments (1)
|
April 21, 2006
what did i do lately?
hehe good question :)
together with krisha i started developing TriX, a flexible patching system.
this patching system is - differently to all other patchers - NOT just for a
fixed phone type. it already is able to patch DCT4, is prepared for DCT3 and
is also thought to patch any file type like EXE/DLL/ELF with ease. (supporting many memory segments)
it has built in parser for ELF file types. that means you can (and we already do)
extract the code of ELF object (.o) produced by GCC suite and inject that
into the flashfiles.
well then i suddenly *cough* was interested in the FlashSignature of the DCT4 phone series.
i wanted to crack it :)
yes, what is the FlashSignature?
okay... we are able to modify DCT4 flashes without any problem....
... except if the modification changes something in the area below 1MB, because then you will end up with no network.
i found a checksum and a block count that really fits my idea of FlashSignature.
its described some blog entries below.
changing the FlashSignature checksum or the block count or start address will cause
the same "no network" effect you realize when changing data in area <1M.
the tricky thing is, nokia just passes the address to the FlashSignature (0x0900006C) to a ROM call. (it is *not* in flash)
now the romcall does *something* that is important for the transceiver to work.
now you say, "why dont u disassemble the rom?"
yes, thanx for the hint :P i really would love to do that, but nokia isnt that stupid.
the hardware just allows the ROM area to get executed (ARM instruction prefetch)
but if you try to read from the ROM area, the hardware gets a data fetch,
that causes some crap to be read. so disassemble what? crap? haha.
well now my thought in the last weeks was to intercept and control the timer interrupt.
this way we can check the processor registers and state and estimate what opcode got executed.
together with krisha - who did a really good work locating the timer int and registers - we did precision work
and were able to reconstruct a little what happens with the FCHK values.
let me explain:
[AAAAAAAABBBBBBBB][CCCCCCCC][SSSSSSSS]
thats the data at 0x0100006C
AAAAAAAABBBBBBBB = FlashSignature
CCCCCCCC = block count in 8 byte blocks
SSSSSSSS = start address of checksum area
i think its done this way:
the ROM call writes the FlashSignature to address 0x0600C8A0/A4in format [BBBBBBBB] [AAAAAAAA]
then it writes the flash data, starting from [SSSSSSSS] to address 0x0600C860/64.
its not just word swapped, but also half swapped.
lets say in flash at 0x01000100 is the data [11223344][AABBCCDD].
now its writing [CCDDAABB][33441122] to the mentioned addresses.
finally the block number is written to 0x0600C82C
well what now?
hmh either we know how the ASIC (hardware) calculates the FlashSignature or we are lost :)
okay not really lost... we already have an idea how to fool the hardware
but this is still an idea which was not successful yet.
*if* you know how the ASIC calculates the FlashSignature or have a good
idea, dont hesitate to contact me or krisha ;) [more] Comments (3)
|
|
| just in case you wanna support me somehow :) |
|
