BB5 SP unlocking, theory...

[Vadim Kova]

Do you mean ADx sequence is the same when reading burst for the first and second instances? And subbr execution does not change it, even for reading of other burst (where subbr is located)? Well, then we have to apply patching while the first instance if there are no 'callx' in the burst, while the second one if we see one 'callx', etc... right?

[X-Shadow]

@Vadim Kova

The instruction we want to patch always has a subroutine branch instruction
before it in all know firmwares of No-Kia BB5. The most important thing to
take note is how each firmware is divided in to 32-byte bursts and our triggers
really depend on this.

For example, the first instace on 5200 v5.0 only executes upto the first
branch instruction which is before the instruction we want to patch. That
instruction we want to patch does not get executed in the first instance at
all.

I just know in theory that after a subroutine is finished the 32-byte block
part of the Function where the branching is called is read again into RAM
before it continues to process the next instruction in that Function. Also,
there should be some instaces where the next 32-byte block is read in
advance before even finishing the previous block.

In short, you must know in advance through some disassembly and analysis
which instance of that 32-byte block should be patched.

And yes, it does not change because it is just reloaded back into the RAM.

[Vadim Kova]

Originally Posted by X-Shadow

In short, you must know in advance through some disassembly and analysis
which instance of that 32-byte block should be patched.

Anyway, dissassemly of branches with unknown conditions and unknown prehistory will not guarantee correct result. It is just a matter of some experimenting to check by patching all instances. How many branches we have inside the burst before patched instruction? 2? 3? It looks better than subbr disassembly.

[X-Shadow]

Anyway, dissassemly of branches with unknown conditions and unknown prehistory will not guarantee correct result. It is just a matter of some experimenting to check by patching all instances. How many branches we have inside the burst before patched instruction? 2? 3? It looks better than subbr disassembly.

That subbr always go back to that function right? ;-)
What you say is 100% true, but keep in mind we deal with branching without conditions
in that subbr before the instruction we want to patch. I see this is the same in all
firmwares that I played with. It is always BL sub_xxxxx before that CMP R0, #1. Now you
know BL is Branch with Link, which means the return address is stored in one of the
Registers. So whatever that sub_xxxxxx do (and all subbr in that sub_xxxxx), it will
always go back to that function where it was called and it would return the value for R0
which we want to compare with '#1'. So what we are looking for is the last burst before
sub_xxxxxx goes back to the function. That "LAST BURST" is affected by how the firmware
is divided into 32-byte bursts, but that is not the only condition that affects it. True enough,
a certain amount of guessing is required... but it is far more guesses if you do not know the
previous burst at all... ;-) Again, we are only speaking "Theoretically" right? Because topic
of this thread is "BB5 Unlocking Theory"... LOL

[Vadim Kova]

Sure, we need some practice Afaik, there is no way to disassemble xilinx jed file? It's a pity

[X-Shadow]

@Vadim Kova

There should be a way... but it's easier to learn verilog and make one yourself
than spend time trying to reverse that jed. I had mine working on the xilinx
simulator, but still need to put tweaks like a UART so that I can get those
wait states without guessing a single bit ;-)

Check attachment...

Trigger was found on 420ns... (I used 5200 v5.0 trigger).
That 'led' and 'b' are the pins used to show that trigger is found.
adx and clk are self-explanatory ;-)

The trigger bits are set on reg [23:0] bb;... but only for simulation purposes...
just for fun ;-)

[Bph&co]

Originally Posted by Vadim Kova

Anyway, dissassemly of branches with unknown conditions and unknown prehistory will not guarantee correct result. It is just a matter of some experimenting to check by patching all instances. How many branches we have inside the burst before patched instruction? 2? 3? It looks better than subbr disassembly.

Hi,

Here some interesting reading about cpu cache and branch prediction.

BR

[X-Shadow]

Some info on cpld jed files...

Ok, so dk said it is possible to inject that 5200 v5.0 trigger into n95unlock.jed ...
I can tell you where to look and how to correct checksum...

First open n95unlock.jed... at the bottom you will see checksum of 'B6E2'... take note
of that.

