[quackquack147]

Please, don't misunderstand me Paul, i really apreciate what are you doing here, it's just a principles thing, i have a big consideration for all the developers around the world, and that includes BlackBerry developers.
Sharing this kind of information could totally compromise the security and the hard job that BB developers had, also this could compromise users that aren't even here in this site, not that YOU would do bad things with that.
Please, i beg you, it's not that i don't wan't to help you, i really liked what you are trying to do, it's just, i can't, i'm sorry.
Imma go eat a pye, see you, and good luck!

sounds like a real blackhat job. but i wish you could share some info, some light, some hope, some ray of light. but no worries i do understand the situation and if this is that bad then there must be some use here also. if you dont wish to share fine enough. i think i got already enough hint. i.e. i need not use a jtag or wire boards with debugging cables. there is some information which you leaked in one line will help me and the community. the thing is you gave a valueable hint. i think thats enough, errors and exception. the answer you alreay provided the question is how do i backwalk to the question. good old school trick answer backwalk to question. thanks for the tip, errors and exception. once again this help i wont waste with a click on the thanks button. ;-) muhahahaha!

yes i fully understand. the thing is. embedded - ARM TrustZone development - Stack Overflow go to post number 4. thats what is the daunting thing. its not tsg's tpm chip which has pretty good documentation and has been ported to make use with kvm and xen via seabios by including the tpm tables. i wish TI or arm also release it to public w/o much NDA signature. well thanks anyway for sharing this info. the thanks button thanks would do no good. looks like if no one donates a board in 2-3 days time i need to buy myself a stolen/useless/damaged board in the local market.

irc style answer!
/me shakes my head in surprise.... astonished ...... could it be this simple? holy mother ******* bull ****......... muhahahaha

/me surprised again ....... wtf its errors & exceptions & panda board and system calls.

muhahahaha you are a genius. thanks again. thanks a lot for the tip!

thanks
-paul
p.s. thanks for the great help! error and exception and system calls, you gave away the answer to my question. now i need to walk back to the question itself. thanks man thanks a lot. hahahahahahahahaha! you are pure evil. real wicked! hate off and enjoy your pyes! ;-) signing out for now.
thanks thanks thanks thanks thanks thanks thanks thanks thanks thanks thanks thanks....... hahaha! thanks thanks thanks thanks thanks thanks thanks thanks thanks! got it got it got it got it. :-D hahaha! got it. thanks for the tip.
the answer is error and exceptions and system calls. muhahahahahahaha! if i meet you your beer is on my bill. ;-) and also pyes! ;-)

[Synerworks]

Even if all the boot source code was released and built verbatim, without the correct signature it would not be seen as valid at launch. Without a JTAG, pushing your own firmware onto the device will not happen with the existing locked bootrom. Maybe if the bootrom had some unhandled exception that was exploited, an image can be generated to overwrite it but none exists to date. The only downside to attempting to clobber a soft-bricked Playbook is that it can potentially be rendered a doorstop if development tools can no longer manage further firmware updates. At least a bricked Playbook will be recoverable when a BB10 image is released by Blackberry whenever they get around to it.

[quackquack147]

Even if all the boot source code was released and built verbatim, without the correct signature it would not be seen as valid at launch. Without a JTAG, pushing your own firmware onto the device will not happen with the existing locked bootrom. Maybe if the bootrom had some unhandled exception that was exploited, an image can be generated to overwrite it but none exists to date. The only downside to attempting to clobber a soft-bricked Playbook is that it can potentially be rendered a doorstop if development tools can no longer manage further firmware updates. At least a bricked Playbook will be recoverable when a BB10 image is released by Blackberry whenever they get around to it.

it is simply not fair me eating the cake alone. here let me share the cake the source for the bsp is here foundry27 : View Wiki Page: TexasInstrumentsOMAP4430Panda you need to register yourself and sign an NDA and thats about it.

the agreement is under apache style. which means

"The Apache license is quite like the BSD license in its scope. It's pretty free and easy, you're not required to distribute the source code of a covered work, and you don't have to worry about it "infecting" a derived work; you just need to be sure to include their license."

Hey this is apache licence. which grants me the rights to distribute it. i need to email qnx aka sonicfoundary if i wish to release the code. once i start to port and create a coreboot binary which is after i am done with this security bypass and install debian and/or netbsd instead of blackberry OS.

i got myself the installer-bbndk-bb10_1_x-linux-1020-201303191709-201303191501.bin and also blackberry playbook OS simulator i will try to work on it. and see if i can up the ante and crash it. if i crash it? thats the "exploit" ;-)

