For now simply follow the instructions and use the provided file download from the link posted below
http://forum.xda-developers.com/showpost.php?p=48392009&postcount=1
I have personaly tested this method in full on My AT&T Samsung Galaxy S4 ZOOM SM-C105AUCUAMJ2 (4.2.2 Jelly Bean)
although it should be safe to use on any AT&T Samsung Galaxy S4 ZOOM running an android version prior to Kit-Kat
All Credit for this, "exellent completely safe", Root method goes to its creator k1mu
And please Know that it is only being shared with you via his explicit permission.
EDIT:
Q&A for [ROOT] Saferoot: Root for AT&T Galaxy S4 ZOOM SM-C105AUCUAMJ2_On 4.2.2 JB
Please if you are not on an AT&T Galaxy S4 ZOOM C-150a, Feel Free to Read
but Do not seek help,instruction, or any other type of advice by posting in this thread as it is hard enough to find information about a specific device when the said device does not have a dedicated forum. Thank You for your Understanding in this.
Instructions & Advice
If ?'s arise
and time allows I will add device specific instruction as well as any advice, Please bear with me. Same as above Q&A Link
Will this same method also work on the SM-C105AUCUAMJ2?
kbracing6 said:
Will this same method also work on the SM-C105AUCUAMJ2?
Click to expand...
Click to collapse
Most Definitely as this was the reason for my post
Hey @Phatboyj420, as far as converting a raw OTA file to Odin files, here's what I can tell you. The OTA file should be filename.cfg, i.e. a cfg file. Believe it or not, this can be manipulated like an archive (like zip or rar or tar) so open that cfg file in 7zip, WinRar, or whatever. You're going to want to extract the files like (I can't guarantee this a full list, just the ones I can remember) modem.bin, NON-HLOS.bin, boot.img, recovery.img, aboot.mbn, rpm.mbn, sbl1.mbn, sbl2.mbn, sbl3.mbn (you might not have all 3, idk), and tz.mbn. Again, there may be others you need, and/or not all the ones I just listed might be necessary, they're just the ones I remember dealing with before. Oh, you're going to need to make sure the system, cache, and persdata partitions are all packed into .img.ext4 files, idk if they're like that in the OTA cfg archive.
Here's where it gets even hazier for me. So, I know from personal experience that you can take any of these files (I'll just use recovery.img for this example). In a linux terminal (I use Ubuntu for convenience's sake, my laptop has windows and ubuntu partitions) run this command:
Code:
tar -H ustar -c recovery.img > recovery.tar
So that's how you can take any one of those files I mentioned last paragraph and pack it into an Odin-flashable tar. I'm still a n00b when it comes to the linux terminal, so I can't really say the syntax for packing more than one at once.
So I guess I haven't really given you the complete process, but hopefully this is at least a decent starting point. Honestly I consider myself a hobbyist at best, not an expert. muniz_ri, who Devo7v mentioned earlier, did all the heavy work in this regard so he can probably help you much more, I just didn't want to volunteer him for the job
thisisapoorusernamechoice said:
Hey @Phatboyj420, as far as converting a raw OTA file to Odin files, here's what I can tell you. The OTA file should be filename.cfg, i.e. a cfg file. Believe it or not, this can be manipulated like an archive (like zip or rar or tar) so open that cfg file in 7zip, WinRar, or whatever. You're going to want to extract the files like (I can't guarantee this a full list, just the ones I can remember) modem.bin, NON-HLOS.bin, boot.img, recovery.img, aboot.mbn, rpm.mbn, sbl1.mbn, sbl2.mbn, sbl3.mbn (you might not have all 3, idk), and tz.mbn. Again, there may be others you need, and/or not all the ones I just listed might be necessary, they're just the ones I remember dealing with before. Oh, you're going to need to make sure the system, cache, and persdata partitions are all packed into .img.ext4 files, idk if they're like that in the OTA cfg archive.
Here's where it gets even hazier for me. So, I know from personal experience that you can take any of these files (I'll just use recovery.img for this example). In a linux terminal (I use Ubuntu for convenience's sake, my laptop has windows and ubuntu partitions) run this command:
Code:
tar -H ustar -c recovery.img > recovery.tar
So that's how you can take any one of those files I mentioned last paragraph and pack it into an Odin-flashable tar. I'm still a n00b when it comes to the linux terminal, so I can't really say the syntax for packing more than one at once.
So I guess I haven't really given you the complete process, but hopefully this is at least a decent starting point. Honestly I consider myself a hobbyist at best, not an expert. muniz_ri, who Devo7v mentioned earlier, did all the heavy work in this regard so he can probably help you much more, I just didn't want to volunteer him for the job
Click to expand...
Click to collapse
Thanks My guy,
This definately gives me a good jumping off point.
The phone shipped with JB-4.2.2 and I think there has been an AT&T OTA for KK so it would have to be a complete Firmware so thats good news.
I'm working on several projects at once so I don't know exactly when I'll get to this but when I do the first thing will be to verify whether the .img's for data/system/cache are img.ext4 or not and if not how to produce correctly.
Also I don't have a Linux Dev setup yet I'm running Windows On a 2011 Dell XPS-17_L702x with an intel 2720 quad core. So from your post I take it Ubuntu would be your suggestion for Linux Distro. and should I make a separate Linux Partition and run from it, or run from a VM-Box inside of windows? Which do you think would be most efficient?
Now that I think of it I'm going to start a dedicated thread for development discussion for this specific device. If I start the thread in the Development section for the general S$-ZOOM but title it specifically for the " AT&T-C105a_ZOOM " do you think the mods would want to move it to the general Q&A section?
" I would hope that, as it would pertain directly to the development of the specific device they would see fit to leave it in the development section.
Sorry for the randomness of my thoughts but I will link you to the thread when I get around to starting on it.
For now I'm going to get back to work on the S4_Active for My daughters B-day I intend to have it Rooted and rommed out for her. When I get that done I'll make my way back to this Project, and start the dedicated thread.
Thanks again,
" I look forward to future collaboration as it seem we share a similar Hobie at the least ",
Phatboyj
Unfortunately for the few lonely SM-C105a users still hanging on out there this does not appear to be a completely effective root. I get this in dmesg: <3>[ 2130.920856] c0 Restricted changing UID. PID = 11580(su) PPID = 11575(sh)
capt_planit said:
Unfortunately for the few lonely SM-C105a users still hanging on out there this does not appear to be a completely effective root. I get this in dmesg: <3>[ 2130.920856] c0 Restricted changing UID. PID = 11580(su) PPID = 11575(sh)
Click to expand...
Click to collapse
What is your build # because this is a fully effective root method for the ATT SM-C105a running build# SM-C105AUCUAMJ2
Please elaborate on where your dmesg is coming from.
Is it from running Saferoot to obtain Root?
Or is it from some other function you are attempting after obtaining root?
@Phatboyj420 Great to see you here--when I'm sure your S4 Zoom is long gone. Yeah, that's my build and I should point out that I get that in dmesg only for certain operations in the system folder (trying to copy modules I think). No biggie, for day to day this method works fine. I'm more interested in whatever happened with that unbrick image you were trying to make from dd. Did you ever test it? Was it effective? My current efforts are focused on developing a reliable unbrick method for our phones. Rather than the complete image I think we may need to extract and flash the original bootloader in many cases. Can you provide any feedback on this?
capt_planit said:
@Phatboyj420 Great to see you here--when I'm sure your S4 Zoom is long gone. Yeah, that's my build and I should point out that I get that in dmesg only for certain operations in the system folder (trying to copy modules I think). No biggie, for day to day this method works fine. I'm more interested in whatever happened with that unbrick image you were trying to make from dd. Did you ever test it? Was it effective? My current efforts are focused on developing a reliable unbrick method for our phones. Rather than the complete image I think we may need to extract and flash the original bootloader in many cases. Can you provide any feedback on this?
Click to expand...
Click to collapse
@ capt_planit
while I have moved on from using my [email protected] S4-Zoom, I do still have it and the dd dumps of it the problem with providing said dumps publicly is that some "idiot would inevitably flash the complete dd.image to there phone giving them an exact clone of my phone explicitly the IMEI via EFS parition are my concerns.
That being said if I know that the dd.images were to be used in a proper manner, by say a knowledgeable Dev. I would gladly supply them to further /Kickoff Development,
It sounds as if we are of like mind but I found myself at a stand still and did not recieve any response from the plea in my Sig.
But rest assured if there is something I can do to assist I will.
as far as an unbrick.img for the Zoom c105a
I did make one but have had no reason to use it to know if it works or if the SD unbrick method even works for the Zoom like it does on the Galaxy S3 that the method was originally discovered on.
Even if it does work the SD-Unbrick method only gets you to a state where Download
mode works SO unless I am mistaken and you can access adb through Download Mode witch I'm pretty sure you cant, we would still be at a stand still as there is no stock firmware publicly available for our device " Ludacris I know " but true none the less.
Edit:
1 thing we need is the OTA update from JB to KitKat available for our device we need some one to extract it before updating then and only then might we be able to create an install-able firmware for our device.
if I'm not mistaken after you download the OTA update you should be able to find it in /cache/fota just zip the entire fota folder move it to your sd-card and make it available to me and we'll make it happen from there.
If you don't want to except the update just delete it at this point and reboot.
...
...
I think this user @awwar describes an inability to access download mode>here. In anycase, I think that thread would be a great place to post your unbrick. image. I think your dd image seems too small. But if you still have it, that is what @moomoo was asking for when he started that thread. I can't provide mine, except as separate img files. My understanding is that flashing an efs image won't provide a real IMEI. I think flashing some combination of boot, system, cache (I'm surprised this would be necessary) and recovery should get the operator some kind of system. But so far it doesn't seem to work that way. Your help getting some working phone flash would be greatly appreciated. I believe, BTW that the OTA is dead...
Related
I have been working on some boot/recovery ROM rebuilds for the Garmin/Asus Garminfone A50 (T-Mobile), as well as the scripts and instructions... I'm not sure where to host them.
I personally don't want to host them myself, and was wondering if there is a repository of sorts.
At the moment, I have the following:
* The tools necessary (dump_image & flash_image) to dump the firmware from the phone
* The scripts necessary to unpack/repack the boot/recovery ROM's (modified to support the Garminfone's different address layout). Linux based.
* Pre-built boot and recovery images that give permanent root and mount the system/data partitions as r/w by default.
* Instructions on how to do it yourself, complete with some tech info on the layut of the Garminfone boot/recovery images and how to verify before you flash it that it built properly.
* Instructions on how to flash the phone without risking bricking it, since there is no hardware key combo to get into recovery and a fastboot that's not fully implemented. The technique goes like:
- Verify with a hex editor that the proper addresses are in the header
- Flash the new boot image to recovery
- Reboot into recovery to make sure it boots the new boot image properly
- Flash the rooted recovery image to the recovery partition
- Reboot into recovery once more and verify that works
- Flash the tested boot image to the boot partition
- Reboot normally and have fun
That method works fairly well, and unless you target the wrong partition, and gives you a 99.9% success rate
I'm going to post what I can on the Wiki (as far as instructions go), but it would be nice if I had a place to put the tool set as well.
I'd rather not use one of the temporary sites like Mediafire or what not, since files on those sites have a tendency to disappear.
Please no PM's on having me send them the files directly. I don't have a heck of a lot of spare time and don't want to get into the habit of sending these out manually.
If you're against the typical file hosts and the files aren't too big you could try using dropbox or sugarsync and sharing the links.
Can I ask you a question? I have a Kyocera ZIO M6000 and have the openzio clockworkmod 2.5.1.1 port that only works with "fastboot boot openzio-recovery" and we have tried flashing to our recovery partition with no success. What will it take to break the tether and reboot recovery locally without fastboot?
Sent from my Zio using XDA App
merwin said:
I have been working on some boot/recovery ROM rebuilds for the Garmin/Asus Garminfone A50 (T-Mobile), as well as the scripts and instructions... I'm not sure where to host them.
I personally don't want to host them myself, and was wondering if there is a repository of sorts.
At the moment, I have the following:
* The tools necessary (dump_image & flash_image) to dump the firmware from the phone
* The scripts necessary to unpack/repack the boot/recovery ROM's (modified to support the Garminfone's different address layout). Linux based.
* Pre-built boot and recovery images that give permanent root and mount the system/data partitions as r/w by default.
* Instructions on how to do it yourself, complete with some tech info on the layut of the Garminfone boot/recovery images and how to verify before you flash it that it built properly.
* Instructions on how to flash the phone without risking bricking it, since there is no hardware key combo to get into recovery and a fastboot that's not fully implemented. The technique goes like:
- Verify with a hex editor that the proper addresses are in the header
- Flash the new boot image to recovery
- Reboot into recovery to make sure it boots the new boot image properly
- Flash the rooted recovery image to the recovery partition
- Reboot into recovery once more and verify that works
- Flash the tested boot image to the boot partition
- Reboot normally and have fun
That method works fairly well, and unless you target the wrong partition, and gives you a 99.9% success rate
I'm going to post what I can on the Wiki (as far as instructions go), but it would be nice if I had a place to put the tool set as well.
I'd rather not use one of the temporary sites like Mediafire or what not, since files on those sites have a tendency to disappear.
Please no PM's on having me send them the files directly. I don't have a heck of a lot of spare time and don't want to get into the habit of sending these out manually.
Click to expand...
Click to collapse
I would also suggest dropbox or even id host them off my computer via ftp
Can your method work with Garminasus A10?
Merwin you still working on this?
Yeah, I am working on it still. I am still looking for a better place than dropbox or hosting off of someone's home PC...
As for the A10, if you can get me a dump of the boot and recovery images I can make one for that too... you will want to preferably use the dump_image utility to get the image and the flash_image utility to flash it.
I can probably attach those to a post with dump instructions. They're tiny.
Basically, you root your phone, copy the files to a certain location, type a couple commands to fix permissions on the executables, then run a command to dump the image.
Flashing back requires clearing the boot or recovery partition with a command and then using the flash_image command to flash it.
My method tests the new boot image first by flashing it to recovery first and rebooting into recovery to make sure the new image works. Then flash the modified recovery image to the recovery and make sure it is rooted (so you can get things up again if something does go wrong). Then you flash the new tested boot image to boot. If, for some reason, that fails, it should reboot automatically into recovery after a few boot failures. Never had to test that, since I pre-test all images I make.
hi merwin, we are a fans group of GA a10 and we trust a lot in your work! if you need any kind of help contact me! probably you are the first in the world who can flash a GA phone
Merwin, Im not completely sure which type of place your looking for if its not either ftp or online file sharing
Rapidshare
2shared
Filefront
4shared
Hi merwin,
I found this page, is that similar to your method? Hope you guys can find out something.
http://mygarminfone.blogspot.com/
afoster1003 said:
Merwin, Im not completely sure which type of place your looking for if its not either ftp or online file sharing
Rapidshare
2shared
Filefront
4shared
Click to expand...
Click to collapse
You forget one widely used protocol. Good old http on a standard web server.
Those other sites annoy me greatly, between the amount of ads, having to wait to download and daily limits, and the fact that they are temporary unless I pay. I am against them on principle.
I figure if there is enough interest, someone will step up to host them, otherwise I will just provide scripts, instructions, and technical info for people to do it themselves.
slumpz said:
Hi merwin,
I found this page, is that similar to your method? Hope you guys can find out something.
http://mygarminfone.blogspot.com/
Click to expand...
Click to collapse
You are my hero That blog has the missing pieces I need to keep going.
A couple of days ago I found some info on how to decompile the .update files which gives us the recovery image and system partition from any other phone that uses a similar format, like the Asus A10... providing a whole host of opportunities for the Asus phones that are still being maintained.
For instance, I grabbed the files from the Chinese A50 that has newer firmware.
With the info from the blog, I may be able to at least compile and integrate the newer kernel and wifi firmware (which is stored on the phone and loaded into memory at boot). The Chinese version does have newer wifi module firmware in it... whether it is compatible or not is another story.
On another note, has anyone successfully downloaded the open sources kernels from Asus? I have tried every method on their site and all but a couple of the kernel versions in the zip are corrupt. One from march extracts fine, so I may use that as a base to start with.
merwin said:
You are my hero That blog has the missing pieces I need to keep going.
A couple of days ago I found some info on how to decompile the .update files which gives us the recovery image and system partition from any other phone that uses a similar format, like the Asus A10... providing a whole host of opportunities for the Asus phones that are still being maintained.
For instance, I grabbed the files from the Chinese A50 that has newer firmware.
With the info from the blog, I may be able to at least compile and integrate the newer kernel and wifi firmware (which is stored on the phone and loaded into memory at boot). The Chinese version does have newer wifi module firmware in it... whether it is compatible or not is another story.
On another note, has anyone successfully downloaded the open sources kernels from Asus? I have tried every method on their site and all but a couple of the kernel versions in the zip are corrupt. One from march extracts fine, so I may use that as a base to start with.
Click to expand...
Click to collapse
I have, magically I might add. I downloaded the source for v.5.0.70 and managed to get it compiled. The resulting files can be found on on my blog, the one Slumpz posted(I can't post links yet, lol.)
The only problem is, I don't have much experience with anything linux. But, If you have any questions Merwin, email me, [email protected].
Here's a little how to, just check my blog, or google: How To: Build Garmin-Asus Kernel from Source.
am willing to giv a subdomain/storage ftp access on this domain for the good of the community if it helps any
Domain darkjester.net
Disk Usage 5.4 / 1500.0 MB
Bandwidth 100000 MB (100GB)
Home Root /home/a2931495
Apache ver. 2.2.13 (Unix)
PHP version 5.2.*
MySQL ver. 5.0.81-community
Activated On 2011-05-15 14:42
Status Active
Hello guys, are you still working on this.
I found out that A10 has a new firmware posted, which is versioned 5.2.7 instead of 5.0.x like the others. I wonder if there's any method to test this firmware on foreign A10 (non Chinese firmware)?
So, got an HTC Sensation 4G... meaning not much more work on the Garminfone for me.
Still trying to find time to compile everything that I have done into some semi-coherent document with the unlocked boot and recovery images. I still have the Garmin, so if someone manages a huge breakthrough then I may pick it up again. Really didn't want to get rid of the phone but there just isn't enough community development going on to make it worthwhile.
By the way, the Garminfone GPS blows every other phone away. The Sensation 4G is crap in comparison.
I live in Japan and after more than 6 months I have successfully and permanently rooted both my Sharp 003 SH Galapagos and the 005SH Galapagos (Softbank not Docomo). My next concern is how to SIM unlock. I have been reading the posts about hacking the nv_bin file. I have searched through all of the the files (Root FTP thank you!) but there was no such file. I am happy to send along any screenshots or data files if that helps.
Thanks in advance.
Search Sharp 003SH Root Success and Sharp 005SH Root success on Youtube for more info
Can't really help you. Don't know anything about it. But I would like to know how you ended up rooting this phone of ours.
Its not a file on the filesystem. The sim locking in these phones is in the radio image; which can be accessed when you use the custom build kernel thats in the latest rootkit (I assume thats what you are using).
See the 2ch root/ROM thread for more details, but basically it is done through ADB, manually backing up the "_modem" partition; stripping the spare/ECC bytes and then extracting the radio OS using QualcommDumpAnalyser
I have managed to extract this image, but no idea where to go from there. None of the other device info seems to apply to this (HTC, Samsung, LG, any other Android that has had its sim-lock discovered in the radio)
Advice i got from the guys on 2ch: "Qualcomm's NAND code is neither difficult, nor unique, so if you know what you are looking for its not hard"
003SH 005SH Sim unlock
Thanks very much for giving me a new direction. I'll get started on it right away and let you know how it progresses.
It just sucks that the guys who know how to unlock it are staying quiet, saying its "taboo"
FYI, stripping the Spare/ECC bytes can be done manually (i wrote a C program to do it), but there is an option in the RevSkills app to do it all for you - i recommend doing that.
Of course we face another issue once we find the actual unlock - recalculating the ECC bytes after making the change; the only way to access the radio is with raw data access.
P.S. hope you have warranty on your phones - this is very likely to brick at least one phone until we get it right
---------- Post added at 12:30 PM ---------- Previous post was at 12:24 PM ----------
In the spirit of open cooperation, here are the instructions i was given, translated and simplified
In ADB Shell, type su to get the # prompt, then:
cat /proc/mtd <Enter>
Confirm that you have the "_modem" partition available. If not, you need to reflash with the custom build kernel
Dump the image to file with the following command:
dump_image -r -D -F _modem /sdcard/backupimages/modem.img
Access this with anything as "raw dump" and all blocks will get read as ECC error, so definitely dont do this
ECC positioning is different to Linux, so take care
The following maps out how 512bytes of data and 10 bytes of ECC info are stored in a 528 byte block:
0000 - 01CF (0-463): Data
01D0 - 01D1 (464-465): Unused (0xff)
01D2 - 0201 (466-513): Data
0202 - 020B (514-523): ECC
020C - 020F (524-527): Unused (0xff)
Use RevSkills application to extract the data portions:
Menu⇒Calculators/Generators⇒Android MTD Nand remove Spare and ECC
Extract all of the Data only portions out of the raw dump, and then use QualcommDumpAnalyser to read it and split up the various parts. I did notice that i wasnt able to get the AMSS block out with QualcommDumpAnalyser - i copied that out manually by calculating the byte positions shown in QDA.
003SH bootloader key sequence?
Eternalardor,
I'd be happy to swap information. Perhaps you could shed some light on the question of the bootloader for the Sharp 003SH and 005SH? There seems to be no discernible key sequence (Power+home+Volume up etc.) to access the bootloader. I feel like I've tried them all. Can you tell me this critical piece of information?
Is a form of the USB Jig necessary to access it?
Looking forward to your response.
003SH SIM unlock
Dominik,
Here are the results of the original /proc/mtd (before rooting)
boot
cache
misc
recovery
ipl
system
persist
log
battlog
calllog
ldb
userdata
I don't see the _modem partition. Should I?
I have also included a screenshot of the results showing size. I have most of them backed up as .img files too.
FYI: .img backed up sizes. Perhaps this will help you to ponder where the _modem partition may have gone. Maybe it's been renamed?
boot 11,264KB
cache 3,072KB
misc 1,024KB
recovery 11,264KB
ipl 15,360KB
system 419,840KB
persist 30,720KB
ldb 45,056KB
userdata 405,120KB
There is no bootloader menu AFAIK. If you install the custom kernel, you will have the option of a quasi-recovery mode, by pressing the home button between 7-12 seconds after the Galapagos logo is seen (or was that the Softbank logo)
Anyway, looking at the screenshots, it seems you do not have the custom kernel.
How did you achieve root on your phone?
To do this, you need to use the "003sh_005sh_dm009sh-rootkit" from at least 5/27 (recommend _0614); which is available on the 2ch forums. This includes 2 possible ways of achieving root:
1. A modified standard kernel (boot image), which, when flashed gives you regular root access
2. A custom compiled kernel, which has full root, a bunch of power profiles, and heaps more features (inc that quasi recovery), as well as access to the "_modem" image.
Judging from your youtube videos, you speak some Japanese, so the Japanese menus in the rootkit shouldnt be much trouble.
http://www1.axfc.net/uploader/Si/so/142435
This is what i used.
Go here for help/instructions http://anago.2ch.net/test/read.cgi/android/1337845757/
And dont even think about typing in English on there, or you will be ignored and/or told to go away
This all looks familiar. I have been using the root kit (5/27) to get where I am now - step by blessed step. It was pretty straight forward BUT I have never seen the option to write to the system partition. It is in all the instructions but the only option I have with respect to the system partition is to back it up. I'm confused as to why it doesn't seem to show up for me. I am using a Japanese machine so all the characters are displayed and I can read the instructions but I can't find help anywhere as to why I don't have that particular (and critical) option. I can see a lot of new and cool options in the 6/14 release. I'm excited and would like to get it installed.
I'll let you know how it goes. Thanks for your help .... keep it coming!
And another thing
Could you explain a little more about "having" the custom kernel? Using the root kit, I wrote to the Recovery partition then the Boot partition then rebooted from the Recovery partition and all seemed well. As I said above, I have never been able to write to the System partition despite it appearing in all the instructions. I suspect that is what is holding me back from the latest and greatest custom kernel. Still, I am enjoying all the same functionality that everyone else seems to be enjoying in root. What am I missing?
Eep, you wrote to the boot partition before trying the recovery? Brave!
The steps should be:
Write image to recovery partition;
Then reboot to recovery partition (from the menu) and confirm it all works without errors.
Then write image to boot partition
And then turn off the phone, and reboot (the last part is only my instructions - you could just select "reboot to boot partition" from the menu)
You are doing this on your 005SH right? It should be the same for the 003SH, but i only have the 005SH. In the rootkit there is 2 options when you say "burn custom image":
1 カスタムビルドrootedカーネル（リカバリーキット機能付き）
2 S4080 標準rootedカーネル（簡易リカバリー機能付き）
Q 中止してメインメニューへ戻る
You must do the first one, the CUSTOM rooted kernel, to get any of the really cool features. The second option is only if you just want root access for a particular app or something. AFAIK the second option doesnt even disable MIYABI LSM, which prevents you from mounting the system dir as R/W
But either way, writing to the System dir is not important for what we are doing. You need the Custom kernel, which gives you access to the "_modem"
Edit, i just noticed in your screenshots above, you didnt even get root in ADB shell?
Type
ADB Shell<Enter>
Then type
su<enter>
The cursor should change to a #, this means root. You may get a prompt on the phone from Superuser asking you to give root access to "shell". Once you have this try the cat /proc/mtd again
jcroot003sh,
can you tell me how to root 003sh?
Use the link i provided in my previous post
http://forum.xda-developers.com/showpost.php?p=27989085&postcount=8
You can use a translator if you dont understand Japanese, but the general instructions are in the post above yours
I translated it for a friend, but that is at work, so wont be able to put it up until monday.
DominikB said:
Use the link i provided in my previous post
http://forum.xda-developers.com/showpost.php?p=27989085&postcount=8
You can use a translator if you dont understand Japanese, but the general instructions are in the post above yours
I translated it for a friend, but that is at work, so wont be able to put it up until monday.
Click to expand...
Click to collapse
Thank you for your replying. I will wait for your translated version. You are really a good person.
Progress
I have successfully found and dumped the "_modem" image. Exactly as you stated - forgot the "su" command in ADB. Thanks. The next problem is editing out the code. I am way above my head here so I will do some research before bugging you for a step-by-step for that.
Also, the bootloader worked. I didn't realize how to do it until I read the notes in the 6/14 release. I successfully put a previously dead phone back on it's feet EXACTLY to the point of my current phone simply by backing up and then restoring partitions through the bootloader. Very slick and easy.
Will get to work. I'll be in contact soon with my progress on the SIM unlock.
I have spent a bit of time looking at it, it certainly isnt easy (Certainly isnt a "lock=yes" section). I assume the actual locking portion is encrypted/compressed/or just compiled, because it would be too easy otherwise (be happy to be proven wrong). For starters, i cannot even find my IMEI number in the dump file... I think that this dump only includes the radio code, not the NV RAM which contains the IMEI and SIM Lock status. If that is the case then the solution should be to change the portion of the radio code that queries the NV RAM, so that it doesnt care if the SIM lock is supposed to be applied.
Extracting the spare/ECC bits out should be done with the RevSkills app; extracting the relevant portions, that is a bit of a cludge; QualcommDumpAnalyser can show the start/end positions, but doesnt extract the AMSS part (AFAIK thats where the code will be). You need to use a hex editor to cut that part out manually... And i am still not 100% sure what the block size is on this NAND.
Good luck!
And if there *are* any experienced hackers out there willing to help out, i can offer some monetary help (as will a few of my fellow Japanese smartphone owning friends) as this will be valuable for not just these 2 phones (there is an army of 007SH owners waiting on this unlock)
Shall we give the 007/009 a shot?
I can see mountains of the 007SH on the auction (mostly pink). Perhaps I should pick one up and take it for a spin. I am happy to try to do something to help out for all the help I am receiving.
Or perhaps the 009SH?
How hard would it be to crack the 007? The 009SH looks like it is supported in the latest release kit.
Thoughts?
Currently, the 003/005SH are going to be the easiest, because they have the custom kernel which allows access to the "_modem" image. To do it on the 007SH we need to build a custom kernel (compiled from the sources available on the ktai-dev site), and add the modem access code (this is in the src directory of the rootkit). Not impossible, but i dont have a Linux machine to compile the sources.
However i think that the code will be fairly universal. Once we find it on the 005SH we will know what we are looking for on the 007SH as well. That will make many people happy
Anyway, my 005SH is under warranty/anshin plan so i dont mind if it gets bricked (especially now that we can take nand backups).
First things first though - examining the 005SH modem image. Does anyone know whether the NAND is a 16kb or 128kb block size? Or is it something completely different?
P.S. The DM009SH is just the Disney Mobile version of the 003SH
Linux machine no problem
I have a Linux server running 24/7 so compiling the kernel is easy. Don't let that be the holdup. I'll keep working on the 003SH _modem image.
DominikB,
I can't open this site [anago.2ch.net/test/read.cgi/smartphone/1319287551/] on channel2 for free. This site had been moved to the past-log storehouse. So.... I even can't look at Japanese version for rooting 003sh. It is very helpful if you can show me the steps for rooting 003sh.
Ok so I'm what you guys would call a newbie with Android, I've been an iPhone user for years (switched from Verizon to AT&T to get the iPhone because at the time it was an AT&T exclusive). However I'm a really big Google enthusiasts so I have followed Android from inception. Growing tired of how bad AT&T's reception was in my house I recently switched back to Verizon and I purchased the GS4. I'm very happy that I can make calls without the use of a Micro Cell, truthfully reliable coverage was the biggest reason why I switched carriers. Else I would probably got the GS4 or HTC 1 on AT&T.
Being a newbie I made some noob mistakes, however I'm glad to report non of my mistakes bricked my phone. My phone works flawless it's only the stock recovery that is jacked up. So to start off I naively though all S4's were 100% open when rooted, by that I thought I could simply install any ROM I wanted to as long as I was rooted. However it appears that Verizon made Samsung lock the firmware with the OTA updates, from what I gather now after reading is the initial firmware was ok but the subsequent OTA downloads introduced the locked boot. Which sucks for me because I willingly took both updates which put the ME7 and now the MI1 builds on my device.
When I started to root process I had the MI1 build and I performed the De LaVega root method (thank you Tomsgt for your videos)! At the time of root and right after the root I was still not aware of the difference with builds. At that point I attempted to install TWRP via GooManager, since I had the MI1 build it did not work. GooManager kept telling me there was no file for my phone or something similar.
Now this should have been huge red flag for me but I was persistent and I looked on TWRP's website and found the file for my phone along with the manual install instructions. I'm familiar with using a Linux command line so followed the instructions to write TWRP into /dev/block/mmcblk0p21 on my device.
After reboot my device failed to get into stock recovery mode, instead it goes back into download mode but has an extra line of text that says "Could not do normal boot". Since I originally hosed my stock recovery I have read up on the different builds and I have also successfully installed the clockmod recovery option. That all works fine it's just factory recovery is still hosed up and it's annoying me!
I know that was a bit long winded but wanted to give a little background. Now I hope I'm not the only guy/girl who has jacked up the stock recovery section. I was hoping someone had some instructions to fix. Heck I think (but I'm not 100% sure) that if I can get someone who still has stock recovery to copy/export what they have in /dev/block/mmcblk0p21, then I can download that file put on my sd card and then write that back into my system using the same dd input/output command I did before.
May not be that easy but that's what I'm hoping for, or maybe some suggestions. :fingers-crossed:
Thx,
Joe
Questions and help issues go in Q&A and Help section
Thread moved
Thanks
FNM
kennyglass123 said:
Questions and help issues go in Q&A and Help section
Thread moved
Thanks
FNM
Click to expand...
Click to collapse
Thanks kennyglass123, sorry it was posted in the wrong area!
Again I don't know if this will work but it's worth a try. For anyone who has a rooted Verizon GS4 and can get into stock recovery with no issues can I have you copy and export what's in /dev/block/mmcblk0p21 to an external file? For those who may not be familiar with Linux I have a few commands you can run below.
1.) Using terminal emulate create a folder to store the file on external card, in my example below I named it "StockRecovery" but you can name it whatever you want.
2.) su
3.) mkdir -p /storage/extSdCard/StockRecovery
4.) dd if=/dev/block/mmcblk0p21 of=/storage/extSdCard/StockRecovery/mmcblk0p21
This should create a file named mmcblk0p21 under the StockRecovery folder of your external SD card. If you could then either attach that file here or maybe upload the file to a public dropbox, or even e-mail that file to me I would really appreciate it!
Not sure this will fix my problem but it's worth a shot!
Thx,
Joe
garzjoe said:
Thanks kennyglass123, sorry it was posted in the wrong area!
Again I don't know if this will work but it's worth a try. For anyone who has a rooted Verizon GS4 and can get into stock recovery with no issues can I have you copy and export what's in /dev/block/mmcblk0p21 to an external file? For those who may not be familiar with Linux I have a few commands you can run below.
1.) Using terminal emulate create a folder to store the file on external card, in my example below I named it "StockRecovery" but you can name it whatever you want.
2.) su
3.) mkdir -p /storage/extSdCard/StockRecovery
4.) dd if=/dev/block/mmcblk0p21 of=/storage/extSdCard/StockRecovery/mmcblk0p21
This should create a file named mmcblk0p21 under the StockRecovery folder of your external SD card. If you could then either attach that file here or maybe upload the file to a public dropbox, or even e-mail that file to me I would really appreciate it!
Not sure this will fix my problem but it's worth a shot!
Thx,
Joe
Click to expand...
Click to collapse
Bump....
Still hoping there is someone out there who can help me out.
garzjoe said:
Bump....
Still hoping there is someone out there who can help me out.
Click to expand...
Click to collapse
If your phone is bricked I would recommend the Verizon Repair Assistant.
THIS IS A LAST RESORT.
This will fully update your phone but it will fix any errors.
southpaw5271 said:
If your phone is bricked I would recommend the Verizon Repair Assistant.
THIS IS A LAST RESORT.
This will fully update your phone but it will fix any errors.
Click to expand...
Click to collapse
Hmm I can investigate that but my phone is not bricked. I'm using it now to reply to you. Stock recovery is hosed...so when I power off and then hold Vol+, Power, Home key and then let go of power and keep holding the other two buttons. That key sequence gets my phone into recovery mode. However I can't get into that with my phone anymore.
Thx,
Joe
Hello,
I'm willing to try and build a custom rom, but I've been diving through the site for a few days and I still don't get it. I believe I do have the required background to do this: programming, linux, etc. and I have wide experience as a phone user, etc. It's just that either I'm not reading what I need or the way I want it. The problem, I believe, is that all I find are guides telling me to install this and those tools and then open this and that and voila! you got your rom. But they're not explaining WHAT exactly goes into those roms, or what is expected to go there, what's the purpose of those contents, etc., and I can't really catch with that. I feel at a loss and hate wasting my time turning around for nothing.
1. I don't understand the difference between a flashable rom and one that is meant to be installed through recovery, although I can see they're different. Do they both models contain the same kind of data? Is there any restriction to what one model can contain over the other one? If so, how would I convert from one to the other? But please, don't tell me to use this or that tool. I just need the theory behind it. Something of sorts like: "You need to extract this or that from this tarball, then mount this image, then the directory tree there goes in that directory over the other model of rom"
2. update-binary: Okay I guess this is run when installing from recovery, and this takes care of installing the rom, right?wrong?. Is this a per-rom thing, per-device thing? generic? If it's per-rom, how to generate it? do I need to compile something? Is there any generic source code that can be used as a start?
3. Although I have a basic understanding of how the Linux directory tree works, I know Android works on top of a heavily modified Linux. So can you explain briefly how the directory tree works? For instance, I believe /data/data is where Android apps install to, in /system/bin or xbin I can find busybox binaries/symlinks if present. /dev and /proc look the same as in Linux. I don't know about /sys. Also how are both rom models deployed to this tree? What is basically being copied?
4. If I were to compile a kernel, where do I find the Android kernel sources? or is it just a generic Linux kernel? where can i get a basic config for the device? Last time I checked my device hadn't /proc/config.gz but maybe I could get it from another rom with it enabled or something. What toolchain and where to get it? Oh and if you know of a native arm version of gcc or whatsnot, I'd prefer that. Setting up IDEs or toolchains is a nightmare. I don't like crosscompiling. But crosscompiling or not, a directory with all needed binaries without needing to set up system variables nor other stuff, would be amazing.
I surely have a lot more questions that I can't get from the back of my mind now, and I'll have yet more as you explain. But the point of my questions was mainly trying to explain the degree of the loss I'm at, so you can assist me better.
If it looks like a foolish petition, well, that's because I'm quite stubborn and can't catch things that don't go my way. I really need to understand the basics before I can move into actually doing something. I want to build a rom for the right reasons(to me). It's not just about packing a set of apps or themes with it, but about learning and doing other stuff like trying to fix things that are not supposed to work for the device in that Android version, etc.
If you can't help, congrats for reading through here anyways But any help is greatly appreciated :good:
oxiroxt said:
Hello,
I'm willing to try and build a custom rom, but I've been diving through the site for a few days and I still don't get it. I believe I do have the required background to do this: programming, linux, etc. and I have wide experience as a phone user, etc. It's just that either I'm not reading what I need or the way I want it. The problem, I believe, is that all I find are guides telling me to install this and those tools and then open this and that and voila! you got your rom. But they're not explaining WHAT exactly goes into those roms, or what is expected to go there, what's the purpose of those contents, etc., and I can't really catch with that. I feel at a loss and hate wasting my time turning around for nothing.
1. I don't understand the difference between a flashable rom and one that is meant to be installed through recovery, although I can see they're different. Do they both models contain the same kind of data? Is there any restriction to what one model can contain over the other one? If so, how would I convert from one to the other? But please, don't tell me to use this or that tool. I just need the theory behind it. Something of sorts like: "You need to extract this or that from this tarball, then mount this image, then the directory tree there goes in that directory over the other model of rom"
2. update-binary: Okay I guess this is run when installing from recovery, and this takes care of installing the rom, right?wrong?. Is this a per-rom thing, per-device thing? generic? If it's per-rom, how to generate it? do I need to compile something? Is there any generic source code that can be used as a start?
3. Although I have a basic understanding of how the Linux directory tree works, I know Android works on top of a heavily modified Linux. So can you explain briefly how the directory tree works? For instance, I believe /data/data is where Android apps install to, in /system/bin or xbin I can find busybox binaries/symlinks if present. /dev and /proc look the same as in Linux. I don't know about /sys. Also how are both rom models deployed to this tree? What is basically being copied?
4. If I were to compile a kernel, where do I find the Android kernel sources? or is it just a generic Linux kernel? where can i get a basic config for the device? Last time I checked my device hadn't /proc/config.gz but maybe I could get it from another rom with it enabled or something. What toolchain and where to get it? Oh and if you know of a native arm version of gcc or whatsnot, I'd prefer that. Setting up IDEs or toolchains is a nightmare. I don't like crosscompiling. But crosscompiling or not, a directory with all needed binaries without needing to set up system variables nor other stuff, would be amazing.
I surely have a lot more questions that I can't get from the back of my mind now, and I'll have yet more as you explain. But the point of my questions was mainly trying to explain the degree of the loss I'm at, so you can assist me better.
If it looks like a foolish petition, well, that's because I'm quite stubborn and can't catch things that don't go my way. I really need to understand the basics before I can move into actually doing something. I want to build a rom for the right reasons(to me). It's not just about packing a set of apps or themes with it, but about learning and doing other stuff like trying to fix things that are not supposed to work for the device in that Android version, etc.
If you can't help, congrats for reading through here anyways But any help is greatly appreciated :good:
Click to expand...
Click to collapse
I am not terribly knowledgeable about all of this, but I will take a crack at it. Others can feel free to correct me.
1. "Flashing" is usually done through the recovery from a zip with an update script inside. That script is in a language called "edify". Read more about Edify Here and Here.
The only other common way that I know of installing a ROM is through fastboot in the bootloader, but that is normally only used with official factory images. Also, I think Samsung ROMs are often flashed with a proprietary program called Odin.
2. I think that the update-binary is standard across all recent devices. I think it is just an interpreter for the Edify scripting language. Old versions of android used a somewhat different scripting language and required a different file. You can probably pull the binary out of another recent zip and use that. The main thing you have to worry about is the update script (instructions for what the zip does) and the folder structure of the zip.
3. I am not confident to explain much here, but the apps and their data are stored in different places. User apps are stored in /data/app with app data stored in /data/data, I think. System apps are installed in /system/app. There is more files stored on the "sdcard" partition which can be internal or external, depending on the device.
4. Kernel sources are usually provided in the source code from whatever repo you are using. Different ROMs use different bases. Here is some info about grabbing the AOSP kernel sources with git: http://source.android.com/source/building-kernels.html
Many of the more popular ROMS have specific build instructions on their individual github pages (Cyanogen, Paranoid Android, etc), so you might what to look at those, too. Also, depending on the individual devices, there might be proprietary binaries sourced from the device or hardware manufacturers for things like camera drivers, graphics chips, etc.
If you want a walk through of the basic build process google has a tutorial. The last time I checked there seemed to be some outdated info, but it might give you a general idea of the build process. http://source.android.com/source/initializing.html
Hopefully someone more knowledgeable can give you more info, but that is all I got
synesthete said:
I am not terribly knowledgeable about all of this, but I will take a crack at it. Others can feel free to correct me.
1. "Flashing" is usually done through the recovery from a zip with an update script inside. That script is in a language called "edify". Read more about Edify Here and Here.
The only other common way that I know of installing a ROM is through fastboot in the bootloader, but that is normally only used with official factory images. Also, I think Samsung ROMs are often flashed with a proprietary program called Odin.
2. I think that the update-binary is standard across all recent devices. I think it is just an interpreter for the Edify scripting language. Old versions of android used a somewhat different scripting language and required a different file. You can probably pull the binary out of another recent zip and use that. The main thing you have to worry about is the update script (instructions for what the zip does) and the folder structure of the zip.
3. I am not confident to explain much here, but the apps and their data are stored in different places. User apps are stored in /data/app with app data stored in /data/data, I think. System apps are installed in /system/app. There is more files stored on the "sdcard" partition which can be internal or external, depending on the device.
4. Kernel sources are usually provided in the source code from whatever repo you are using. Different ROMs use different bases. Here is some info about grabbing the AOSP kernel sources with git: http://source.android.com/source/building-kernels.html
Many of the more popular ROMS have specific build instructions on their individual github pages (Cyanogen, Paranoid Android, etc), so you might what to look at those, too. Also, depending on the individual devices, there might be proprietary binaries sourced from the device or hardware manufacturers for things like camera drivers, graphics chips, etc.
If you want a walk through of the basic build process google has a tutorial. The last time I checked there seemed to be some outdated info, but it might give you a general idea of the build process. http://source.android.com/source/initializing.html
Hopefully someone more knowledgeable can give you more info, but that is all I got
Click to expand...
Click to collapse
OMG Finally some light! THANK YOU, THANK YOU, THANK YOU for all the info. I didn't get much right now, I'll need to read through your post a few times before I get it all, haha. I'll be sure to check the links too. Thank you!
Drawing from the impressive work of CrashXXL in rooting our phones, jahrule in simplifying the process, and Sabissimo in developing a tutorial to bake in apps for those of us with locked bootloaders and write protected systems, I have with great effort arrived at this glorious day. I present to thee: Suicide Flash.
What is Suicide Flash? It is a collection of Bash scripts and other files which streamline and automate the process of using the Qualcomm emergency download mode (Qualcomm HS-USB QDLoader) to write to the system partition on Moto phones using MSM8960 processors. It applies the method used to root these devices (see here, for example) to the task of arbitrary system modification. In other words: Suicide Flash makes it easy(ish) to modify system files for those of us who can't use traditional methods.
Code:
DISCLAIMER: This is obviously a dangerous tool. I mean, it
flashes your phone by bricking it first. Be smart. I shan't be held
responsible if your phone melts, explodes, loses all of its data,
or cheats on you with a hula dancer.
Who Can Use It?
Suicide Flash is for sure compatible with most Moto X variants. The testing has been done primarily with an XT1049, the Republic Wireless model, but has also included the XT1060 (Verizon) and should work on most/all of them. However, in theory any phone, or at least any Moto phone, using the MSM8960 chip could be compatible, such as the Droid Turbo. So to simplify:
XT1049 (Moto X Republic Wireless): Tested and working
XT1060 (Moto X Verizon): Tested and working
XT1058 (Moto X AT&T): Untested, highly likely to work
XT10XX (Any other Moto X): Untested, likely to work
Others: Untested, may work as long as they use MSM8960
How Do I Use It?
Suicide Flash (SF) consists of three main scripts: a flashing script, a package creation script, and a pushing script. Details:
suicideflash.sh: Flashes SF packages to the phone in bricked (QDLoader) mode
pkgmaker.sh: For developers. Creates SF packages from system images.
suicidepush.sh: Uses the SF system to "push" system files in an ADB-like way
To use these scripts, simply extract them to a place of your convenience. All scripts must be run from the root Suicide Flash folder. Do not run any of them from within the "scripts" folder. Also, while it may not strictly be necessary, it is best (if you are developer) to include any relevant system images in the root Suicide Flash folder, as well.
As an end user, you can download SF packages created by developers and flash them using the main Suicide Flash script. As a developer, you can pull system images and use them to create SF packages with the pkgmaker.sh script. Anyone can feel free to use the Suicide Push script to push files to their device. For more information, here are the help pages for each.
Suicide Flash:
Code:
Usage: suicideflash.sh PACKAGE
Flashes PACKAGE to the system parition of a Moto phone using Qualcomm
emergency download mode.
Options:
-h, --help displays this help message
-s, --skip skips all prompts and runs without user interaction
Created by the Nicene Nerd, whose blog at <http://www.thenicenenerd.com/> has
absolutely nothing to do with Android
Package Maker:
Code:
Usage: pkgmaker.sh [OPTION]... ORIGINALSYSTEM TARGETDEVICE REQUIREMENTS
SYSTEMOFFSET OUTPUTFILE
Creates a Suicide Flash package for writing to Moto phones via the emergency
Qualcomm download mode.
Arguments:
ORIGINALSYSTEM provides the original system image to be modded
TARGETDEVICE specifies the model of phone for the package to flash
REQUIREMENTS notes any important requirements for the phone state
prior to flashing
examples: "Stock", "Rooted", or "Rooted+Xposed"
SYSTEMOFFSET the address of the system partition on the target device
should be in hex format (i.e. 0x6420000 or 6420000)
can use value ADB to pull the offset over ABD
OUTPUTFILE the name of the Suicide Flash zip package to be created
Options:
-h, --help returns this help message
-m MODDEDSYSTEM specifies an existing modded system image
if not given, will mount original for modification
Created by the Nicene Nerd, whose blog at <http://www.thenicenenerd.com/> has
absolutely nothing to do with Android
Suicide Push:
Code:
Usage: suicidepush.sh LOCALFILE REMOTEFILE
Uses Suicide Flash to push LOCALFILE to a phone system at REMOTEFILE.
Created by the Nicene Nerd, whose blog at <http://www.thenicenenerd.com/> has
absolutely nothing to do with Android
What Do I Need to Use It?
A Linux installation
ADB
Fastboot
Rhino
Python
A package called python-serial
VirtualBox
ADB Insecure (if developing or using Suicide Push)
If you don't have some of these (except, obviously, the first one and the last one), you can run the included script install-tools.sh. It will automatically install anything you're missing.
Okay, Give Me Step-By-Step Instructions
For End Users:
Download the attached Suicide Flash zip
Extract the zip to a convenient folder and open a terminal window there
Go ahead and use sudo su
Run install-tools.sh
Download an SF package from a developer for your device
Flash the package with the command:
Code:
./suicideflash.sh DOWNLOADEDPACKAGE.zip
Profit!
For Developers:
Download the attached Suicide Flash zip
Extract the zip to a convenient folder and open a terminal window there
Go ahead and use sudo su
Run install-tools.sh
Pull a system image from your phone
Run pkgmaker.sh to create an SF package
Upload the package for the benefit of others
For Anyone, to Use Suicide Push
Download the attached Suicide Flash zip
Extract the zip to a convenient folder and open a terminal window there
Go ahead and use sudo su
Run install-tools.sh
Push files to your phone's system partition with this command:
Code:
./suicidepush.sh LOCAL_SOURCE /system/PUSH_DESTINATION
So, What Can I Do with It Right Now?
If you're a developer, you can get to work creating SF packages for your device. If you're just a plain ol' user, there's not much to be done until others chip in. I have uploaded one package as a sample and for the convenience of anyone looking to root their XT1049 and install Xposed. I will maintain a master list of uploaded packages as people make them.
XDA:DevDB Information
Suicide Flash for Moto, Tool/Utility for the Moto X
Contributors
Nicene Nerd, CrashXXL, Sabissimo
Version Information
Status: Testing
Created 2015-08-07
Last Updated 2015-08-07
Master Package List
XT1049: Republic Wireless Moto X
- root-xposed-xt1049-4.4.4.zip: Root and Xposed for XT1049. Requires stock 4.4.4 from SBF, not OTA.
- busybox-xt1049-rooted-xposed-4.4.4.zip: BusyBox for XT1049. Requires 4.4.4 rooted w/ Xposed.
XT1058: AT&T Moto X
- root-xt1058-4.4.4.zip: Root for XT1058 KitKat. Requires stock 4.4.4 from SBF, not OTA.
- xposed-xt1058-rooted-4.4.4.zip: Xposed for XT1058 KitKat. Requires rooted 4.4.4.
- root-xt1058-5.1.zip: Root for XT1058 Lollipop. Requires stock 5.1 from SBF, not OTA.
XT1060: Verizon Wireless Moto X
- root-xt1060-4.4.4.zip: Root for XT1060. Requires stock 4.4.4 from SBF, not OTA.
- xposed-xt1060-rooted-4.4.4.zip: Xposed for XT1060. Required rooted 4.4.4.
Changelogs:
08/07/2015 - v0.2
- suicideflash.sh: Increased wait period before giving error on not finding phone in emergency mode
- mountimg.sh: Fixed issue which would cause errors preventing images from mounting
- pkgmaker.sh: Added option to pull system image over ADB, improved error handling
Developer pkgmaker.sh Tutorial: Creating an Xposed Framework Package
Say you want to make a package that installs the Xposed framework, since that requires writing to /system. Here's how you would do it with Suicide Flash (assuming you have already rooted the phone):
Open a terminal window to your Suicide Flash root folder. Then sudo su.
Pull a system image. One way to do that:
Code:
adb root
adb shell dd if=/dev/block/platform/msm_sdcc.1/by-name/system /sdcard/originalsystem.img bs=1024
adb pull /sdcard/originalsystem.img
Run the pkgmaker script like this, assuming you're using a rooted XT1049 on 4.4.4, but you don't know the offset of the system partition, so you want to pull it via ADB. The script will be placed in output/xposed-flash-package.zip.
Code:
./pkgmaker.sh originalsystem.img XT1049 "Stock 4.4.4" ADB xposed-flash-package.zip
The script will pause when originalsystem.img is mounted for writing. As root, copy the Xposed app_process file (which you can extract from the APK if you need it) to "mnt-originalsystem.img/bin/app_process". Then press enter.
The script will continue executing, hopefully without errors.
Voila! Your package xposed-flash-package.zip is ready to upload and/or flash.
Finally!
The XT1049 has stumped me for a long time, but finally someone found a way!
Just a thought as I'm going into this, there's no mention of drivers for linux. Obviously this isn't to "user" level yet, and I wouldn't put myself too much beyond that, but it's a nice thing to include. I'll be trying it later, but are the drivers for USB/ADB the same as the emergency mode drivers? I'm kind of nervous to try because of the soft brick, and there doesn't appear to be any mention of how the flashed file that bricks it is put back. I'm assuming I can pull the original image before I flash the new one, but I'm not sure yet.
Also, if you have it tested and everything with Republic, I would appreciate a torrent or hosted file somewhere. If there isn't one before I finish, I'll post it.
---------- Post added at 09:42 PM ---------- Previous post was at 09:38 PM ----------
Cindex said:
The XT1049 has stumped me for a long time, but finally someone found a way!
Just a thought as I'm going into this, there's no mention of drivers for linux. Obviously this isn't to "user" level yet, and I wouldn't put myself too much beyond that, but it's a nice thing to include. I'll be trying it later, but are the drivers for USB/ADB the same as the emergency mode drivers? I'm kind of nervous to try because of the soft brick, and there doesn't appear to be any mention of how the flashed file that bricks it is put back. I'm assuming I can pull the original image before I flash the new one, but I'm not sure yet.
Also, if you have it tested and everything with Republic, I would appreciate a torrent or hosted file somewhere. If there isn't one before I finish, I'll post it.
Click to expand...
Click to collapse
Sorry for the double post but I can't edit yet, just realized that the zip file there is all that's needed for Republic. I was going to post the ADB/USB driver setup link for linux, but I'm not allowed yet.
Cindex said:
The XT1049 has stumped me for a long time, but finally someone found a way!
Just a thought as I'm going into this, there's no mention of drivers for linux. Obviously this isn't to "user" level yet, and I wouldn't put myself too much beyond that, but it's a nice thing to include. I'll be trying it later, but are the drivers for USB/ADB the same as the emergency mode drivers? I'm kind of nervous to try because of the soft brick, and there doesn't appear to be any mention of how the flashed file that bricks it is put back. I'm assuming I can pull the original image before I flash the new one, but I'm not sure yet.
Click to expand...
Click to collapse
You shouldn't need to do anything special for Linux drivers. It works straightforwardly as long as you have fastboot and ADB. The flashed file that creates the softbrick is included by the package maker script in every Suicide Flash package, so it is easy to unbrick. In fact, I can upload another package just for unbricking if you'd like.
Added a BusyBox package for XT1049, and added root and Xposed packages for XT1060.
Edit: also added root packages for XT1058 on both KitKat and Lollipop, plus Xposed for XT1058 KitKat.
Nicene Nerd said:
You shouldn't need to do anything special for Linux drivers. It works straightforwardly as long as you have fastboot and ADB. The flashed file that creates the softbrick is included by the package maker script in every Suicide Flash package, so it is easy to unbrick. In fact, I can upload another package just for unbricking if you'd like.
Click to expand...
Click to collapse
That's good to know, I looked around and couldn't find anything on the driver for the Qualcomm Emergency Download mode. I suppose not needing one would be why. Actually some kind of emergency package to unbrick might be good. Now that I see the script in there I don't have a problem, but someone might like it.
So now I'm wondering if I actually have to do a factory reset again, or if I can just flash the SBF file itself and not have to wipe. I'm not sure how big of a difference there is, because I did the factory restore recently and the OTA update was like 6MB or something. I wouldn't think there's be an issue flashing it rather than factory restore. Any ideas?
Also, if anyone knows a good way to do this with Virtualbox it would be a nice addition. I'm personally not going to bother since I already have a bootable Ubuntu USB, but it seems that most people would rather set up a VM with a small linux distro. If it had the tools baked in, it would make it an easy process.
Cindex said:
That's good to know, I looked around and couldn't find anything on the driver for the Qualcomm Emergency Download mode. I suppose not needing one would be why. Actually some kind of emergency package to unbrick might be good. Now that I see the script in there I don't have a problem, but someone might like it.
So now I'm wondering if I actually have to do a factory reset again, or if I can just flash the SBF file itself and not have to wipe. I'm not sure how big of a difference there is, because I did the factory restore recently and the OTA update was like 6MB or something. I wouldn't think there's be an issue flashing it rather than factory restore. Any ideas?
Also, if anyone knows a good way to do this with Virtualbox it would be a nice addition. I'm personally not going to bother since I already have a bootable Ubuntu USB, but it seems that most people would rather set up a VM with a small linux distro. If it had the tools baked in, it would make it an easy process.
Click to expand...
Click to collapse
Technically, the only reason for the SBF is because when you install OTA updates, files may end up in slightly different positions depending on the circumstances. For this to work, you must start with an identical system partition to the one used for making the package. So all you need to really do is extract the system.img and flash it, if you wish. No data loss necessary.
Also, I'll look into a minimal VM. I thought about actually trying to make a Windows version of Suicide Flash. I'm not sure which I'll end up with.
So I tried this on my Ubuntu 12.04.5 last night, and it didn't recognize the device in fastboot. I'm going to try on Ubuntu 15.04 soon here. Another question for you though, which sdk do I use for XPosed? I don't seem to be able to figure it out searching all over. I would think 16, but maybe it's for Lollipop?
I think I'm going to get some of these with the OTA, it'll make it easier for the average Republic user once it's gotten going.
Cindex said:
So I tried this on my Ubuntu 12.04.5 last night, and it didn't recognize the device in fastboot. I'm going to try on Ubuntu 15.04 soon here. Another question for you though, which sdk do I use for XPosed? I don't seem to be able to figure it out searching all over. I would think 16, but maybe it's for Lollipop?
I think I'm going to get some of these with the OTA, it'll make it easier for the average Republic user once it's gotten going.
Click to expand...
Click to collapse
I can't answer your Xposed Lollipop question. I was wondering the same thing, but I ended up simply pulling the file from an existing Xposed installation. I suppose you could do the same and then diff the files to find out which is correct.
As for the OTA, that's not possible. Every time an OTA is installed, the files can end up in different places on the flash memory, and this utility requires knowing the exact locations for making changes. You'd have to make separate packages for every phone. Otherwise you'll end up with bootloops.
Has anyone tried using Suicide Push? It's slow, but I thought it would be the more celebrated part of this since it lets you do basically the same as an ADB push to the system partition. You could even install Xposed that way:
Code:
./suicidepush.sh local_app_process_file /system/bin/app_process
Nicene Nerd said:
Has anyone tried using Suicide Push? It's slow, but I thought it would be the more celebrated part of this since it lets you do basically the same as an ADB push to the system partition. You could even install Xposed that way:
Code:
./suicidepush.sh local_app_process_file /system/bin/app_process
Click to expand...
Click to collapse
I'm still working on getting it to root. I was going to a few days ago, but my flash drive burned out. I'm going to try Ubuntu 14.04.3.
What linux distro did you use?
---------- Post added 14th August 2015 at 12:41 AM ---------- Previous post was 13th August 2015 at 11:47 PM ----------
Sorry to double post again, but I can't edit yet and have a few more things. I can't seem to be able to find a RW SBF file. I'm thinking restore from factory sounds like a good solution, but I don't know if that's the same thing.
How can I pull a system image if I'm not root? Without an SBF file, I need to package it for myself. Without root, I can't pull the system.img. I'm sure others on networks not covered yet would like to know also. Where did you get your system.img?
Also, if we can get this deep, and you can modify the bootloader, couldn't you just flash the old bootloader image and then the rest of the ROM? Then we could unlock the bootloader using older methods. We might have to flash block by block, but it should work?
Cindex said:
I'm still working on getting it to root. I was going to a few days ago, but my flash drive burned out. I'm going to try Ubuntu 14.04.3.
What linux distro did you use?
---------- Post added 14th August 2015 at 12:41 AM ---------- Previous post was 13th August 2015 at 11:47 PM ----------
Sorry to double post again, but I can't edit yet and have a few more things. I can't seem to be able to find a RW SBF file. I'm thinking restore from factory sounds like a good solution, but I don't know if that's the same thing.
How can I pull a system image if I'm not root? Without an SBF file, I need to package it for myself. Without root, I can't pull the system.img. I'm sure others on networks not covered yet would like to know also. Where did you get your system.img?
Also, if we can get this deep, and you can modify the bootloader, couldn't you just flash the old bootloader image and then the rest of the ROM? Then we could unlock the bootloader using older methods. We might have to flash block by block, but it should work?
Click to expand...
Click to collapse
I used Ubuntu 14.04.
The RW 4.4.4 SBF can be found here or here. It does not appear possible to pull a system image without root. But even without permanent root, KingRoot can get you temp root long enough to pull a system image.
As for the bootloader, there's certainly a chance that this could be done. It's just so risky that I won't try it myself. If there was a single variable missed, it could easily mean hard-brick. But in theory, as far as I understand, it might work. The biggest obstacle might be partition changes. If you got the bootloader to get into fastboot mode, though, you could presumably fix that with an old SBF.
Flashing the olderer bootloader will not work (I have tried and confirmed it does not work). It is because the efuses verify the bootloader.
Wow! That's hell of a tool you've created here Awesome job! I haven't tried it myself yet, but, judging by source code, it should get the work done. More of a developer tool, ofc, but it's more then impressive Maaan, I wish there was a normal way to work with ext4 partitions to make it available on Windows))
Since you've made "push" version of it (and that's the most interesting part, longest though), the next step in future development should be doing the same with TWRP flashable zips. Some of them just put apk-s in system folder, some of them have shell scripts inside, I've yet to figure out the pattern But that would be awesome next step to this awesome project
download link not found )
theres a tool bar at top crash with download links next to discussions and screenshots
Sabissimo said:
Wow! That's hell of a tool you've created here Awesome job! I haven't tried it myself yet, but, judging by source code, it should get the work done. More of a developer tool, ofc, but it's more then impressive Maaan, I wish there was a normal way to work with ext4 partitions to make it available on Windows))
Since you've made "push" version of it (and that's the most interesting part, longest though), the next step in future development should be doing the same with TWRP flashable zips. Some of them just put apk-s in system folder, some of them have shell scripts inside, I've yet to figure out the pattern But that would be awesome next step to this awesome project
Click to expand...
Click to collapse
I've actually started work on a Windows version, but it's on back burner because school just started. Here's a hint, though: with OSFMount and Ext2Fsd, you can mount Moto system images (pulled from the phone, not SBF ones) as hard drives or removable disks. Suicide Flash for Windows will rely on them.
So what are the chances I could use this to pull a system.img, and actually go in and delete some apps out of my XT1058? I had some success but it pulled the image as a mbn and I'm hesitant to try flashing it.
lpjunior999 said:
So what are the chances I could use this to pull a system.img, and actually go in and delete some apps out of my XT1058? I had some success but it pulled the image as a mbn and I'm hesitant to try flashing it.
Click to expand...
Click to collapse
Here's what you'll want to do:
Create the system image on the phone with
Code:
dd if=/dev/block/platform/msm_sdcc.1/by-name/system of=/sdcard/oldsystem.img bs=1024
ADB pull or MTP copy the image to your PC.
Run pkgmaker.sh like so:
Code:
./pkgmaker.sh oldsystem.img XT1058 "My System" 4B000000 modded-system.zip
When prompted, you can delete apps as root from the mounted system image under mnt-oldsystem.img/app or mnt-oldsystem.img/priv-app
Continue and finish the script.
Flash with
Code:
./suicideflash.sh -s output/modded-system.zip