[WANTED] users who have NEVER OTA-d (only used RSD to update) - Atrix 4G General

EDIT
I think the "mystery" has been solved. I feel stupid. When an OTA updates the bootloader, it writes to mmcblk0p1 (write_raw_image() in updater-script) and the very next lines in the script are:
assert(olympus.set_bl_update("00300000"));
assert(olympus.set_mb_update("00040000"));
This must set flags to update the boot loader and micro boot (from mmcblk0p1) either immediately or on the next boot... and, those also look like the file sizes in hex.
Presumably, RSD can just bypass this step and update both directly. So, if you RSD, you have no 'leftover' bootloader image in mmcblk0p1. And if you OTA, it goes through this interim step before the update. You are probably still getting the new bootloader when using RSD (although I don't know how to test this yet.) And if you have NEVER OTA'd, your mmcblk0p1 is blank, because RSD has always bypassed this step, and your device did not ship with this 'shadow' of your bootloader on emmc.
Thanks to everyone who sent me their files!
for posterity:
Intro:
I am investigating the strange but likely possibility that RSD Lite and sbf_flash do not update the bootloader on Atrix, which is live on /dev/block/mmcblk0p1.
This observation comes from the many ATT users who have flashed the 1.8.3 .sbf but remain on a 1.5.7 bootloader (such as myself.) Although the April bootloader is in the 1.8.3 ATT .sbf's CG44 (& CG47), it does not seem we have it.
In contrast, all users I have talked to so far who applied the 1.8.3 OTA (update.zip contains mbm_combo.bin) are on the April 1.8.3 bootloader. It is very easy to tell, by "grep -a <date> mmcblk0p1" as root, where <date> is "Feb" (1.2.6), "Mar" (1.5.7) or "Apr" (1.8.3)
Help wanted!
If you have applied an OTA even once, either manually or automatically, this thread is not for you. Sorry!
But if you are on ATT and have never applied an OTA (on-the-air update[.zip]), and went to 1.5.7 (and possibly 1.8.3) by RSD ONLY, then I am looking for you!
Or if you are a Bell user who flashed Telstra .sbf, since AFAIK you guys have never had any OTAs. Either group can be very helpful to solve this mystery!
If you are one of these users (and have a clue), please do the following:
1. adb shell
2. su
3. dd if=/dev/block/mmcblk0p1 of=/sdcard/mmcblk0p1.img
4. grep -a <date> /sdcard/mmcblk0p1.img
(where date is 'Feb' or 'Mar' or 'Apr')
WARNING
If you **** up that dd line, you will brick your phone for all time and not be able to RSD it back to life. Do NOT swap the 'if' and 'of' lines. Please, if you have any doubt whether you should be doing this, then you shouldn't.
Conclusion
If you think you can help (you have never applied an OTA) and can run lines 1-4 comfortably, then post your result as a reply below! You will probably see some junk from the "grep -a" but what is interesting is if you get:
Code:
grep -a Apr /sdcard/mmcblk0p1.img
Apr 4 2011, 14:57:23console=ttyS0,115200n8 console=null Downloaded code started...
...
or
Code:
grep -a Mar /sdcard/mmcblk0p1.img
Mar 1 2011, 09:20:20console=ttyS0,115200n8 console=null Downloaded code started...
...
or
Code:
grep -a Feb /sdcard/mmcblk0p1.img
<some garbage>
Feb 5 2011, 02:53:29console=ttyS0,115200n8 console=null Downloaded code started...
Thanks!! And if you do get 'Feb 5' ... would you mind sending your mmcblk0p1.img to eval_at_a-trix.net ? (From PC: "adb pull /sdcard/mmcblk0p1.img" and you might have to "chmod 777 /sdcard/mmcblk0p1.img" as root ['su'] in adb or terminal first in order for the 'adb pull' to succeed).
Much appreciated...

Are you sure it's partition 1? What I have is all 0xFF's.

NFHimself said:
Are you sure it's partition 1? What I have is all 0xFF's.
Click to expand...
Click to collapse
What? Your mmcblk0p1 is not your bootloader?? It's not a 3.5mb partition?
I promise you, I have a half dozen dd from users. Here, I'll make you a zip:
http://dl.dropbox.com/u/268607/bl-mystery.zip
They're all the same. Except that those of us who went to 1.8.3 by .sbf have a bootloader that looks like 1.5.7. Bootloader for ATT is mmcblk0p1, CG44+47.

eval-, I wonder if the sbf's were never intended to flash the bootloader because they are not Moto's intended method for update. If they assume nearly everyone is going to update through OTA means (as that nagging on-screen message is impossible to resist indefinitely), then they are likely to assume that an RSD flash will only occur when a customer takes their phone back to the carrier or manufacturer. Is it not the case that our sbf's are merely leaked and only intended for use by the carrier or by Moto themselves? If this were the case, and the returned phone was already brought up to date, then the bootloader would not need to be reflashed through an sbf.

eval- said:
What? Your mmcblk0p1 is not your bootloader?? It's not a 3.5mb partition?
I promise you, I have a half dozen dd from users. Here, I'll make you a zip:
http://dl.dropbox.com/u/268607/bl-mystery.zip
They're all the same. Except that those of us who went to 1.8.3 by .sbf have a bootloader that looks like 1.5.7. Bootloader for ATT is mmcblk0p1, CG44+47.
Click to expand...
Click to collapse
It's ~3.5MB, sure, but it's either protected and returns 0xff or really doesn't exist there. Could be the difference between the SE and NS showing up in rsd lite, dunno.

I applied the OTA to 1.5.7 but used the SBF for 1.8.3 so i was interested in the results even if they weren't helpful to you.
I don't have that Download code started... line, but i do have:
grep -a Mar /sdcard-ext/mmcblk0p1.img
Mar 1 2011, 09:20:20
Marking Runtime Bad block: Chip%u Block=%u
Block dev Physical Ioctl failed. Marking Chip=%d,Blk=%d
Marking Bad block failed forChip=%d Block=%d
Marked blk bad bank = %d, block = %d Rev = %d lba = %d
So not even the 1.2.6 sbf flashes the stock bootloader? Anyway, i think we had dumps of 1.2.6 before we had the SBF so you could get what you want that way...

NFHimself said:
It's ~3.5MB, sure, but it's either protected and returns 0xff or really doesn't exist there. Could be the difference between the SE and NS showing up in rsd lite, dunno.
Click to expand...
Click to collapse
Yeap, fascinating. Here's Nvidia's patents on the secure boot process:
http://worldwide.espacenet.com/publicationDetails/biblio?CC=GB&NR=2457172
Wonder if perhaps our bootloader is encrypted by that strategy (on top of being signed), in some region we cannot directly access from android userspace. Sigh.

Somebody reverse engineer that ****.

Related

[Q] Any trick to replace a (still) working M4G2DE DZ?

Three months ago my DZ bricked. It was supposedly an M4G2DE, since it showed the same symptoms, but I couldn't check. Now I've got a new one and alas, it has M4G2DE for sure.
Code:
C:\android-sdk-windows\platform-tools>adb devices
List of devices attached
SH16VRT00681 device
C:\android-sdk-windows\platform-tools>adb shell
$ cat /sys/devices/platform/msm_sdcc.2/mmc_host/mmc0/mmc0:0001/name
cat /sys/devices/platform/msm_sdcc.2/mmc_host/mmc0/mmc0:0001/name
M4G2DE
It is still untouched/unrooted: since there is a chance it will brick again and rooting voids the warranty, is there any trick to block it or fake-bricking it to ask for a replacement with valid warranty (and hopefully get one with SEM04G)?
jan_axhell said:
Three months ago my DZ bricked. It was supposedly an M4G2DE, since it showed the same symptoms, but I couldn't check. Now I've got a new one and alas, it has M4G2DE for sure.
Code:
C:\android-sdk-windows\platform-tools>adb devices
List of devices attached
SH16VRT00681 device
C:\android-sdk-windows\platform-tools>adb shell
$ cat /sys/devices/platform/msm_sdcc.2/mmc_host/mmc0/mmc0:0001/name
cat /sys/devices/platform/msm_sdcc.2/mmc_host/mmc0/mmc0:0001/name
M4G2DE
It is still untouched/unrooted: since there is a chance it will brick again and rooting voids the warranty, is there any trick to block it or fake-bricking it to ask for a replacement with valid warranty (and hopefully get one with SEM04G)?
Click to expand...
Click to collapse
Yes there is, however you would need root/s-off first. Then you could dd your hboot partition, after that your phone won't even charge.
Sent from my HTC Vision using XDA App
Eh, but that would void warranty, which makes the trick useless .
jan_axhell said:
Eh, but that would void warranty, which makes the trick useless .
Click to expand...
Click to collapse
Well they can't tell it was rooted or s-off if the phone doesn't turn on or even charge (which it wouldn't). Trust me this is the only way to get it done, the reason we need s-off is to get rid of write protection. Then we could destroy the emmc's instuctions for everything, and it looks like the chip went bad
Ah, now I understand. Ok, thanks, I was thinking about something less destructive from which I can rollback in case of warranty problems, but I'll keep this method in mind.
jan_axhell said:
Ah, now I understand. Ok, thanks, I was thinking about something less destructive from which I can rollback in case of warranty problems, but I'll keep this method in mind.
Click to expand...
Click to collapse
I understand . It makes me die a little inside to kill a G2, but I'm realistic enough to realize people have to look after their best intrests. I'll keep and eye on his thread, or you can pm me if you want the dd command.
Meh.. don't hold your breath, I'm not that brave. But ok, should I decide to do it, I'll PM you. Thanks!
Currently my phone will only go to hboot (PC10IMG flashing seems to work) and fastboot, all else leads to HTC splash screen (green htc on white background).
As I am S-Off sending it in for warranty in France will not work (according to various posts found by googling) I was wondering if it would it be possible to use PC10IMG.img to flash a hboot that is nonsense to completely kill the boot loader thereby bypassing the -off status that is visible in bootloader ?
if fastboot still allows you to write on the emmc then just completley brick your phone making it impossible to even see the bootloader screen. just make sure you are completley under warranty for they will have to give you a new phone
Sent from my HTC Vision using xda premium
So OK I've mastered using a PC10IMG.zip to flash hboot (I have a modified StockROM.zip where I switched standard hboot with engineering one and standard recovery with 4ext-touch-recovery android-info.txt is taken from a Radio.zip. I just flashed it with fastboot and it worked I'm back on engineering hboot...
So to destroy my bootloader beyond booting at all (So they can't see I was S-Off but just attribute it to a emmc total failure) I should generate a 0 filled hboot.nb0 file with the exact same size as the original one ? Or just full out write a 2000Mb 0 filled file and erase the whole emmc ?
Any indications and guides (use dd to create the file ?) on how do do this would be welcome as I'm not an expert.
Before doing this I was wondering if there is a way to see if the emmc is "for sure" the culprit and that not booting is not due to something else (say CPU or mainboard failure)...

Don’t try OTA 4.5.141 with a rooted phone

I was getting "Failed to boot 2 starting RSD mode" error and when my Atrix tried to reboot to install the OTA update. The only way I could get to boot again was to remove the battery and put it back, and after that, it boots normally to the home screen, and after the SD card gets mounted it shuts down to try to install the OTA update and you get the same error again.
I got it working again by following the suggestions from Atrixforums.com. What I did was to flash my phone with RDS lite v5.6 using the file 1FF-olympus-user-2.3.4-4.5.91-110625-release-keys-signed-ATT-US-GAS_NA_OLPSGBATTSPE_P011 and that fixed my phone and it’s been working normally.
If you can get your phone to the home screen without rebooting or you get a different type of error, you could try the Automated Update (PC Users Only) from Motorola website (I need confirmation if this would work with a unlocked bootloader)
Details:
My phone was using the stock rom version 2.3.4
Rooted (I did not remove the root access before applying OTA 4.5.141 and this is reason why I got in this problem)
Locked bootloader (I am not sure if this would work with unlocked bootloader)
Unlocked sim card
I hope it helps,
Already posted in Dev section:
Warning 1
Warning 2
Search before posting :>
Alaq said:
Already posted in Dev section:
Warning 1
Warning 2
Search before posting :>
Click to expand...
Click to collapse
Those threads reference problems with unlocked phones. The OP has a rooted phone that is not unlocked. So, not a dupe per se.
That said, I upgraded my rooted-only phone with no issues. I rather suspect the OP may have unlocked his bootloader and forgotten about it.
You can OTA 141 with a locked and rooted phone. Just be sure to unroot (you need to do this manually if you ever used the fastboot preinstall method) and make sure everything is back to stock. If you used oneclick or any other root method that has an unroot, manually verify it really removed everything (su, superuser.apk, etc).
gnahc79 said:
You can OTA 141 with a locked and rooted phone. Just be sure to unroot (you need to do this manually if you ever used the fastboot preinstall method) and make sure everything is back to stock. If you used oneclick or any other root method that has an unroot, manually verify it really removed everything (su, superuser.apk, etc).
Click to expand...
Click to collapse
I have used the one click easy method only and nothing else. And I agree with you, it seems that not unrooting your phone before the OTA update creates this problem. I’ll be more careful the next time when the ICS it’s available.
I just want people like me that it’s not been in the android scene for long, do not get in to this kind of problems.
It would probably be a good idea to post a check list every time a new update comes up, reminding us of the precautions that we must have. Because even if you know what you are doing If you forget just one little change you made it could lead to some problems.
Greetings,
btw, here is what I did to unroot prior to the 141 update. I rooted 2.3.4 with the fastboot preinstall method...no idea if this unroot method cleans up the one click method.
link
1. Open Android Terminal Emulator
2. Type in the following commands, hitting ENTER after each line of code: (after typing 'su' below, look for the Superuser request and approve it, you can only continue if you get the # prompt.
Code:
su
mount -o rw,remount /dev/block/mmcblk0p12 /system
mount -o rw,remount /dev/block/mmcblk0p17 /preinstall
rm /system/bin/su
rm /preinstall/sqlite3
rm /preinstall/dosu
rm /preinstall/Superuser.apk
rm /preinstall/su
reboot
3. Let the phone reboot fully and then go into Settings > Applications > Manage Applications > find Superuser and uninstall it just like any other app.
Click to expand...
Click to collapse
I am was also facing the same issue with OTA. I finally managed to update my rooted, locked phone via USB method using Motorola Software Updater.
Root is lost after the update.
I did the OTA on my atrix which was locked and rooted. Updated fine without any problems, but I did lose root. Can't figure out which method is safe to use to re-root.
http://www.android-advice.com/2012/root-the-motorola-atrix-4g-running-4-5-141/
k00ey said:
I did the OTA on my atrix which was locked and rooted. Updated fine without any problems, but I did lose root. Can't figure out which method is safe to use to re-root.
Click to expand...
Click to collapse
live4nyy said:
http://www.android-advice.com/2012/root-the-motorola-atrix-4g-running-4-5-141/
Click to expand...
Click to collapse
I used this method and it worked fine. It did give an error message that superuser was already installed but it rooted the phone anyway.
Sent from my MB860 using Tapatalk
live4nyy said:
http://www.android-advice.com/2012/root-the-motorola-atrix-4g-running-4-5-141/
Click to expand...
Click to collapse
Thank you! Worked great.
charlyee said:
I used this method and it worked fine. It did give an error message that superuser was already installed but it rooted the phone
Click to expand...
Click to collapse
Charlyee, did you unroot your 4G with the preinstall method prior to following these instructions? Please confirm. Thanks!
badnokia said:
Charlyee, did you unroot your 4G with the preinstall method prior to following these instructions? Please confirm. Thanks!
Click to expand...
Click to collapse
I did the root saver method but I had all kinds of problems doing the OTA, so I ended up by downloading the software from the Moto website via USB.
At that point my Atrix was unrooted, but I don't know if it was the root saver method or download of the software.
I tried Motofail to root as well but that didn't work.
Hope that helps.
Sorry, didn't mean to write a thesis in answer to a simple question.
Sent from my MB860 using Tapatalk
Is it safe to use the aRoot unroot method if my Atrix is rooted and unlocked in order to update to 4.5.191?
Confirmed Success: Unroot, OTA Update, Root
Sorry if this info is redundant, but I'm super paranoid about the OTA updates & wanted to confirm what I did worked for my rooted, but locked Atrix 4G:
1) Unrooted with the directions on this page: http://www.atrixforums.com/forum/mo...ons-including-stock-locked-2-3-4-2-3-6-a.html
2) Ran OTA update
3) Rooted again with the following instructions: http://www.android-advice.com/2012/root-the-motorola-atrix-4g-running-4-5-141/
I just did sucessful update on my unlocked and rooted Motorola Atrix 4G (MB860) from 2.3.4 to 2.3.6 via RSDLite 5.6, and 1FF-olympus-user-2.3.6-4.5.141-111212-release-keys-signed-ATT-US-GAS_NA_OLPSGBATTSPE_P012.sbf SBF file.
Windows 7 64-bit Ultimate. Everything passes O.K.
I had this happen on my atrix rooted no unlocked bootloader I reflashed with the above method nd success. I unrooted my wife's atrix first and installed the ota with no problems. So unroooting first seemed to work.
Sent from my MB860 using XDA App
I did not have a problem at all updating to 4.5.141 with a rooted phone minus the fact I lost root until I saw the link live4nyy posted.
Just an FYI for others like me that have been waiting to pull the trigger on the update.
I was rooted with the /preinstall (briefmobile) method (had never unlocked the bootloader). I read conflicting reports on whether OTA would work, and for some reason I couldn't get the Motoroloa update program to see my phone. Rather than figuring out why it wasn't seeing my phone, I did the "unroot" steps listed by gnahc79 in this thread and then let the phone update OTA and then rooted again using the /preinstall method.
The whole process took about 30 minutes, most of that was the OTA download and install.
Did you guys have to re-hack mobile hotspot after the OTA update?
Sent from my Motorola 2-way pager

[WARNING] Do NOT Downgrade Your Bootloader or Partition Table - You Risk Bricking!!!

BEFORE YOU COMMENT ON THIS THREAD - PLEASE READ THIS POST AND UNDERSTAND WHAT THE DIFFERENCE IS BETWEEN THE BOOTLOADER, PARTITION TABLE, SYSTEM AND KERNEL/RAMDISK!!!!
This post is not about downgrading from lollipop to kit kat in general. It is SPECIFICALLY about and it is ONLY about downgrading the BOOTLOADER (motoboot.img) and the PARTITION TABLE (gpt.bin). The system (system.img) and kernel/ramdisk (boot.img) are NOT the subject of this thread. If you don't understand the difference b/t the bootloader, partition table, system and kernel/ramdisk, then please refrain from posting on this thread and simply read until you understand the difference.
Please do not comment if you do not even know the version of the bootloader you are running b/c you have nothing substantive to contribute then. If you know the version of the bootloader you are running now and know what it was before you upgraded and after you downgraded, great, please let us all know your experience. But if you don't, AGAIN, you have nothing of value to contribute to this thread.
The Moto X 2014 is not a Nexus device - you CANNOT safely downgrade your bootloader (motoboot.img) or partition table (gpt.bin). You risk bricking if you do, especially if you downgrade the bootloader!!!
You need to understand what you are flashing. If you don't understand what you are flashing, read and ask questions before you flash until you do understand what you are flashing. You also need to know what version of the bootloader you currently have before you flash.
Also, you should not attempt to have a bootloader-partition table mismatch in terms of versions. Both your bootloader and your partition table should be the same version - i.e., if your bootloader is the 5.0 bootloader, your partition table should be the 5.0 partition table.
Edited - it looks like mfastboto and maybe even regular fastboot have checks in them to prevent a bootloader or partition table downgrade. However, the OTA updater scripts may or may not have sufficient checks in them to prevent bricking if you have previously upgraded then downgraded the system/kernel/radios and then attempted to take an OTA. For instance, people have reported bricking after flashing to 5.1 then downgrading system/kernel/radios to 4.4.4 then taking the 5.0 OTA = brick.
I've seen alot of stuff about that in the threads. Are you saying that you can't downgrade back to 5.0 or 4.4? Cause I have successfully flashed back to stock KitKat from the 5.1 soak several times. Even flashing partition and motoboot. It just downgraded the tz.
Sent from my XT1095
dustin_b said:
I've seen alot of stuff about that in the threads. Are you saying that you can't downgrade back to 5.0 or 4.4?
Click to expand...
Click to collapse
I am saying exactly what I said in the OP - you can't safely downgrade your bootloader or partition table. And you can't have a bootloader/partition table version mismatch. There are rare exceptions to that like the one for the MX13 that jcase used to root 4.4.
dustin_b said:
Cause I have successfully flashed back to stock KitKat from the 5.1 soak several times. Even flashing partition and motoboot. It just downgraded the tz.
Click to expand...
Click to collapse
Did you use RSDLite to flash motoboot.img and gpt.bin? If so, like I said in the OP, it has checks built into it and it will prevent you from downgrading your bootloader and partition table. mfastboot may have the same checks built in, idk, but I don't think fastboot from the SDK does and that is where people are getting into trouble.
What did you use to flash?
Also, can you post a video showing you doing this w/o bricking? Show your BL version on 5.1, which from what has been reported is 60.14, and then flash the 5.0 BL, which is 60.1 1 and show us that you were able to downgrade your bootloader back to 60.11 w/o bricking. Then once you do that, downgrade the bootloader down to 4.4.4 (I am not sure what the version number is, but once you successfully downgrade you can tell us).
The Q&A forum is littered with people who bricked their devices when they attempted to downgrade their bootloaders.
I think people would be foolish to believe that it is safe to downgrade the bootloader of a Moto X given all the bricks unless you post some proof it is safe.
It might be awhile before I could do a video but I just used fastboot from the SDK. I don't know if it actually downgrades the bootloader. Maybe just the trust zone. I've never actually checked. I wonder if people have noticed but on the 5.1 soak you have to go into developer options and check OEM unlocking now.
Sent from my XT1095
In the past when I downgraded to KK from 5.0, if I tried to flash the old bootloader, it would simply fail to flash. It never bricked. I have also flashed the gpt from KK when downgrading in the beginning. It flashed fine and didn't brick. I don't flash gpt now that I know what it is but the first few times I downgraded, I did flash it.
Edit: I always used fastboot/mfastboot. I can't get RDSLite to detect my Moto X. MDM doesn't detect it either.
dustin_b said:
It might be awhile before I could do a video but I just used fastboot from the SDK. I don't know if it actually downgrades the bootloader. Maybe just the trust zone. I've never actually checked.
Click to expand...
Click to collapse
Honestly, I would not try this as there is no reason to do it. It is dangerous and it doesn't provide any benefit. If you don't believe me that it it dangerous, read on the Q&A forums when people ask for help after bricking their devices - almost always they were attempting a bootloader or partition table downgrade when they bricked. It is just not worth it IMO. You do what you want of course as you seem to believe it is possible but it is not something I would do.
dustin_b said:
I wonder if people have noticed but on the 5.1 soak you have to go into developer options and check OEM unlocking now.
Click to expand...
Click to collapse
That is how it is on the Nexus 6 too.
walrusmonarch said:
In the past when I downgraded to KK from 5.0, if I tried to flash the old bootloader, it would simply fail to flash. It never bricked.
Click to expand...
Click to collapse
why some people get a failed flash and others get a brick, idk, but all you have to do is read on the Q&A forums how many people brick attempting to downgrade the BL and/or PT.
JulesJam said:
why some people get a failed flash and others get a brick, idk, but all you have to do is read on the Q&A forums how many people brick attempting to downgrade the BL and/or PT.
Click to expand...
Click to collapse
Yeah, I've seen people brick it that way. I think I just got lucky the few times I have done it
walrusmonarch said:
I have also flashed the gpt from KK when downgrading in the beginning. It flashed fine and didn't brick. I don't flash gpt now that I know what it is but the first few times I downgraded, I did flash it.
Edit: I always used fastboot/mfastboot. I can't get RDSLite to detect my Moto X. MDM doesn't detect it either.
Click to expand...
Click to collapse
I just don't see why it is ever necessary to mess with the BL or PT. System, recovery, radios, kernel, sure I see why you would do that. If downgrading your BL or PT doesn't provide any benefit to you, why do it?
JulesJam said:
I just don't see why it is ever necessary to mess with the BL or PT. System, recovery, radios, kernel, sure I see why you would do that. If downgrading your BL or PT doesn't provide any benefit to you, why do it?
Click to expand...
Click to collapse
I agree with you. I did it mostly because I didn't know what the heck I was doing back then. I was just flashing away hoping everything would work
walrusmonarch said:
I agree with you. I did it mostly because I didn't know what the heck I was doing back then. I was just flashing away hoping everything would work
Click to expand...
Click to collapse
My first device was a Nexus (GNex) so I flashed with abandon w/o knowing what I was doing and never bricked. When I got my Moto X 2013, I went to the MX13 XDA forum and started to read and am damn glad I did b/c I would have never known. There were tons of people who bricked trying to downgrade. I am sure Motorola had to do a lot of warranty replacements for this reason. Really, there should have been more checks that would prevent bricking and the flash would just fail. There weren't though except with RSDLite. IMO Motorola deserved having the added cost of these warranty replacements.
Hopefully, Motorola has built more checks into the system now where the flash will fail rather than bricking the device, but clearly whatever they have done isn't enough. Again, idk why some people report being able to do this and others end up with bricks, but I don't see the need to do it at all and until it becomes universally safe to do this across the board every time, I wouldn't do it.
JulesJam said:
My first device was a Nexus (GNex) so I flashed with abandon w/o knowing what I was doing and never bricked. When I got my Moto X 2013, I went to the MX13 XDA forum and started to read and am damn glad I did b/c I would have never known. There were tons of people who bricked trying to downgrade. I am sure Motorola had to do a lot of warranty replacements for this reason. Really, there should have been more checks that would prevent bricking and the flash would just fail. There weren't though except with RSDLite. IMO Motorola deserved having the added cost of these warranty replacements.
Hopefully, Motorola has built more checks into the system now where the flash will fail rather than bricking the device, but clearly whatever they have done isn't enough. Again, idk why some people report being able to do this and others end up with bricks, but I don't see the need to do it at all and until it becomes universally safe to do this across the board every time, I wouldn't do it.
Click to expand...
Click to collapse
Yeah, my first android device was a N7 (2012). I flashed away at it like crazy. Sometimes multiple times a day... I guess I just had that same mentality when I started trying to flash the Moto X... It is a good idea to read before flashing. I've been trying out Windows phone recently and managed to flash a rom on my lumia 635 without bricking. I barely read anything, and I probably just got lucky again...
RSDLite seems convenient. I wish I could get it to work for me, along with MDM. Sigh... oh well.
walrusmonarch said:
RSDLite seems convenient. I wish I could get it to work for me, along with MDM. Sigh... oh well.
Click to expand...
Click to collapse
The only thing with RSDLite if you don't want your data overwritten, you have to edit the xml file.
As far as the driver issue, you can try downloading the drivers from root junky's site to see if you can install them that way.
http://rootjunkysdl.com/?device=Android Drivers&folder=Motorola
JulesJam said:
The only thing with RSDLite if you don't want your data overwritten, you have to edit the xml file.
As far as the driver issue, you can try downloading the drivers from root junky's site to see if you can install them that way.
http://rootjunkysdl.com/?device=Android Drivers&folder=Motorola
Click to expand...
Click to collapse
Yep, I have tried those too. No luck. I have at least got fastboot and adb working fine, so its not so bad. Thanks for trying to help!
OK, I changed the title from stating "you will brick" to "you risk bricking".
JulesJam said:
Honestly, I would not try this as there is no reason to do it. It is dangerous and it doesn't provide any benefit. If you don't believe me that it it dangerous, read on the Q&A forums when people ask for help after bricking their devices - almost always they were attempting a bootloader or partition table downgrade when they bricked. It is just not worth it IMO. You do what you want of course as you seem to believe it is possible but it is not something I would do.
Click to expand...
Click to collapse
Ok, so after attempting again I have discovered a couple of things. First, I had to use the fastboot commands from withn the mfastboot folder. I did not use mfastboot commands though. Secondly, it doesnt actually downgrade the bootloader. I think it just downgrades the tz (there is a message about this on the fastboot screen). It did not brick though and I have done this multiple times. But it obviously doesnt make a difference so I'm with you. No one should try this at the risk of bricking their device! My apologies to you @JulesJam. I wasn't trying to be offensive but just thought I would throw it out there since I thought I had done it before. I am far from an expert on these things especially fastboot cause I was on Galaxy devices before this so i never had to use it. I'm kind of like the other guy I have always went by another guide on returning to stock and just thought it should be that way. So again, DO NOT DO THIS AT THE RISK OF BRICKING YOUR PHONE:good:
dustin_b said:
Ok, so after attempting again I have discovered a couple of things. First, I had to use the fastboot commands from withn the mfastboot folder. I did not use mfastboot commands though.
Click to expand...
Click to collapse
I am not sure what you mean fastboot commands w/in the mfastboot folder. Mfastboot
is just motorola's version of fastboot that allows the system image to be flashed as a single image file instead of being broken down into chunks. Unless you manually rename it, it is called fastboot, however some people have manually renamed it and then uploaded it in a zip file and you can find links to it online. I manually renamed mine mfastboot.exe so as to avoid confusion with fastboot.exe from the SDK.
dustin_b said:
I was on Galaxy devices before this so i never had to use it. I'm kind of like the other guy I have always went by another guide on returning to stock and just thought it should be that way. So again, DO NOT DO THIS AT THE RISK OF BRICKING YOUR PHONE:good:
Click to expand...
Click to collapse
Did you use ODIN before? I think RSDLite is similar to ODIN but since I have never used ODIN I don't really know.
But yes, what Samsung does and what Motorola does wrt the bootloaders is completely different as the bootloaders are proprietary. I am just glad to see that there are more checks now than there used to be that prevent you from downgrading at least some of the time.
There are some very sad people on the Q&A forum right now searching for the signed binary files to restore their bootloaders but those have to be leaked and so far, they do not seem to be anywhere accessible by outsiders.
I've done it loads of times too. Everytime I tried to flash back the gpt or motoboot, it just failed (was trying to relock bootloader, never would let me), normal fastboot. Also with the newest version of fastboot it can flash the system files, no need to use mfastboot at all anymore.
nbell13 said:
I've done it loads of times too. Everytime I tried to flash back the gpt or motoboot, it just failed (was trying to relock bootloader, never would let me), normal fastboot.
Click to expand...
Click to collapse
Yeah, again I can't explain why some people just get a failure and others get a brick, but on the Q&A forum you will see there are those who brick attempting to downgrade.
nbell13 said:
Also with the newest version of fastboot it can flash the system files, no need to use mfastboot at all anymore.
Click to expand...
Click to collapse
Last time I tried the latest version of fastboot, it cannot flash the single file system.img. It can flash the system if it is broken down into chunks. So if you are using the fxz with the single system.img, you have to use mfastboot last I checked.

[HOWTO] Converting your Retail Note 4 to a Developer Edition Note 4

This guide will walk you through the process of converting your Retail Note 4 to a Developer Edition Note 4. This means you have an unlocked boot loader and you are free to do what you wish with your device.
Requirements:
Retail Note 4 (Verizon)
Computer (PC, Linux or Window)
USB Cable
Samsung USB Drivers (If you are on Windows)
SD Card (Recommend a small one that you do not mind storing away for later)
ADB (Android Debug Bridge)
Root (Either Temp or Perm, that will not be explained here)
Samsung Unlock file (Creators Thread)
Steps:
- Verify you have an ADB connection to your device and you have root.
Connect your phone and launch ADB in either command prompt or terminal (Depending on your OS).
Type the following command to view the currently connected devices:
Code:
adb devices
You should see a list of devices. If not, verify USB Debug Mode is enabled on your phone.
-Copying the unlock file to your phone
After you have downloaded the file from ryanbg's thread (samsung_unlock_n4-2) we need to copy it to the device. You will want to make sure your current directory is the directory that the file you downloaded is in.
Time to push the file to the phone, run the below command:
Code:
adb push samsung_unlock_n4-2 /data/local/tmp/
-Connect to your phone
Type the following command:
Code:
adb shell
You are now in in a shell through ADB on your phone.
Elevate your permissions by entering:
Code:
su
You may get a confirmation on your phone for requesting root access. Be sure to grant ADB permission.
-Change Directory
Go to the directory we copied our files to
Code:
cd /data/local/tmp/
-CHMOD and CHOWN the unlock file
This allows us to actually execute the file. Execute the below commands
Code:
chmod 777 samsung_unlock_n4-2
Code:
chown root.root samsung_unlock_n4-2
-Time to execute
Running the below command will generate a warning and a requirement to enter yes or no. Read the warning carefully before continuing:
Code:
./samsung_unlock_n4-2
At this point you will see a few thing similar to this:
Code:
[+] CID at boot time is/was: 1501xxxxxxxxxxxxxxxxxxxxxxxxx
[+] device not yet dev CID, now changing to dev CID
[+] programming new CID 150100523231384d4100657e54fc1200
[+] success! powering off device, power back on and verify CID
[+] then run this binary again to finish the process
As binary states, your phone CID is changing is going to reboot.
Before turning your phone back on, be sure the SD card you are okay with formatting is inserted into the phone.
Once your phone comes back online, launch terminal, ADB shell, obtain root access, and change directories. Now launch the unlock binary again:
Code:
./samsung_unlock_n4-2
You will see the same warning and you will need to enter yes or no again. Once you enter yes, you should see something like this.
Code:
[+] CID at boot time is/was: 150100523231384d4100657e54fc1200
[+] dev CID matching, proceding to unlock
[+] backing up loaders, this will take a few minutes
[+] loaders successfully backed up
[+] success! powering off device, hopefully its not bricked!
Keep the SD card in a safe place. If for some reason you ever break your phone, you can possibly use the loaders on this card to fix it.
Power your phone up in download mode (VOL-DOWN + HOME + POWER). Your phone should now show Developer mode. If this is not the case, you either did something wrong or your phone is not a Verizon Note 4
i can say it is really appreciated that we have this ability but this blunt "we wont tell you how to at least temp root it" thing is kind of messed up because a lot of people have no idea where to go to find the right temp root for this phone. We have always needed root yet now we have unlocked bootloader which again is appreciated, but a little help with the latter would be nice.
KingVekxin said:
i can say it is really appreciated that we have this ability but this blunt "we wont tell you how to at least temp root it" thing is kind of messed up because a lot of people have no idea where to go to find the right temp root for this phone. We have always needed root yet now we have unlocked bootloader which again is appreciated, but a little help with the latter would be nice.
Click to expand...
Click to collapse
To be honest if a person cannot find KingRoot, they should not be using this method. This mindset is shared by a lot of people on XDA. This is not a simple click and go type unlock, it requires someone to get down and dirty to get things done.
chriskader said:
To be honest if a person cannot find KingRoot, they should not be using this method. This mindset is shared by a lot of people on XDA. This is not a simple click and go type unlock, it requires someone to get down and dirty to get things done.
Click to expand...
Click to collapse
Trust me it wouldnt be the first down and dirty with rooting for me lol. But i have found it and will see if it goes alright and then i will try to link others to it to make it a little easier, at least with that part
can someone who has not done this, download and install brick bug app from Play store and post of screen shot of it running. I wanna check if Note 4 come with a emmc other than Samsung.
Well I did everything as stared and now it's stuck in a bootloop.
I wiped everything also. It does say mode developer though.
Couldn't get some help guys?
I can already hear the laughter
I have successfully completed these steps. However, I want to know is there any difference between this and an actual developer edition at this point?
I'm really kind of in trouble here. It only boots up in download mode and in recovery. It says mode developer but it just bootloop. Kies won't connect to it.
Is it possible to Odin back?
Thank you.
edjahman said:
I'm really kind of in trouble here. It only boots up in download mode and in recovery. It says mode developer but it just bootloop. Kies won't connect to it.
Is it possible to Odin back?
Thank you.
Click to expand...
Click to collapse
remove battery and sd card. Then insert battery and reboot.
KingVekxin said:
i can say it is really appreciated that we have this ability but this blunt "we wont tell you how to at least temp root it" thing is kind of messed up because a lot of people have no idea where to go to find the right temp root for this phone. We have always needed root yet now we have unlocked bootloader which again is appreciated, but a little help with the latter would be nice.
Click to expand...
Click to collapse
To be fair, I don't even own this device. The exploit happened to apply to the Note 4 and we decided to make it compatible for you guys. That's why I can't really help you with it. Make sense?
edjahman said:
I'm really kind of in trouble here. It only boots up in download mode and in recovery. It says mode developer but it just bootloop. Kies won't connect to it.
Is it possible to Odin back?
Thank you.
Click to expand...
Click to collapse
Try pulling your battery and removing your SD card. Then try to wipe cache in recovery. Typically, you would unlock your bootloader if you wanted to flash custom ROMs/kernels. If that doesn't work, feel free to PM me and I'll help you as best I can.
Phew. Ty guys. Somehow I overlooked that lol.
It's fine now. I really appreciate it.
Edjahman
---------- Post added at 04:04 PM ---------- Previous post was at 03:59 PM ----------
So I assume we treat this like a Dev edition Note 4 then as long as it says developer mode in recovery?
I'd hate to ODIN TWRP or CF Autoroot and brick it for real.
Thanks
Just ODIN TWRP and flash supersu in twrp.
I'm unclear about the directory part. If someone could clarify that would be great
Will this work on the latest Verizon OTA? LMY47X.N910VVRU2BPA1 (Android 5.1.1)
I'm currently on BOG5 - Safe Upgrade with the BOAF Bootloaders (hsbadr). Should I flash back to 4.4.4 and allow all of the OTA updates or is there a point to where this won't work?
Suggestion to OP: Update Step 1 on the Requirements to include which Android version we need to be on for this to work. I "assume" 4.4.4, because I've heard that KingRoot only works on 4.4.4. Please confirm this. Thank you.
EDIT: Also, Step 5 of the Requirements section, I assume you meant MicroSD card, not SD Card.
BotRob said:
I'm unclear about the directory part. If someone could clarify that would be great
Click to expand...
Click to collapse
You would just copy and paste the commands into the ADB shell window.
sixtythreechevy said:
You would just copy and paste the commands into the ADB shell window.
Click to expand...
Click to collapse
K thank you very much for clarifying
Wait so do you need root to do this? If that is the case is there any way I could do anything with the note 4 on the latest firmware?
After typing Yes to confirm the warning message all I get is:
[-] this is for <some> Samsung devices only
[-] it will kill other devices
I keep getting this ::
------------------------------------------------------ 2nd attempt
(Yes/No)
[+] CID at boot time is/was: 15
[+] dev CID matching, proceding to unlock
[+] backing up loaders, this will take a few minutes
[-] you MUST have a 1GB or greater sd card inserted
[-] 4GB or greater is recommended
[-] do NOT patch this out of code!
[-] fail
10|[email protected]:/data/local/tmp #
------------------------------------------------------
Fails I got this the first time... I loaded fully back in then tried again and got this. not in dev mode.
----------------------------- FIRST TIME -----------------
(Yes/No)
[+] CID at boot time is/was: 15
[+] device not yet dev CID, now changing to dev CID
[+] programming new CID 15
[+] success! powering off device, power back on and verify CID
[+] then run this binary again to finish the process
------------------------------------
Thanks
JimChagares said:
After typing Yes to confirm the warning message all I get is:
[-] this is for <some> Samsung devices only
[-] it will kill other devices
Click to expand...
Click to collapse
download brickbug app from Playstore and check emmc cid, if it starts with 15 only then can you use this process. If it starts with 15 it would be better to wait and see what comes up tomorrow.

Potential way to unlock bootloader?

Since we are using engboot, write protection seems to be off, so it appears you can use dd to write to normally write protected partitions such as the bootloaders (ex: "dd if=/sdcard/aboot of=/dev/block/sdd10"). In my testing I was successfully "dd" a backed up aboot (secondary bootloader) partition and also write to the modem partition and have it stick (which means write protection should be off akaik). If you were to "dd" the Chinese bootloaders, you might be able to flash and re-partition onto the Chinese firmware and then use the CROM service to unlock the bootloader from there. I personally don't know too much about this type of stuff and haven't tried to actually "dd" the Chinese bootloader, but for those more knowledgeable, could this potentially work?
Partitions likely needed are:
- rpm (Resource and Power Manager / Primary Bootloader) located at /dev/block/sdd1 (/dev/block/bootdevice/by-name/rpm)
- aboot (AP Bootloader / Secondary Bootloader) located at /dev/block/sdd10 (/dev/block/bootdevice/by-name/aboot)
- xbl (Extended Bootloader) located at /dev/block/sdb1 (/dev/block/bootdevice/by-name/xbl)
- ? located at /dev/block/sdc1
Modifying the bootloader is dangerous and could permanently brick your device. I take no responsibility if you try this and it breaks your device.
Edit 5: Additional Details
qwewqa said:
Since we are using engboot, write protection seems to be off, so it appears you can use dd to write to normally protected partitions (ex: "dd if=/sdcard/aboot of=/dev/block/sdd10"). In my testing I was successfully dd a backed up aboot (secondary bootloader) partition and also write zeros to the modem partition and have it stick (which means write protection should be off). If you were to dd a Chinese bl/ap, you might be able to flash/re-partition onto the Chinese firmware and then use the CROM service to unlock the bootloader from there. I personally don't know too much about and haven't tried to actually dd the Chinese bootloader, but for those more knowledgeable, would this work?
Edit: Modem partition sticks after reboot.
Click to expand...
Click to collapse
@Binary100100 you probably know somebody that knows little bit more about this, tell them to check it out
Magnifik81 said:
@Binary100100 you probably know somebody that knows little bit more about this, tell them to check it out
Click to expand...
Click to collapse
Nope. Don't know anyone specific.
Wish I had the $175 for my insurance deductible, I'd give it a try. All in all, it should work. The hardware is the same.
thescorpion420 said:
Wish I had the $175 for my insurance deductible, I'd give it a try. All in all, it should work. The hardware is the same.
Click to expand...
Click to collapse
Well, if it WORKS, I'm sure the bounty on unlocking the bootloader is a lot higher than $175! ?
DOMF said:
Well, if it WORKS, I'm sure the bounty on unlocking the bootloader is a lot higher than $175!
Click to expand...
Click to collapse
Lets start a thread . . . I am willing to contribute $25.00 :good: into a pool with others here at XDA to the developer who can produce an unlocked bootloader that is rooted with a decent rom that works great and better than stock, something that will fix all of the untold bugs and address the known issues.
Anyone else?
serendipityguy said:
Lets start a thread . . . I am willing to contribute $25.00 :good: into a pool with others here at XDA to the developer who can produce an unlocked bootloader that is rooted with a decent rom that works great and better than stock, something that will fix all of the untold bugs and address the known issues.
Anyone else?
Click to expand...
Click to collapse
$25? Hell think about how much we spend on the phone itself and bill every month.. I'd easily pledge $100 for an unlocked bootloader with twrp support.
That's the 1 thing I don't understand.. this is the most highly sought after phone right now with 0 developer support. I understand the limitations with the locked bootloader but other phones have overcome the same through the works of various motivated individuals. There is no one even interested in trying it seems on ANY carrier forum. Instead we have countless threads with people more interested in getting the nougat update early which will hardly provide anything useful compared to an unlocked bootloader with working root.
serendipityguy said:
Lets start a thread . . . I am willing to contribute $25.00 :good: into a pool with others here at XDA to the developer who can produce an unlocked bootloader that is rooted with a decent rom that works great and better than stock, something that will fix all of the untold bugs and address the known issues.
Anyone else?
Click to expand...
Click to collapse
"Start?" It was started ages ago and it thousands of dollars. https://forum.xda-developers.com/tmobile-s7-edge/how-to/bounty-unlocked-bootloader-s7edge-t3339857
bdvince said:
$25? Hell think about how much we spend on the phone itself and bill every month.. I'd easily pledge $100 for an unlocked bootloader with twrp support.
That's the 1 thing I don't understand.. this is the most highly sought after phone right now with 0 developer support. I understand the limitations with the locked bootloader but other phones have overcome the same through the works of various motivated individuals. There is no one even interested in trying it seems on ANY carrier forum. Instead we have countless threads with people more interested in getting the nougat update early which will hardly provide anything useful compared to an unlocked bootloader with working root.
Click to expand...
Click to collapse
Root right now is just too impractical for most people. I'm still rooted, but for most people it isn't worth the hassle and trade-offs, for many it's worse than stock. I think most people who are really into root probably switched devices. Switching to android N could actually prevent bootloader unlock in this way, unless root for N comes out. That is if this unlock method could actually work, hard to say without anyone experienced in bootloaders and write protection though.
I'd like to find someone with a sm-g9350 to DD a dump of sdd10.
thescorpion420 said:
I'd like to find someone with a sm-g9350 to DD a dump of sdd10.
Click to expand...
Click to collapse
Sdd1 is the primary bootloader, probably also necessary.
Came to the realization that the Chinese bootloader is v2 where all US models are v4. I'd imagine the Chinese nougat update will make it v4, so we wait to try.
Don't want to a be downer or anything but I'm pretty sure you can't just replace the bootloader, even if write protection is off on the Eng kernel. Even if you did replace it you'll have probably bricked your phone.
Sent from my SM-G935T using Tapatalk
dogredwing1 said:
Don't want to a be downer or anything but I'm pretty sure you can't just replace the bootloader, even if write protection is off on the Eng kernel. Even if you did replace it you'll have probably bricked your phone.
Click to expand...
Click to collapse
The thinking is that since the devices are virtually the same hardware wise, there is a chance the bootloader could be replaced. I do agree that there is a good chance of hard bricking though. I haven't done any testing other than apparently successfully dding a backed up version of the same bootloader.
If I wasn't on nougat I would try it if someone posted instructions and devs confirmed the directions are correct..
Sent from my SM-G935T using Tapatalk
I was actually playing with the bootloader, and found this thread when I went to post. I'm going to be pulling fastboot commands also to see if I can find anything interesting. I'm tired of not being able to use a custom kernel
My device is on nougat. Bit I can easily downgrade and test if someone has a rock solid idea. I don't mind bricking as the device has a cracked screen and I have my s6 edge plus to use until the s8 drops...
Sent from my SM-G935T using Tapatalk
Count me in as well!
I have a theory that we can open the BL file in WinRAR and extract the rpm.mbn file from G9350 odin file,
and flash to our device. But I cannot determine which one is for aboot. I have not tested this yet.
aaron007 said:
Count me in as well!
I have a theory that we can open the BL file in WinRAR and extract the rpm.mbn file from G9350 odin file,
and flash to our device. But I cannot determine which one is for aboot. I have not tested this yet.
Click to expand...
Click to collapse
What I know is:
RPM = Resource and Power Manager = Primary Bootloader
ABoot = AP Bootloader = Secondary Bootloader
I believe the boot process is "RPM > ABoot > boot.img (Main OS)", so both the rpm and aboot file would be needed. Also I think the partition layout in the Chinese version is slightly different, so a flash and repartition would be needed after replacing bootloader to actually root. I don't know what the chances success are though, the devices are virtually the same hardware wise, and the Chinese rom with the U.S. bootloader works according to the Verizon fourm, but there is a chance there are other differences what might prevent this from working.
Flippy125 said:
I was actually playing with the bootloader, and found this thread when I went to post. I'm going to be pulling fastboot commands also to see if I can find anything interesting. I'm tired of not being able to use a custom kernel
Click to expand...
Click to collapse
Isn't fastboot disabled on the s7. Also, were your results the same?
qwewqa said:
What I know is:
Isn't fastboot disabled on the s7. Also, were your results the same?
Click to expand...
Click to collapse
Yes, found that out when I started playing with it more. I'm currently reading sdd10 line by line. I did find an entry "Device is unlocked! Skipping verification...". I'm starting to think we need to look into recovery-side exploits. I'm too scared to try and mess with the bootloader too much.
EDIT: If we can find a way to get fastboot working, possibly piggybacking off of Odin, I found a command written in the aboot code 'fastboot oem unlock-go'
EDIT2: Using that command requires some sort of key. May be a dead end.
EDIT3: I'd be willing to test modifying the recovery image to see if it triggers the bootloader's hash checking. If anything, this could lead to writing a custom boot image that would open TWRP.

Categories

Resources