i am attaching the binaries. but i am not sure if they will work or not since i have not tried them myself. these are stock binaries except x-load.bin.ift which happens to be my signing x-load.bin. just rename the old MLO to MLO.panda.backup and rename x-load.bin.ift to MLO. and jtag it up.

follow the PandaBoard JTAG Debugging - OMAPpedia and build your own jtag and upload. it shouldnt complain since it signed. and the u-boot with show you panda in prompt. i am recompiling the source to see if i can make come cosmetic changes like change prompt to "PlayBook#" prompt.

and as synerworks said you need to have a bricked BB PB and jtag tools and jtag jig and jtagging skils to do this. else wait till i find a way to exploit the system. and lastly i am working and also waiting for someone to make my work easy an easy not "zoo vulnerability" (already released) but a "wild vulnerability" (not yet published) will make my work lasy. well i am lazy just like others.

many out in wild who are willing to revive their playbook and omap4430 HS (high security) based Blackberry devices including phones. i am not sure about the u-boot.bin for phones. but u-boot.bin for playbook is bound to work. proceed on devices other than playbook with u-boot.bin at your own risk. hope this helps many unfortunate souls/bbpb owners.

i wish them good luck.
thanks
-paul
source is under NDA and yet apache licence. WTF looks like rim and qnx fscked up the licencing terms. hehe!;-)

[urstrinath]

it doesn't work so i think

[quackquack147]

it doesn't work so i think

you jtagged already? or you tried a software push? i told you this is still epsilon testing not even beta or alpha. can i have the report log? or some log? so i can understand it better. provide me with the logs. because i need the logs. w/o logs i cannot proceed.

i will wait for 2-3 days for someone to donate me a board or send me a blackberry playbook and he/she has to pay the return shipping cost. else i will buy a stolen/locked device from grey market and then carry on.

anyway i will repeat again. which part didnt work? did you try to push this into the device via bb desktop util or did you try pushing them via jtag? if its jtag? what is/are the error message(s)? unless i have the log i dont understand anything. i hope you understand.

thanks
-paul

[quackquack147]

this is the POA (plan of action)!
#1. Make a livecd 32 bit, which is hybridiso which means it can boot from cd and also usb.
OS will be debian and default desktop manager will be kde.
#2. Harden it. Not that insane like RIM OS.
#3. Install all the developer tools.
#4. Install all the developer tools which are not for free.
#5. check and recheck if everything works fine.
#6. Now install the RIM tools and utils minus the RIM developer certificates which i got for free from RIM after i signed up their NDA. sucks!
#7. Now harden the environment with RIM and TI and other tools which are non free and all nda stuffs. w/o licences so i can install the licence later in a live session and carry on with work. And also include xsacha's tools. i thinks its very handy for live BB OS.
#8. Now again sanitize the environment and set paths correctly and check permissions.
#9. Beef up the security a little bit with IDS and IPS and firewall as usual and port scan detection.
#10. Try to make it developer friendly as much as i can with jtag and ejtag and support for buspirate include the drivers aka modules and also include the debugging environment.
#11. Check and final check one more time so things work well.
#12. Build it up! and burn it into an ISO rom.

Does anyone need it? If you guys need it let me know. i will upload it. i guess with soo much utils and documents its going to be huge. and around 7-8 GiB. i am not sure how huge it will be. But it will have all the tool you might need to get it to work with. plus i will be converting all the binaries (NDA binaries obviously w/o licence certificates), you can register yourself and get yourself a free licence and insert and it works on the fly.

Why am i asking. "ITS TOO MUCH WORK!" any work load sharing will be a great asset. plus this is a community. let me know if you need it. i will upload it once i am done with step #12. if you folks also do a little bit for me it will speed up the process. thanks for wasting 5 mins reading this post.

Thanks
-paul

[quackquack147]

nmap -f -n -p 1-65535 -T4 -A -vv -O -r -sX -sU -sY -Pn -d2 -PS -PU -PA -PE -PP -PM -sV -e usb0 --script "default or (discovery and safe)" 169.254.1.1 2>&1 | tee blackberry-playbook.log
this is very interesting. i will read the whole log its more than 9 MB and reveals too much info. lets see what it bring with a few more switches then i will run some vulnerability scan and see what are the vulnerable services. i am not going for something called "lets exploit" my approach is like "data drain" from sony playstation dot hack infection. .hack//INFECTION (Part 1) - Data Drain FAQ
i have nothing personal against either RIM or blackberry and never will be thanks for the lovely device. all i want is root access. thats about it. and lastly what all info i release here is under GFDL. hehe. why GFDL? my @$$ is safe then if at all i push to the limit and which is push comes to shove.

