frontpage
frontsthe boardsearch
Log in
termsprivacycookiessupport
frontpage
log insign up
termsprivacycookiessupport
frontssearchlog in
CRbaiehclacaadminc/osdev · 1 month ago · No.10164981

Does anyone here know if there is a chance to boot a blackberry classic Q20 into a custom OS?

Does anyone here know if there is a chance to boot a blackberry classic Q20 into a custom OS?

7
2

9 notes

7 comments2 points

Log in to comment.

MLmai_lapyst✓1 month ago

Very interesting device choice! I think it's not quite easy, as blackberry's often have locked bootloaders. But searching a bit online, it seems that there are some custom roms (mostly patched blackberry os), but maybe you can use them to inject an custom os as well?

1
MLmai_lapyst✓1 month ago

Hmmm... did some more research and aparently the "original" blackberry is likely not going to be modified as they're explicitly build and marketed to be secure / tamper proof. Some did an restomod, aka using the blackberry shell but housing an android inside to make it work, but no idea how viable/doable this is: https://www.reddit.com/r/blackberry/s/2il0TZYZ3x

1
CRbaiehclacaadminoriginal poster1 month ago

Yes i seen that i think its called the zinqwa q25 or something like that

1
MLmai_lapyst✓1 month ago

Yeah, I was on there store aswell. To get the component kit to upgrade your own device, they charge 283 euros and ofc have wait times since they produce in batches.


Looked further into it and the problem is the Qualcomm CPU. It uses an builtin source of trust feature to verify the software being booted, so unless you can reverse the process and derive the key blackberry used to sign their software/updates, this isn't likely to be possible.

That being said, I know of some people that got around a similar feature in PS3 (I think), where they analysed stacks of machines to get the root key (which they got successfully after years of efford).

1
CRbaiehclacaadminoriginal poster1 month ago

Ohh yeah maybe that could be applied to the blackberry too.

1
MLmai_lapyst✓1 month ago

Got to admit, you really nerd-sniped me with this post x3

So I dug a little bit deeper and sadly ran into a wall.

So, quallcom's root of trust works by taking the certificate chain of an signed bootloader, and comparing the root certificates hash against one stored in an special memory region (called OEM_PK_HASH), to verify the software (bootloader in this case) is genuine. This is done by an piece of code in immutable memory, called the PBL (or Primary Boot Loader). The hash itself is ALSO immutable due to eFuses being blown, holding the set values in place. The good part: it is readable afterwards, using specialized tool and evilated priviliges (i.e. an rooted android, which the Q20 seems to be able via some linux kernel flaws, aka "towelroot").

Now comes the problamatic part. The OEM_PK_HASH is 384 bits wide, meaning an SHA-384 was used, which is considered to hold post-quantom securtiy (i.e. even an quantum computer will have an hard time discovering hash collisions). So breaking that hash will likely never happen. (Quick sidenote: the PS3 key was "only" 43 bits wide and had other issues they used to reverse it... so yeah; a very differnt story sadly)

The only missing piece I dont get is where exactly these eFuses are physically located and how the eFuses exactly work; to "blow" them (i.e. securing the value) you have to write a specific bit. If that is just one fuse that, if reverted, could theoretically allow writes again, it would be a way. If each bit of storage is an own fuse which are collectively blown, it makes things harder, but not impossible. Though I highly suspect that these are in the SoC burried somewhere not easily accessible, even with microscopic precision. But if I'm mistaken and they're at some easy-to-get-to location, that would make things easier.

Another avenue would be the memory access itself. Since OEM_PK_HASH is mapped to an particular memory location, something inside the memory bus / controller must route the bytes correctly. If that could be changed, it would be another path forward. But honestly this is just the same problem as before, since it's most likely in the SoC, in an not-easy-to-reach (meaning impossible) physical location.

... So realistically, the only thing would be to somehow get an unused Qualcomm Snapdragon S4 chip, that hasn't been burned yet, and swap it into the phone, providing there arent MORE chips that prevent such an hardware swap, but couldn't find informations on that. If not exactly available, maybe an chip with the same pinout would work, but harder to come by I assume.

So even more realisitcally, the only thing really feasible is to do stuff like zinqwa, and simple replacing the entire mainboard; not fancy but also not taking potentially years to find a workaround.

Must say blackberry REALLY took securtiy seriously with their phones. And qualcomm too.

1
CRbaiehclacaadminoriginal poster1 month ago

Thats a crazy deep dive you did there xd. I admire you.

2