I think now that everyone seems to be empowered about the phone, I've been seeing some posts about thoughts to unlock the bootloader. But I'm finding some ideas have misunderstandings of what the phone is doing.
So I decided to make this post to clear up alot of confusion about the locked bootloader. It's literally most of my notes on the subject. It's almost enough to teach a class on it.
Phone Basics
- The phone's flashable memory space is broken into data sets called partitions
- Each partition is used for a different function on the phone
- Access to the partitions is found in /dev/block/
- The main partitions are mmcblk0 and mmcblk1
- mmcblk0 is the main internal flash memory
- mmcblk0 is broken into parts (e.g. mmcblk0p1, mmcblk0p2, etc...)
- mmcblk1 is the internal sd card
- Notable partitions:
--- Bootloader and Microboot - mmcblk0p1
--- CDT Table - mmcblk0p2
--- Recovery - mmcblk0p10
--- Boot (kernel and ramdisk) - mmcblk0p11
--- System - mmcblk0p12
--- Userdata - mmcblk0p16
- Certain partitions are file system mountable (e.g. System and Userdata)
- Mountable partitions are defined in /proc/mount
- Partitions can be flashed in a number of ways:
--- SBF files via RSD
--- Direct byte-by-byte (e.g. dd if=/scdard/boot.img of=/dev/block/mmcblk0p11)
--- Some partitions via fastboot (e.g. fastboot flash recovery recovery.img)
- SBF files contain data sets known as code groups
- SBF files can be unpacked with MotoAndroid Depacker (http://modmymobile.com/forums/402-general-motorola-android/530781-sbf-depacker-1-3-03-22-2011-a.html)
- When an SBF is flashed with RSD, the code groups flash onto the assigned partitions in flash memory
- Notable code group to partition mappings:
--- Bootloader - CG42 -> mmcblk0p1
--- Microboot - CG47 -> mmcblk0p1
--- CDT Table - CG3 -> mmcblk0p2
--- Recovery - CG58 -> mmcblk0p10
--- Boot (kernel and ramdisk) - CG59 -> mmcblk0p11
--- System - CG60 -> mmcblk0p12
- A "full" SBF does NOT include all CG groups. Not all partitions will be flashed with an SBF.
Digital Signing Basics
- The goal of digital signing is to assert that a set of data is generated by one authorized source
- A digital signature is:
--- An encrypted data string that expresses that a set of data is from one source
--- Comprised of a representation of the data (hash) and a cryptographic component of the signer (private key)
- A digital certificate is a data package that contains the signature of the data set and other cryptographic information that verifies the signature
- A signature verification algorithm verifies that the signed data has not been tampered with:
--- A hash is performed on the data set
--- Using the public key provided from the certificate, a hash is generated from signature
--- If the two hashes match, the signature check passes
- You fail a signature check if:
--- The hashes don't match meaning either the data or the signature has been tampered with
--- The certificate is tampered with via cryptographic checks on the certificate (unknown to us on this phone)
Locked Bootloader
- A bootloader is said to be "locked" when a regular user does not have the complete authority to change all of the phone's flash memory
- In the case of Motorola Tegra-based phones, digital signature (NOT encryption) is used on some partitions. (In some Motorola OMAP phones, some partitions are encrypted. Blah).
- The digital certificate asserts to the phone that the partition is "From Motorola"
- A signed partition has an attached digital certificate near the end of the data
- A signature check algorithm is run at phone startup to check the signed partitions
- In most cases (so far), a failed signature check at bootup leads to a soft brick with the ability to use RSD to SBF
- Notable signed partitions:
--- Bootloader and Microboot - mmcblk0p1
--- CDT Table - mmcblk0p2
--- Recovery - mmcblk0p10
--- Boot (kernel and ramdisk) - mmcblk0p11
Atrix Notes that should apply the DX2
- Unlock-capable bootloaders were found through development leaks. Thus, the bootloaders are signed by Motorola which allows them to be run before the fastboot oem unlock command is issued. To my knowledge, no unlock method for a Motorola phone has been found without a development leak.
- The fastboot oem unlock command issues something in a phone to "burn" a fuse on the board which indicates that the phone is unlocked. The "burn" process is said to be irreversible.
- You can check for the unlock fuse by reviewing /sys/firmware/fuse/ReservedOdm
- Atrix has the same partition map (including signed partitions) as the DX2
- Atrix has the same SBF flashing map (CDT) for the most part with the DX2 (sometimes different CG number but the same map)
Some Notable Results
- A signature failure on the CDT Table partition produces a "Failed to boot 1" error
- A signature failure on the Recovery partition produces a "Failed to boot 2" error
- Locked bootloader prevents flashing of an unsigned partition via fastboot. However, flashing a signed partition with a tampered signature is allowed through fastboot but will fail the signature check upon phone startup.
- Despite having the same partition and certificate format, flashing the Photon 4G boot image causes a signature failure. Certificate must have some kind of identification to determine the uniqueness of the phone (model/carrier).
Potential Unlock/Trick/Bypass Approaches
- Find the command force unlock fuse to be set (unlock command outside of the bootloader fastboot)
- Trick the phone to not check the unlock fuse and always report the phone as unlocked
- Trick the phone never to run the signature checking code
- Trick the phone to assume that the boot and recovery partitions are "regular" partitions and not signed ones
- Find a flaw in the signature such that you can sign the partition as if you are Moto
- Get kexec to work so that a new custom kernel can be loaded after kernel is first loaded (kinda like 2nd-init)
Currently at the end of the day
Bootloader unlocks for Motorola phones have been through development leaks. Motorola's bootloader locking system is quite complicated (and surprisingly well thought out). No Motorola unlock has been achieved solely through the external development community. The best possible chance for an unlock today is through supporting Project Pudding or Project Cheesecake for a development leak. I'm not saying you shouldn't try to work on a locked bootloader workaround. The technical expertise necessary is quite advanced for most people and if you don't understand half the stuff I mentioned, I think your help is best served through something like Project Cheesecake.
For some light reading
Digital Signature on Wikipedia - http://en.wikipedia.org/wiki/Digital_signature
kexec on Wikipedia - http://en.wikipedia.org/wiki/Kexec
EternityProject Kexec method for Motorola Olympus (Atrix 4G) - http://forum.xda-developers.com/showthread.php?t=1079097
Project Pudding: http://forum.xda-developers.com/showthread.php?t=1225072
Project Cheesecake: http://forum.xda-developers.com/showthread.php?t=1226664
I really enjoyed reading this, and appreciate you taking the time to post it.
Sent from my R800x using xda premium
Thank you very much for this compilation of intelligence XD
I enjoyed reading it.
Just wanted to add:
mmcblk0p13 - osh
mmcblk0p15 - cache
mmcblk0p17 - preinstall
So basically we're hosed until someone that works for Moto leaks a deveolpment build (i.e. anonymously posts it on the web?)
nitwit said:
So basically we're hosed until someone that works for Moto leaks a deveolpment build (i.e. anonymously posts it on the web?)
Click to expand...
Click to collapse
Yep that's exactly what it means.
navenedrob said:
Just wanted to add:
mmcblk0p13 - osh
mmcblk0p15 - cache
mmcblk0p17 - preinstall
Click to expand...
Click to collapse
True. But I noted only what I thought was notable. Also, the DX2 has the osh/webtop partition mmcblk0p13 but it has no data or mount point. A possible side project to get a dockless webtop to work for the DX2 from the Atrix or Photon. But I think there are plenty of other items people really want.
---------- Post added at 04:24 PM ---------- Previous post was at 04:08 PM ----------
nitwit said:
So basically we're hosed until someone that works for Moto leaks a deveolpment build (i.e. anonymously posts it on the web?)
Click to expand...
Click to collapse
donlad said:
Yep that's exactly what it means.
Click to expand...
Click to collapse
If that's what you got out of reading all of this, then that's what YOU and only YOU think is the conclusion.
Again, I originally wrote this as a means of informing people since many people reported findings based what they randomly saw with little to no research or thought. It's the same thing for every locked bootloader forum thread on every phone. So I hope this focuses people's thinking about possible attempts on this.
But if can't understand the above and come to the conclusion that "we're screwed", that is totally fine by me as long as you support Project Pudding, Project Cheesecake or any phone initiative to the best of your ability. I could care less if people have a grim outlook on their phone, Moto and/or VZW. As long as you take any available time to do something for this phone. Even knowing all of this for some time, I for one ain't sitting around and praying to the phone gods to start raining custom kernels.
if this helps any here is the config file for the kernel. i havent looked at it yet but i just got it from my phone a few seconds ago
i started reading threw it and kexec is disabled in the kernel so we can forget about that
it would also appear that magic sysrq keys are enabled. would it be possible that they key is in memory? if so would echo m > /proc/sysrq-trigger be useful to dump the memory?
gnuworldorder said:
if this helps any here is the config file for the kernel. i havent looked at it yet but i just got it from my phone a few seconds ago
i started reading threw it and kexec is disabled in the kernel so we can forget about that
it would also appear that magic sysrq keys are enabled. would it be possible that they key is in memory? if so would echo m > /proc/sysrq-trigger be useful to dump the memory?
Click to expand...
Click to collapse
First, can you reupload that file and make sure it is ASCII text? I opened it and it's jarbeled which tells me that it's not in ASCII format.
Second, as soon as I read this, several questions pop into my head:
- Where did you get this file?
- Are you sure it's not in just the ramdisk? Are you sure you can't overwrite it with 2nd-init?
- How do you know it is something the kernel loads/uses? Did you check the seperate post about the compile code and found it's use there (http://forum.xda-developers.com/showpost.php?p=17424418&postcount=20)?
- How do you know that it is disabled in all versions (we have a few development SBFs and update files from Project Pudding and it could be enabled in there)?
- Did you actually test kexec on the phone and determined the phone's response?
I dunno. I'm not one to dismiss kexec on one file alone without testing it on the phone first.
Last, the signature check for the locked bootloader is in the bootloader. So unless there is a log of the bootloader, I seem to lean on dismissing every log file about a key unless you can prove that the bootloader logs it before the kernel comes up. At the same time, there's no reason in the private key would be stored on the phone since digital signing is done in the public key methodology. I dunno. You can try. It just think any log like that is for the many other crypto needs for the operating system which won't help us for the bootloader. There's already a means of pulling anything out of flashable memory (dd if= of= ), we already know what partitions are signed and the signature locations. I don't believe the private key to the signatures are on the phone memory (let alone have a reason to be there).
I got it from /proc/config.gz and yes its what is running its actually a .gz if you want your kernels .config run
cp /proc/config.gz /sdcard/
I tried to echo c to /proc/sysrq-trigger which you force a kexec but all it did was reboot
Sent from my DROID X2 using XDA App
gnuworldorder said:
I got it from /proc/config.gz and yes its what is running its actually a .game if you want your kernels .config run
cp /proc/config.gz /sdcard/
I tried to echo c to /proc/sysrq-trigger which you force a kexec but all it did was reboot
Sent from my DROID X2 using XDA App
Click to expand...
Click to collapse
Interesting. I dunno since I'm not that familiar on the kernel subject. I feel like that it would've been the same result on the Atrix and their kexec project wouldn't have gotten as involved as it did. I glad that you tested it. But I dunno.
I Don't Care What Anybody Else Thinks, Says, Or Does I Know 100% There Is The Possibility To Get Around The Bootloader. Every System Has A Hole Somewhere We Just Need To Find It.
MikeJ92YJ said:
I Don't Care What Anybody Else Thinks, Says, Or Does I Know 100% There Is The Possibility To Get Around The Bootloader. Every System Has A Hole Somewhere We Just Need To Find It.
Click to expand...
Click to collapse
No one ever said there wasn't. All I said was exec was disabled I don't the gingerbreak kernel
Sent from my DROID X2 using XDA App
gnuworldorder said:
No one ever said there wasn't. All I said was exec was disabled I don't the gingerbreak kernel
Sent from my DROID X2 using XDA App
Click to expand...
Click to collapse
Who Said It Was Directed Towards You? It Was Towards The Two Debbie Downers In The Beginning.
MikeJ92YJ said:
Who Said It Was Directed Towards You? It Was Towards The Two Debbie Downers In The Beginning.
Click to expand...
Click to collapse
Maybe clarify that next time
Gnu and mostknown : loving this exchange. Brainstorming.
Sent from my DROID X2 using xda premium
"Burn" a fuse on the board, eh? ...So if someone just points out this fuse to me, and I go to town on that bad boy with a soldering iron, then I can overclock my processor, right? Where the hell did I leave my tiny screwdrivers and soldering iron, I have work to do! XD
Sent from my DROID X2 using Tapatalk
Physically/manually disabling the fuse would be interesting. But how would one distinguish which fuse would be correct? I am assuming it may be identifiable by nearby objects that are used to "burn" the fuse when done by software. Perhaps we should look for a combination of a capacitor and fuse that shouldn't belong together. Maybe they're labeled? Capacitor would be rated higher than the fuse. They're would have to be some other chip in between to trigger the burn action.
Sent from my DROID X2 using XDA App
hapyman said:
Physically/manually disabling the fuse would be interesting. But how would one distinguish which fuse would be correct? I am assuming it may be identifiable by nearby objects that are used to "burn" the fuse when done by software. Perhaps we should look for a combination of a capacitor and fuse that shouldn't belong together. Maybe they're labeled? Capacitor would be rated higher than the fuse. They're would have to be some other chip in between to trigger the burn action.
Sent from my DROID X2 using XDA App
Click to expand...
Click to collapse
I like this kind of thinking. It's like walking up to a fortress only to see they left the back door open.
Correct me if I'm wrong but, isn't eFUSE a TI thing? Patented by IBM, but I've never seen any documentation (I briefly looked around online, brief meaning about an hour) that nVidia actually uses eFUSE. Maybe it's something similar but by a different name. Any insight to this?
Sent from my DROID X2 using xda premium
juhde said:
Correct me if I'm wrong but, isn't eFUSE a TI thing? Patented by IBM, but I've never seen any documentation (I briefly looked around online, brief meaning about an hour) that nVidia actually uses eFUSE. Maybe it's something similar but by a different name. Any insight to this?
Sent from my DROID X2 using xda premium
Click to expand...
Click to collapse
if its patented could you just look it up?
Related
I had a look at
SPDREM_U_01.6.5.1-73_SPU-11-PASS-10_SIGNEuropeAustraliaEMEA_USASPDRRTGB_HWp2b_Service1FF_fastboot.xml
and being a Android noob I have a couple of question.
1.) Why is there a Windows executable, MotoCast-installer (~72MB) included, in the cdrom_signed file?
2.) Would it not be possible to add mods and root-kit into this firmware, e.g. system_signed, webtop_signed or any of the other xxxx_signed files, create a new MD5 checksum for the changed file to be added to SPDREM_U_01.6.5.1-73_SPU-11-PASS-10_SIGNEuropeAustraliaEMEA_USASPDRRTGB_HWp2b_Service1FF_fastboot.xml?
I have seen that those xxxxx_signed files have a signature and assume that the bootloader will check these.
As I said I am a Android noob, but have a little bit of experience with previous Motorola's phones, especially the Linux based Motomagx OS used on a few models. They worked roughly this way.
I am trying to get my head around how Android phones and OS are working.
Rasputin007 said:
2.) Would it not be possible to add mods and root-kit into this firmware, e.g. system_signed, webtop_signed or any of the other xxxx_signed files, create a new MD5 checksum for the changed file to be added to SPDREM_U_01.6.5.1-73_SPU-11-PASS-10_SIGNEuropeAustraliaEMEA_USASPDRRTGB_HWp2b_Service1FF_fastboot.xml?
Click to expand...
Click to collapse
As far as I know, those checksums are just to verify the integrity of the downloaded files, so that a bad connection or storage device can't brick your phone. I think the signatures themselves are stored in the individual partition images and verified the the bootloader at flashing-time.
The bootloader of the Motomagx phones had a RSA protection, which meant that signed codegroups could not be modified. Bizarre really as Linux based Motomagx was OpenSource and Motorola pointed the finger at the providers for that.
So I assume that a locked bootloader behaves the same way.
Once the RSA protection was cracked, we were able to modify the codegroups/firmware, even though we could leave out the signature, we still had to keep to the same byte size of most codegroups and had to keep one "security code", e.g. "00 01".
I guess this still applies now.
Sent from a mobile phone using Tapatalk
Alright, now that Adamoutler finally posted (I was waiting on that) I can now explain what we're going to try to do. You all know the unbrickable mod for a few samsung devices? The guy who did that wants to help us out but he needs a nook tablet. Anyway, what it does is completely disable hardware security and allows the flashing of a new bootloader. That's about as simple as I can make it. I would love to see this happen so hopefully, we can make it.
Question is, who's giving up a tablet?
Note:
Code:
This is not a thread to come in and complain saying that you're going to take it back. That's not our problem nor is it our concern. We need a place where we can have organized information about the bootloader and you telling us "I HATE IT, I need to return it!" doesn't help that.
If someone (me) wanted to get involved in this, how would I go about doing so? I know enough about linux, but nothing about Android programming. Is there somewhere I can start learning? I'd like to contribute to this if I am able.
http://forum.xda-developers.com/showthread.php?t=1366215
+
http://forum.xda-developers.com/showthread.php?t=1378919
I think you can through the service mode to replace the keys which the employee to sign the firmware and tested.
hobbit19 said:
http://forum.xda-developers.com/showthread.php?t=1366215
+
http://forum.xda-developers.com/showthread.php?t=1378919
I think you can through the service mode to replace the keys which the employee to sign the firmware and tested.
Click to expand...
Click to collapse
According to information from TI about the M-Shield security features of this chip, the "secure on-chip keys (E-Fuse) are OEM-specific, one-time-programmable keys accessible only from inside the secure environment for authentication and encryption". Protecting against that kind of key replacement is a big part of how this chip was designed. Finding out the private is likely to be the only way to create valid signed images of our own
Here is the source for that quote.
Indirect said:
Botnets are typically used under illegal reasons / methods. Im not talking about [email protected], im talking about stormworm, etc.
Sent by breaking the sound barrier
Click to expand...
Click to collapse
I know what you mean, but what _I_ mean is that botnets CAN be used for other things than illegal hacking and malicious intent. They can replace a supercomputer, as [email protected] proves. I think I have seen a similar initiatives for cancer research and DNA research, though I don't know the names of those projects.
notes
Hopefully this doesn't lead to any red herrings. I haven't been looking at this stuff very long.
"arm.com" has some info on the processor.
TI licensed the processor design from ARM. It's an ASIC, not really a cpu chip.
You have to agree to a non-disclosure to see the docs on arm.com.
After reading about it, not sure that the dual cpu is actually getting used like folks think. There may be two systems actually running.
The arm docs hint that it may be the hash key that actually gets stored on the asic not a private key and that there may be more than one. TI may have designed in their own protocol which is the M-Shield trademark.
TI doesn't exactly give out much info on it. The ARM site is a lot more informative. It doesn't cost anything to access it other than giving away your email address and agreeing to the nondisclosure.
In particular look for these documents:
DDI0406C_arm_architecture_reference_manual.pdf
DEN0013B_cortex_a_series_PG.pdf (chapter 26)
PRD29-GENC-009492C_trustzone_security_whitepaper.pdf
You can also review the source code for the tablet.
See the following exerpts:
distro\x-loader\lib\board.c
image.image = 2;
image.val = 99;
SEC_ENTRY_Std_Ppa_Call ( PPA_SERV_HAL_BN_CHK , 1 , &image );
if ( image.val == 0 )
{
/* go run U-Boot and never return */
printf("Starting OS Bootloader from %s ...\n", boot_dev_name);
((init_fnc_t *)CFG_LOADADDR)();
}
distro\u-boot\common\cmd_bootm.c
function do_bootm
...
U32 SEC_ENTRY_Std_Ppa_Call (U32 appl_id, U32 inNbArg, ...);
\x-loader\board\omap4430sdp\omap4430sdp.c
...
There are several calls to the SEC_ENTRY_Std_Ppa_Call function.
One (or two) for each image block being loaded.
I think these are the calls to the security layer..
SEC_ENTRY_Std_Ppa_Call ( PPA_SERV_HAL_BN_CHK ,...
They took the crc32 validation out in various places in the code. I suspect that if it is a signed key that if the image doesn't process out to the end key, then the crc2 would have failed anyway.
Has anyone actually checked what the "key" is? Could it be a crc or checksum?
The "_BN_" I assume is for barnes and noble.
Looking at "omap4_hs.h", it looks like that function can do a callback into the secure area and execute up to 32 different functions, though I'm guessing from the list in the file that BN only added two - INIT and CHK.
There is also a reference in that file to "Development CEK". Could this be the private key? Not the hash, just one part of the key? I'm by no means up on crypto algorithms.
/*
Defines from MShield-DK 1.2.0 api_ppa_ref.h
Make sure these align with the existing services in PPA.
*/
// Number of APIs
#define NB_MAX_API_HAL 32
// command / api keys
PPA_SERV_HAL_CPAUTOLOAD
PPA_SERV_HAL_CPINIT
PPA_SERV_HAL_CPSWRV
PPA_SERV_HAL_CPMSV
PPA_SERV_HAL_CPREPORT
PPA_SERV_HAL_CPCEK
PPA_SERV_HAL_TEST_API
PPA_SERV_HAL_BN_INIT
PPA_SERV_HAL_BN_CHK
/* Development CEK */
#define CEK_3 0x01234567 //127_96
#define CEK_2 0x89ABCDEF // 95_64
#define CEK_1 0x11121314 // 63_32
#define CEK_0 0x15161718 // 31_0
Another question I have, what level of GPL does android use?
The simple fact that they linked in the M-Shield function calls may be enough to force the release of that source as well. The latest GPL has a pretty nasty copy left. It may be in that archive already too. I haven't gotten through much of it yet.
And is it true that this tablet has a different wifi chip and thus doesn't have the fm and bluetooth available to it?
The brute force idea might work except that you'd have to do it on a nook tablet. You have to validate a data block using that function call.
Figuring out how to automate it through that security layer might be a bit troublesome. If you could call that function directly, maybe, but I suspect that it is only accessible from one side of the architecture. But that might also be why the tablet has so much memory dedicated to B&N and not split evenly. Maybe the bigger chunk of the memory is all in the secure side?
I have to say the OMAP4 is a pretty neat layout. Has a huge potential for corporate ethical abuse but technically it really is cool. They are going through a lot of hoops to keep this tablet locked down. I found one whitepaper on the netflix issue. Netflix apparently has a whole massive requirements list and this was the first tablet to meet it. I'm not sure netflix isn't overvaluing their product. There are other ways they could have done this versus locking the whole tablet down. They could have put the netflix app as a service in the secure side and just signed that part of the application. They could have still allowed the secondary bootloader in the unsecure area to be whatever the user wanted. I don't think they thought through the ethical notions of it all. But maybe they did and they just want to control something like apple is doing. Apple was defeated once by a lower cost, open architecture. History will repeat itself. It's a shame B&N's didn't go that route instead. If it wasn't for this one issue, they would have had a much better platform to work from than the fire.
Asking others for the info / ideas on bootloader isn't related to development. Hence moved to general
cheers,
I've been sitting back watching this thread for a while now. It's time to stop this foolishness. First off, the first post was started with absolutely no information.. basically 'you know what would be cool?'.. then the rest of the discussion has been a bunch of randomness. Why has not a single person mentioned the datasheets for the processor or memory? Why has Boone posted a memory dump of IROM? This thread contains nothing useful.
UnBrickable mod is the way to go. Put a device in my hands and ill enable it to boot from USB or sdcard. The device uses a hardware initiates boot chain. This chain can be broken at the hardware level.
This is an omap4430 device right?
Give me a device. Rebellos and I will locate the boot mode 5 pin which unlocks the boot from one NAND. We will then require an interceptor bootloader which is where Rebellos specializes. Once we hardware unlock the device and the interceptor bootloader is in place, the device will accept an insecure bootloader flash.
Adam, I can try and get you a nook tablet.
Also, I was waiting for you to post that. I wanted to leave this up to the community to see what could be thought of. Surprised hardware modification never came up. :|
AdamOutler said:
I've been sitting back watching this thread for a while now. It's time to stop this foolishness. First off, the first post was started with absolutely no information.. basically 'you know what would be cool?'.. then the rest of the discussion has been a bunch of randomness. Why has not a single person mentioned the datasheets for the processor or memory? Why has Boone posted a memory dump of IROM? This thread contains nothing useful.
UnBrickable mod is the way to go. Put a device in my hands and ill enable it to boot from USB or sdcard. The device uses a hardware initiates boot chain. This chain can be broken at the hardware level.
This is an omap4430 device right?
Give me a device. Rebellos and I will locate the boot mode 5 pin which unlocks the boot from one NAND. We will then require an interceptor bootloader which is where Rebellos specializes. Once we hardware unlock the device and the interceptor bootloader is in place, the device will accept an insecure bootloader flash.
Click to expand...
Click to collapse
I figured youd be here when the final specs on the Nexus Prime were released, and they used the OMAP4460 which is ironically very simmalir to the OMAP4430.
Thanks for your help and let us know if theres anything we can help you with.
Just for your all's information, Adam will have one in a day or two it has already been shipped.
AdamOutler said:
Give me a device. Rebellos and I will locate the boot mode 5 pin which unlocks the boot from one NAND. We will then require an interceptor bootloader which is where Rebellos specializes. Once we hardware unlock the device and the interceptor bootloader is in place, the device will accept an insecure bootloader flash.
Click to expand...
Click to collapse
I'm curious what you're getting at here.
SYSBOOT[5] selects between boot lists that put external type devices first and internal type devices first. I don't have a NT anymore, but I suspect the boot list is 0b010110, or USB->UART->MMC1->MMC2. Setting SYSBOOT[5] high would change the order to MMC2->USB->UART->MMC1.
All the above boot modes, and all others requiring a config header will need to pass the signature check before the OMAP will boot it.
The only boot mode that doesn't do config header checks is fast external boot (NORflash style), and the TRM has this to say:
The fast external boot is a special memory booting mode, possible only on GP devices. It consists of a blind jump to a code in an external XIP memory device connected to GPMC CS0. Fast external booting is set up by means of the SYSBOOT configuration pins and lets customers create their own booting code.
Click to expand...
Click to collapse
Not applicable of course since this is an HS part, and it would be painful to wire up external memory to boot this way.
Now, if you were to strip out the secure headers from the MLO and u-boot and throw them on a GP 4430 platform like a Pandaboard, you could start hunting for an attack. I can't remember if this u-boot reads any variables from unsecured parts of the flash, but if so there might be some buffer overflow magic waiting to happen.
Not trying to crap on your plans, just making sure you know the score before you commit to this.
Hardware mod
JoeM01 said:
Can this in fact be replicated by someone who is NOT necessarily a dev, but isn't afraid of cracking open a device and going to work with a soldering iron?
Click to expand...
Click to collapse
It depends ...
Assuming for the purpose of discussion that all you need to do is (un)ground an external pin, the difficulty can range from:
Getting access to a ball-grid-array device on a multi-layer board (effectively impossible).
Lifting a pin on a surface-mount chip (easy with the right tools and some skill).
Cutting a trace or soldering a jumper (easy with the right tools and some skill).
(Un)grounding at a solder pad pair (easy).
While the last is not likely, it happens. A case in point:
When IBM released a parallel port board for the original IBM PC, they also released the schematic in the technical reference manual for the PC. The schematic showed that the data buffer buffer chip was bidirectional (74LS374), but its ^OE (output-enable) pin was grounded (active-low logic), in effect making the parallel port output-only.
When the clone-makers replicated the parallel port from the IBM schematic, they all replaced the 74LS374 chip with one that was not bidirectional (a 74LS274, as I recall), saving a tiny bit of money.
However, you you actually had one of IBM's parallel port cards, you noticed that the ground trace on the 74LS374 was not grounded next to the chip (as would normally be expected), but ran a couple inches across the board to a "via", and then grounded in a short trace run. That "via" was exactly 0.1" away from another "via" that was connected to an "unused" bit on the control chip. In other words, a simple trace cut of the final ground run, followed by the installation of standard 0.1' spacing header pins (or a simple jumper) at the "via"s, would convert the parallel port to be bidirectional. Which I did at the time.
Several years later, when IBM modified their BIOS to support bidirectional parallel port operation, they introduced a new parallel port card. The above modification to the old ones worked, but all the clone parallel cards were obsolete.
So, I would not put it outside the realm of possibility that B&N provided a solder pad to be able to disable the signed bootloader feature.
I would also not put it outside the realm of possibility that instead, the hardware modification is very, very difficult, even with the right tools.
Then there is the software issue still to be fixed. Certainly worthy of investigation, but don't get your hopes too high (especially before Christmas).
The best way to think of this hardware unlock, is that the nook is like a building, there are lots of rooms we can get into, but there are also rooms that we cannot. What I assume is adam will get into those rooms, and there might be ways to turn off the power to certain rooms, and or put something in the water. This might allow us to make a software mod that will effect the rooms .
rooms .
pokey9000 said:
I'm curious what you're getting at here.
SYSBOOT[5] selects between boot lists that put external type devices first and internal type devices first. I don't have a NT anymore, but I suspect the boot list is 0b010110, or USB->UART->MMC1->MMC2. Setting SYSBOOT[5] high would change the order to MMC2->USB->UART->MMC1.
All the above boot modes, and all others requiring a config header will need to pass the signature check before the OMAP will boot it.
The only boot mode that doesn't do config header checks is fast external boot (NORflash style), and the TRM has this to say:
Not applicable of course since this is an HS part, and it would be painful to wire up external memory to boot this way.
Now, if you were to strip out the secure headers from the MLO and u-boot and throw them on a GP 4430 platform like a Pandaboard, you could start hunting for an attack. I can't remember if this u-boot reads any variables from unsecured parts of the flash, but if so there might be some buffer overflow magic waiting to happen.
Not trying to crap on your plans, just making sure you know the score before you commit to this.
Click to expand...
Click to collapse
I know the score. We had the same problem to deal with on the Hummingbird processor. What we ended up doing is exploiting a memory jump and redirecting the boot sequence. Rebellos can explain the inner working of the Hummingbird Interceptor Bootloader. Performing a total secure boot would tax the processor greatly and I believe that they likely just have a check in place on the first few bytes. It is possible to modify a bootloader to jump to a memory location which is unsecure. Using this technique, it may be possible to run Galaxy Nexus bootloader or Kindle bootloaders on the device.
So, lets get started with a IROM dump.
I need someone with a rooted device to get a memory dump for me please. This will be a snapshot of the live memory running on the device.
in order to do this:
place this binary on your internal storage http://blog.maurus.be/wp-content/uploads/viewmem
use market app "Mount /system (rw/ro)" https://market.android.com/details?id=com.beansoft.mount_system to mount your system folder RW
use market app "terminal emulator" https://market.android.com/details?id=jackpal.androidterm and type the following
Code:
su
cat /sdcard/viewmem > /system/bin/viewmem
chmod 1777 /system/bin/viewmem
exit terminal and restart terminal app
Now Viewmem is setup.
run this to get a dump
Code:
su
viewmem 0x40030000 0xC000>/sdcard/40030000Dump
and
Code:
viewmem 0x40028000 0xC000>/sdcard/40028000Dump
This will place two 48kb (or 0xC000 in hexidecimal length) files on your sdcard called ########Dump. Put these files onto your desktop into a zip form and upload them here.
I need both of these dumps because the processor manual has an obvious error in it... So I'm asking for the values for the 4460 processor as documented and the 4430 processor which may be the same... however they are documented differently.
These are Internal ROM boot dumps. They are important to figure out what is going on inside a on boot up and may reveal secrets. I'll try to get some strings and other data from these dumps and then I'll pass them over to Rebellos for analysis.
Doing the memory dump now.
Got this error on the first one:
[INFO] Reading 49152 bytes at 0x40030000...
[1] Bus error viewmem 0x40030000 0xC000 >/sdcard/40030000Dump
Only the 2nd one dumped properly.
http://dl.dropbox.com/u/15069134/40028000Dump.zip
AdamOutler said:
I know the score. We had the same problem to deal with on the Hummingbird processor. What we ended up doing is exploiting a memory jump and redirecting the boot sequence. Rebellos can explain the inner working of the Hummingbird Interceptor Bootloader. Performing a total secure boot would tax the processor greatly and I believe that they likely just have a check in place on the first few bytes. It is possible to modify a bootloader to jump to a memory location which is unsecure. Using this technique, it may be possible to run Galaxy Nexus bootloader or Kindle bootloaders on the device.
So, lets get started with a IROM dump.
I need someone with a rooted device to get a memory dump for me please. This will be a snapshot of the live memory running on the device.
in order to do this:
place this binary on your internal storage http://blog.maurus.be/wp-content/uploads/viewmem
use market app "Mount /system (rw/ro)" https://market.android.com/details?id=com.beansoft.mount_system to mount your system folder RW
use market app "terminal emulator" https://market.android.com/details?id=jackpal.androidterm and type the following
Code:
su
cat /sdcard/viewmem > /system/bin/viewmem
chmod 1777 /system/bin/viewmem
exit terminal and restart terminal app
Now Viewmem is setup.
run this to get a dump
Code:
su
viewmem 0x40030000 0xC000>/sdcard/40030000Dump
and
Code:
viewmem 0x40028000 0xC000>/sdcard/40028000Dump
This will place two 48kb (or 0xC000 in hexidecimal length) files on your sdcard called ########Dump. Put these files onto your desktop into a zip form and upload them here.
I need both of these dumps because the processor manual has an obvious error in it... So I'm asking for the values for the 4460 processor as documented and the 4430 processor which may be the same... however they are documented differently.
These are Internal ROM boot dumps. They are important to figure out what is going on inside a on boot up and may reveal secrets. I'll try to get some strings and other data from these dumps and then I'll pass them over to Rebellos for analysis.
Click to expand...
Click to collapse
Adam,
If no one has done this by the time i get home, I will do it for you. I will be on IRC tonight for some of the night and will be able to do whatever you need.
I just did it loglud, no worries.
I'm seeing the following strings in the boot dumps:
Code:
pGpGpGpG
@ABCDEGKJ
CHMMCSD
CHFLASH
CHRAM
PRIMAPP
X-LOADER
CHSETTINGS
KEYS
ISSW
It's not much to go on, but I'd expect to see something on UART from this.
Both of the files are the same. 49.2kB. http://dl.dropbox.com/u/15069134/40028000Dump.zip
however, those are just the complete strings... there's more..
Code:
Texas Instruments
Nokia
Motorola
OMAP4430
NOKIA USB ROM
BLANK
OMAP4430 N/A
N/A
PCB
PCI
R&D
2nd
CH
HLO
MLO
ULO
This NOKIA USB ROM looks interesting.
That's so strange i wonder what it is pointing to because from what i see there's no a single Nokia part in the entire device. You think its just the rom driver they use to flash the OMAP's Rom?
Is there an unlock for the SGS3 yet?
Does the Galaxy_S or the sgs2 unlock code finer work anyone know?
Well.. carriers haven't gotten the device yet so not sure. All the SGS3's that peeps have now come unlocked from Europe.
sent from my Galaxy S III
Coreym said:
Well.. carriers haven't gotten the device yet so not sure. All the SGS3's that peeps have now come unlocked from Europe.
sent from my Galaxy S III
Click to expand...
Click to collapse
+1
Mine was carrier unlocked when I received it (UK on contract with Three via Carphone Warehouse) doesn't even have a CPW CSC.
hmm...yeh...*#7465625# shows all locks off, although I was told when I bought it that it was locked...didn't have another microsim to check. Looks like my handset is like the others mentioned. Happy days...
Hi guys, well my sgs3 is locked and galaxy s unlock and sgs2 unlock respectively from helroz and chainfire dont work.
Im thinking about buying a code... unless someone have some kind of solution ?
Odia was able to unlock my SGS3 succesfully last week. He is still researching stuff using a friends phone this time so he will be releasing a guide on how to do it.
For the moment it has been reported from several users that flashing a custom kernel removes the lock.
Well I don't understand how can this be possible but you are free to try installing omega rom from the dev forum and see if that helps.
m33ts4k0z said:
Odia was able to unlock my SGS3 succesfully last week. He is still researching stuff using a friends phone this time so he will be releasing a guide on how to do it.
For the moment it has been reported from several users that flashing a custom kernel removes the lock.
Well I don't understand how can this be possible but you are free to try installing omega rom from the dev forum and see if that helps.
Click to expand...
Click to collapse
Thanks for the tip but, i've already installed the omega rom and network lock is still ON, and i think Odia did it by editing nv_data.bin.
The thing is, and i think that is why galaxy unlock of helroz doesnt work, is that the offset in the file that determine the network status are not in the same place.
And this is a problem since the app does the unlock by editing that file too.
That is just what i think , and i also dont see why flashing a kernel should remove the lock.
Coreym said:
Well.. carriers haven't gotten the device yet so not sure. All the SGS3's that peeps have now come unlocked from Europe.
sent from my Galaxy S III
Click to expand...
Click to collapse
woo.. galaxy s3 spreading fast.. and i am still with my S2.. hope Xda wont forgot to pull out S2 update..
dw4 said:
Im thinking about buying a code... unless someone have some kind of solution ?
Click to expand...
Click to collapse
For what is worth, I seem to have managed to unlock the phone, but it was not a matter of click & run an application (encrypted hashes)
http://forum.xda-developers.com/showpost.php?p=26917982&postcount=37
I haven't checked with another SIM, just checked network lock [ON] -> [OFF]. At some point while I was playing aroung and trying things I was asked to enter a code, but I didn't know about 0000000, which seems to have worked for some.
the method involved rooting the phone, installing an unbranded firmware and editing /efs/nv_data.bin. In my case, the (encrypted) hashes were stored exactly at the same offset, I don't understand why some people say they are not :?.
* backed up efs
* copied /efs/nv_data.bin to sdcard
* hex edited /efs/nv_data.bin - changed flag 0x01 for network lock to 0x00, copied the 32 byte long encrypted hash from the "off" locks (which were all the same) to the network lock hash, just in case.
* I also reset the MCC/MNC to FFFFFF
* Copied back the /sdcard/nv_data.bin to /efs
* removed the md5 hash (for some reason, the existing md5 did not match the existing file either), but it seems in my case was ok to remove it has been regenerated. Removed the old files
* chmodded /efs/nv_data.bin
* chown radio.radio the file
* rebooted-
It is much better documented elsewhere though - Proceed at your own risk!
---------- Post added at 09:48 AM ---------- Previous post was at 09:41 AM ----------
dw4 said:
And this is a problem since the app does the unlock by editing that file too.
Click to expand...
Click to collapse
As stated above, I managed to, but I did everything manually. At some point I got an unexpected "enter code" dialog that I dismissed (a issue that I solved by installing an unbranded firmware first).
- I found the encrypted hashes at the same location (NET 0x18146e).
- I did *NOT* find PERSO, but I also resetted the MCC/MNC
i also dont see why flashing a kernel should remove the lock.
Click to expand...
Click to collapse
agreed, I fail to see the relationship, but there are so many things I don't know...
Thanks iphdrunk, i'll try this.
Dont know if its a good idea tho since i've got no knowledge whatsoever of hex editing...
Thanks iphdrunk for the explanation! Do you by any chance have the time and mood to write a detailed guide on how to do this progress?
It would be ideal to start a new thread about unlocking and post the guide there. Then Odia may jump in too and help with anything.
Its 100% safe to mess with nv_data.bin because even if you screw up you can always restore a back up of that file and it will start working again.
m33ts4k0z said:
Thanks iphdrunk for the explanation! Do you by any chance have the time and mood to write a detailed guide on how to do this progress?
Click to expand...
Click to collapse
I appreciate the offer and consideration, but I would feel uncomfortable writing such a guide for several reasons: first, it would not be based on my research and findings (I just applied a quite well known method), it is heavily documented elsewhere and, finally, I may not be able to provide the deserved level of support
In any case, the skeleton of the method is here. Read those posts to get a clear overview of the process and then any other comment or disclaimer. Credits given to their respective authors
http://forum.xda-developers.com/showthread.php?t=1064978
http://forum.xda-developers.com/showthread.php?t=761045
What one needs to know is:
- you need a rooted device. Root can be otained either with the unsecure kernel method (cfr. intratech posts) or using recovery. The second one seems to be the most straighforward.
- It is nice to have busybox installed. It allows you to use cp, tar and other unix commands.
- it is mandatory to have a backup of the the /efs folder, which is the mount point of the /dev/block/mmcblk0p3, in ext4. In some guides it is advised to backup the partition at block level, using dd if=/dev/block/mmcblk0p3 of=/sdcard/mmcblk0p3.raw or something. Personally, I found that I could work with regular files. You can use adb shell or a "terminal application" typing su
- You need a backup, specially since this process can mess your IMEI and the nv_data.bin file (!). You may want to read about "Recovering IMEI" which is also related to the /efs folder.
- in that directory there is the famous nv_data.bin file, it is binary, and contains the hashes that are checked to validate unlock codes. There is a bin.md5 file (as a checksum to validate the file integrity) which, for proactical purposes, it will be recreated if missing and, finally, two (hidden) old backup copies. Unlocking is then reduced to either reverse engineering the hashes to find the code (a method which was doable when they where sha1 hashes of a 8 digit password salted with zeros) or, ignoring the hashes simply flip a bit that represents locked to unlocked.
- In recent samsung devices as well as in SGS3, the plain 20-byte long sha1 hashes are now padded and encrypted (I am not sure with which block cypher, aes?), giving you a raw 32 - byte stream that is also stored in the same place. Being able to locate the key to decrypt the encrypted hashes seems to involve patching modem.bin and / or ARM debugging, as per Odia posts.
- This means that, unlike in previous tutorials, reverse engineering the 20-byte hash using CUDA and similar approaches (ighash etc.) will not work: the program will iterate all 8-digit passwords and find that no hash matches the stored one.
- It has also been reported that a branded firmware may interfere with the unlocking process. In my case it did have some effect, although I solved it by installing an unbranded firmware.
- I concluded that, without accessing the key, the way to proceed was to reset the bit that signals that the phone is locked,
- This requires editing the file with an hex editor, looking for the pattern "Ox01, 0x00 etc" as explained above.
- I also copied the encrypted hashes of the "OFF" codes as the encrypted hash of the network lock hash. The reason for this is that the 3 were equal and could be the result of encrypting a very simple password (e.g. 0000000) with the same key.
- At offset 00180069-0018006e, there is a 5-byte stream and a "#" sign, with the carriers MCC / MNC For example 208 01 Orange France. Replace those with 0xFFFFFFFFFF
I am sorry I did not write a full guide, let me restate that the whole process is well documented and you should be able to apply the method if you understand it.
HTH
Well i made some progress, but still it seems that i cant push the edited nv_data file in place.
dw4 said:
Well i made some progress, but still it seems that i cant push the edited nv_data file in place.
Click to expand...
Click to collapse
You dont need to push it. Just copy it to place using root explorer or file explorer.
Sent from my GT-I9300 using XDA
iphdrunk said:
I appreciate the offer and consideration, but I would feel uncomfortable writing such a guide for several reasons: first, it would not be based on my research and findings (I just applied a quite well known method), it is heavily documented elsewhere and, finally, I may not be able to provide the deserved level of support
In any case, the skeleton of the method is here. Read those posts to get a clear overview of the process and then any other comment or disclaimer. Credits given to their respective authors
http://forum.xda-developers.com/showthread.php?t=1064978
http://forum.xda-developers.com/showthread.php?t=761045
What one needs to know is:
- you need a rooted device. Root can be otained either with the unsecure kernel method (cfr. intratech posts) or using recovery. The second one seems to be the most straighforward.
- It is nice to have busybox installed. It allows you to use cp, tar and other unix commands.
- it is mandatory to have a backup of the the /efs folder, which is the mount point of the /dev/block/mmcblk0p3, in ext4. In some guides it is advised to backup the partition at block level, using dd if=/dev/block/mmcblk0p3 of=/sdcard/mmcblk0p3.raw or something. Personally, I found that I could work with regular files. You can use adb shell or a "terminal application" typing su
- You need a backup, specially since this process can mess your IMEI and the nv_data.bin file (!). You may want to read about "Recovering IMEI" which is also related to the /efs folder.
- in that directory there is the famous nv_data.bin file, it is binary, and contains the hashes that are checked to validate unlock codes. There is a bin.md5 file (as a checksum to validate the file integrity) which, for proactical purposes, it will be recreated if missing and, finally, two (hidden) old backup copies. Unlocking is then reduced to either reverse engineering the hashes to find the code (a method which was doable when they where sha1 hashes of a 8 digit password salted with zeros) or, ignoring the hashes simply flip a bit that represents locked to unlocked.
- In recent samsung devices as well as in SGS3, the plain 20-byte long sha1 hashes are now padded and encrypted (I am not sure with which block cypher, aes?), giving you a raw 32 - byte stream that is also stored in the same place. Being able to locate the key to decrypt the encrypted hashes seems to involve patching modem.bin and / or ARM debugging, as per Odia posts.
- This means that, unlike in previous tutorials, reverse engineering the 20-byte hash using CUDA and similar approaches (ighash etc.) will not work: the program will iterate all 8-digit passwords and find that no hash matches the stored one.
- It has also been reported that a branded firmware may interfere with the unlocking process. In my case it did have some effect, although I solved it by installing an unbranded firmware.
- I concluded that, without accessing the key, the way to proceed was to reset the bit that signals that the phone is locked,
- This requires editing the file with an hex editor, looking for the pattern "Ox01, 0x00 etc" as explained above.
- I also copied the encrypted hashes of the "OFF" codes as the encrypted hash of the network lock hash. The reason for this is that the 3 were equal and could be the result of encrypting a very simple password (e.g. 0000000) with the same key.
- At offset 00180069-0018006e, there is a 5-byte stream and a "#" sign, with the carriers MCC / MNC For example 208 01 Orange France. Replace those with 0xFFFFFFFFFF
I am sorry I did not write a full guide, let me restate that the whole process is well documented and you should be able to apply the method if you understand it.
HTH
Click to expand...
Click to collapse
Thanks for the long post anyway . That explains how Odia was so fast
Sent from my GT-I9300 using XDA
I tried the above method, but it seems that the phone alters the nv_data.bin upon reboot.
When i push my edited nv_data.bin to the phone (having removed all backups and the md5 file), reboot the phone, and then pull it back to my computer, here is what I notice:
The network lock byte is back to 0x01, and the MCC/MNC code gets restored somehow. The file also gets altered in a bunch of places (7471 changes if I'm not mistaken).
Code:
cmp -l nv_data.PUSHED nv_data.PULLED | wc -l
7471
Is anyone willing to speculate on what's going on here ?
PS: I haven't flashed a new firmware, but it looks like it's unbranded: (XXLE8/ IMM76D.I9300XXALE8)
Guillaume2x said:
I tried the above method, but it seems that the phone alters the nv_data.bin upon reboot.
Click to expand...
Click to collapse
Just for completeness, set the permissions on the file and chown to radio.radio
Guillaume2x said:
I tried the above method, but it seems that the phone alters the nv_data.bin upon reboot.
When i push my edited nv_data.bin to the phone (having removed all backups and the md5 file), reboot the phone, and then pull it back to my computer, here is what I notice:
The network lock byte is back to 0x01, and the MCC/MNC code gets restored somehow. The file also gets altered in a bunch of places (7471 changes if I'm not mistaken).
Code:
cmp -l nv_data.PUSHED nv_data.PULLED | wc -l
7471
Is anyone willing to speculate on what's going on here ?
PS: I haven't flashed a new firmware, but it looks like it's unbranded: (XXLE8/ IMM76D.I9300XXALE8)
Click to expand...
Click to collapse
I have exactly same problem ... I have omege V4 ROM....
iphdrunk said:
Just for completeness, set the permissions on the file and chown to radio.radio
Click to expand...
Click to collapse
Thanks for your reply. I did, I chowned and chmoded the files right after uploading them, before rebooting the phone. I'm just going to try to flash my phone with another unbranded ROM, just in case my original ROM seems unbranded but actually isn't.
Guillaume2x said:
Thanks for your reply. I did, I chowned and chmoded the files right after uploading them, before rebooting the phone. I'm just going to try to flash my phone with another unbranded ROM, just in case my original ROM seems unbranded but actually isn't.
Click to expand...
Click to collapse
After several checks and discussions, it seems that most users have a problem in the sense that:
- If the md5 file is missing, the nv_data (locked) is restored, deleting the patched one.
- If old backups are deleted, same thing (plus the risk that one may end with the nv_data.bin file with a wrong imei)
- MD5 does not seem to be a simple md5 hash (e.g as in Linux) since the existing md5 bytes one and the result of running the md5 command do not match
- No one has tried the chattr +i nv_data.bin, just to check that the restoration fails.
In my case, I managed to unlock the phone, but I did several things that I cannot easily reproduce. In short, it seems that in my case, the md5 file was somehow regenerated after copying the patched file. In previous posts, I also mentioned that, during one of the tests (without touching the sim card) I was prompted to type the unlock code (and I clicked dismiss). This was also after installing an unbranded phone.
A user via PM suggested checking the nv.log. This is interesting
Code:
Sun Jan 1 00:01:03 2012: MD5 is turned on.
Sun Jan 1 00:01:03 2012: nv_data.bin does not exist.
Sun Jan 1 00:01:03 2012: default NV restored.
Sun Jan 1 00:01:11 2012: Network lock unlock input.
Sun Jan 1 00:01:11 2012: NV data back-up begin.
Sun Jan 1 00:01:11 2012: secondary NV built
Code:
Sun Jan 1 00:05:59 2012: MD5 is turned off on 0
Sun Jan 1 00:00:39 2012: MD5 is turned off on 2
Sun Jan 1 00:09:40 2012: enabling MD5 automatically because it was off temporarily.
Sun Jan 1 00:09:40 2012: NV data back-up begin.
Sun Jan 1 00:09:40 2012: secondary NV built
As suggested there seems to be a way by which md5 check is on or off.
A curious thing is that there seems to be a "date" backward
Code:
Thu May 24 04:12:38 2012: NV data back-uped.
Sun Jan 1 00:00:06 2012: NV data back-up begin.
May to January? -- clock reset?
And finally followed by
Code:
Sun Jan 1 00:02:57 2012: NV data back-uped.
Sun Jun 3 11:46:05 2012: MD5 is turned on
June 3... For some reason, in my case the check was off?
- Can we turn on and off md5 checking?
- If md5 check is off, the nv_data is backed up and the md5 is recreated?
- if md5 check is on, the nv_data md5 is checked and if fail, restored?
Any pointers welcome.... Check your /efs/nv.log file ?
I live in Japan and after more than 6 months I have successfully and permanently rooted both my Sharp 003 SH Galapagos and the 005SH Galapagos (Softbank not Docomo). My next concern is how to SIM unlock. I have been reading the posts about hacking the nv_bin file. I have searched through all of the the files (Root FTP thank you!) but there was no such file. I am happy to send along any screenshots or data files if that helps.
Thanks in advance.
Search Sharp 003SH Root Success and Sharp 005SH Root success on Youtube for more info
Can't really help you. Don't know anything about it. But I would like to know how you ended up rooting this phone of ours.
Its not a file on the filesystem. The sim locking in these phones is in the radio image; which can be accessed when you use the custom build kernel thats in the latest rootkit (I assume thats what you are using).
See the 2ch root/ROM thread for more details, but basically it is done through ADB, manually backing up the "_modem" partition; stripping the spare/ECC bytes and then extracting the radio OS using QualcommDumpAnalyser
I have managed to extract this image, but no idea where to go from there. None of the other device info seems to apply to this (HTC, Samsung, LG, any other Android that has had its sim-lock discovered in the radio)
Advice i got from the guys on 2ch: "Qualcomm's NAND code is neither difficult, nor unique, so if you know what you are looking for its not hard"
003SH 005SH Sim unlock
Thanks very much for giving me a new direction. I'll get started on it right away and let you know how it progresses.
It just sucks that the guys who know how to unlock it are staying quiet, saying its "taboo"
FYI, stripping the Spare/ECC bytes can be done manually (i wrote a C program to do it), but there is an option in the RevSkills app to do it all for you - i recommend doing that.
Of course we face another issue once we find the actual unlock - recalculating the ECC bytes after making the change; the only way to access the radio is with raw data access.
P.S. hope you have warranty on your phones - this is very likely to brick at least one phone until we get it right
---------- Post added at 12:30 PM ---------- Previous post was at 12:24 PM ----------
In the spirit of open cooperation, here are the instructions i was given, translated and simplified
In ADB Shell, type su to get the # prompt, then:
cat /proc/mtd <Enter>
Confirm that you have the "_modem" partition available. If not, you need to reflash with the custom build kernel
Dump the image to file with the following command:
dump_image -r -D -F _modem /sdcard/backupimages/modem.img
Access this with anything as "raw dump" and all blocks will get read as ECC error, so definitely dont do this
ECC positioning is different to Linux, so take care
The following maps out how 512bytes of data and 10 bytes of ECC info are stored in a 528 byte block:
0000 - 01CF (0-463): Data
01D0 - 01D1 (464-465): Unused (0xff)
01D2 - 0201 (466-513): Data
0202 - 020B (514-523): ECC
020C - 020F (524-527): Unused (0xff)
Use RevSkills application to extract the data portions:
Menu⇒Calculators/Generators⇒Android MTD Nand remove Spare and ECC
Extract all of the Data only portions out of the raw dump, and then use QualcommDumpAnalyser to read it and split up the various parts. I did notice that i wasnt able to get the AMSS block out with QualcommDumpAnalyser - i copied that out manually by calculating the byte positions shown in QDA.
003SH bootloader key sequence?
Eternalardor,
I'd be happy to swap information. Perhaps you could shed some light on the question of the bootloader for the Sharp 003SH and 005SH? There seems to be no discernible key sequence (Power+home+Volume up etc.) to access the bootloader. I feel like I've tried them all. Can you tell me this critical piece of information?
Is a form of the USB Jig necessary to access it?
Looking forward to your response.
003SH SIM unlock
Dominik,
Here are the results of the original /proc/mtd (before rooting)
boot
cache
misc
recovery
ipl
system
persist
log
battlog
calllog
ldb
userdata
I don't see the _modem partition. Should I?
I have also included a screenshot of the results showing size. I have most of them backed up as .img files too.
FYI: .img backed up sizes. Perhaps this will help you to ponder where the _modem partition may have gone. Maybe it's been renamed?
boot 11,264KB
cache 3,072KB
misc 1,024KB
recovery 11,264KB
ipl 15,360KB
system 419,840KB
persist 30,720KB
ldb 45,056KB
userdata 405,120KB
There is no bootloader menu AFAIK. If you install the custom kernel, you will have the option of a quasi-recovery mode, by pressing the home button between 7-12 seconds after the Galapagos logo is seen (or was that the Softbank logo)
Anyway, looking at the screenshots, it seems you do not have the custom kernel.
How did you achieve root on your phone?
To do this, you need to use the "003sh_005sh_dm009sh-rootkit" from at least 5/27 (recommend _0614); which is available on the 2ch forums. This includes 2 possible ways of achieving root:
1. A modified standard kernel (boot image), which, when flashed gives you regular root access
2. A custom compiled kernel, which has full root, a bunch of power profiles, and heaps more features (inc that quasi recovery), as well as access to the "_modem" image.
Judging from your youtube videos, you speak some Japanese, so the Japanese menus in the rootkit shouldnt be much trouble.
http://www1.axfc.net/uploader/Si/so/142435
This is what i used.
Go here for help/instructions http://anago.2ch.net/test/read.cgi/android/1337845757/
And dont even think about typing in English on there, or you will be ignored and/or told to go away
This all looks familiar. I have been using the root kit (5/27) to get where I am now - step by blessed step. It was pretty straight forward BUT I have never seen the option to write to the system partition. It is in all the instructions but the only option I have with respect to the system partition is to back it up. I'm confused as to why it doesn't seem to show up for me. I am using a Japanese machine so all the characters are displayed and I can read the instructions but I can't find help anywhere as to why I don't have that particular (and critical) option. I can see a lot of new and cool options in the 6/14 release. I'm excited and would like to get it installed.
I'll let you know how it goes. Thanks for your help .... keep it coming!
And another thing
Could you explain a little more about "having" the custom kernel? Using the root kit, I wrote to the Recovery partition then the Boot partition then rebooted from the Recovery partition and all seemed well. As I said above, I have never been able to write to the System partition despite it appearing in all the instructions. I suspect that is what is holding me back from the latest and greatest custom kernel. Still, I am enjoying all the same functionality that everyone else seems to be enjoying in root. What am I missing?
Eep, you wrote to the boot partition before trying the recovery? Brave!
The steps should be:
Write image to recovery partition;
Then reboot to recovery partition (from the menu) and confirm it all works without errors.
Then write image to boot partition
And then turn off the phone, and reboot (the last part is only my instructions - you could just select "reboot to boot partition" from the menu)
You are doing this on your 005SH right? It should be the same for the 003SH, but i only have the 005SH. In the rootkit there is 2 options when you say "burn custom image":
1 カスタムビルドrootedカーネル（リカバリーキット機能付き）
2 S4080 標準rootedカーネル（簡易リカバリー機能付き）
Q 中止してメインメニューへ戻る
You must do the first one, the CUSTOM rooted kernel, to get any of the really cool features. The second option is only if you just want root access for a particular app or something. AFAIK the second option doesnt even disable MIYABI LSM, which prevents you from mounting the system dir as R/W
But either way, writing to the System dir is not important for what we are doing. You need the Custom kernel, which gives you access to the "_modem"
Edit, i just noticed in your screenshots above, you didnt even get root in ADB shell?
Type
ADB Shell<Enter>
Then type
su<enter>
The cursor should change to a #, this means root. You may get a prompt on the phone from Superuser asking you to give root access to "shell". Once you have this try the cat /proc/mtd again
jcroot003sh,
can you tell me how to root 003sh?
Use the link i provided in my previous post
http://forum.xda-developers.com/showpost.php?p=27989085&postcount=8
You can use a translator if you dont understand Japanese, but the general instructions are in the post above yours
I translated it for a friend, but that is at work, so wont be able to put it up until monday.
DominikB said:
Use the link i provided in my previous post
http://forum.xda-developers.com/showpost.php?p=27989085&postcount=8
You can use a translator if you dont understand Japanese, but the general instructions are in the post above yours
I translated it for a friend, but that is at work, so wont be able to put it up until monday.
Click to expand...
Click to collapse
Thank you for your replying. I will wait for your translated version. You are really a good person.
Progress
I have successfully found and dumped the "_modem" image. Exactly as you stated - forgot the "su" command in ADB. Thanks. The next problem is editing out the code. I am way above my head here so I will do some research before bugging you for a step-by-step for that.
Also, the bootloader worked. I didn't realize how to do it until I read the notes in the 6/14 release. I successfully put a previously dead phone back on it's feet EXACTLY to the point of my current phone simply by backing up and then restoring partitions through the bootloader. Very slick and easy.
Will get to work. I'll be in contact soon with my progress on the SIM unlock.
I have spent a bit of time looking at it, it certainly isnt easy (Certainly isnt a "lock=yes" section). I assume the actual locking portion is encrypted/compressed/or just compiled, because it would be too easy otherwise (be happy to be proven wrong). For starters, i cannot even find my IMEI number in the dump file... I think that this dump only includes the radio code, not the NV RAM which contains the IMEI and SIM Lock status. If that is the case then the solution should be to change the portion of the radio code that queries the NV RAM, so that it doesnt care if the SIM lock is supposed to be applied.
Extracting the spare/ECC bits out should be done with the RevSkills app; extracting the relevant portions, that is a bit of a cludge; QualcommDumpAnalyser can show the start/end positions, but doesnt extract the AMSS part (AFAIK thats where the code will be). You need to use a hex editor to cut that part out manually... And i am still not 100% sure what the block size is on this NAND.
Good luck!
And if there *are* any experienced hackers out there willing to help out, i can offer some monetary help (as will a few of my fellow Japanese smartphone owning friends) as this will be valuable for not just these 2 phones (there is an army of 007SH owners waiting on this unlock)
Shall we give the 007/009 a shot?
I can see mountains of the 007SH on the auction (mostly pink). Perhaps I should pick one up and take it for a spin. I am happy to try to do something to help out for all the help I am receiving.
Or perhaps the 009SH?
How hard would it be to crack the 007? The 009SH looks like it is supported in the latest release kit.
Thoughts?
Currently, the 003/005SH are going to be the easiest, because they have the custom kernel which allows access to the "_modem" image. To do it on the 007SH we need to build a custom kernel (compiled from the sources available on the ktai-dev site), and add the modem access code (this is in the src directory of the rootkit). Not impossible, but i dont have a Linux machine to compile the sources.
However i think that the code will be fairly universal. Once we find it on the 005SH we will know what we are looking for on the 007SH as well. That will make many people happy
Anyway, my 005SH is under warranty/anshin plan so i dont mind if it gets bricked (especially now that we can take nand backups).
First things first though - examining the 005SH modem image. Does anyone know whether the NAND is a 16kb or 128kb block size? Or is it something completely different?
P.S. The DM009SH is just the Disney Mobile version of the 003SH
Linux machine no problem
I have a Linux server running 24/7 so compiling the kernel is easy. Don't let that be the holdup. I'll keep working on the 003SH _modem image.
DominikB,
I can't open this site [anago.2ch.net/test/read.cgi/smartphone/1319287551/] on channel2 for free. This site had been moved to the past-log storehouse. So.... I even can't look at Japanese version for rooting 003sh. It is very helpful if you can show me the steps for rooting 003sh.
Hi! So I'm wondering if anyone know if there is\have been any development for
the Tizzbird Stick N1 (M\G) ?
We have this Android-stick in stock at my store, but I'm not sure if I'm going to get it or not yet. Depends the development, as I'd really like to see the capabilities for it. I believe it's a lowbrand tho. so I might be out of luck.
Anyone know anything?
I searched the forums, and did a google search. Didnt find much.
regards,
Dag M.
Hi there!
I own one of those, and there are a handful of (german-speaking) people activly posting in this forum http://forum.tizzbird-tv.de/ about the Tizzbird N1. - The problem with that forum is that they heavily censor it - as soon as anyone posts info on how to "get in", or if someone asks uncomfortable questions - those posts gets deleted.
They sell it really cheap for 30€ (not all the time, but twice for one day @ redcoon) and although the Wifi-Chip (or the drivers for it) are really crappy, the media player part is really nice.
update: I've did a little research, and here is a little list of relevant links about the tizzbird n1:
==== Marketing Product Pages ====
http://valueplus.co.kr/english/product/product_player_n1.html
http://www.tizzbird.com/eng/index.php?mm_code=719&sm_code=755
http://tizzbird-tv.de/tizzbird/tizzbird-n1.html
==== Official Firmware ====
http://www.tizzbird.com/eng/index.php?mm_code=726&sm_code=727&board_search_head_word=stick+n1
http://download.tizzbird-tv.de/TizzBird_N1G_update_GMS_V3_20_13072719.tzbird
==== German Support Forum (posting info about root-access prohibited) ====
http://forum.tizzbird-tv.de/viewforum.php?f=11
==== GPL-Code for Tizzbird N10, N20 & N30 - but not for N1? ====
http://www.tizzbird.com/eng/index.php?mm_code=752&sm_code=754
==== Kernel Sources ? ====
http://www.cnx-software.com/2012/03...k-n1-android-ics-hdmiusb-dongle-media-player/
http://www.cnx-software.com/2012/07...hips-tcc8925-mini-pcs-cx-01-z900-tizzbird-n1/
https://github.com/cnxsoft/telechips-linux
Yeah, the pretend to be "community friendly and supportive" but once you actually start digging in, they get quite agressive and boot you out.
Anyways, I got a N1 a couple of days myself now (snagged it for 30 bucks at another RedCoon sale ) and I am surprised.
Got it pretty much only to tinker around with it and this thing suits more perfectly for that than I imagined.
Esp. that fact they used a simple SD card as "internal flash storage" - my guess is because a simple SD is cheaper than an actual eMMC flash chip, but it's so cool on so many levels for us.
I already found out how to replace the 4GB SD with a bigger one (have a 16GB in mine ATM).
I'll post some more details about it here later, got a few things I want to test and/or prepare first (thinking of some "easy to use cloning script"), but long story short:
You need to copy the bootloader to the very end (last few blocks) of the SD you want to use.
Once the BL is at the proper place it already boots from the new SD again, to be sure everything is as it's supposed to be one should apply an update via USB (I'm not 100% sure about a possible pointer to the BL that needs to be corrected, which the update does).
After that the partition information has to be edited to make the userdata partition larger and you're done.
thanks for the info HellcatDroid!
It would be great if you could elaborate on how to put the bootloader at the end of the sd-card.
Also I would love to get info how to get root into the stock firmware, that crippled down root-firmware that they allow to exist in the official tizzbird forum doesn't really satisfy my needs
I did it via a hex editor, but it should be doable with a few "dd" commands as well - that's one of the things I still want to try, find the propper dd params to copy the BL over.
If you dumped the original SD into a file using dd, at the very end of the image file you will find the bootloader and the very last block of the SD is a "header" telling the bootrom of the N1 a few things about it, so it can properly locate and load it.
So what you got to do is to copy those last ~230k from the image to the end of the new SD card.
As said, I'll try to write a small shell script that does it.
The rooting is even more easy (Stonecold would kill me if he'd read this, lol):
For when running on Linux (no can do on Windows, as Windows doesn't know the ext4 FS):
Since you got the SD in your PC anyways already, just mount partition 2 (e.g. if the SD is sdc on your PC, mount /dev/sdc2).
That is the partition where the Android system is sitting on.
Then just copy over the files needed for root to where they need to go, chown/chmod them properly, unmount and done
I used the "update-supersu.zip" I had for my Nexus7 to grab the required files.
But I'm planning to make a simple rooting script as well.
So if all goes as planned it'll come down to
- insert original SD
- run script 1
- insert new SD
- run script 2
- to root run script 3
brilliant! I would love to see those scripts
way easier than start tinkering with that stuff myself
One thing I wonder about - over at the official forum you said that a simple dd copy didn't work - is that if the target sd-card is bigger or also for an sd-card of equals size? because with equal size simple dd copy of the sd-card should still work, even if some things need so be exactly at the end.
Yup, just a dd didn't work because the new SD card was larger and the bootloader ended up being somewhere in the middle of the card instead of at the end.
While your thought of "dd to equal size cards" is totally correct, it might still fail due to the fact every card is not 100% exact same size counting down to last byte.
There ususally is a tiny size difference (a few bytes to kbytes) between cards, even if they are supposed to be same, so the bootloader might end up truncated or not exactely at the end.
If, however, the size of the cards is 100% the same, down to the last byte, then yes, a simple dd clone would work.
HellcatDroid said:
... There ususally is a tiny size difference (a few bytes to kbytes) between cards, even if they are supposed to be same, so the bootloader might end up truncated or not exactely at the end. ...
Click to expand...
Click to collapse
Oh! Didn't know that. I thought same marketing size means not the same size they write on the box, but at least the same size between those that are marketed with the same GB numbers on their stickers.
OK, here we go, I slapped together a few scripts for prepping a new (and larger) SD card to work in the N1 and while having the SD in the PC to aplly some root.
* hints at attachment of this post
The scripts might still have problems and not work on any Linux out there, but it's a start.
If there's more people interested and joining in on this I might continue but for now I got what I wanted - more storage and root.
Hi
I think I destroyed my MiniSC cand! The N1 is dead. I tried to insert the card in a linux and gparted did not see anything. What can I do?
thank you for your help
somade said:
Hi
I think I destroyed my MiniSC cand! The N1 is dead. I tried to insert the card in a linux and gparted did not see anything. What can I do?
thank you for your help
Click to expand...
Click to collapse
Could you post how you got there? what did you do to the sd-card that destroyed it?
Hi.
If you got a dump from a working state of the SD you can just dd it back onto the card.
If you don't, it can still be recovered but might need bit more work.
Two options:
find someone who gives you a dump of their card and use the write-card script from my above post to write it to your SD.
Problem with this: a working dump contains copyrighted code, like the bootloader, it technically it's "not OK" to share it
we come up with another script that only contains an "empty" image (i.e. only partitioning information) and that takes the bootloader and recovery from the official update and gets the card into a state that it boots into recovery and lets you install a working system using the official update from USB (option in the recovery menu)
Option 2 would be nicer, IMO.
I'll try to make up said script
Thank you for your immediate answer!.
Actually I dont know what has happened, maybe the sharp instrument I used to remove the plastic cover scratch it...But now when I put it in a card reader the led of the reader switch off and the card is heated!!!. And also when I put it in the N1 the blue led turns off!.
So I bought a new empty micro Sd .
Waiting for your script to partition the new card and then boot in recovery mode and install a firmware....
Because I am not expert to linux please give me a lot of details how to do this.
Thanks again!
HellcatDroid said:
we come up with another script that only contains an "empty" image (i.e. only partitioning information) and that takes the bootloader and recovery from the official update and gets the card into a state that it boots into recovery and lets you install a working system using the official update from USB (option in the recovery menu
Click to expand...
Click to collapse
Do you think the bootloader is even part of the offical updates? wouldn't it be "best practice" to leave the bootloader partition alone as long as possible (and normally firmware updates don't need to change the bootloader)
update: something else I've just found, those might be kernel sources for our Tizzbird N1:
http://www.cnx-software.com/2012/07...hips-tcc8925-mini-pcs-cx-01-z900-tizzbird-n1/
-->
https://github.com/cnxsoft/telechips-linux
Yep, the bootloader is in the update - at least in the 3.20 one.
And yes, usually the bootloader shouldn't be touched because that's usually the one thing that can "perma-brick" Android devices.
However, sometimes the manufacturer updates it (fixing bugs, adding functionality) - on my Nexus7 they updated the bootloader on pretty much every update and also Samsung updates their bootloaders every now and then (and every single update flashes the current one).
Last, not least, on the N1 the bootloader isn't on a partition but at unpartitioned space at the very last blocks of the SD (=> reason for a simple dd to a larger card not booting).
Ohyay at the possible kernel sources!
It'd be so cool if that's really sources able to build a kernel for the N1 with - I think we might be able to even get custom recovery (CWM and the likes) on the N1 if those sources work
OK, while trying to recreate a working SD card w/o using a dump of a working one I found out a few more things - some of them still need figuring out if we wanna do it properly.
There seem to be TWO bootloaders!
A stage1 bootloader of ~1kB size located at the third and second last block of the SD. If it's missing the N1 can't boot and it looks like ARM code (haven't tried to disassamble it yet), I assume the bootrom loads and executes that piece of code which in turn parses the header (see below) and load/starts the stage2 bootloader (the one also found in the FW update).
The very last block of the SD is a "header block" with some information beeing parsed either by the bootrom or (more likely) the stage1 bootloader.
The headerblock contains (among numerous other unkown data) the size of the ("stage2") bootloader (the one that then actually loads and boots the Linux kernel of the Android OS, this is also the one contained in the FW update) and the usable size of the SD card! (everything works fine though if the SD size is wrong and a proper FW update updates the header during writing of the bootloader and also sets the correct size).
Also, the headerblock has a checksum of which I have no clue on how it is generated.
All that is just educated guesses and might be totally off, but for now it looks like it's not too far off.
So, for now we can assume the following boot sequence:
Boot-ROM
-> loads stage1 bootloader from fixed position "SDsize - 3 blocks" (1 block = 512bytes)
stage1 bootloader at fixed position on SD
-> checks checksum of headerblock (?), gets size of stage2 bootloader from headerblock, locates stage2 bootloader based on it's size and loads/executes it
stage2 bootloader on variable position on SD
-> base initialisation of hardware
-> checks for recovery trigger (the red button on the remote control) and boots kernel from partition 6 if trigger present
-> boots kernel from partition 1 if recovery was not triggered
-> enters fastboot mode when booting the kernel fails
Kernel
-> loads base drivers and boots up the system
you're brilliant Hellcat!
And did you also find both bootloader stages inside the firmware updates?
Another question that came to my mind while reading your post (fastboot..)
Is there a way to use the Tizzbird as USB-slave? So to make use of adb and fastboot and such stuff? Okey adb could also be used via network I guess..
somade said:
Hi
I think I destroyed my MiniSC cand! The N1 is dead. I tried to insert the card in a linux and gparted did not see anything. What can I do?
thank you for your help
Click to expand...
Click to collapse
Somade, do you have a linux running on your pc? If no, download and get a knoppix running. and then contact me via pm. I have the original n1 image so no problem to recover the n1.
sebastian.heyn said:
Somade, do you have a linux running on your pc? If no, download and get a knoppix running. and then contact me via pm. I have the original n1 image so no problem to recover the n1.
Click to expand...
Click to collapse
Welcome to our rouge and non-censored Tizzbird N1 forum Sebastian!
I wonder if you found us here, if the German Tizzbird support also already knows about us
update: I just remembered, I've sent you the link as PM over in the official forums, thats how you landed here.
Sharing your sd-card image might be a copyright violation, and if you're profile name is strongly linked to you're real identity you should definitly be cautious with such things on public forums...
kaefert said:
And did you also find both bootloader stages inside the firmware updates?
Click to expand...
Click to collapse
Nope, unfortunately the stage1 bootloader is not in the update :-/
kaefert said:
Is there a way to use the Tizzbird as USB-slave? So to make use of adb and fastboot and such stuff? Okey adb could also be used via network I guess..
Click to expand...
Click to collapse
Yeah, it works, even officially XD
Go to the TizzBird settings -> "System Settings" -> "Advanced Settings"
It has an option "OTG Mode" there, set it to "Debug".
If you have your N1 connected to your PC via the micro-USB port (and hence your PC powering the N1!) you can use ADB and fastboot just as usual
I have not yet tried if that option is persistant, i.e. it survives a power loss.
When booting the kernel fails it should fall back to fastboot mode, so flashing a new kernel w/o pulling the SD should be possible - need to test this a bit more, though.
What works is, if you're rooted and and you fire the command "reboot bootloader" from a root shell, that gets you into fastboot mode no matter what (given you applied above mentioned setting first).
But needing a running system to get into fastboot mode kinda defeats the purpose of it - this aint Ouya which is a total fail when it comes to fastboot XD
---------- Post added at 09:26 AM ---------- Previous post was at 09:05 AM ----------
kaefert said:
I wonder if you found us here, if the German Tizzbird support also already knows about us
Click to expand...
Click to collapse
Eventually they will, I'd say.
And I'd love to see their faces when they do XD