i am done binary reading 2% of the 2.1.0.1526 and i am discovering some amazing things and real exciting things. i will post them slowly. as of now i have run
nmap -f -n -p 1-65535 -T4 -A -vv -O -r -sX -sU -sY -Pn -d2 -PS -PU -PA -PE -PP -PM -sV -e usb0 --script "default or (discovery and safe)" 169.254.1.1 2>&1 | tee blackberry-playbook.log and it gave me sh!t load of info about playbook and RIM's QNX in general and the best being?
RSA key SIZE is 3072
if this is the case then we can expect 4096 bit RSA keys, crypto analysis, difficult next to impossible, and bruteforce? hmmmmmm by the time its done i will gain 20 more years. so? breaking the key which is RSA 3072 is over ruled.

this is why i said we need the data drain approach. we will discover an exploit and then its fixed in an update and rot we had is gone. lets find a fundamental design flaw/error. if we find it? then its RIM who has to redesign their philosophy and we can use the same technique and method no matter which firmware is pushed as an update.

i applied this method to that lava w150 and i got in. but it didnt have a boot loader signed and locked. so software was easy. but here we NEED IT. data drain. attacking the logic and exploit is like hit and run. core hit is like 100% fatality and never an issue in future. so this is not a smash and grab job.

by the way i am done with stage 1-2-3-4-5, as of now no error/flaw going to stage 6 today in the morning. hope we win.
GNU Free Documentation License v1.3 - GNU Project - Free Software Foundation (FSF)
thanks
-paul
adding footnote: RSA with 2048 is an eyebrow raising point here at user level 3072 i am not willing to face legal sweet chin music. ;-) so i am releasing the info under GFDL. let gnu and RMS (richard m stallmann) handle the lawyers. :-D

[quackquack147]

pg. 270
target debugging ieee1149.1 (jtag) and ieee1149.7 (complementary superset of jtag aka ejtag) i.e. 14 pin and 20 pin and also the 2 pin aka tap both are supported.
by default it operated in ieee1149.7 i.e. 20 pin ejtag support.
it supports global starting and stopping of individual CPU cores (this is fascinating).
each cpu can generate triggers (wonderful)
system clocking and powering up/down, so this means we can clock it to max 1.2 ghz and also underclock it using jtag. whoa super cool.
interconnecting multiple devices, hmmmmmmmmmmm extremely interesting, does it mean we can boot of mmc or sd card, who knows the pin out? please shout out loud if you know the pin outs. :-D
we can even channel trigger. excellent. and that too 256 channels. now we are talking to the OMAP4430 CPU. hmmmm real nice.
we can control power during normal debug? this clock and registers? hmmmm someone shed light please.
processor trace subsystem? so this means we can trace all the calls made by cpu. correct me if i am wrong. this can be a real cool information.
system trace subsystem....... waqqqqqqqqqqq! we can run a system trace? *i think good news* but still dont know if it will work jack or not.
cross triggering unit (wtf is this?)
debug resource manager aka DRM (again wtf is this?)

pg 271
power reset and clock mgmt.
dynamic clock gating. okay nice.
dynamic voltage and frequency scaling. nice just like acpi, cpu freq scaling.
dynamic power switching. we can switch powers....... nice.
static leakage mgmt aka slm (dont know jack mike what it means)
adaptive body bias aka abb (still dont know jack mike)
retention till access aka RTA whattttttttt .......... could we run a cold boot attack and read the keys from memory. looks like some info albeit keys has to be stored in memory for a long time. hmmmmmmmm interesting.
clock mgmt 2 types.
cm1, its for clock, distribution and mgmt of MPU (math/multi processing unit), abe and core? news....
cm2 its for clock, distribution and mgmt of other modules, even security registers? hmmmm we need to poke this.

memory secret...... wink wink!
L3 OCM RAM - 56 KB of on-chip SRAM. sweet. so we got 56*8 = 448 exact for blowfish. hmmm this means may be very bad news.
SAR RAM is 4KB so we know one thing bootram is 4KB i.e. 4096 bits. am i right or guessing right? the bootrom sign key is 4096 bit. hmmmmmmmmm. we got dual bad news. i could be wrong. expert arm cpu developers please explain whats what here. can you?

now good news, SAR RAM got 8KB divided into 4 blocks i.e. each block 2KB or 2048, so are the keys split into 4 sub keys? what does this BS mean? all BS to me. stuck! its used as a context saving memory, and data is stored even when device goes off mode. whoa, this sounds like cold boot. i am wondering if there is a /dev/fmem or /dev/mem reading option for ARM? If so then its excellent news.

