Related
Hi all,
New to the forums and to android dev... your help and patience much appreciated. Made (hopefully) good faith effort to track down an answer, but no luck yet...
2 (related?) questions on Motorola Ultra root (4.4 KitKat):
On the adb side, having issues with signature/certs.
Using original mymoto apk from jcase's post...
I initially get INSTALL_PARSE_FAILED_NO_CERTIFICATES
I create key, run jarsign and zipalign per Android dev instructions (referred there from suggestions on stackoverflow).
This appears to successfully add signature, but then on install I just get parse failed inconsistent certs.
Most of the suggestions I've seen for inconsistent certs revolve around uninstalling the app... but since I haven't successfully installed to begin with, not sure if that applies. (Indeed, running pm list packages in adb shell, I don't see anything that looks like PwnMyMoto to uninstall).
Any thoughts much appreciated.
Secondly, I also tried to download apk direct to phone from web, and the message on install (attempt) was rather interesting:
"PwnMyMoto
Do you want to install an update to this built-in application? Your existing data will not be..." etc.
(When attempt to install, simply comes back: "App not installed").
The 'built-in application' part seemed strange to me, and I haven't found reference to it in forums. Assume this has something to do with the fact that PwnMyMoto takes over existing recovery boot function of the native system? Is this message unique / does it imply any additional workaround to uninstall existing packages?
(Saw the X has moved from PwnMyMoto to RockMyMoto... but haven't seen any similar updates on the Ultra side. If I've missed it please let me know).
Thanks for any help!
shen
I'm new here as well, with an unrooted verizon ultra 4.4. From what I can see now, the certificate issue is because the PwnMyMoto apk is relying on a previously rooted phone. It appears there is still a bounty for a stock root procedure.
Hopefully someone more experienced can chime in as if this is indeed the state of things.
aletoledo said:
I'm new here as well, with an unrooted verizon ultra 4.4. From what I can see now, the certificate issue is because the PwnMyMoto apk is relying on a previously rooted phone. It appears there is still a bounty for a stock root procedure.
Hopefully someone more experienced can chime in as if this is indeed the state of things.
Click to expand...
Click to collapse
Ah, okay. That puts a few things I read in other posts into place. Unfortunate. Was reading up on SlapMyMoto as a solution for those who already took the OTA for 4.4, but I think it's a similar situation... you can only perform the downgrade to 4.2 required to load SlapMyMoto if you already have a rooted device (from what I can tell). Not a solution for a stock 4.4.
Hello All! I am me2151.
I am here to tell you some kind of good news.
We have achieved a temporary root shell using a modified recowvery script. Originally Recowvery installed a custom "recovery" but I have modified it to instead create a temporary root shell using the System_Server SELinux context and disable the flashing portion of the script. Yes we are still limited until we can get Kernel or Init context but I am working on that as well.
This exploit will be useful down the line because of one major thing. WE CAN INSERT KERNEL MODULES!!! But they need to be signed. So I am releasing this out here so we can take the next step into our full root! We also have rw to the /data partition and changes save over a reboot.
If we can get someone to sign a kernel module that the system accepts we can set SELinux to permissive.
This exploit SHOULD work for all variants.
NOTE: This should only be used by devs who know what they are doing.
Instructions(this should work on MacOS and Linux only!):
Download linked file below.
Extract to either adb directory OR a directory you have adb access in.
Give execute permissions to temp.sh.
Run temp.sh.
When you are all done with your exploring and stuff type "Reboot" to reboot normally.
https://drive.google.com/open?id=0B8CP3g3AqMuHcmNJUUJWLUJUelE
Credit:
@jcadduono - For recowvery, and pointing me in the right direction on IRC.
@brenns10 - Wrote the lsh used in the exploit to spawn the shell.
The group over here for ideas and solutions.
Very cool work! Glad to see people putting my shell (such as it is) to good use. Wish I had a V20 to try it out
I don't think you'll ever be able to sign a kernel module (SHA512 hash). You'd probably have better luck signing your own boot image.
Here's a theory to toy with:
I think the way to do it would be to gain read access to /init binary allowing you to dirtycow /init with the same init binary but change a very specific (but not vital to system integrity) set of instructions to point back to the setenforce code with a value of 0 without disturbing the rest of the binary/instructions. This way, init should continue running without crashing and taking down the whole system, and you can do something that might trigger that specific instruction set - which would then result in selinux becoming permissive.
This is beyond me, unfortunately. This method would also be very device specific until someone also finds an intelligent way to read init, modify instructions, then dirtycow it back.
I think system server context might be able to read init?
Once you get your permissive selinux, you'll also have to deal with Unix capabilities limitations (find a way around them).
jcadduono said:
I don't think you'll ever be able to sign a kernel module (SHA512 hash). You'd probably have better luck signing your own boot image.
Here's a theory to toy with:
I think the way to do it would be to gain read access to /init binary allowing you to dirtycow /init with the same init binary but change a very specific (but not vital to system integrity) set of instructions to point back to the setenforce code with a value of 0 without disturbing the rest of the binary/instructions. This way, init should continue running without crashing and taking down the whole system, and you can do something that might trigger that specific instruction set - which would then result in selinux becoming permissive.
This is beyond me, unfortunately. This method would also be very device specific until someone also finds an intelligent way to read init, modify instructions, then dirtycow it back.
I think system server context might be able to read init?
Once you get your permissive selinux, you'll also have to deal with Unix capabilities limitations (find a way around them).
Click to expand...
Click to collapse
if system_server can read init then thats a serious flaw.... Question for you. you said it would be very device specific. does that mean its unique for each individual phone or each model?
EDIT:Unfortunately we only have access to the init.rc not the binary it self.
@jcadduono I appreciate your input and direction in this matter another idea we have been toying with is
We have the aboot boot recovery and system dump. From the tmob variant would it be possible to make a tot from that for our devices changing the props to match our device, build, and carrier info? We can also pull apks from /system/apps and /privapps to our ext sdcard
@me2151, @jcadduono, @brenns10: Great work guys, keep it up. Good to see some people are trying for root. What model/s are being tested, or should this theoretically work on all models? Whilst you probably aren't doing it for the cash, there is a bounty I hope someone can claim soon, for a functonal root alone (not boot unlock) posted on this board.
RoOSTA
roosta said:
@me2151, @jcadduono, @brenns10: Great work guys, keep it up. Good to see some people are trying for root. What model/s are being tested, or should this theoretically work on all models? Whilst you probably aren't doing it for the cash, there is a bounty I hope someone can claim soon, for a functonal root alone (not boot unlock) posted on this board.
RoOSTA
Click to expand...
Click to collapse
It should work on all models. I personally use a sprint model(LS997). I think it MAY have been tested on VZW as well.
I can confirm that work on H990DS
Sent from my MI PAD using XDA-Developers mobile app
We know from earlier LG phone releases that the laf partition when bypassed in some way (corrupted, etc) aboot will boot to fastboot when going into download mode. It was my thought that the bootloader could be unlocked from there. However corrupting laf eliminates device recovery. Catch-22.
I think the best way to proceed is to get a working .TOT first which is just a waiting game. That would ensure device recovery and replacing the bootloader in the .TOT and signing it with something unlockable.
This is a great way to explore the locked phones in the meantime, thanks.
ATT Pretty Please
me2151 said:
Hello All! I am me2151.
I am here to tell you some kind of good news.
We have achieved a temporary root shell using a modified recowvery script. Originally Recowvery installed a custom "recovery" but I have modified it to instead create a temporary root shell using the System_Server SELinux context and disable the flashing portion of the script. Yes we are still limited until we can get Kernel or Init context but I am working on that as well.
This exploit will be useful down the line because of one major thing. WE CAN INSERT KERNEL MODULES!!! But they need to be signed. So I am releasing this out here so we can take the next step into our full root! We also have rw to the /data partition and changes save over a reboot.
If we can get someone to sign a kernel module that the system accepts we can set SELinux to permissive.
This exploit SHOULD work for all variants.
NOTE: This should only be used by devs who know what they are doing.
Instructions(this should work on MacOS and Linux only!):
Download linked file below.
Extract to either adb directory OR a directory you have adb access in.
Give execute permissions to temp.sh.
Run temp.sh.
When you are all done with your exploring and stuff type "Reboot" to reboot normally.
https://drive.google.com/open?id=0B8CP3g3AqMuHcmNJUUJWLUJUelE
Credit:
@jcadduono - For recowvery, and pointing me in the right direction on IRC.
@brenns10 - Wrote the lsh used in the exploit to spawn the shell.
The group over here for ideas and solutions.
Click to expand...
Click to collapse
At the moment all I am using root for is to add a line within my build.prop to disable Tethering checks, so I can tether at full 4G speed and not get throttled. Would this be possible using the method above, or would build.prop immediately get replaced at the reboot?
Thanks, and keep up the good work!
NRadonich said:
At the moment all I am using root for is to add a line within my build.prop to disable Tethering checks, so I can tether at full 4G speed and not get throttled. Would this be possible using the method above, or would build.prop immediately get replaced at the reboot?
Thanks, and keep up the good work!
Click to expand...
Click to collapse
no. it is a tcp root shell that can only do a few things such as kernel modules.. only section we were able to write to and have it stick was the /data partition which wont help you in this scenario
elliwigy said:
no. it is a tcp root shell that can only do a few things such as kernel modules.. only section we were able to write to and have it stick was the /data partition which wont help you in this scenario
Click to expand...
Click to collapse
So if we can write to data partition then in theory can we adb push to it using this? I ask because I'd like to install some tbo apps that normally would require flashing. But if we could push them we would be solid
markbencze said:
So if we can write to data partition then in theory can we adb push to it using this? I ask because I'd like to install some tbo apps that normally would require flashing. But if we could push them we would be solid
Click to expand...
Click to collapse
Unfortunately its a tcp shell. not a pure adb shell. so we cannot push or pull to those directories
Wow great progress keep up the good work. You guys are helping those assholes from LG sell more phones. Obviously some people have not made the switch because the lack of root. Root users are very influential leaders to get others to try out a new device.
Sent from my LG-LS997 using XDA-Developers mobile app
Works on the LG G5 also...
Hey guys, with the expectation of many that 'root is coming' to the other v20 models...are we likely to see the same type of root format that applied to the LG G4, where you have to (either) download or rip your own image to a PC. Use commands to insert root, then reflash to the device?
Any root is better than nothing, I know...but I ask because with the amount of software updates for the G4 (v10c software through to v10k before MM came out), meant the sheer amount of times you'd have to go through this process to keep your phone up to date whilst maintaining root was extremely frustrating - as it also meant xposed and related settings/apps needed to be reinstalled each time you performed an OTA update and re-flashed root.
Is this going to be a side effect of dealing with a locked bootloader? PS: If I sound dumb, it's probably because I am.
RoOSTA
roosta said:
Hey guys, with the expectation of many that 'root is coming' to the other v20 models...are we likely to see the same type of root format that applied to the LG G4, where you have to (either) download or rip your own image to a PC. Use commands to insert root, then reflash to the device?
Any root is better than nothing, I know...but I ask because with the amount of software updates for the G4 (v10c software through to v10k before MM came out), meant the sheer amount of times you'd have to go through this process to keep your phone up to date whilst maintaining root was extremely frustrating - as it also meant xposed and related settings/apps needed to be reinstalled each time you performed an OTA update and re-flashed root.
Is this going to be a side effect of dealing with a locked bootloader? PS: If I sound dumb, it's probably because I am.
RoOSTA
Click to expand...
Click to collapse
it shouldnt be an expectation as weve made it clear we do not have root and are hitting hurdles.. we have been advised we need to atack selinux and or the bl but at this point were wanting to try to use debug firmware which hoprfully would allow a bl unlock..
unfortunately nobody can creat a .tot with the debug firmware at al and theres no way at all to flash the images..
we need to somehow leverage an exploit to gain a temp adb root shell before we could even attempt anything and this has not been done in a way thats useful to us..
unfortunately we need more experienced devs at this point.
LG Australia (and as such, Taiwan) have effectively confirmed their H990DS v20 mobile phone's bootloader is confirmed as being unlockable. However (and for no apparent reason) they will not confirm why one region have released a variant of the phone with the bootloader unlock and why they are refusing this to others phones/regions. Because of course, they have zero training and information about anything related to their company expect for goods released in a specific region. That comes from a 'product expert'
Titanium Backup
Howdy,
Just reading through the thread, I understand that it's not quite a "full" root, but would it be enough to run Titanium Backup? I'm hoping to move away from root access with my V20 but it would be really helpful if I could do it temporarily, restore some application and data backups, reboot and uninstall Titanium.
Tim
Hey all
I have bricked my t-mobile V20 trying to network unlock it.
Anyway, I have been investigating solutions to this problem, and well, let's say there is no easy solution for most people.
The problem as I see it, is that this chipset (msm8996), while not exactly super new, is for all intents and purposes VERY new indeed. Because of the widespread use of UFS NAND introduced with this cpu. Almost all phones based on these newer qualcomm chips use this modern storage, which works as a multi-LUN device. Meaning it will show as several independent logical storage devices depending on configuration. V20 has 7, or at least the H918 does.
In short, it means the storage device is no longer mounted in mmcblk0, but on /dev/sda sdb sdc... etc depending on how many LUN's.
So the community has not catched up yet to this new development. (Well I guess hard-brick has always been a pain for many phones, but this makes it worse)
Now there are, I think, 5 ways to approach the 9008 mode in this instance.
*JTAG: Bypass all this QC hodge-podge and program the darn NAND directly.
*USB with Box: Some type of box with the capability to program your specific phone. Proprietary, closed source, have to pay.
*USB with firehose: Program yourself with programs like QFIL. Need device specific "prog_ufs_firehose_8996*.elf" file. LG has not released this. Can probably only be leaked, which happens on occasion.
*Enter DL or 9006 mode: It may be possible to short certain test points on the motherboard, which will put the phone into 9006 or Download Mode. Would require instructions, or the Service Manual.
*SD-Card Rescue: Make an sdcard with the required partitions. Some say this can't be done on newer QC chips with UFS because of the aforementioned multi-LUN situation.
I have been looking into this SDCARD method, and I found some info on the DragonBoard 820C (which uses msm8996, with UFS). This board has 6 LUN's, so it's multi-lun just like V20.
If you see here: DragonBoard, there is listed a method of SD CARD rescue. The tools can be found here: db-boot-tools
Unfortunately I don't have a full dump of my partitions, so I only have the ones included in the TOT, or KDZ files. I tried making a image using those files, it didn't work, but something interesting happened. With this sd card inserted the phone does not show the qdloader 9008 port on my pc, actually nothing shows. I did double check using a normal card inserted, and yes with normal storage card qdloader 9008 mode appears.
So this is interesting and makes me think I should try some more with this, but I need someone with a T-Mobile H918 to dump their partitions. EFS is not needed (where the imei is).
Update: I currently don't need a dump (Except for engineering firmware).
Update2: I could not make the SD-Card boot work, see here (with normal firmware).
List partitions
Command: ls -l /dev/block/platform/soc/624000.ufshc/by-name/
Or this: ls -al /dev/block/bootdevice/by-name/
Then dd the relevant partitions not listed above: dd if=/dev/sd*1/2/3/4... etc of=/sdcard/"filename".img
As an example, maybe you can do it other ways, perhaps with an app.
You can also use the patched LGUP to dump partitions. Should be the simpler method.
In any case I will be grateful for your assistance, as I'm sure many others will if this pans out.
Engineering Rom: I got an idea, if I can't get this to work then maybe it's because the support isn't compiled in the bootloader. If I could get the eng-firmware (for H918) to test that it would be great. So please if you have an eng device or a dump of that, I would be thrilled try it out.
Update: Below I've attached a zip with a limited partition layout, and the commands to dump from adb. Use the patched LGUP for Engineering firmware. (actually, with engineering formware I need all, or most of the partitions. PM me if you have such a device)
Support your work. Lg
China user
I would certainly go the QPST/QFIL/Firehose method & my strategy would be to restore Download mode.
I'm sure once that has happened you can restore full firmware with the patched LGUP method here
Prowler_gr said:
I would certainly go the QPST/QFIL/Firehose method & my strategy would be to restore Download mode.
I'm sure once that has happened you can restore full firmware with the patched LGUP method here
Click to expand...
Click to collapse
Yes, but how would you go about doing that without the required firehose file? LG apparently uses certificate or some signing, so you can't use just any file.
Although that patched LGup is nice. If I had known about that tool before I messed up, I probably would not have messed up. Because then I wouldn't be afraid of loosing root, and just flashed H910pr with LGup, then flash back with the patched one later.
Edit: As I have later found out ^^this would not be a good idea. The result would be the same - BRICK Hard. Just as a precaution for anyone contemplating doing so. The H918 can not be flashed with any other V20 firmware, neither can you flash H918 firmware on any other V20.
askermk2000 said:
Yes, but how would you go about doing that without the required firehose file? LG apparently uses certificate or some signing, so you can't use just any file.
Although that patched LGup is nice. If I had known about that tool before I messed up, I probably would not have messed up. Because then I wouldn't be afraid of loosing root, and just flashed H910pr with LGup, then flash back with the patched one later.
Click to expand...
Click to collapse
I don't pretend to know the answer, but I believe that the firehose file is not any type of signed LG file, but just a partition layout (mbn or elf) file that can be generated from a .kdz file...
Make sure you use QPST_2.7.460 or later which supports MSM8996...
Google is your friend but you can start reading from here & here
Prowler_gr said:
I don't pretend to know the answer, but I believe that the firehose file is not any type of signed LG file, but just a partition layout (mbn or elf) file that can be generated from a .kdz file...
Make sure you use QPST_2.7.460 or later which supports MSM8996...
Google is your friend but you can start reading from here & here
Click to expand...
Click to collapse
Well, there is a difference between an MPRG and MSIMAGE/Singleimage. I believe you are thinking about the latter here. Those can be generated, but are of little use without a programmer file (mprg/firehose).
askermk2000 said:
Well, there is a difference between an MPRG and MSIMAGE/Singleimage. I believe you are thinking about the latter here. Those can be generated, but are of little use without a programmer file (mprg/firehose).
Click to expand...
Click to collapse
Remember we only aim to get bootloader mode, not the full layout...
Btw I probably wouldn't mind wasting $5 on this
Prowler_gr said:
Remember we only aim to get bootloader mode, not the full layout...
Click to expand...
Click to collapse
Yes I know. But Qualcomm and LG has made that very difficult for us. All the common info on the web so far is outdated, or doesn't work because of missing firehose file.
Except for possibly SDcard method.
Having read your OP again, of how you SD card affects how windows detects your phone, I believe this may be a good step to our solution. of getting the phone recognised in download mode
Prowler_gr said:
Having read your OP again, of how you SD card affects how windows detects your phone, I believe this may be a good step to our solution. of getting the phone recognised in download mode
Click to expand...
Click to collapse
Do you have brick as well?
I looked at that page, and pretty sure I've looked at it before. There is nothing there that can be of use.
askermk2000 said:
Do you have brick as well?
I looked at that page, and pretty sure I've looked at it before. There is nothing there that can be of use.
Also I'm very suspicious of that Aryk site. They don't seem to know what their talking about many times, their downloads dubious with viruses and the like. On the page you linked they claim QHSUSB_BULK is the same as 9008, while it is actually 9006.
It almost seems like that site was set up solely for the purpose of spreading malware or something. Just cobble up something random and presenting it like information, like with algorithms and bots or whatever.
I think there a lot of that stuff going on in the "gms" business. Like for example, on gsmarena I found a sticky thread which supposedly had files to repair a LG V20 which has been stuck in bootloop because of "use of cheap chinese usb-c cable". Anyway, that archive had some files, including a *prog_ufs_firehose_8996_lite.elf*. That file did not work, and there was an instructions file there also, in XLS format which contained virus.
Come to think about it. This whole crap with qualcomm "security" stuff seems like just a way to create the sub-market of gsm repair boxes. Well, who knows, just a guess on my part. But there's something fishy about the whole thing.
Click to expand...
Click to collapse
I was, I'm now unbricked (I worked out the method with the LGUP patch).
What I'm suggesting (as the website describes) is to write the v20 boot image to an SD card using Win32DiskImager/, & see if your device will boot with it, & then upgrade with LGUP.
I've got the H990DS variant (I can send you my boot image to try)
Prowler_gr said:
I was, I'm now unbricked (I worked out the method with the LGUP patch).
What I'm suggesting (as the website describes) is to write the v20 boot image to an SD card using Win32DiskImager/, & see if your device will boot with it, & then upgrade with LGUP.
I've got the H990DS variant (I can send you my boot image to try)
Click to expand...
Click to collapse
I would welcome a boot image, or images of partitions. That's why I started this thread mostly.
askermk2000 said:
I would welcome a boot image, or images of partitions. That's why I started this thread mostly.
Click to expand...
Click to collapse
link removed
Prowler_gr said:
...removed
Click to expand...
Click to collapse
Ok, I got it. Thx
Will try with this. Did you get it with LGUP ?
I extracted it from my phone
Prowler_gr said:
I extracted it from my phone
Click to expand...
Click to collapse
Im in this to but i have a lg g5 msm8996 board
me and him have been trying to work very closely to get a fix for msm8996 in gen of coarse he is worried about v20 me g5 but common interests.
i dont wanna knock any v20 discussions off track so im here but im sitting in the corner most quietly
he is def on the right track i have dealt with many hardbricks in the past
and the no reconition on pc is most def a good step
my problem is being a new moderator plus my job plus after hours work i dont have time to test a lot of stuff any more he has bought a lot of info to my eyes and am trying to work on what i can.
look and 8994 g4 it took 2 years for a hardbrick fix to come about only from people doing the same as we are
TheMadScientist420 said:
Im in this to but i have a lg g5 msm8996 board
me and him have been trying to work very closely to get a fix for msm8996 in gen of coarse he is worried about v20 me g5 but common interests.
i dont wanna knock any v20 discussions off track so im here but im sitting in the corner most quietly
he is def on the right track i have dealt with many hardbricks in the past
and the no reconition on pc is most def a good step
my problem is being a new moderator plus my job plus after hours work i dont have time to test a lot of stuff any more he has bought a lot of info to my eyes and am trying to work on what i can.
look and 8994 g4 it took 2 years for a hardbrick fix to come about only from people doing the same as we are
Click to expand...
Click to collapse
We agree he's on the right path (about SD method), that's why I sent him my boot image & suggested he burns it into an sd card. I'm hoping he only needs to boot with it & everything else would be straight forward
I burned the *.img file directly onto a 64gb uSDXC card. It creates a single 63gb fat mbr partition on the card. So it seems you managed to make a single complete image of your entire UFS chip. Have no idea how though, but I've not exactly had the chance to look into that myself because of brick.
The image, burned this way did not work, it's not even recognized by the phone as a boot image. I will see if I can perhaps extract the file from within the img-file and split that somehow.
Because windows can't edit/remove partitions on external devices, I used linux, since ubuntu's standard tools there can simply burn the image directly onto the device, automatically removing any partition scheme in the process.
That win32diskimager program is strange because it can not target device directly, but only mountpoint, and because my card was already formatted with numerous partitions from before, I could not use that program.
Prowler_gr said:
We agree he's on the right path (about SD method), that's why I sent him my boot image & suggested he burns it into an sd card. I'm hoping he only needs to boot with it & everything else would be straight forward
Click to expand...
Click to collapse
That has always been the rite track just to get to download mode.
I thank you for providing the files. Its always stressful when dealing with owns hardbrick. ive spent hours of burning images to mine lol even fried a couple sd cards
but most def seems as if you are knowledgeable also in this area so id love to keep you in this loop
If we all can pull this off. We will be the next heros of the day lol also if u are interested in reading some suposedly the s8+ also has same boards so even may be able to piece stuff from there
and i know sammys have been booted of sd in the past.
the more people we can get the better
Hey guys,
I've been using XDA for quite a while, but so far the community as a whole has been so helpful and thorough that I have never needed to make an account and post, so if any part of this post is wrong or in the wrong section please feel free to move or close this thread.
Now down to business: recently, some old Moto Droid 2 Globals resurfaced at my house, and as they are very old and outdated I figured I would re-purpose them into a few projects I'm working on, as they probably won't be extremely useful in any other ways. Here is my problem though: in order to use them how I would like, they must be rooted. Rooting is not my problem: I have rooted one of them many times when I was still using it (I might or might not have bricked it one or seven times while trying to install custom ROMs so flashing, rooting, and every other aspect of un-bricking is familiar to me). HOWEVER, ALL THE FILES NEEDED TO DOWNGRADE, ROOT, REFLASH AND RESTORE DO NOT EXIST ANYMORE!. This is one of those times where things on the internet actually disappear, as quite a few of the mirrors to the files I need were hosted on the gem of the internet back in the early 2010s, MegaUpload. The rest of the files were linked to personal servers, smaller and now nonexistent file hosting companies, or were straight up removed from their links. So what I'm asking is: if you ever had to root a Motorola Droid 2 Global running GingerBread 2.3.4, System Version 4.5.629.A956.Verizon.en.US, and for some reason you still have the files required to root it, could you upload it and post a link in the comments? I will list the necessary files below in case you would like to scour the internet as I have, or if you want to check that the files you might have are the ones needed. I will also post links to a few guides so if you want to refresh yourself or see how the process is done you can do so without extra searches.
And seriously guys, thanks in advance. Even if no one has the files, this community has helped me out so much over the years that a thank you was way overdue.
https://forum.xda-developers.com/showthread.php?t=1592154
(not entirely sure what this one below is, it looks like its a correct file but its got huge red "DO NOT INSTALL" all over the page so take it how you will)
http://rootzwiki.com/topic/21934-4.5.629.zip-please-do-not-install,-only-for-developers
Files I'm (mostly) Certain I Need:
Verizon OTA Version 4.5.608 (but it looks like this is a modified and repacked version)
Verizon OTA Version 4.5.629
wrong section buddy, post this thread in your device's forum
I rooted my Motorola Edge (regular not +) and I'm trying to do this so I can do the Motorola software updates without wiping out my Android installation and starting from scratch. I need to know how the stock ROM image(which I have) needs to be named and where to put it so Magisk can see it. I asked for help in the Motorola + section here in this thread, but it was a ghost town. The one response I did get was very helpful as it's where I got the first link in this post from.
I found a little help here on another site. While that thread is regarding Magisk, it's using it with another phone, so I don't know how relavant it is for using Magisk with my phone. It says to put the file in /data/data on the root partition. Is that right? They also mentioned putting the file's SHA1 hash in a magisk config file, which I did, but it didn't help. It also said to rename the file and GZIP it, ending up with a file with an img.gz extension, which I didn't do.
Maybe not exactly what you are looking for, but I've posted some
General Updating Moto devices and keeping root instructions here.
[Guide] Update Rooted (Magisk) Motorola Device
[Guide] Update Rooted (Magisk) Motorola Device This is a General Motorola Guide If you need more help Please create a thread in your device's forum. Mention me by Posting "@sd_shadow" I'll help you as much as I can... Required Android SDK...
forum.xda-developers.com