Now look at:
L004720 01101010011010100110111111101111101111111110111111 111111111111111111111111111111*
which is located at 'Note Block 0 PLA AND array *'... this is where dk put the 13 bits of hi n95 trigger...
In CPLD, "01" = 1, "10" = 0 and "11" is not used (nu)...
so put a space after each bit and you will see something like this:
01 10 10 10 01 10 10 10 01 10 11 11 11 10 11 11 10 11 11 11 11 10 111111111111111111111111111111111111*
and then convert to:
1-0-0-0-1-0-0-0-1-0-nu-nu-nu-0-nu-nu-0-nu-nu-nu-nu-0-nu-nu-nu....
so we get 13 bits from it which is '1000100010000'

Now we move on to find the next 11 bits which is found here:
L009648 01010111110110101101011111111011111110111101111111 111111111111111111111111111111*
which is found in 'Note Block 1 PLA AND array *'...
From that, convert it so that you will get the bits...
You should get: '11110011001' ...

Now you have the 24 bits he used for trigger which is '1000100010000' - '11110011001'

Easy enough??? Well, we know these are the bits, but because the CPLD fitter is the
one that decides where and how to store these bits, you still need to guess the proper
arrangement of this bits! In short, for now we only know that the trigger uses 10 bits
that are '1' and 14 bits that are '0'... we don't know the proper arrangement ;-(
So we get '1111111111-00000000000000' and we want to put 5200 v5.0 bits in there...
First you will have to change the checksum because the 5200 v5.0 have different
number of '0' and '1'. For 5200 v5.0 111111000000000010000010, we have 8 bits that
are '1' and 16 bits that are '0'. We need to change 3 '0' from n95.jed into '1' and so
we just simply add 3 to the checksum to make our changes valid. So B6E2 + 3 = B6E5.

Now all you have to do is guess where to put those bits in the proper location and
you will be able to use it for any bb5... Via bruteforce,,, it should take you 1,000.000 attempts!
If you have the time,,, go ahead ;-)

Or wait for further developements on this topic!

[nokiroki]

Hello, I see this is a thread where BB5 guru are discussing possibilities of unlocking BB5 phones... Well, I'm not a guru but could anybody provide any info about frames which Dejan's program sends over FBus? First of all, I would like to see a description of frames starting with "1e 00 10 53" bytes. As I understand, this is to read the phone memory, right?

The reason why I'm asking this is simple. I have Nokia E65 phone which does not communicate with Dejan's program over DKU-5 cable with ark3116 USB-UART converter inside. Perhaps, E65 does not support FBus on PopPort. Though I'm not sure of this... At the same time another program, NSS (Nemesis Service Suite) can read the phone data over CA-53 USB cable, including famous 308.1 section. USB analyzer shows that NSS mimics FBus communication over USB bulk transfer with some modifications: byte 0x1b is used as frame header instead of 0x1e, no ACK frames are sent, no SeqNum, no FramesToGo, and no checksum, since USB bulk transfer is considered as absolutely reliable. After writing some program to translate between serial FBus and USB frames, I could make Dejan's bb5_unlocker to communicate with the phone connected over plain CA-53 cable. I got the phone version, IMEI and SP Ver lines. But then nothing... It seems that the phone does not understand "1e 00 10 53", err... sorry "1b 00 10 53" frames, or sends wrong data.

I think that "1e 00 10 53" frames can be translated into "1b 00 10 23" frames used by NSS. However, these frames have quite different format. So, I would appreciate if someone could provide any valuable information about FBus frames used to read BB5 phones memory.

Thank you.

[dandylion]

man u seem like u know your onions,
historys/research is always good tho
http:///vbb/showthread.php?t=215949

http:///vbb/showth...ight=technical

Aswell as the unlock theory thread,every thing u want to know is here on gsm

jus search a little more

[dandylion]

best of luck anyways (couldent edit my post for a ps)

[nokiroki]

dandylion, thank you... Unfortunately, I could not find any documentation regarding FBus frames format used in Dejan's program but I could find in this forum a log from serial port sniffer when bb5_unlocker communicated with a phone supporting FBus over serial port. I could compare this dump with mine and found that my USB-Serial translator program was not completely correct. It calculated SeqNo bytes for all frames instead of using one sequence counter for ACK frames and another for data frames. I fixed that and now I could get complete info after hitting "Read Phone" button!!!