pg 5503
each cpu can generate trigger which can control the flow of execution of other processors?
interconnection of multiple devices ....... hmmmmm so tis is like a bridge?
we can trigger channels, or DMA? hmmmmmm confused again.

TI Tool called CToolsLib is a tool, which are system level debug capabilities for TI's omap4 devices including HS ones and GP as usual.
CToolsLib - Texas Instruments Wiki

Jtag (ieee1149.1) signals which are supported nTRST, TCK, TMS, TDI, TDO and RTCK (return clock) from arm968, so we need 2 clocks one to clock and one to return the clock, tick tock?
pg 5504 for more detailed pin config. sheesh there are countless unpopulated pins and headers which one is the right one? who knows please shout.
we got news. it also supports 2 pin ieee1149.7 ejtag taps. hurray. in jtag tap we got 2 pins which works in parallel. hehehe sweet. they are tck, tms, tdi, tdo, ntrst and rtck on one pin. tck and tmsc on another pin. this is like i2c.... or am i wrong, or is it 2-wire. which one is correct? someone with good electronics knowledge please explain.

pg 5505 table 28-3.
icepick can operate in parallel mode with super-bypass select. excellent. we found the missing piece. this is the sweetest information i read in the ti doc. ;-)

TAP's ICEPick supports full CPU reset, which also means HS reset. whatttttttttttttttttttttt? this is the best news pg. 5509

what say now synerworks? where are we? are we there yet? i will be downloading the security doc and will read it up. i only read from 5500 till end.
thanks
-paul

[Synerworks]

The programming of the SoC can be done on the bare chip with a jig attached to the jtag pins. With it on the mainboard, the pins will be tied either high or low and you will not be able to use them to program the bootrom unless you find and cut traces. The Playbook is certified as FIPS 140-2 compliant, but it does not mean it is immune to hardware manipulation, just the level of effort to do what you want is questionable. I commend you for your enthusiasm, but since the Playbook is a niche device with a small community, even if Android can run on it, there are no more Playbooks being manufactured that people can purchase other than what residual inventory is left. Even if you build something for your Playbook, the procedure for the common folk will be beyond their comfort level to get it to work on their units.

[quackquack147]

bare soc programming is easy i done it many times. on both mips and arm cpu.
mainboard? this is something new. there are many empty pads. since i am not an electronics/electrical engineering student i have no knowledge. and if we find the right trace then we have a field day.
my intention is coreboot gsoc 2014, i missed 2013 because i picked omap3 and omap4, developers didnt approve it. leaves me with empty workfile in the backpack.
does android interest me? nah! but it doesnt mean i will not use android or support in future. it doesnt interest me anymore. back in 2009-2010 android was hot topic and now its stale and commercial dirt bag.
last line is whats interesting.
"Even if you build something for your Playbook, the procedure for the common folk will be beyond their comfort level to get it to work on their units. " --> we dont know if we will succeed or not. if we do succeed with a bare software level w/o much tinkering? nice. but if its not the case then? well looks like very few hand picked will have it since it needs some hardware adjustments.
thanks anyway for your feedback.
-paul
p.s. i am not giving up on omap. i believe i can. i cant say when. be it omap3 or omap4 or omap5. this gsoc14 i am submitting omapX series.

[quackquack147]

pull "the stop chain" page 103 incase of an emergency
http://www.ti.com/pdfs/wtbu/OMAP4430...ic_Book_vC.pdf
and where is it located? page 4
http://www.ti.com/lit/an/swpa182c/swpa182c.pdf

well. Now the jtag is picture perfect and complete.

if crypto analysis fails? then we usb uart, if it fails? then only manual override AKA jtag. here are the pins and their location.

last bit of the puzzle, where the pins for jtag are solved. So time to pull my sleeves and socks up and get to work. enough of forumming for oneday. sunday funday -> over. back to business because its monday in 5 hours from now. yayyyyyyyyy!

hope this helps!
thanks
-paul

[quackquack147]

adding more information.
I found more pins and pads showing signs of electric pulse and or potential difference and or current. my initial findings show me too many pads giving off voltage difference ranging from 0.2 volt to 5.6 volt.
now the TI doc on page 84 says vpp_cust must be connected and powered on when we are cpfrom programing. which means there has to be pads on the board which does allow resetting the voltage.
this weekend work will be to trace the pins and locate the exact location of which pin/pad does what....
keeping the logic of orgamizations in mind "break the seal incase of emergency" which means RIM must also follow the same backdooring mechanism. which means, RIM for pets's sake got the board with headers and pins and carry on their design. but they need to test it on a factory device. which is exactly when you and i got. thus it must have a kill/trip switch which saves their *** incase something goes wrong. and having shiffed the voltage on the pads i am sure and certain that RIM also got something like that before they ship out the firmware to public. this also means that the same information is there with the service center and they know the pins for hard reset. its for us to find it out. and the best part is TI gave all the secrets out already. RIM cant stop it from happening.
so the secret lies in finding the exact pin. i need to spend this whole weekend doing a logic sniff/swipe the entire board and look for the beep beep beep tone.
once i get it. we can be sure we are in. and this also means we got jtag traces on the board and we need not SMD the whole chip just to look out for the header pins and wipe memory clean.

