BB5 SP unlocking, theory...

[Redeagle]

@Dejan, @All,
Hi, all,
As i know, LEA is not an ARM/THUMB (psudo) instruction, and an undefined instruction, either.
Could someone kindly tell me why Dejan decode "FE A4" and "01 A8" as "LEA"?
Thanks in advance.
Best regards
Redeagle

00A0C9BC: FE A4 LEA R4,[PC+#03F8] ;[00A0CDB8]=33323130 '012345678901234'
00A0C9BE: 85 B0 SUB SP,#0014
00A0C9C0: 2E CC LDM [R4],(R1,R2,R3,R5)
00A0C9C2: 01 A8 LEA R0,[SP+#0004]

[X-Shadow]

hmm...

It's just probably a mistake in the mnemonics in the disassembler he used...
But as you can see, the opcode is still processed as 'ADD'
You will also notice that his disassembler displays the code in
BIG Endian but processes it as LITTLE Endian...


For me, it should be:

b58ca: a4ff add r4, pc, #1020 (adr r4, 0xb5cc8) ; 0xb5cc8='012345678901234'
b58cc: 1c06 adds r6, r0, #0
b58ce: 1c0f adds r7, r1, #0
b58d0: cc2e ldmia r4!, {r1, r2, r3, r5}
b58d2: b085 sub sp, #20
b58d4: a801 add r0, sp, #4

(code taken from E90 _mcusw)

Not a big problem really...

[X-Shadow]

This document might help for reference purposes only...

http://www.gbadev.org/download.php?s...entation&ID=19

It's really old and was for gameboy advance...

B/R/

[jose miguel]

Originally Posted by X-Shadow

This document might help for reference purposes only...

http://www.gbadev.org/download.php?s...entation&ID=19

It's really old and was for gameboy advance...

B/R/

Unfortunately there was a problem. If you can read this, you have most likely tried to download a file from our website. The server have not permitted you to do this however.

........................

[X-Shadow]

http://gbadev.org/docs.php

2nd from the top...
ARM THUMB reference sheet [ARM]

[X-Shadow]

Can someone confirm this:

...
00A0C9DE: 50 F6 6C E8 CALLX 0085CABA ;should be CALLX 0085CA98 ??
...
00A0CA2E: 50 F6 34 E8 CALLX 0085CA9A ; should be CALLX 0085CA98 ??
...


Both IDA 5.0 and objdump gives me 0085CA98...

Firstly, BIG UP to Bph&Co who helped me trace that
impotant subroutine that is called before that bit we need to patch along
with giving much needed info to complete this BB5 Unlock Theory!



Now the trigger bits can be best explained when we divide the them into
three groups which are:

bits from previous burst (taken from previous 32-byte burst)
bits from flash wait state (6 to 9 bits.. check datasheets of flash used)
bits from current burst (taken from current 32-byte burst we want to patch)

For the 5200 v5.0 trigger '111111000000000010000010', it can be divided to:

bits from previous burst = '11111'
bits from flash wait state = '100000000'
bits from current burst = '0010000010'


"bits from previous burst" of 5200 v5.0 can be found by tracing subroutine
_94fd54 which is called just before the instruction we want to patch!

a0ca14: f743 f99e bl 0x94fd54 ; subroutine called
a0ca18: 2801 cmp r0, #1 ; we want to apply patch here

after tracing that subroutine (use IDA v5), we get previous burst which is:

94fde0: bdf0 pop {r4, r5, r6, r7, pc}
94fde2: b5f3 push {r0, r1, r4, r5, r6, r7, lr}
94fde4: 1c04 adds r4, r0, #0
94fde6: 2000 movs r0, #0
94fde8: b083 sub sp, #12
94fdea: 43c0 mvns r0, r0
94fdec: 2700 movs r7, #0
94fdee: 9701 str r7, [sp, #4]
94fdf0: 9002 str r0, [sp, #8]
94fdf2: 8821 ldrh r1, [r4, #0]
94fdf4: 88e0 ldrh r0, [r4, #6]
94fdf6: 2901 cmp r1, #1
94fdf8: d109 bne.n 0x94fe0e
94fdfa: 0781 lsls r1, r0, #30
94fdfc: d003 beq.n 0x94fe06
94fdfe: 0781 lsls r1, r0, #30

from that burst, we get 16 bits for AD0 which is '0100100101011111'


"bits from flash wait state" for now can be guessed and the length of wait
states should be documented in flash datasheet so you know the exact
length of bits to guess... For discussion's sake, Dejan found wait state bits
to be '100000000' for 5200 v5.0 which is 9 bits long

"bits from current burst" was already explained on page 2 of this thread and
it is '0010000010'


Now since we already have 10 bits from our current burst + 9 bits from flash
wait state, we only need 5 more bits from the previous burst which is '11111'.
In the end, we get ''11111 100000000 0010000010' which can be used for
CPLD with 2 clk delay before toggling bit.


Now these information is accurate in theory, but the real "MAGIC" is done
by the CPLD or FPGAs used by current boxes/clips in the market. These
trigger bits are practially useless for "FREE UNLOCKING" and this is just an in
depth explaination of how those BB5 phones are hacked...

[Vadim Kova]

Is the short sequence (f.e 10 bits 0010000010) repeated somewhere else in the subroutines while entering code by kbd? I mean probability of wrong 10-bit sequence decoding may be low enough.

[Ganja47]

Originally Posted by X-Shadow

Now these information is accurate in theory, but the real "MAGIC" is done
by the CPLD or FPGAs used by current boxes/clips in the market. These
trigger bits are practially useless for "FREE UNLOCKING" and this is just an in
depth explaination of how those BB5 phones are hacked...

not necessarily, i am not saying any noob could do it but some knowledge can help you with free bb5 unlocking.
look at the clip update #2 from mr. dejan
calculate the trigger strings for the 4 models included in this update like dejan describes in theory, he even mentions the used delay he needs for his device.
now if you've got these triggerstrings disassemble the cpld code and search for these strings and replace them with trigger strings for the models you want to unlock. also the patch routine has to be adapted of course.
assemble the code again and flash to the clip and off you go.

as i said at the start you need to have some knowledge about soft/hardware and understand dejan's theory and there's quite some work to do but this info can definitely be put to good use.

Regards,
Ganja

[ihmgsm]

these days if I am lucky will finish my project see photo...

[Ganja47]

there you go, very nice development board, only $49.99 as well
this way you don't have to worry too much about hardware design
how much is it for the usb interface m8, couldn't find it

Regards,
Ganja47

[ihmgsm]

usb interface is taken from another project - just fits for that job (not a development board it a custom board with ATMEGA162 and ftdi)

[X-Shadow]

@Ganja47

No offense man... but are you seriously telling me to disassemble a JEDEC file??? Maybe you want me
to convert JEDEC bitsream back to EQUATIONS (Look at Reverse Engineering Section, I discussed
more on JEDEC there). The JEDEC is not instrctions for CPU,,, it is design for logic itself, and so there
is nothing to disassemble. JEDEC is nothing like HEX for PIC.

Also, did you try to compare old_n95.jed to new_4in1.jed?? Dejan did not just inject those new bits
for new phones in the new jedec. He put extra logic for testpins on DIP switch as well (and maybe
some more logic to make it work more efficient with 4 internal trigger configs.) This means that we
cannot just compare them side by side like comparing a patched.exe to an original.exe because they
can be thought of as TWO entirely different exes...

True enough you can "inject" new triggers to the jedec and recalculate checksum to make it work
with other phones... But we don't know where to inject it. For now, we only have further knowledge
on what to inject!

So really, it all boils down to learning Verilog/VHDL or wait for someone to make open source design
for it. For the first option, "some knowledge" does not cut!

[X-Shadow]

@Vadim Kova
The probability is very high for 10 bits alone @ 66Mhz, but the technique is to use
16-bits from previous burst, then start guessing the wait state bits (6-9 bits long)
one by one. This is the reverse manner of what dejan explained.

If you already have hardware to check whether your trigger
is valid or not, you can do it this way:

(the example here is for 5200 v5.0)
Use 16-bits from previous burst which is '0100100101011111'
Since last bit is '1', then there is more probability that first
bit of wait state is '1'. So add '1' to the end and check the
17-bit trigger with your hardware. If it sees it, add another '1'.
If it does not see it change it to '0'. Once you get your first
'0', all bits in the wait state after that should now be zero since
the first bit of the current burst we want to patch is '0'. Now
you will still need to guess the length of the wait state, so
just keep adding '0' until you get an error. When that happens,
that bit '1' is already part of the burst you want to patch! So
now you just connect the bits from the current burst you want
to patch and you have a valid trigger!

All this is just theory and it is only proven in 1 example made by
dejan and is implicitly implied in some Spansion datasheets. Please
don't take my word for it because I do not own an expensive
LogicAnalyzer with serial triggering. Follow this at your own risk
please!

[Vadim Kova]

Yes, it is clear, but can we start similar move from the last (current) burst back?
We can add at once 7 zero (or 1's?) of waitstate in front of known 10 bits from the last burst.
So we got 17 bit sequence and win 2^7 times in probability of correct decoding. Is it insufficient too?

[X-Shadow]

@Vadim Kova

You can do that if you want... But according to recent info shared to me
by someone who know a lot BB5, that 32-byte block we want to patch is
read again right after that subroutine called finishes. Meaning, if you patch
the first instance of that 32-byte block in 5200 v5.0, your patched instruction
will not be executed! Sometimes, depending of how the firmware is divided
in 32-byte blocks, that block we want to patch gets read more than 2 times
so really if you use that as your INITIAL trigger, then you have a big chance of
patching the wrong INSTANCE of the that block in the end.
Another BIG UP to Bph&Co who shared this info.

Maybe this is what Dejan means when he said:
"On the end with luck you will find only one long string in size of 24 bits or
more.If you found more than one string YOU have to test all of them until you
find right one!"

One the other hand, if you already know the correct previous burst and you
only want to "guess" the wait states... then by all means you can do it
in reverse just like dejan stated.

BR.