Yep, I know - stupidly I flashed the wrong image to the Shield TV pro (2015) and am stuck in apx mode.
I read somewhere I can flash a hard drive image and lose access to netflix etc due to keys. Can someone point me the way to the guide/image download so I can try and recover with this just now before I throw the box in the bin and get a new one.
Thanks.
das_kern said:
If any of you got any problems with WV L1 DRM the solution is here :
https://forum.xda-developers.com/showpost.php?p=82385839&postcount=554
Click to expand...
Click to collapse
Unfortunately I do not have access to my widevine keys as my hard drive is completely toast. Do you know if the widevine keys are required, or just the DTB fastboot flashing?
Cheers,
B.D.
no you cant. APX mode=ysf. send it back to nvidia
Ok, quick update.
I was able to recover by putting the drive in a USB caddy, In windows 10 I used winhex in admin mode and flashed the first GB of the drive with one of the backups that someone on here provided.
So that's me up and running now. Does anyone know the location on the drive on where the widevine keys are stored? I made a backup of the gig I overwrote before flashing, so I assume they are in that area.
Thanks.
Edit: OK I found them in broken image dump at address 0x2200000
I copied the hex from 0x2200000 (2178336 bytes) and then flashed that to the fixed drive at the same location, now Widevine is back to Level 1, so I guess that's me back up and running to the state before I bricked now.
Well done. Wish I had your tech knowledge.
Well done. Wish I had your tech knowledge.
Click to expand...
Click to collapse
It's not all that complex really to do, as I bricked the files written were to do with the boot procedure wiping out the first stage boot loader. As the Pro (500 GB) version boots from hard drive rather than a chip it was a case of restoring the boot part - which resides at the start of the drive. As I was able to download a dump from the net (and the partition table is stored at the end of the drive - so no chance this would be wiped out), I could flash that boot loader, and then get into adb/fastboot to restore an image downloaded from Nvidia.
Now as it happens, I didn't know where the widevine keys (for DRM) were stored, and I overwrote them when I flashed the backup (and someone else's keys), so Netflix and Amazon prime video didn't work - luckily I made a backup of the first gig of my drive before I started (probably to be even safer I should have just used a spare sata drive to flash to), so I assumed if my keys were lost that they would be in that image dump (which they were). Someone was kind enough to post this:
https://nv-tegra.nvidia.com/gitweb/...11dd2d9103a205c9ed66e695664;hb=rel-29-partner
Which I was able to figure out the exact location of where the EKS partition was (where the keys are stored), so I then extracted those from my dump and flashed them back to my drive. (winhex makes that easy to do).
I've now made a backup of the first part of my drive and the last part - so if ever in the future I mess up, I can restore (brick proof). Also I had a spare 120GB SSD, so I also made a spare drive with the newest shield firmware on so I can just swap drives out if the original drive breaks down.
Instructions are here on how to do that:
https://forum.xda-developers.com/shield-tv/development/nvidia-shield-tv-ssd-t3402580
https://forum.xda-developers.com/shield-tv/general/guide-migrate-to-ssd-hdd-size-satv-pro-t3440195
So really I'm not technical at all as I was just following guides (apart from the winhex stuff).
outstanding work well done my understanding was apx mode was the proprietry nvidia bootloader and this could not be messed with welldone once again
Very interesting! I'm glad I didn't trash my 2015 Shield TV those many months ago!
rockspin said:
Very interesting! I'm glad I didn't trash my 2015 Shield TV those many months ago!
Click to expand...
Click to collapse
If it's a pro (500GB internal drive), it's brick proof. Even APX mode - can't break it.
If you have a spare 500GB drive, you can use that to test - use the guides I put links to - then flash someone else dumped image using those guides (using a sata drive caddy). Then on your original drive - extract the widevine keys - and flash those to the new drive. Once you're up and running - you can clone your working drive back to your orignal drive (that way you'll always have a spare and be brickproof forever).
mrdude2478 said:
If it's a pro (500GB internal drive), it's brick proof. Even APX mode - can't break it.
If you have a spare 500GB drive, you can use that to test - use the guides I put links to - then flash someone else dumped image using those guides (using a sata drive caddy). Then on your original drive - extract the widevine keys - and flash those to the new drive. Once you're up and running - you can clone your working drive back to your orignal drive (that way you'll always have a spare and be brickproof forever).
Click to expand...
Click to collapse
I have the NON pro version, do you think this method will work?
rockspin said:
I have the NON pro version, do you think this method will work?
Click to expand...
Click to collapse
Not with the non pro - the bootloader/software is held on the nand/nor (16GB chip that holds the firmware - I can't remember off the top of my head what type of chip it is). You'd need to find the pinouts of that chip to reprogram it with a hardware programmer.
Another way would be like the way that Nintendo switch is hacked - (purposely put into apx mode), then a modded apx driver loads software from USB (or via usb dongle/computer/chip) which would then allow you to reflash via the Fusée Gelée hack. I think if you go to the switch hacking scene, and visit https://www.ktemkin.com/ - ktemkin was looking for a bricked switch so he/she could write a driver for it for unbricking purposes - he/she has a twitter feed and was asking on there. Maybe you could make
contact and get help on unbricking via software as that would be far easier than removing a chip and flashing it with a programmer.
The difference from booting via a hard drive is that - the software is stored on the drive - not on a chip - so it's easy to recover via a PC. If there's a way to add a hard drive to a 16GB model - that would probably work, but you'd need to compare motherboards to see the difference on how the chip version differs from the HD version - I would imagine both motherboards are similar - if you somehow managed to boot a HD on a 16GB chip model - you could most likely be able to access your flash memory that way to reprogram - but that might be out of your skill level, and the time it would take to do it - you'd most likely be cheaper just buying a new shield.
If I was you though - keep hold of the shield - you may get a modded apx driver at some point in the future and be able to reflash that way.
If you have the 2015 (16GB) version - it could be possible to boot from sata - but you'll need a 500GB drive and a working dump (already posted in this site), and some soldering skills - read this entire page for info on soldering info, adding capacitors - https://www.eevblog.com/forum/reviews/teardown-nvidia-shield-tv/
mrdude2478 said:
Ok, quick update.
I was able to recover by putting the drive in a USB caddy, In windows 10 I used winhex in admin mode and flashed the first GB of the drive with one of the backups that someone on here provided.
So that's me up and running now. Does anyone know the location on the drive on where the widevine keys are stored? I made a backup of the gig I overwrote before flashing, so I assume they are in that area.
Thanks.
Edit: OK I found them in broken image dump at address 0x2200000
I copied the hex from 0x2200000 (2178336 bytes) and then flashed that to the fixed drive at the same location, now Widevine is back to Level 1, so I guess that's me back up and running to the state before I bricked now.
Click to expand...
Click to collapse
First of all , thanks!! I have exact same problem
How did you copy the hex? I'm not sure how to do it . ..
mrdude2478 said:
Ok, quick update.
I was able to recover by putting the drive in a USB caddy, In windows 10 I used winhex in admin mode and flashed the first GB of the drive with one of the backups that someone on here provided.
So that's me up and running now. Does anyone know the location on the drive on where the widevine keys are stored? I made a backup of the gig I overwrote before flashing, so I assume they are in that area.
Thanks.
Edit: OK I found them in broken image dump at address 0x2200000
I copied the hex from 0x2200000 (2178336 bytes) and then flashed that to the fixed drive at the same location, now Widevine is back to Level 1, so I guess that's me back up and running to the state before I bricked now.
Click to expand...
Click to collapse
Thank you for your work.，Can you backup the 1GB data including EKS? My devices widevine keys (for DRM) is Level 3, thanks!!
oldshanshi said:
Thank you for your work.，Can you backup the 1GB data including EKS? My devices widevine keys (for DRM) is Level 3, thanks!!
Click to expand...
Click to collapse
That's not how it works, you have to back up YOUR keys that came on your device hard drive. That's the only way it will match the keys to the hardware on your shield TV.
mrdude2478 said:
...
OK I found them in broken image dump at address 0x2200000
I copied the hex from 0x2200000 (2178336 bytes) and then flashed that to the fixed drive at the same location, now Widevine is back to Level 1, so I guess that's me back up and running to the state before I bricked now.
Click to expand...
Click to collapse
Ok I'm having the same issue you did, bricking the pro with a bad flash.
I'm just editing the hex for my backup to retrieve the keys from my EKS partition. Can I ask you to confirm/clarify ..
1. The blocks you copied are at curser offset 2200000 (I've got that far, I can read the hex stating that the eks partition starts there).
2. You then copied 2178336 bytes of data from that curser offset?
The reason I'm asking is that I can't see any bytes of data around that end curser offset to start a new partition etc. so I want to make sure I get all the EKS data needed.
Thanks, the info you posted here has been really valuable in getting me to this point.
EDIT: Yeah, that all worked out in the end. The actual amount of data in that EKS partition is very minimal, it doesn't use all of those 2178336 bytes at all and I didn't even copy the hex for all of it as most of it was simply empty! Anyway, I've managed to restore my shield with Netflix etc all working so thank you again for sharing this information!
mrdude2478 said:
Ok, quick update.
I was able to recover by putting the drive in a USB caddy, In windows 10 I used winhex in admin mode and flashed the first GB of the drive with one of the backups that someone on here provided.
So that's me up and running now. Does anyone know the location on the drive on where the widevine keys are stored? I made a backup of the gig I overwrote before flashing, so I assume they are in that area.
Thanks.
Edit: OK I found them in broken image dump at address 0x2200000
I copied the hex from 0x2200000 (2178336 bytes) and then flashed that to the fixed drive at the same location, now Widevine is back to Level 1, so I guess that's me back up and running to the state before I bricked now.
Click to expand...
Click to collapse
kirillinfinite said:
First of all , thanks!! I have exact same problem
How did you copy the hex? I'm not sure how to do it . ..
Click to expand...
Click to collapse
Once you've got your backup file it will be in a .bin format, I'm presuming you've got that far. Once you've got that you need to read the hex data with a hex editor, any should do it really. Then you want to go to address 0x2200000 (that's at curser offset 2200000 in hex mode). You'll see a header in the translation window which indicates it's EKS data. You need to copy that data until it stops and there's just zeros).
You then need to open the .bin file that you downloaded which you want to restore (this won't have your eks partition data in it yet) and find the same data with the hex editor as you did before. You then want to overwrite it with the data from your back up. It needs to be copied in the exactly the same location so make sure of that.
Once you've done that you can flash the data using DD commands in Linux and follow the tutorials linked before.
@andy4shure, well done on fixing your Shield, here's some info for future reference:
Shield Pro SSHD Drive Size: 500107862016 bytes (0x7470C06000)
Shield Operating System (7.1):
Start Offset: 0x0
To Offset: 0xD2913BFF (Total Size: 3532733440 bytes)
Widevine Keys Location: (back these up before doing anything - or you'll lose access to widevine level 1)
(Search for Hex: 902100004E56454B5350)
Start Offset: 0x2200000
End Offset: 0x22021FF (Total Size: 8704 bytes)
Partition Table - (Stored at the end of the drive - required on a new drive so the drive can boot and access partitions - you'll need these for a new drive):
From Offset:0x7470C04C00 (sector 976773158)
To Offset: 0x7470C05FFF (Total Size: 5120 bytes)
If you flash someone else's dump, or reflash the firmware - wipe the user data - or you might get stuck on the nvidia logo:
Erase Userdata:
fastboot erase userdata
fastboot erase cache
or
fastboot format userdata
fastboot format cache
After having restored my Shield TV with the shared image and my DRM keys I have realised that there is another key which I needed to restore - the serial number of the device. Not everyone may be bothered about restoring this back to the original as it doesn't affect use of Netflix or any DRM restriced content but there are definitely some use cases. If your device is still under warranty then Nvidia will ask for this (although my warranty is long expired). If you're selling the device and want it to match the packaging serial number then you will have to do this as well. In my case however, I actually had app licences tied to this serial so I needed to restore the original key for that reason.
Now after looking into this serial number a little further it is a 20 character key and although my serial is all numeric I have seen evidence that it can also be alphanumeric.
Also, the key is split into 2 parts...
- The first 14 characters are declared within a partition on the drive and *I think* these are all numeric. As it is declared in a drive partition this means it is editable and can be restored back to the original.
- The last 6 characters seem to be derived from hardware and are not declared anywhere on the drive. This isn't a problem though as this means that they will remain the same no matter if you have the original first part or not!
After looking through the dump of the HDD the serial is actually mentioned in a number of places, however, most seem to be boot logs (mainly from twrp). The actual declaration of the key can be found at address 0x10502156 and the block size to replace is 14 bytes, literally just the first 14 characters of the serial.
Once that is replaced the Shield TV picks up on it straight away on next boot and I didn't need to wipe any cache or anything.
Hopefully this will help someone else that comes across this thread looking for help like I did! Thanks again to @mrdude2478 as I would probably still have a bricked shield if it weren't for him sharing info on how he restored his device.
Andy4Shurr said:
After looking through the dump of the HDD the serial is actually mentioned in a number of places, however, most seem to be boot logs (mainly from twrp). The actual declaration of the key can be found at address 0x10502156 and the block size to replace is 14 bytes, literally just the first 14 characters of the serial.
Click to expand...
Click to collapse
Can you do a screenshot - I checked my dump (or what I restored from), and it doesn't look like a serial at that address: Mine are all at different addresses (but in plain text).
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Thanks.
mrdude2478 said:
Can you do a screenshot - I checked my dump (or what I restored from), and it doesn't look like a serial at that address: Mine are all at different addresses (but in plain text).
Thanks.
Click to expand...
Click to collapse
That definitely doesn't look like mine did, I'll check my dump and take a screenshot ASAP. It could be a few days to a week though, we're doing some work to the spare bedroom where my PC is so I can't get to it at the moment.
I'll update this post when I've got it
@mrdude2478 offset which @Andy4Shurr wrote is correct but it's decimal. Correct hex offset: 0xa0400C
Related
Hello, first than everything I'd like to thank you all in advance... Now to the problem in hand, I recently got 2 CUBOT GT72E Phones, one of them I flashed with was supposed to be a STOCK Firmware:
http://blog.geekbuying.com/index.ph...for-cubot-gt72-mtk6572-dual-core-smart-phone/
I used SP Flash Tool for this, the process went seamlessly and when I got to the final OK Green Circle and then disconnected and tried to turn on my phone, it wouldn't turn on or do anything at all, I inmediatly freaked out and tried to find out how to solve it... So after some reading and learning, trial and error, I have found out the phone is not fully bricked and that there might be a solution.
First I took the battery out, connected the phone and put on the battery again and managed to install "MTK USB Port" Driver, the computer successfully detects the device as it, though when trying to reflash the "STOCK" Firmware or some other Backups and previous "working" Firmwares I stumble on ERROR 4032 - ENABLE DRAM FAILED!
After some more reading I think the reason might be a wrong PRELOADER, or so it seems to be with many other devices of other people that had the same problem.
So then I had an idea, I considered myself an idiot for flashing a PRELOADER without backing up the previous Firmware beforehand, but I have another working phone, exact same one, came on same shipping, same stock ROM, so well I then decided hoping I wouldn't end up bricking the second one, to try and backup the Stock Firmware from my working phone, so after Rooting it I used MTK Droid Tools and successfully made a Backup that included what I'm almost entirely sure is a working PRELOADER.bin, I also downloaded some other Backups and Readbacks that meet the same criteria and that I assume work as well, or so they should.
Now... I feel I'm pretty close to REVIVING this bricked phone, just a few more issues and I'm running out of help online just by reading, I'm hoping someone can directly help my case.
After making the scatter file for my backup of the working phone using the firmware.info, and trying to load it into SP Flash Tools, it fails to load the PRELOADER (Fail to load ROM file: PRELOADER) and it apppears in red letters in list.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
If I double click PRELOADER on list and pick the working file it keeps saying it fails, what can I do to avoid this, or is there any other tool, I have already tried MTK Flash Tools, I manage to load the PRELOADER.bin in it, but as I go ahead and "Download" it just gets stuck on the Download DA 100% Red Bar until it finally stumbles back on ENABLE DRAM FAILED!
I've tried mixing it up and using the other backups that should work as well, I have checked and they fill all the specifications and criteria for the specific phone, and what happens is that, even if I'm able to properly load the Scatter file with the PRELOADER and everything, when I try to flash it, it goes ahead and fills up the Red Bar and immediatly after that it does nothing and just stops, leaving the Format, Firmware Upgrade and Download Buttons enabled again, the Red Bar remains on the bottom but no change at all.
Now what I guess might be the missing piece would be to be able to fully load the backup I made from the working phone to flash it successfully and reviving the phone. I'm also considering I might have the wrong driver or somehow I'm not accessing the download mode on the phone needed to flash it properly. I've heard something about META mode, holding Volume UP and without battery, I've tried that, though PC identifies it with the same driver, so I'm not aware if I should be using another driver, and uninstalling and deleting the previous one first before trying...
So in conclusion I think I need some help with two specific things:
- Pinpoint the Driver needed for my CUBOT GT72E a MT6572 device.
- Find out how to load the backup from working phone into SP Flash Tool.
I'll also leave the detailed specifics of the phone (the working one) from MTK Droid Tools
Hardware : MT6572
Model : CUBOT GT72E
Build number : Z22D_CQ_E2_A_H1.00_V01_CUBOT
Build date UTC : 20131030-152620
Android v : 4.2.2
Baseband v: MOLY.WR8.W1315.MD.WG.MP.V1.P18, 2013/09/07 14:55
Kernel v : 3.4.5 (gcc version 4.6.x-google 20120106 (prerelease) (GCC) ) #1 SMP Wed Oct 30 23:22:42 CST 2013
Uboot build v : -----
LCD Driver IC : 1-HX8379A_wvga_vdo
I don't mean to be pushy but this sort of things tend to get me very anxious and worried, I'd love some help or even replies trying to contribute, I'm doing my best and even if I'm not an expert on Phones and Android Devices, I think I can handle myself with some advice, shouldn't be too hard so just give it a try, any advice or hint will do.
This seems like a good phone, the working one I've been using so far is doing great, it's the first cheap Dual Core device I've seen and I'm really looking forward to developing custom releases for this one, I mean to contribute to this community, but if I can even un-brick this one I don't think I'd be of much help, hurts my pride a bit, I think I can do it, I just need a little help, I'm not giving up just yet so please I'd appreciate you avoid comments like "You blew it" "It's hard bricked, just give it up" or "Return to supplier"
This is a thread that explains how to unbrick MT65XX devices, so before you refer me to it and just paste the link, I've read it and found it really helpful, quoting this thread (Added on Nov 23, 2012 - MT65xx is truly UNBRICKABLE) Please refrain from telling me to give up, I haven't seen a successfull post of Cubot GT72E Unbricking and I intend to be the first one, yet I've seen many posts on both Cubot Forums and other sites of people having bricked their phones by using this "STOCK" Firmware, finding a solution for me is allowing me to help others to solve this as well
http://forum.xda-developers.com/showthread.php?t=1943442
I'll try and contact "rua1" who has developed all this tools and seems like an expert to see if he can help me.
Again thanks for taking the time to read this thread, I look forward to your replies.
BUMP
BUMP (Perhaps I posted too late in the night)
Aedirus said:
BUMP (Perhaps I posted too late in the night)
Click to expand...
Click to collapse
If you have 2 phones then you are in luck.
Use the mktool and sp flash to make a full backup of the working phone and use the back up and to restore the soft bricked one.
Loads of guides on how to do it.
Use this guide to backup the working one forum.xda-developers.com/showthread.php?t=2438752
Managed to unbrick - lost imei & baseband
I managed to revive the phone using the "Stock" firmware, it's scatter file, but writting the preloader from my other phone, the ROM had no Developer Options to enable USB Debugging, I installed an update through recovery and it was now there, rooted it, but now I've lost IMEI and Baseband on it, I also had WARNING NVRAM = ERR 0x00 on Wifi, but managed to solve it by Hex Editting the WIFI file inside data\nvram\APCFG\APRDEB with the right MAC Address.
So far so good, but from all the methods I've seen and found to write IMEI into device, none have worked...
I assume there is a problem regarding "pttycmd1" and lot of files that are on the dev\radio folder of the working phone and that the unbricked one doesn't have, strangely though I can't seem to copy the "radio" folder or any of the files inside it with Root Explorer or any other root file explorer, it simply gets stuck on the first file, permissions on the folder and files are fine... So I don't know what the problem might be or how to sort it out...
Some threads I've seen online suggest flashing the SEC_RO.img from a backup (I'd use the one from the working phone). Yet I'm not sure if I should or could do it, strangely the only Scatter file that works is the one from the "Stock" firmware, should I try loading that scatter file, only ticking SEC_RO.img and loading the one from my backup into it and hit Download?
There should be no harm in it, but I wonder if it would cause both phones to have the same IMEI...
In conclusion and to make it clear, I have revived the phone but it seems somehow NVRAM got formatted and I lost IMEI, Baseband and pretty much everything you'd lose when you format NVRAM...
Any thoughts?
Aedirus said:
I managed to revive the phone using the "Stock" firmware, it's scatter file, but writting the preloader from my other phone, the ROM had no Developer Options to enable USB Debugging, I installed an update through recovery and it was now there, rooted it, but now I've lost IMEI and Baseband on it, I also had WARNING NVRAM = ERR 0x00 on Wifi, but managed to solve it by Hex Editting the WIFI file inside data\nvram\APCFG\APRDEB with the right MAC Address.
So far so good, but from all the methods I've seen and found to write IMEI into device, none have worked...
I assume there is a problem regarding "pttycmd1" and lot of files that are on the dev\radio folder of the working phone and that the unbricked one doesn't have, strangely though I can't seem to copy the "radio" folder or any of the files inside it with Root Explorer or any other root file explorer, it simply gets stuck on the first file, permissions on the folder and files are fine... So I don't know what the problem might be or how to sort it out...
Some threads I've seen online suggest flashing the SEC_RO.img from a backup (I'd use the one from the working phone). Yet I'm not sure if I should or could do it, strangely the only Scatter file that works is the one from the "Stock" firmware, should I try loading that scatter file, only ticking SEC_RO.img and loading the one from my backup into it and hit Download?
There should be no harm in it, but I wonder if it would cause both phones to have the same IMEI...
In conclusion and to make it clear, I have revived the phone but it seems somehow NVRAM got formatted and I lost IMEI, Baseband and pretty much everything you'd lose when you format NVRAM...
Any thoughts?
Click to expand...
Click to collapse
Should be fine, extract the recovery and sec ro from working phone and flash.
Tried it
Well I did it with the SEC_RO.bin, and even managed to flash the NVRAM.bin after some pretty annoying scatter file editting, the only scatter that works is quite more complex than your regular scatter, but I managed to do it, so I know have the same files in the "radio" folder and etc...
Still can't manage to recover IMEI or write it with any tools...
I didn't flash the Recovery.bin from the working phone, would it make any actual difference? Just asking... I'm still quite new to all of this...
Recover IMEI
Any clues or thoughts on how to recover my IMEI?
IMEI doesn't remain
I managed to Write the IMEI with this tool, check this screenshot:
However when I reboot the phone IMEI's remain "Invalid", I'm assuming the phone is rolling it back, when I had problems with the Wifi WARNING ERR 0x00 I had to not only Hex Edit the WIFI file with the correct MAC Address but also change it's permission to only read to prevent the phone from rolling back to wrong file, is there a way to prevent the IMEI not being stuck to the phone? Perhaps formatting the NVRAM before trying to write the IMEI?
HELP PLZ
C'mon people, I'm so close already, just one more push, read the post and help me out, I know I can solve this!
Aedirus said:
C'mon people, I'm so close already, just one more push, read the post and help me out, I know I can solve this!
Click to expand...
Click to collapse
Try this app http://d-h.st/xGU there is a option to write IMEI
http://www.youtube.com/watch?v=4gRAlf--D8E
Doesn't work...
I don't have CDS Information Option, it doesn't appear, I'm guessing it doesn't work for MT6572...
BUMP
BUMP! C'mon guys almost there, with two phones, there must be a way to backup and flash Baseband, NVRAM or w/e is needed from the working phone to the other one, I just haven't stumbled on the right one... MT6572, CUBOT GT72E, Thanks!
Re-BUMP
Re-BUMPING, I hope I'm not abusing it, I just would like for more people to try and give me some advice... Can't be that hard, again I have two phones, one of them is working with the stock firmware and has all the Baseband and IMEI info...
I had the same problem with my Huawei Y511, I can restore with the phone of my wife, this is the same phone! For restore the NVRAM you can use MTK DROID TOOLS the last version, support the MT6572...
spawn784 said:
I had the same problem with my Huawei Y511, I can restore with the phone of my wife, this is the same phone! For restore the NVRAM you can use MTK DROID TOOLS the last version, support the MT6572...
Click to expand...
Click to collapse
Somebody progress?
Of Course!!!
h3ct0r said:
Somebody progress?
Click to expand...
Click to collapse
Yeah Friend! Any question ask me! :good:
hello ! im in the same situation here... ive revived the phone but no imei and can't write it with any tool out there... can anybody give me a hand here?? please !!!
thanks in advance !!
i have finally find a solution to our problem !! i will open a new topic with all the info and the working ( modified ) ROM !!
http://forum.xda-developers.com/showthread.php?t=2656547 check my tutorial
Great to hear!
Next week I'll have the bricked GT72E again in my hands,
I read the url what was placed here to another topic but that file is made for another MTK6572.
Anyone who can supply me the correct file for the GT72E with a small tutorial.
Thnx in advance
BUMP @Aedirus
Can you send me a scatter file, I have the device here but with the tutorials that I found on this topic I can't come further.
Thnx in advance!
Hello all, I have been a lurker for quite a while here. I own an Xperia M (Rooted, Unlocked BL running CM11). I was feeling adventurous and started messing with the partition table hoping to resize the system and data partitions using parted. I was unaware that the bootloader detects such modifications and ended up with a brick.
Just to clarify, this is a hard brick, since the Flashtool and fastboot modes do not work. I do not see the blue LED while trying to start the device in the fastboot mode using the volume rockers. My PC only detects a "QHSUSB_DLOAD" device for which I've installed the drivers and it is now "Qualcomm HS-UDB QDLoader 9008".
However, before I started to work with the partition table, I took a raw backup of the emmc i.e. mmcblk0. This should include the correct partition table and all the partitions (TA, userdata, system etc.). Theoretically (I believe so), if this is reflashed onto the device, an unbrick could be possible. However, so far, I haven't been able to figure out a way to push this image back to the device. I came across QPST and some linux bash scripts but haven't been able to use them successfully.
Has anyone come across such a scenario before? I looked for solutions in other threads but didn't find anything conclusive for Xperia devices. Can someone help me with this? thanks.
randallstevens said:
I was feeling adventurous and started messing with the partition table
Click to expand...
Click to collapse
Hi,
On other forum one user followed suggested by me same theory of remapping paritions as described here to shrink so large /system and increase /userdata
He gotta same brick because deleted 3 partitions and then they was cannot created by any commands, so seems this method not applicable to our phone.
Next he very early quited from recovery without restoring partition table from backup.
Surprisingly, in un-offical service center phone was quickly fixed, seems with JTAG-device.
QHSUSB_DLOAD – this is fall-back low-level mode of CPU that allow access to all partitions just like fastboot
Needed to repair / writing stock ROM at factory.
Can be enabled manually by connecting to PC with holding both volume buttons. How to exit – don't know.
QPST utility not useful because we not have dump in it's proper format. So only Linux our hope.
That user tried to manage with Ubuntu but phone was not recognized. Very likely he went into something wrong.
That's very great that you created backup of whole NAND.
Maybe will be enough restore GPT (partition table), I have one and own per-partitions dump too.
So plan very easy: connecting phone to PC with Ubuntu and restore dump via dd utility.
Partially follow this instruction with modifications because you have full dump.
Connect phone, find where it "attached" (whole nand, not partitions), restore file there.
Be careful with disk naming, you can damage data on HDD.
Bonoboo said:
So plan very easy: connecting phone to PC with Ubuntu and restore dump via dd utility.
Partially follow this instruction with modifications because you have full dump.
Connect phone, find where it "attached" (whole nand, not partitions), restore file there.
Be careful with disk naming, you can damage data on HDD.
Click to expand...
Click to collapse
Hi Bonoboo, thank you for replying.
Unfortunately, Ubuntu isn't able to detect the emmc and therefore, I'm unable to find the "/dev/sdX" node for the device. The phone is being detected only as "Qualcomm, Inc. Gobi Wireless Modem (QDL mode)".
I've seen some threads wherein QPST is first used to enable the partitions detection of emmc. However, as you mentioned, we do not have the necessary MSM8227 HEX file for this.
A windows app called "s1tool.exe" can be used to flash the bootloader files from the FTF, Link to thread. However, a testpoint combination is needed to access the emergency mode. I was unable to find a testpoint for Xperia M.
Is JTAG the only way forward here? Thanks again for the help.
EDIT: Looks like the s1tool I mentioned is device specific, may not work with XM.
randallstevens said:
I'm unable to find the "/dev/sdX" node for the device.
The phone is being detected only as "Qualcomm, Inc. Gobi Wireless Modem (QDL mode)".
Click to expand...
Click to collapse
Yeah, this is not good, same as was with that guy. 1, 2
But here under spoiler I found Perl-script that may open access to eMMC.
Here more info.
Maybe it device-specific too, but anyway try.
UPD: post
just connect your phone to PC (at this time your /var/log/kern.log should update and ttyUSB0 should be added), in terminal, cd to your download folder and run './qd.pl --check', or run 'perl ./qd.pl --check'.
Click to expand...
Click to collapse
Bonoboo said:
Yeah, this is not good, same as was with that guy. 1, 2
But here under spoiler I found Perl-script that may open access to eMMC.
Here more info.
Maybe it device-specific too, but anyway try.
UPD: post
Click to expand...
Click to collapse
Hello Bonoboo,
I've tried using the qd.pl script but I'm not sure which file needs to be sent to the device when using the "qd.pl --pfile X" and the other parameters. The script detects the Qualcomm modem. I've tried uploading the first 256 kilobytes of the dump which should include the partition table but this results in an "Invalid Response" error from the script. Tried uploading the TA and some other partitions, but received the same error. No eMMC access yet. What file do you think the script requires?
randallstevens said:
What file do you think the script requires?
Click to expand...
Click to collapse
Was mentioned some *.hex, that maybe relates with same from QPST.
In threads more info.
Very likely script just not compatible with M.
UPD: it's sounds weird, but try to connect phone in fastboot / flashmode with long holding volume key.
In some cases this really helpful due second "bootloader" (alt_s1sbl2 partition and other).
Bonoboo said:
UPD: it's sounds weird, but try to connect phone in fastboot / flashmode with long holding volume key.
In some cases this really helpful due second "bootloader" (alt_s1sbl2 partition and other).
Click to expand...
Click to collapse
Hi, I tried long-pressing the volume key, it does not seem to work. Thanks for the confirmation about the hex file. It looks like I'll need the right files for the handset, as using hex files of similar chipsets did not help. I'll keep working on it and write back with an update if I'm able to fix it.
I've got the same problem., but unfortunately I didn't make a dump of mmcblk0. There is a way I can get yours? Or a part of it with the interesting data with which I can try figuring out how the qdload.pl script works (maybe leave out userdata cause of its size and the private data).
fakier said:
I've got the same problem., but unfortunately I didn't make a dump of mmcblk0. There is a way I can get yours? Or a part of it with the interesting data with which I can try figuring out how the qdload.pl script works (maybe leave out userdata cause of its size and the private data).
Click to expand...
Click to collapse
Hi fakier, sorry to know you have the same problem. I've sent you a PM with a link to a compressed copy of the first 140 MBs of the raw eMMC dump I made earlier. This should contain all the important partitions besides system and userdata. Note that this also includes my TA partition which probably shouldn't be written to your device.
randallstevens said:
Hi fakier, sorry to know you have the same problem. I've sent you a PM with a link to a compressed copy of the first 140 MBs of the raw eMMC dump I made earlier. This should contain all the important partitions besides system and userdata. Note that this also includes my TA partition which probably shouldn't be written to your device.
Click to expand...
Click to collapse
Thanks, a backup of my TA partition I do have...
Update
Hello folks, after spending a lot of time trying to fix my device with qdloader and QPST, I gave up. Before getting it JTAGed, I wanted to try my luck (again) and approached Sony to claim warranty, since there was a month remaining before its expiry.
My warranty claim was accepted and they replaced the mainboard, though the bootloader was unlocked!! My Xperia is alive and kicking again! Will unlock it soon.
Trying to fix the phone was not a pleasant experience, but I think I learned much along the way. Hope nobody else screws-up the way I did.
Thanks XDA, see ya around! :good:
randallstevens said:
Hello folks, after spending a lot of time trying to fix my device with qdloader and QPST, I gave up. Before getting it JTAGed, I wanted to try my luck (again) and approached Sony to claim warranty, since there was a month remaining before its expiry.
My warranty claim was accepted and they replaced the mainboard, though the bootloader was unlocked!! My Xperia is alive and kicking again! Will unlock it soon.
Trying to fix the phone was not a pleasant experience, but I think I learned much along the way. Hope nobody else screws-up the way I did.
Thanks XDA, see ya around! :good:
Click to expand...
Click to collapse
Dude what was the point of this thread and when you tried to fix your phone did you re flash stock ROM?
Reply to Piravinthb's comment
Piravinthb said:
Dude what was the point of this thread..
Click to expand...
Click to collapse
The point of this thread, dude, was to see if the device could somehow be taken out of the "Qualcomm HS-USB QDLoader 9008" mode, a (very) low-level interface meant for vendors to flash bootloaders and system images on their devices.
..and when you tried to fix your phone did you re flash stock ROM?
Click to expand...
Click to collapse
Had you googled this, you'd know that this mode isn't the same as the Flashtool flash mode or fastboot. No rom, stock or CM, can be flashed before fixing the bootloader itself, which is needed to start the device.
Not much progress could be made here since the bootloader hex files for Qualcomm's OEM tools (QPST) would be needed to fix such a hard brick. Also, the QDloader scripts mentioned earlier were written for a different chipset from the one used in Xperia M.
Cheers, RS.
randallstevens said:
Hello all, I have been a lurker for quite a while here. I own an Xperia M (Rooted, Unlocked BL running CM11). I was feeling adventurous and started messing with the partition table hoping to resize the system and data partitions using parted. I was unaware that the bootloader detects such modifications and ended up with a brick.
Just to clarify, this is a hard brick, since the Flashtool and fastboot modes do not work. I do not see the blue LED while trying to start the device in the fastboot mode using the volume rockers. My PC only detects a "QHSUSB_DLOAD" device for which I've installed the drivers and it is now "Qualcomm HS-UDB QDLoader 9008".
However, before I started to work with the partition table, I took a raw backup of the emmc i.e. mmcblk0. This should include the correct partition table and all the partitions (TA, userdata, system etc.). Theoretically (I believe so), if this is reflashed onto the device, an unbrick could be possible. However, so far, I haven't been able to figure out a way to push this image back to the device. I came across QPST and some linux bash scripts but haven't been able to use them successfully.
Has anyone come across such a scenario before? I looked for solutions in other threads but didn't find anything conclusive for Xperia devices. Can someone help me with this? thanks.
Click to expand...
Click to collapse
hi i have same problem with same adventure , but i was using stock rom with customized kernel with cwm.
i think the solutions are 2
repair hard brick with JTAG or test point and s1tool what is not implemented for xperia m
see http://forum.xda-developers.com/showthread.php?t=2646405 for Z1
my handset will be in trash no free or paid solution or sony service . i'll buy another one
thx
rafik23 said:
my handset will be in trash no free or paid solution or sony service . i'll buy another one
thx
Click to expand...
Click to collapse
Buy a nexus 4 off amazon for 140€
It only takes 2 taps to thank somebody here.
I have created boot recovery files based on Samsung's pdf titled "[14-96]_Boot_Recovery_Guide_Qualcomm_APQ8084_[includes_SM-N910F]__Rev_3.0"
These were done on a 32gb clas 10 microSD, they are imaged to a file via Norton Ghost portable (GHO file.
If your note doesn't boot, that might help. (No charging light, PC detects as QHUSB 9008 mode etc)
Download these GHO files and norton ghost portable.
Insert an empty microSD, Open norton ghost > Local>Image>to Disk the choose your microSD.
Your disk capacity might show up less, but don't worry, you can restore later on with Minitools (Check online on how to use).
I have also created an eMMC backup image of n910p running MM (PE2 build version)
It's a 2gb file, on unzipping with 7zip, around 4gb. (While creating, the output from adb shell is shown in the pick. Not sure if it's an error... is it supposed to be bigger? it was on a clean stock but rooted.. no user content)
Follow this guide http://www.droidsavvy.com/unbrick-qualcomm-mobiles/ to check it's in new 9008 mode.
Then my file might work for you.
All files are at https://mega.nz/#F!qRAGBZDY!_k24QWYaA0We2IQoAgE2Ng
Hi,
and Thanks
Well I have tried these Gho files but no joy. Ghost says file sizes are 19. After writing to the mirco SDCard there is no spaced used and 3 folders that are blank.
I am looking for these files below to recover to use QPST (QFIL) / MiFlash , maybe you can extract them from your device but I have no idea how to do it.
MPRG8084.hex
-8084_msimage.mbn
-rawprogram_32GB.xml
-patch0.xml
-Settings.xml
Thanks
dray_xclusive said:
Hi,
and Thanks
Well I have tried these Gho files but no joy. Ghost says file sizes are 19. After writing to the mirco SDCard there is no spaced used and 3 folders that are blank.
I am looking for these files below to recover to use QPST (QFIL) / MiFlash , maybe you can extract them from your device but I have no idea how to do it.
MPRG8084.hex
-8084_msimage.mbn
-rawprogram_32GB.xml
-patch0.xml
-Settings.xml
Thanks
Click to expand...
Click to collapse
And my phone its same
I hope to find way to solve it
i have also same issue does any one solve ?
an interesting read... curious, under what circumstances would this be more convenient / more practical than a simple odin flash?
is this supposed to recover hard bricks / bad bootloaders?
Took N910P back to Sprint.
I experienced my problem when I was using my secondary (not activated, clean esn) Sprint N910P as an MP3/MP4 player. After the last update which i don't know... it would not boot into the OS after the Sprint splash screen, so it would continue to do this constantly after removing the battery and rebooting even after optimizing apps screen. I researched and found XDAs forums with a lot of How tos, troubleshooting and workarounds. Long story short the Reactivation Lock was not disabled and even using the techniques supplied here I did not have any success.
I took it to the Sprint store and they deactivated my Primary LGV20 and activated the Note 4 so they could service it and then flash it to the current OS. They couldn't flash it and were going to have to send if off to replace the motherboard or replace the phone. The tech told me that this has been happening to Sprint Note 4 phones after an update and since it was a update error there will be not charge to me. Now I had insurance on the Note 4 for six years prior to upgrading to the LGV20, so they had to activate it to be able to service it. I will update their findings when i receive my phone in 7 to 10 days.
I pray this helps someone in my situation, as for me it is bittersweet. I didn't fix my phone but I found a new forum and I can tell everyone here is as passionate about what they do as I am!
- Jacob
I was able to dump the RDC that is provisioned to my 640 XL prototype. I dumped it and renamed it with a .bin extension. Have a couple of questions for those that know more about as I currently know little.
1. What is the RDC file, meaning what does it consist of? Or how is it used?
2. Where is it written when writing it from thor2? Or where is it stored on the phone?
3. Can it be re-used or is it good only for the one device it is provisioned to?
So, I am not sure if "dump" is the correct term to use here, as the command from thor2 would include the option -readrdc which sends it to a file that you choose...So it is reading something from the phone and generating a file...
I opened the file in hex editor but see little about its contents. It is small in size, about 804 bytes. I tried to write it to a different device same model but it failed with a specific error "Certificate error 25 (0x19) (0)"
Thanks.
Where to get prototypes phone?
nate0 said:
I was able to dump the RDC that is provisioned to my 640 XL prototype. I dumped it and renamed it with a .bin extension. Have a couple of questions for those that know more about as I currently know little.
1. What is the RDC file, meaning what does it consist of? Or how is it used?
2. Where is it written when writing it from thor2? Or where is it stored on the phone?
3. Can it be re-used or is it good only for the one device it is provisioned to?
So, I am not sure if "dump" is the correct term to use here, as the command from thor2 would include the option -readrdc which sends it to a file that you choose...So it is reading something from the phone and generating a file...
I opened the file in hex editor but see little about its contents. It is small in size, about 804 bytes. I tried to write it to a different device same model but it failed with a specific error "Certificate error 25 (0x19) (0)"
Thanks.
Click to expand...
Click to collapse
A RDC file is a research and development certificate tied to the device hardware it came with, it will only work on the device it was shipped with, having the same IMEI, hardware serial number and everything unique, you can't use them with other devices at all.
@gus33000
I was almost certain it was unique to the device it was installed in. Does it reside on the boot partition? Thanks for sharing.
nate0 said:
@gus33000
I was almost certain it was unique to the device it was installed in. Does it reside on the boot partition? Thanks for sharing.
Click to expand...
Click to collapse
It's in DPP along with all other provisioned data specific to the phone, you won't be able to do anything with it, just abort, you'll loose time and you'll most likely brick devices.
Was only wanting to know more about it. Thanks again.
nate0 said:
Was only wanting to know more about it. Thanks again.
Click to expand...
Click to collapse
Also as a tip, never overwrite MODEM*, SSD, and DPP with the ones from another phone, it will be destructive for prototypes. I advise you make a full backup of the prototype emmc first, before doing anything, (even if it's just reflashing with a ffu, it's very important to back everything up in mass storage using something like Win32 disk imager), if you however for some reason ever end up with wrong MODEM*, DPP and/or SSD, boot to flash app, switch to download mode, send the emergency payloads for that device RM, and write the rdc, writing it without DLOAD won't work.
DPP is the one nice to work with but never copy and replace, delete and eventually copy over onto it
I need this file
Can you help
Kidsnet said:
I need this file
Click to expand...
Click to collapse
I sold this phone along with dozens of other Lumias and Windows Phones over 2 years ago. I do not own the phone anymore, and I unlikely will find that RDC file if I even backed it up. It would be almost to you unless you are the new owner of this exact device that I dumped it from. Are you planning to use the file for any other reason?
I got a refurbished mobile came locked so i have to fl it since its demanding protection key so i need help
nate0 said:
I sold this phone along with dozens of other Lumias and Windows Phones over 2 years ago. I do not own the phone anymore, and I unlikely will find that RDC file if I even backed it up. It would be almost to you unless you are the new owner of this exact device that I dumped it from. Are you planning to use the file for any other reason
Click to expand...
Click to collapse
Kidsnet said:
I got a refurbished mobile came locked so i have to fl it since its demanding protection key so i need help
Click to expand...
Click to collapse
They are coming already locked, or if there's any tool i can download so that it will vo well with m
Sounds like the lock you are seeing is like a safety net lock. Someone must have had windows on it but had logged in with their account in Windows 10 mobile and set up the Reset protection with their Microsoft account. There is a method to remove that but it is quite dangerous and could ruin the phone.
There is a way to by pass it though as a work around so that you can use the phone but every time you hard reset it it will always lock back.
nate0 said:
Sounds like the lock you are seeing is like a safety net lock. Someone must have had windows on it but had logged in with their account in Windows 10 mobile and set up the Reset protection with their Microsoft account. There is a method to remove that but it is quite dangerous and could ruin the phone.
There is a way to by pass it though as a work around so that you can use the phone but every time you hard reset it it will always lock back.
Click to expand...
Click to collapse
@Kidsnet this is especially a problem for a lumia 640/640 xl. Because what happens is that if they upgraded it to Windows 10 mobile and enabled the protection but you reflash it back to Windows phone 8 you will unlikely set yourself up to not even get a workaround to get in the phone. Since the provisioning of W10M and WP8 are completely different.
I was posting some questions in the "Rooted Jeep Cherokee '14 Uconnect" thread but I've started this new thread for the 17.xx versions because the methods (if we are able to identify them) aren't the same as the 16.33.29 and earlier firmwares...
I am still trying to crack into that unit with the 17.11.07 software. I have a D-Link USB Ethernet but its a HW revision D and I believe I would need a B if we can get ethernet enabled at all.
Also, if we can get Ethernet enabled we will still need to get SSH password or key.
devmihkel said:
For good or for bad NOT everything appears correct, except the running 17.x version... As of now neither the "commercial jailbreak" supports new versions (well yes they were using exactly the same file to start with Also 16.51.x or newer appears to be no go: uconnect-8-4-8-4an-update
EDIT: haven't got 17.09.07 to try, but on 17.11.07 manifest.lua has changed and the last block/ search keyword is "ota_update" instead. Otherwise all the same, image valid after the edit and script.sh gets fired - at least on 16.33.29 that is @HanJ67 Did you actually try to mount installer.iso after the edit and checked /etc/manifest.lua for the end result before?
Click to expand...
Click to collapse
devmihkel said:
Yeah, 2nd attempt is much better as last lua block is correctly terminated and your script might actually run, but unfortunately no successful 17.x runs have been reported so far SWF scripts are not involved in update/jail-breaking run, these ones become relevant only once you are in (and need to enable some app or wifi or navi features etc). Afaik 17.x blocks ethernet dongle usage as well, but let's see if even the USB driver/link gets activated at all?
Click to expand...
Click to collapse
Do you have a 16.33.29 version I can try this on? I'm wondering if it will get me far enough to execute the "manifest.lua HD_Update" hack you and @HanJ67 were discussing.
I've used the 17.43.01, then finally found a 17.11.07 and had no luck there either.
In my latest attempts on the 17.11.07, I was able to hex edit the "ifs-cmc.bin" on the UPD and replaced the SSH-RSA key with my own. I think this bin will be flashed to the MMC during an update.
That SWDL.UPD got past the initial check and rebooted into update mode, but then it fails the second ISO check and loops. I had to use an unmodified image to finish the update and get back up and running.
I keep reading about making changes only after the 2048 Byte mark in the older versions with the "S" at 0x80. Is this still relevant
in later ISO/UPD images and to the second ISO check?
Right now, I'm looking to find a way to disable that check so that my modified .bin will be written to disk? I think this route would work to also modifying and getting WiFi enabled after a flash of the edited image.
If I had I 16.33.29 or similar older UPD version to attempt the HD_UPDATE hack in the Manifest.lua file I would give that a shot to be thorough.
Do You have an idea how to connect by USB2LAN adapter to uConnect ?
Do You know if there is an UART pins on the mainboard ?
itsJRod said:
I was posting some questions in the "Rooted Jeep Cherokee '14 Uconnect" thread but I've started this new thread for the 17.xx versions because the methods (if we are able to identify them) aren't the same as the 16.33.29 and earlier firmwares...
I am still trying to crack into that unit with the 17.11.07 software. I have a D-Link USB Ethernet but its a HW revision D and I believe I would need a B if we can get ethernet enabled at all.
Also, if we can get Ethernet enabled we will still need to get SSH password or key.
Do you have a 16.33.29 version I can try this on? I'm wondering if it will get me far enough to execute the "manifest.lua HD_Update" hack you and @HanJ67 were discussing.
I've used the 17.43.01, then finally found a 17.11.07 and had no luck there either.
In my latest attempts on the 17.11.07, I was able to hex edit the "ifs-cmc.bin" on the UPD and replaced the SSH-RSA key with my own. I think this bin will be flashed to the MMC during an update.
That SWDL.UPD got past the initial check and rebooted into update mode, but then it fails the second ISO check and loops. I had to use an unmodified image to finish the update and get back up and running.
I keep reading about making changes only after the 2048 Byte mark in the older versions with the "S" at 0x80. Is this still relevant
in later ISO/UPD images and to the second ISO check?
Right now, I'm looking to find a way to disable that check so that my modified .bin will be written to disk? I think this route would work to also modifying and getting WiFi enabled after a flash of the edited image.
If I had I 16.33.29 or similar older UPD version to attempt the HD_UPDATE hack in the Manifest.lua file I would give that a shot to be thorough.
Click to expand...
Click to collapse
Hello, any news about it?
hi,
can you explain how to change SSH key in "ifs-cmc.bin" file?
thanks a lot
itsJRod said:
I was posting some questions in the "Rooted Jeep Cherokee '14 Uconnect" thread but I've started this new thread for the 17.xx versions because the methods (if we are able to identify them) aren't the same as the 16.33.29 and earlier firmwares...
I am still trying to crack into that unit with the 17.11.07 software. I have a D-Link USB Ethernet but its a HW revision D and I believe I would need a B if we can get ethernet enabled at all.
Also, if we can get Ethernet enabled we will still need to get SSH password or key.
Do you have a 16.33.29 version I can try this on? I'm wondering if it will get me far enough to execute the "manifest.lua HD_Update" hack you and @HanJ67 were discussing.
I've used the 17.43.01, then finally found a 17.11.07 and had no luck there either.
In my latest attempts on the 17.11.07, I was able to hex edit the "ifs-cmc.bin" on the UPD and replaced the SSH-RSA key with my own. I think this bin will be flashed to the MMC during an update.
That SWDL.UPD got past the initial check and rebooted into update mode, but then it fails the second ISO check and loops. I had to use an unmodified image to finish the update and get back up and running.
I keep reading about making changes only after the 2048 Byte mark in the older versions with the "S" at 0x80. Is this still relevant
in later ISO/UPD images and to the second ISO check?
Right now, I'm looking to find a way to disable that check so that my modified .bin will be written to disk? I think this route would work to also modifying and getting WiFi enabled after a flash of the edited image.
If I had I 16.33.29 or similar older UPD version to attempt the HD_UPDATE hack in the Manifest.lua file I would give that a shot to be thorough.
Click to expand...
Click to collapse
sofro1988 said:
Hello, any news about it?
Click to expand...
Click to collapse
I have not had had much time to work on this.
I actually had an idea last week that brought me back to this. I plan to use a custom flash drive to present an unmodified ISO for verification, then swap nand to an identical image that has been he's edited to enable usb Ethernet and add a custom key for ssh access.
I thought to stack a NAND on top of the original on a is flash drive, then breakout the Chip Enable pin to a switch. I've seen this done for with guys modifying game consoles to be able to run modified firmware.
Once the 2nd NAND is in place I will restore an image of the original nand containing the unmodified update, then hex edit the required portions to allow access after updating.
If this method works, I should be able to pass the verification with the original nand chip, then switch it (hopefully there's a big enough window to do this by hand) then present the modified nand before it begins the flash procedure.
Hopefully someone more intimately familiar with the update scripts can verify I'm not missing anything in the process
Tajadela said:
hi,
can you explain how to change SSH key in "ifs-cmc.bin" file?
thanks a lot
Click to expand...
Click to collapse
I used a hex editor to find the Ssh RSA key and replace it. This passed the initial check to reboot into update mode, but wouldn't pass the full check in update mode. I'm hoping my attempt below will pass that check and still update with the modifications.
itsJRod said:
I used a hex editor to find the Ssh RSA key and replace it. This passed the initial check to reboot into update mode, but wouldn't pass the full check in update mode. I'm hoping my attempt below will pass that check and still update with the modifications.
Click to expand...
Click to collapse
thanks for answer.
I saw an ssh key with the hex editor, but I would like to see exactly what you have replaced.
if it's not too much trouble, it would be interesting to see with some screenshots the changes you've made.
So we could work on two fronts. The idea of the double nand is good, but not very simple to make ...
Just thinking out loud here, when you say it passes the initial check, does it then give you any confirmation of that or any message on the screen before rebooting to upgrade mode?
Sent from my CLT-L09 using Tapatalk
SquithyX said:
Just thinking out loud here, when you say it passes the initial check, does it then give you any confirmation of that or any message on the screen before rebooting to upgrade mode?
Sent from my CLT-L09 using Tapatalk
Click to expand...
Click to collapse
I tried much the same thing -- the swdl.upd is another CDROM filesystem:
martinb$ file swdl.upd
swdl.upd: ISO 9660 CD-ROM filesystem data 'CDROM'
It contains three more .iso files : installer.iso, primary.iso, and secondary.iso
installer.iso is a CDROM image, but is not mountable on my linux system
primary.iso is a CDROM image, and has the usual /bin, /etc/, and /usr filesystem for an install
the /bin directory has one file - update_nand
the /etc directory has the usual mfgVersiontxt, nand_partion.txt, system_etfs_postinstall.txt, system_mmc_postinstall.txt and version.txt
the /usr/share directory is all the firmware for various components - EQ, HD_FIRMWARE, IFS, MMC_IFS_EXTENSION,OTA,SIERRA_WIRELESS,V850, and XM_FIRMWARE
What's interesting to me is that they did update the SIERRA_WIRELESS firmware -- and have done some housecleaning:
Code:
#---------------------------------
# sierra_wireless_disable_flowcontrol.file
# \d == 1 second delay
SAY " Send AT \n"
'' AT\r
OK \d
SAY "Disable flow control\n"
'' at+ifc=0,0\r
OK \d
SAY "Send SMS command CNMI\n"
'' at+cnmi=2,1,0,1,0\r
OK \d
SAY "Clear emergency number list\n"
'' AT!NVENUM=0\r
OK \d
SAY "Set emergency number to 911\n"
'' AT!NVENUM=1,"911"\r
OK \d
SAY "Save Setting\n"
'' at&w\r
OK \d
#---------------------------------
Also in the IFS directory, when you hexedit the ifs-cmc.bin file it reveals another little treat... an SSH root public key ( not as nice as a private key, but hey )
(Sorry about the formatting, this is cut/paste right out of the hex editor)
Code:
ssh-rsa [email protected]
2E..IwU.Q....njle8r9nrJ7h8atg4WfqswU0C0Rk/Ezs/sQs5ZA6ES82MQONjHBd7mw
uo8h0xfj3KeeSHMXCEBpmU26guNE4EqfvdioLFCDUxtvMYswlUZjsvd/NYz9lnUZg2hy
pwzFQjXgSzmHVrHjkKKvq7Rak/85vGZrJKxlvHnowA8JIl1tVNVQjPMNgDDJabaETtfw
LL1KlvAzI81cKOG/3IRn9lU6qyYqyG+zYoza0nN\..7/AtxdL481k81Go5c3NQTnkl2U
68lbu8CpnwrYCU098owLmxdI4kF5UOL4R61ItJuwz30JSESgT..!8RDgM6XEiHUpK9yW
vvRg+vbGWT/oQn0GQ== [email protected]
in /usr/share/MMC_IFS_EXTENSION/bin/cisco.sh and dlink.sh there's another good hint - what adapter you need for USB ethernet
Code:
#!/bin/sh
# Handle an Ethernet connection via the CISCO Linksys USB300M adapter
or
Code:
#!/bin/sh
# Handle an Ethernet connection via the D-Link DUB-E100 adapter
The static IP it brings up if no DHCP is offered is : 192.168.6.1
There's tons more in there -- like the V850 chip has access to the Sierra Wireless CDMA modem, but can configure it for voice calls through the car speakers:
"AT!AVSETPROFILE=8,1,1,0,5" ( embedded in the cmcioc.bin update file )
secondary.iso is a CDROM image and only has /etc/ and /usr
the /etc/ directory has speech_mmc_preinstall.txt and xlets_mmc1_preinstall.txt
the /usr/ directory has /usr/share/speech and /usr/share/xlets ( tons of information about sensors in the car, etc in xlets )
martinbogo1 said:
I tried much the same thing -- the swdl.upd is another CDROM filesystem:
martinb$ file swdl.upd
swdl.upd: ISO 9660 CD-ROM filesystem data 'CDROM'
It contains three more .iso files : installer.iso, primary.iso, and secondary.iso
installer.iso is a CDROM image, but is not mountable on my linux system
primary.iso is a CDROM image, and has the usual /bin, /etc/, and /usr filesystem for an install
the /bin directory has one file - update_nand
the /etc directory has the usual mfgVersiontxt, nand_partion.txt, system_etfs_postinstall.txt, system_mmc_postinstall.txt and version.txt
the /usr/share directory is all the firmware for various components - EQ, HD_FIRMWARE, IFS, MMC_IFS_EXTENSION,OTA,SIERRA_WIRELESS,V850, and XM_FIRMWARE
What's interesting to me is that they did update the SIERRA_WIRELESS firmware -- and have done some housecleaning:
Code:
#---------------------------------
# sierra_wireless_disable_flowcontrol.file
# \d == 1 second delay
SAY " Send AT \n"
'' AT\r
OK \d
SAY "Disable flow control\n"
'' at+ifc=0,0\r
OK \d
SAY "Send SMS command CNMI\n"
'' at+cnmi=2,1,0,1,0\r
OK \d
SAY "Clear emergency number list\n"
'' AT!NVENUM=0\r
OK \d
SAY "Set emergency number to 911\n"
'' AT!NVENUM=1,"911"\r
OK \d
SAY "Save Setting\n"
'' at&w\r
OK \d
#---------------------------------
Also in the IFS directory, when you hexedit the ifs-cmc.bin file it reveals another little treat... an SSH root public key ( not as nice as a private key, but hey )
(Sorry about the formatting, this is cut/paste right out of the hex editor)
Code:
ssh-rsa [email protected]
2E..IwU.Q....njle8r9nrJ7h8atg4WfqswU0C0Rk/Ezs/sQs5ZA6ES82MQONjHBd7mw
uo8h0xfj3KeeSHMXCEBpmU26guNE4EqfvdioLFCDUxtvMYswlUZjsvd/NYz9lnUZg2hy
pwzFQjXgSzmHVrHjkKKvq7Rak/85vGZrJKxlvHnowA8JIl1tVNVQjPMNgDDJabaETtfw
LL1KlvAzI81cKOG/3IRn9lU6qyYqyG+zYoza0nN\..7/AtxdL481k81Go5c3NQTnkl2U
68lbu8CpnwrYCU098owLmxdI4kF5UOL4R61ItJuwz30JSESgT..!8RDgM6XEiHUpK9yW
vvRg+vbGWT/oQn0GQ== [email protected]
in /usr/share/MMC_IFS_EXTENSION/bin/cisco.sh and dlink.sh there's another good hint - what adapter you need for USB ethernet
Code:
#!/bin/sh
# Handle an Ethernet connection via the CISCO Linksys USB300M adapter
or
Code:
#!/bin/sh
# Handle an Ethernet connection via the D-Link DUB-E100 adapter
The static IP it brings up if no DHCP is offered is : 192.168.6.1
There's tons more in there -- like the V850 chip has access to the Sierra Wireless CDMA modem, but can configure it for voice calls through the car speakers:
"AT!AVSETPROFILE=8,1,1,0,5" ( embedded in the cmcioc.bin update file )
secondary.iso is a CDROM image and only has /etc/ and /usr
the /etc/ directory has speech_mmc_preinstall.txt and xlets_mmc1_preinstall.txt
the /usr/ directory has /usr/share/speech and /usr/share/xlets ( tons of information about sensors in the car, etc in xlets )
Click to expand...
Click to collapse
Have you tried connecting to it?
Sent from my iPhone using Tapatalk
sofro1988 said:
Have you tried connecting to it?
Sent from my iPhone using Tapatalk
Click to expand...
Click to collapse
I managed to connect with the cisco adapter (usb / ethernet), but I don't know the root password. is the problem at the moment insurmountable ..
Using a cisco connector, I have gotten the ethernet to come up, but that's it. At the moment, there doesn't seem to be anything I can connect to.
@Tajadela - sounds like you at least were able to either SSH or telnet in to a port... I'm on software version 17.43.01 .. which are you on, and what year vehicle? ( Jeep Grand Cherokee, 2015, Uconnect 8.4AN with the 3G Sierra Aircard modem for Sprint )
martinbogo1 said:
Using a cisco connector, I have gotten the ethernet to come up, but that's it. At the moment, there doesn't seem to be anything I can connect to.
@Tajadela - sounds like you at least were able to either SSH or telnet in to a port... I'm on software version 17.43.01 .. which are you on, and what year vehicle? ( Jeep Grand Cherokee, 2015, Uconnect 8.4AN with the 3G Sierra Aircard modem for Sprint )
Click to expand...
Click to collapse
I connected in telnet on a uconnect 6.5 with firmware 15.xx.xx. You can connect to Uconnect with static IP it brings up if no DHCP is offered is: 192.168.6.1
itsJRod said:
I used a hex editor to find the Ssh RSA key and replace it. This passed the initial check to reboot into update mode, but wouldn't pass the full check in update mode. I'm hoping my attempt below will pass that check and still update with the modifications.
Click to expand...
Click to collapse
after rsa key replaced, do you have recalculate the checksum of UPD file?
have you replaced the first 64 bytes of the file?
thanks
@itsJRod, isn't it that you would like to explain the procedure to replace the RSA key in the swdl file? thank you
Hello,
have you made any progress? I am a bit lost. I put the EU uconnect MY15 to US dodge charger MY16 and Perf Pages were working fine even on 16.16.13, although after upgrade to 17.x (17.46.0.1 right now) I am meeting the problem of expired subscription (which is not possible to have on EU radio).
I am considering basically three solutions:
a) going back to US radio, but modify the language pack/nav/FM frequencies (it is doable, but I do not know how, although I can pay for it relatively less than time invested)
b) downgrade to 16.16.13 - I have no clue how to do it, I tried to put swdl.upd with swdl.iso as and installer.iso with no luck of course.
c) take xlets from KIM2/ of 16.16.13 to KIM23 of 17.46.0.1 secondary.iso - this is probably preferred way but I do not know how to make it to pass ISO validation.
Of course root on uconnect is extremely nice to have but I will be fully satisfied with Perf Pages working again.
Hello.
I'm hoping the community can help me out. I have a RAM 1500 with the RA4 (was running the 17.11.07 software that I got pushed to me OTS style a couple years ago. Since them problems, radio turn on delay, no GPS and cellular phone warning popup.
I was told to do the 18.45 update which I got from driveuconnect.com, but this has essentially bricked my radio with the "bolo update failed" error and it is looping continuously
I have tried many ways to modify the update software's manifest.lua script to try to get rid of the sierra wireless portion by manually editing, hex editing, etc but always get the "please insert the USB card" screen.
Uconnect is obviously completely worthless to help me and the dealer wants me to pay them money to tell me what I already know. I know I can pay 300 and send my radio to infotainemnt.com to get it repaired, but I would like to solve this on my own is possible, because I would like to further modify the software to make it more custom and unique.
From my reading the 17x version keeps you from downgrading to a version that can be hacked easily.
Everything seems like it should be pretty straight forward as I have a lot of experience in programming and embedded devices.
It seems they are validating the ISOs using some mechanism, I believe I have tried all of tricks/methods
I have searched the code to see if I can find the iso MD5 or SHA256 hashes that ioc_check is probably using to figure out I changed somethign but nothing work.
I have even tried the swapping the flash drives after validation but it seems they are using the ISos they already copied to continue the process, I then end u getting some invalid errors or the update just crashes out
I got other updates from the link: http://www.mydrive.ch/
http://www.mydrive.ch/http://www.mydrive.ch/
username: [email protected]
Password: gasolio
Havent tried all of them yet, but pretty sure they wont work, due to the 17x security changes.
Any help would be appreciated grealty, I really dont want to shell out any cash for something a company told me to to and due to their screw up with bricking modems, this is now bricking my radio.
Thanks to all in advance !!!
djmjr77 said:
Hello.
I'm hoping the community can help me out. I have a RAM 1500 with the RA4 (was running the 17.11.07 software that I got pushed to me OTS style a couple years ago. Since them problems, radio turn on delay, no GPS and cellular phone warning popup.
I was told to do the 18.45 update which I got from driveuconnect.com, but this has essentially bricked my radio with the "bolo update failed" error and it is looping continuously
I have tried many ways to modify the update software's manifest.lua script to try to get rid of the sierra wireless portion by manually editing, hex editing, etc but always get the "please insert the USB card" screen.
Uconnect is obviously completely worthless to help me and the dealer wants me to pay them money to tell me what I already know. I know I can pay 300 and send my radio to infotainemnt.com to get it repaired, but I would like to solve this on my own is possible, because I would like to further modify the software to make it more custom and unique.
From my reading the 17x version keeps you from downgrading to a version that can be hacked easily.
Everything seems like it should be pretty straight forward as I have a lot of experience in programming and embedded devices.
It seems they are validating the ISOs using some mechanism, I believe I have tried all of tricks/methods
I have searched the code to see if I can find the iso MD5 or SHA256 hashes that ioc_check is probably using to figure out I changed somethign but nothing work.
I have even tried the swapping the flash drives after validation but it seems they are using the ISos they already copied to continue the process, I then end u getting some invalid errors or the update just crashes out
I got other updates from the link: http://www.mydrive.ch/
http://www.mydrive.ch/http://www.mydrive.ch/
username: [email protected]
Password: gasolio
Havent tried all of them yet, but pretty sure they wont work, due to the 17x security changes.
Any help would be appreciated grealty, I really dont want to shell out any cash for something a company told me to to and due to their screw up with bricking modems, this is now bricking my radio.
Thanks to all in advance !!!
Click to expand...
Click to collapse
Just to follow up for anyone who reads this in the future.
I was able to get my uconnect working again a few minutes ago.
As my previous post stated I got stuck in the "bolo update failed" loop.
I downloaded the UCONNECT_8.4AN_RA4_16.33.29_MY16.exe update from the url posted in my previous comment.
I did the S Byte HEX Mod to the swdl.iso file, loaded it and the swdl.upd file on a thumb drive. Used Hxd on windows. Followed the section in the Uconnect exploitation PDF:
https://www.google.com/url?sa=t&source=web&rct=j&url=http://illmatics.com/Remote%2520Car%2520Hacking.pdf&ved=2ahUKEwjZsOGNl5nyAhWhGVkFHZy2AnAQFnoECAcQAg&usg=AOvVaw0NAi3a1eh-IRd3n1VHv-ys
When I plugged it in, it started with the update process, after the first unit, the screen said the Uconnect had to restart, please wait..
And whalaa my radio worked again!!! It even says it has the 18.45 firmware on it.. go figure.. Navigation still does not work, but thats most likely because the sierra wireless card is bad.
I cannot say for sure the S Byte thing did anything, because I'm not messing with this anymore, almost had to buy a new radio.
I would say try it with out, then with it if it doesn't work.
This could also be a fluke with my particular unit, but at least its something else to try than pay 600+ dollars!!
Good luck to anyone else who goes through this mess!!!
djmjr77 said:
Just to follow up for anyone who reads this in the future.
I was able to get my uconnect working again a few minutes ago.
As my previous post stated I got stuck in the "bolo update failed" loop.
I downloaded the UCONNECT_8.4AN_RA4_16.33.29_MY16.exe update from the url posted in my previous comment.
I did the S Byte HEX Mod to the swdl.iso file, loaded it and the swdl.upd file on a thumb drive. Used Hxd on windows. Followed the section in the Uconnect exploitation PDF:
https://www.google.com/url?sa=t&source=web&rct=j&url=http://illmatics.com/Remote%2520Car%2520Hacking.pdf&ved=2ahUKEwjZsOGNl5nyAhWhGVkFHZy2AnAQFnoECAcQAg&usg=AOvVaw0NAi3a1eh-IRd3n1VHv-ys
When I plugged it in, it started with the update process, after the first unit, the screen said the Uconnect had to restart, please wait..
And whalaa my radio worked again!!! It even says it has the 18.45 firmware on it.. go figure.. Navigation still does not work, but thats most likely because the sierra wireless card is bad.
I cannot say for sure the S Byte thing did anything, because I'm not messing with this anymore, almost had to buy a new radio.
I would say try it with out, then with it if it doesn't work.
This could also be a fluke with my particular unit, but at least its something else to try than pay 600+ dollars!!
Good luck to anyone else who goes through this mess!!!
Click to expand...
Click to collapse
I created an account just to reply to this and All I have to say is you're literally an absolute life saver. I've been working on this every day for two weeks now, trying every trick people said, trying every USB, every format, every version and nothing ever worked from me. Uconnect support was absolutely no help and it was a lot of back-and-forth finger pointing and no you need to reach out to this person between them and the dealership. Dealership tried to charge me for a Proxy Alignment when I asked to just update my damn radio stuck in this loop.
I have a 2015 Jeep Cherokee 8.4AN VP4 NA Head Unit 68238619AJ. I was updating from 17.11.07 to 18.45.01 and got stuck at the step 11 1% and would get a failed sierra wireless every time and then got in that "bolo update failed" loop..Well to fix it just now all I did was download the UCONNECT_8.4AN_RA4_16.33.29_MY16.exe update from the url posted in the previous comment and quick format to FAT32 on a 16GB Micro Center USB extracted the files from 16.33.29 to the USB with 7ZIP, plugged in like normal and BOOM it ran the first step restarted and I had a working radio again showing update 18.45.01.
(So i'm assuming you don't have to do the S Byte thing I didn't even mess with it I just used the 16.33.29 to bypass step 11 since that version only has 14 steps and 18.45.01 was already preloaded from attempting before. My navigation still is the wrong address but I don't care about all that just thankful to have my radio back before my wife killed me for trying to update it by myself. )
I hope this helps someone else one day because it took some deep research and hours on hours of forum hoping to finally find the solution. <3
djmjr77 said:
Just to follow up for anyone who reads this in the future.
I was able to get my uconnect working again a few minutes ago.
As my previous post stated I got stuck in the "bolo update failed" loop.
I downloaded the UCONNECT_8.4AN_RA4_16.33.29_MY16.exe update from the url posted in my previous comment.
I did the S Byte HEX Mod to the swdl.iso file, loaded it and the swdl.upd file on a thumb drive. Used Hxd on windows. Followed the section in the Uconnect exploitation PDF:
https://www.google.com/url?sa=t&source=web&rct=j&url=http://illmatics.com/Remote%2520Car%2520Hacking.pdf&ved=2ahUKEwjZsOGNl5nyAhWhGVkFHZy2AnAQFnoECAcQAg&usg=AOvVaw0NAi3a1eh-IRd3n1VHv-ys
When I plugged it in, it started with the update process, after the first unit, the screen said the Uconnect had to restart, please wait..
And whalaa my radio worked again!!! It even says it has the 18.45 firmware on it.. go figure.. Navigation still does not work, but thats most likely because the sierra wireless card is bad.
I cannot say for sure the S Byte thing did anything, because I'm not messing with this anymore, almost had to buy a new radio.
I would say try it with out, then with it if it doesn't work.
This could also be a fluke with my particular unit, but at least its something else to try than pay 600+ dollars!!
Good luck to anyone else who goes through this mess!!!
Click to expand...
Click to collapse
Do you have another link to download the UCONNECT_8.4AN_RA4_16.33.29_MY16.exe files? I am trying to help a friend of mine they way this helped me. Thank you again for this!