http://www.ti.com/pdfs/wtbu/OMAP4430...ic_Book_vC.pdf page number 84. its somewhere near twl6030 we got some hot spot. we just dont know the exact location. time to trace.
thanks
-paul

[quackquack147]

more good news on the way. after reading at a very high speed 372 pages i found out these.

the pins are

jtag_ntrst - jtag test reset - I - AH2 - 1.8v (-0.5v to 2.20v) (0.05 mA to 50 mA)
jtag_tck - jtag test clock - I - F4/AG1 - 1.8v (-0.5v to 2.20v) (0.05 mA to 50 mA)
jtag_tms_tmsc - jtag test mode select/ compressed jtag packets (cJTAG) - IO - E1/AH1 - 1.8v (-0.5v to 2.20v) (0.05 mA to 50 mA)
jtag_rtck - jtag ARM clock emulation - O - AE3 - 1.8v (-0.5v to 2.20v) (0.05 mA to 50 mA)
jtag_tdi - jtag test data input - I - AE1 - 1.8v (-0.5v to 2.20v) (0.05 mA to 50 mA)
jtag_tdo - jtag test data output - O - AE2 - 1.8v (-0.5v to 2.20v) (0.05 mA to 50 mA)

Vpp = system voltage for eFuse -> 1.65v ~ 1.70v ~ 1.75v
Vpp_Cust = system voltage for customer eFuse -> 1.65v ~ 1.70v ~ 1.75v

now an electronics engineer have understood the logic. for those non electonics and electrical speaking folks here in simple english.
AH2, AG1, AH1, AE3, AE1, AE2 are the bottom pins for jtagging or sending the reset signal and wipe clean the contents on emmc and/or cpu. in mips its completely different, it just wipes the NOR flash chip (eg the ones placed on the system board in your router to store all data) and we got a few top ball pin connectivity too.

the top pin corresponding to bottom pins are :-

F4 <-> AG1
E1 <-> AH1

Now the good news is when i did run a trace last time i did find 1.8 v which is the operating voltage for the jtag on this CPU via the system board. now i forgot and i need to run a scan again.

YES I AM DEAD CONFIDENT & ALSO 100% SANGUINE THAT THE SYSTEM BOARD GOT THESE 1.8v PADS.

which means i overshot the gold mine. and the gold mine is present. i need to rescan and redo the logic sniffing. there are too many pads and pins and its back breaking to find and isolate each and everypins.

important thing to remember? the Operational voltage is 1.8v and the OPP or operation condition addendum is 2500 nano second to 0 seconds.

so we are now a few mm away from resetting the board.

the HS chip wont reset unless we pass a 0.05 mA to 50 mA. which means we may have to use a resistor which is less than
V=I/R or R = I/V i.e. R = 50mA/1.8v ~= 27.78 ohms.

eureka! we need a 20-25K resistor to activate the bootrom chip and diffuse the HS mode. and we got it.
if any electronics guy here would like to correct me and my calculations...... please feel free to do so.

this is all the good news i got.

thanks
-paul

[Synerworks]

Once you have the jtag pins, use it to read out the bootrom. If it is identical to your bootrom image on file, clear it and rewrite it to make sure you can retstore it a working state. As I have said, normally the jtag pins on the SoC is driven either high/low when it is place on the mainboard so that the chip cannot be clobbered after manufacture. The SoC is produced bare and pre-programmed with with the clients firmware prior to being shipped to final assembly on the mainboard during a production run. The chip is not programmed after final assembly since the jtags are locked when the chip is socketed. If you find the traces, they need to be cut to enable you to connect your jtag pads for programming. RIM did not do any work on the Playbook design and build, it was entirely outsourced to a contract manufacturer and used the reference designs of the parts suppliers. The software is theirs, or the QNX folks since they were a Java shop for all their other stuff.

[biglo30]

Appreciate you guys hard work, especially you quackquack will be ready to donate when you have full success with your work or even if you give up for all the effort that your putting in. Thanks!

[quackquack147]

Once you have the jtag pins, use it to read out the bootrom. If it is identical to your bootrom image on file, clear it and rewrite it to make sure you can retstore it a working state.