However, after hitting "Make Log" the program said "Error read pm data"... Well, it seems that now the problem is with large data frames with contents of 308.1 memory area. With USB transport one frame is 1Kbytes long and it seems Dejan's program does not expect that. I need to cut every frame for smaller fragments and send them to bb5_unlocker in separate frames. So, still there is a hope that it will work.

Is there any chance of Dejan replying to this? I think he could make his program to communicate over plain CA-53 cable over USB. This is really simple. I do that as follows:

My translator program is running in Linux using open source libusb to communicate with USB. This program is also connected to a socket/pipe created by VMware Player. The socket is a virtual COM1 port for Windows XP running inside VMware. So, when bb5_unlocker runs inside VMware, it communicates with this socket instead of real COM port, and therefore with that translator program. If Dejan is so kind to rewrite his program to communicate directly over USB than things might be much easier.

[ok2ucx]

Hi,

I guess you've studied serial spy from this thread.

It all seems conforming to FBUS protocol that is also described in: http://wiki.gnokii.org/index.php/Protocol_description

just like this, only ID is different:

	  buf[at++]=0x1e;         //   id comunication 0x1e cable=0x1e infred=0x1c
	  buf[at++]=0x00;         //   dest  0x00=mobil
	  buf[at++]=0x0c;         //   source  0x0c=pc
	  buf[at++]=type;         //   comand type  see below
	  buf[at++]=0;            //   multiple sms
	  buf[at++]=size;         //   size of data
	  for(n=0;n<size;n++) buf[at++]=data[n];
...

I've recently browsed through various forums (Hasnain et al.) and tried to understand how the log file is constructed:

bytes from 0x00 to 0x6F are really taken from famous [308] block, right after dead0400 sequence

then bytes from 0x70 to 0x7F are really copied from 0x40 to 0x4F

then between 0x80 to 0x83 are zeros

followed 10 bytes from unknown source (0x84 to 0x8D)

then there are 6 bytes that can be constructed as following:

value from 0x3A XOR value from 0x6A -- put it to 0x8E
value from 0x3B XOR value from 0x6B -- put it to 0x8F
value from 0x3C XOR value from 0x6C -- put it to 0x90
value from 0x3D XOR value from 0x6D -- put it to 0x91
value from 0x3E XOR value from 0x6E -- put it to 0x92
value from 0x3F XOR value from 0x6F -- put it to 0x93

followed by 16 bytes that are not taken into calculations at all.

So it would be nice to understand which command is used to get these 10 (or maybe 16) bytes using FBUS and from where? Unfortunately the serial spy does not include the final log.

So if someone could possibly make the similar spy and attach the LOG file, it would be great. Then also the same command could be possibly sent over USB to newer BB5 versions?

Pavel

[HydroFlash]

Maybe who knows how 2 decode strings in DK box cfg file?

For example all the same 5200 5.00:

V 05.00 27-04-07 RM-174 (c) Nokia. $30 2 9F7000928508C5D744262D ;5200 ad0

V 05.00 27-04-07 RM-174 (c) Nokia. - version of phone
$ - marker end of version of phone
30 - not used in last version
2 - not used in last version(in previous version it may be value 4)

9F7000928508C5D744262D - sequence which sending 2 box in native form
What does it sequence mean?

It is not like a triggering string because so big.How 2 allocate trigerring pads?

Maybe can someone explain this format?

[PhantomGSM]

i really like your first post it made me laugh.

glad to see you have joined the main forum for anything to do with mobile phone unlocking and repairs....be sure to use the search feature at will as its useful.

p.s can i guess the answer to be something like the sequence translates to another language that some nice other gsm forum member will have to explain.

p.p.s. pls slap me silly if the answer is easy

p.p.p.a. ok my sarcism is lost in space a.t.m. i really don't know how else to welcome a new member that got stuck right into all this programming and an-alysis stuff so quick/deep quickly....thats enthusiam for you i guess....


Hello & welcome to gsmforum