first jtag job in 2006, when i screwed up my wrt54g! exact procedure i followed.

As I have said, normally the jtag pins on the SoC is driven either high/low when it is place on the mainboard so that the chip cannot be clobbered after manufacture.

there is HiZ (high impedence), yes you are right i need to find the traces, but this is a multi layer board and sandwiched. so even if there is/are traces it will take a whole weekend, min 2 days. aah here goes my weekend for a toss.

The SoC is produced bare and pre-programmed with with the clients firmware prior to being shipped to final assembly on the mainboard during a production run. The chip is not programmed after final assembly since the jtags are locked when the chip is socketed.

does it mean RIM has its own assebly line? where the chips are preprogrammed and then sent to assembly line outside RIM's HQ for china or taiwan? If they cannot be reprogrammed? what happens to a systemboard if its screwed and sent for a RMA?

If you find the traces, they need to be cut to enable you to connect your jtag pads for programming. RIM did not do any work on the Playbook design and build, it was entirely outsourced to a contract manufacturer and used the reference designs of the parts suppliers.

these are quad layer pcb and i think it will be hard to find the trace else we hit the hot spot. agreed, and i am dead sure there has to be a weakness. its hidden but we dont know whats the hidden weakness. but since into this line since 1995, i believe every manufacturer keeps a backdoor, yes each and every. so does RIM. question is where is it? and thats the answer. we dont know if the manufacturer left out some pads for us like easter eggs. because when they finish the assembly they then for sure check the working of each and every board for defect. isnt it.
now if i assume they get the CPU from RIM HQ in Canada, then ship it to taiwan/china, then get them assembled? doesnt sound nice. i am starting to suspect fish. a company which is almost bankrupt will spend that much? nah. i believe they are going this way.

CPU and SystemBoard made in china/taiwan timbaktoo where ever it be -> assembled in factory -> first initial check -> jtag check with a dummy x-loader -> jtagged wiped -> shipped to RIM HQ Canada -> Jtagged wiped clean -> Signed bootloader tattoed -> Firmware loaded eg 2.0/2.1/10.x -> packed -> stored in warehouse.

because if they are shipped from China/taiwan to Canada and then back to china/taiwan is cost intensive, i dont think anyone would do it. we first thought N900 doesnt have jtag but later it was found it has jtag. its written designed in finland & made in taiwan. check out debug ports. N900 Hardware Hacking - maemo.org wiki thats why i said this must have jtag too. we dont know where it is in Blackberry Playbook. Entire forum and IRC flooded with questions "Where is the jtag maaaaaaannnnnnnnnn?" but later discovered rather reinvented. likewise it will be gross underestimation of RIM and i am still putting my bets on the jtag ports. considering RIM's paranoia and track record over security? it must have jtag and some Blackberry phones got jtag too. which is why i am saying this. eg http://forum.gsmhosting.com/vbb/8525659-post13.html

This whole business is inhouse and its not outsources and re-redesign is not feasible as hardware vlsi design is again cost intensive. ;-)

The software is theirs, or the QNX folks since they were a Java shop for all their other stuff.

QNX sources say they are under apache licence, i think they havent read the apache licence and then they say dont release the source. and then they say lawyers will take care of us.
ARE RIM FULL OF IDIOTS? OR IS THE LAW FIRM FILLED WITH IDIOTS?
Do they even know the apache licence? hehehe, we got a loop hole in the licencing of QNX. i will have to ask my lawyer friend, we can sue the tip of their large intestine. i will take this issue to FOSS lawyers and will see to that they get sued. "conflicting licencing terms" and since we are playing with jtag they cant touch us. we are not playing with their prop stuffs. ;-)

hope this helps!
thanks
-paul

[quackquack147]

Appreciate you guys hard work, especially you quackquack will be ready to donate when you have full success with your work or even if you give up for all the effort that your putting in. Thanks!

a little donation acts/works like an encouragement. but the grand prize will be if it gets selected for gsoc14, google summer of code 2014. thats what i am heading for. GSOC will be the best prize. but thanks again for your appriciation and concern.
thanks
-paul

[Synerworks]

The contract manufacturer was Quanta who did all the design and build work and also built the Amazon Kindle. They are almost identical. The SoC were sourced from TI/Elpida by Quanta including every other parts for the Playbook and then assembled for the client, being RIM, just like an automobile assembly line. The firmware was provided to Quanta and the chips were pre-loaded prior to assembly on the boards. They are not loaded after manufacture since if there is a failure of the SoC or the system board, it is dumped in the garbage. All SoC are pre-tested before assembly since it would get mighty expensive to keep chucking bad units away that fail after assembly. The BBOS is post loaded after build on the SSD. RMA'd Playbooks are generally swapped with either new or refurb'd units. No post production work is ever done to repair failures found on the mainboard, it is swapped with another unit. It would cost too much to do diagnosis, repair, and retesting. As mentioned, to reprogram the bootrom, the SoC would need to be bare if the traces cannot be cut.

[quackquack147]

The contract manufacturer was Quanta who did all the design and build work and also built the Amazon Kindle. They are almost identical. The SoC were sourced from TI/Elpida by Quanta including every other parts for the Playbook and then assembled for the client, being RIM, just like an automobile assembly line. The firmware was provided to Quanta and the chips were pre-loaded prior to assembly on the boards. They are not loaded after manufacture since if there is a failure of the SoC or the system board, it is dumped in the garbage. All SoC are pre-tested before assembly since it would get mighty expensive to keep chucking bad units away that fail after assembly. The BBOS is post loaded after build on the SSD. RMA'd Playbooks are generally swapped with either new or refurb'd units. No post production work is ever done to repair failures found on the mainboard, it is swapped with another unit. It would cost too much to do diagnosis, repair, and retesting. As mentioned, to reprogram the bootrom, the SoC would need to be bare if the traces cannot be cut.

okay understood. i been posting in other threads and created a mess. i am new to this phpbb protocol (language and behaviour). anyway, i got the idea now!
so this mean? i need to really do not one weekend but 2 even more weekend signal tracing job. because this looks like a 4 layer board. and we can not go to the inbetween layers. which means we either need to cut the traces. have you got any idea or have you sniffed before using a logic analyser? i havent done a trace on this board. i plan to do this from this weekend on. looks like it will be hard and tiring and too much wall punching out of frustration.
thanks
-paul

[Synerworks]

Did work in the past with embedded systems troubleshooting and socketed devices with SoC to help trace schematic diagrams, mind you not with BGA components. The Playbook is not much more different from the products that I worked with, so I anticipate it will take much more work than you had predicted. If you have the equipment to lift the chip, go with that and put a BGA pad on that you can clamp the SoC onto. Should be easier mask the pins that you cannot cut traces to.

[quackquack147]

Did work in the past with embedded systems troubleshooting and socketed devices with SoC to help trace schematic diagrams, mind you not with BGA components. The Playbook is not much more different from the products that I worked with, so I anticipate it will take much more work than you had predicted. If you have the equipment to lift the chip, go with that and put a BGA pad on that you can clamp the SoC onto. Should be easier mask the pins that you cannot cut traces to.

aah this reminds me of freenode and efnet and oftc. hurrayyyyyyyyy!
same here our work modes are an exact sha512sum match. yes i did work with bga too. but this is very very deep work. having said that, and also 1.8 v sniffed out?
yes i can arrange a bga pad. a bread board should do i guess. this is real hardcore stuff. i am loving it. deep deep deep deep into the subject.
oh by the way i will be out of town for 2 days and taxi is waiting downstairs. flight in 2 hours.
afterall i was right there will be a geek everywhere who is unwilling to bend infront of the authority.
there are too many rebels in irc. good to see one here too.
hurray!
we will continue with the work on sunday. one and a half day will be hectic. so see ya on sunday.
good bye!
thanks
-paul

[WhiteSpir1t]

Just because QNX is open source does not mean the Playbook bootloader is open source. They are not the same thing. The bootloader initialises the necessary hardware and loads QNX. It is not itself QNX, or part thereof.

And even if it were open source, being able to compile your own code does no good without being able to flash it. And you can't flash it without it being signed with the right private keys, which as the name suggests, are private. The bootrom (which cannot ever be overwritten, because it's ROM) will check the signature of the bootloader before allowing it to run. Unless you manage to figure out the private key for the bootloader (or find some exploit in the bootrom), there will never be a non-BlackBerry approved bootloader on the PB.

Finding the key to the bootrom would be so nice. By extension, it could potentially allow Android OS to run on the Z10.

[WhiteSpir1t]

nmap -f -n -p 1-65535 -T4 -A -vv -O -r -sX -sU -sY -Pn -d2 -PS -PU -PA -PE -PP -PM -sV -e usb0 --script "default or (discovery and safe)" 169.254.1.1 2>&1 | tee blackberry-playbook.log
this is very interesting. i will read the whole log its more than 9 MB and reveals too much info. lets see what it bring with a few more switches then i will run some vulnerability scan and see what are the vulnerable services. i am not going for something called "lets exploit" my approach is like "data drain" from sony playstation dot hack infection. .hack//INFECTION (Part 1) - Data Drain FAQ
i have nothing personal against either RIM or blackberry and never will be thanks for the lovely device. all i want is root access. thats about it. and lastly what all info i release here is under GFDL. hehe. why GFDL? my @$$ is safe then if at all i push to the limit and which is push comes to shove.

i am done binary reading 2% of the 2.1.0.1526 and i am discovering some amazing things and real exciting things. i will post them slowly. as of now i have run
nmap -f -n -p 1-65535 -T4 -A -vv -O -r -sX -sU -sY -Pn -d2 -PS -PU -PA -PE -PP -PM -sV -e usb0 --script "default or (discovery and safe)" 169.254.1.1 2>&1 | tee blackberry-playbook.log and it gave me sh!t load of info about playbook and RIM's QNX in general and the best being?
RSA key SIZE is 3072
if this is the case then we can expect 4096 bit RSA keys, crypto analysis, difficult next to impossible, and bruteforce? hmmmmmm by the time its done i will gain 20 more years. so? breaking the key which is RSA 3072 is over ruled.

this is why i said we need the data drain approach. we will discover an exploit and then its fixed in an update and rot we had is gone. lets find a fundamental design flaw/error. if we find it? then its RIM who has to redesign their philosophy and we can use the same technique and method no matter which firmware is pushed as an update.

i applied this method to that lava w150 and i got in. but it didnt have a boot loader signed and locked. so software was easy. but here we NEED IT. data drain. attacking the logic and exploit is like hit and run. core hit is like 100% fatality and never an issue in future. so this is not a smash and grab job.

by the way i am done with stage 1-2-3-4-5, as of now no error/flaw going to stage 6 today in the morning. hope we win.
GNU Free Documentation License v1.3 - GNU Project - Free Software Foundation (FSF)
thanks
-paul
adding footnote: RSA with 2048 is an eyebrow raising point here at user level 3072 i am not willing to face legal sweet chin music. ;-) so i am releasing the info under GFDL. let gnu and RMS (richard m stallmann) handle the lawyers. :-D

After pulling out my sim card from my Z10 and putting the iPhone 4S back into commission, seeing your post is like a breath of fresh air. All I can say is staying faithful with the work involved here is logical as an exploit will eventually be found on this device.

Let me know if you are looking for any test takers.

[Dr_Acula]

http://pandaboard.org/content/usb-do...otloader-omap4

This is a USB based boot utility for OMAP4
Platform. And allows you to boot OMAP4 platform
over USB interface.
Usage: ./usbboot ./aboot.bin u-boot.bin
where: usbboot is the PC side utility listening on
USB bus for asic-id from omap
aboot.bin is the second-stage loader getting
loaded to internal sram of omap
The second-stage loader loads u-boot.bin to
external ddr
(u-boot.bin can be replaced by any binary that
one wishes to execute from ddr)
Project is maintained by Brian Swetland.
Project website:
https://github.com/swetland/omap4boot

Questions:
* Is playbook based on panda board?
*using this method do we need to sign the bootloaders using mshield?
*can we use r own boot loader with this?

[quackquack147]

USB downloader and USB second stage bootloader for OMAP4 | Pandaboard


Questions:
* Is playbook based on panda board?
*using this method do we need to sign the bootloaders using mshield?
*can we use r own boot loader with this?

* Is playbook based on panda board?

yes sort of but not fully. there are minor adjustments. like removing the debug ports and et al. panda board is the 4 layer etched board. i.e. 4 layers of circuit sandwitched one on top of another hence 4 layer.

*using this method do we need to sign the bootloaders using mshield?

unless you work in RIM or some other dictatorial company and or you are dr jekyll and you got someting to hyde, you never need to sign it.

*can we use r own boot loader with this?

yes and no, if you enable HS registers? then yes you may need to sign else you can leave it aside. if its in GP mode then you never need to sign it. because in GP mode you need not sign ever and never.
and yes i build the source from pandaboard and omappedia only i has to stall my work for one reason. i dont have the key hence even if i sign it. it still wont get inside the emmc and which when called by the HS registers will not undergo a sign verification hence failure.
get the idea?
we need the key. so this means?
either we brute force it -> #1.
we can cryptanalyze it, are you that patient? it can take ages to find the reverse logic. -> #2.
we find an exploit which deals with the HS and HS is under NDA and unless you sign a pact with TI you wont get it and thus you find an exploit is 1/10^6 probability. i.e. 1 in a million. apple and others use separate chip. so we can trick or fool it. here rom chip is inside cpu. you need to fool the cpu. and which is why ytou need HS documents released not under NDA but public documents. which is not happening mike. its TI's USP. -> #3
got it?
thanks
-paul