Related
Hi chaps,
I've just bought a Galaxy tab with plans to port Meego to the device.
I'm new to all the Android stuff, and tbh the myriad methods for doing this/that/the other and the relative lack of explanation of what's actually being done in these various methods/tools is quite confusing (and worrying).
So, if you'll bear with me, I have a few questions which are probably quite basic.
I've rooted my Tab using SuperOneClick, no problems there, I also understand that there is a leaked flashing tool called (Multi)Odin and an open source flashing tool called Heimdall. I understand adb.
So onto the questions:
Before I start messing about, how should I backup my existing firmware image? I see people talking about taking image dumps using dd, or Odin or Heimdall. What is the preferred method? And how should one then restore the device from these backups?
Alternatively is it possible to simply download the firmware directly from Samsung (I see links to later firmware, but really I'd be happy with what I have currently - P1000XXJK5 and FROYO.XWJJ7)?
I'm assuming that the best installation method would be to replace recovery, then I can add my own kernel and have it boot a rootfs mounted on the external SD card for example. Any thoughts?
I've seen one thread about people compiling their own kernels, with panics and the like which are solved by giving the full path to the initramfs extracted from the existing image. Any clues as to why the built version doesn't work? This is not so important as I can have a look at this when I build the Samsung source.
Is anyone looking at the bootloaders? Is there any information anywhere about them (as changing the bootloader to allow selection of the kernel to be booted would make life easier)?
Thanks for your patience!
Ok, so to partly answer myself, I see www dot samfirmware dot com has links to downloads of firmware images.
I'd really prefer to generate my own image of what's currently on the device rather than trusting a download site, but I guess it's better than nothing. Does anyone know how these images were generated anyway?
lardman said:
Ok, so to partly answer myself, I see www dot samfirmware dot com has links to downloads of firmware images.
I'd really prefer to generate my own image of what's currently on the device rather than trusting a download site, but I guess it's better than nothing. Does anyone know how these images were generated anyway?
Click to expand...
Click to collapse
Samfirmware get their images direct from Samsung insiders. They are not dumps.
If you want to dump from your device search "rotobackup" here in the dev forum.
Sent from my GT-P1000 using Tapatalk
alias_neo said:
Samfirmware get their images direct from Saunaing insiders. They are not dumps.
Click to expand...
Click to collapse
Ok that's reassuring.
alias_neo said:
If you want to dump from your device search "rotobackup" here in the dev forum.
Click to expand...
Click to collapse
Great, just what I was looking for, many thanks
So some more questions:
Any limit to the size of the kernel? Presumably just the size of the partition (which after extracting the image for backup seems to be a pretty large 15.4MB)?
What do all the .rc files in the raminitfs do? They are as follows: fota.rc, init.goldfish.rc, init.rc, init.smdkc110.rc, lpm.rc, recovery.rc
The init.rc is the normal init.rc file, so that's fine. Presumably the recovery.rc file is run if the bootloader detects that recovery mode is wanted (holding down keys during boot). The init.goldfish.rc? I guess this is to do with the emulator, though why it would be in a release image I don't know.
I assume that init.smdkc110.rc is automatically run somewhere along the line, though I don't see where it's started.
Any thoughts on lpm.rc and fota.rc? Are multiple .rc files run for the normal and recovery boots?
Thanks
lpm.rc is for low power mode that displays battery charging animation
goldfish is for running the rom under qemu.
backup your rom using rotobackup. compile samsung's kernel from sources, mix up default initramfs with meego's init scripts. pack all Meego stuff into loop mounted disk image. then flash zImage to kernel and your disk image to factoryfs using heimdall. I assume you have experience hacking N8xx/N900 and Maemo or Meego?
factoryfs is around 300MB so I think it should fit Meego and it (and kernel) can be easily restored with heimdall.
Thanks for the comprehensive reply
Yes I do have experience hacking Maemo/Meego, though have never really had to fiddle with init scripts before and this is as good a reason as any to learn.
I'd actually like to dual boot, so am modifying recovery.rc to bring up the Meego system on the external SD card.
Am just fiddling about building extra kernel modules now (needs btrfs for my image for example) and modifying the recovery.rc file.
Hmm, well I was all set to go and flash my new zImage and was looking for the heimdall command line, when I saw this at the top of one of the threads in this part of the forum (http://forum.xda-developers.com/showthread.php?t=870690):
Restoring to factory after using this process (you need using stock images):
heimdall flash --kernel stockzImage --recovery stockzImage --factoryfs factoryfs.rfs
Click to expand...
Click to collapse
Which has made me worry a bit that I've missed a recovery partition with its own kernel and wrongly assumed that the same kernel is used for both recovery and normal running, just with a different .rc file to be interpreted by init.
Any thoughts?
Do we trust the partition sizes reported here: http://forum.xda-developers.com/showpost.php?p=9471190&postcount=14
They seem very small for the kernel partition. I used RotoHammer's dd method to grab the contents of the partitions as a backup, so am assuming the sizes shown above are not correct (or represent something else?)
Going back to RECOVERY and ZIMAGE partitions - the ZIMAGE partition contains a recovery.rc, the question is really whether, even if they use the same zImage in both the ZIMAGE and RECOVERY partitions, the version in the RECOVERY partition is actually booted if recovery mode is selected (by holding the up volume key, etc.)? OTOH it may be that the RECOVERY partition is either empty or unused, has anyone tested specifically to see whether recovery.rc is run from the ZIMAGE partition?
Well I think I can answer my own question there, I flashed my modified kernel (modified recovery.rc) only to the KERNEL partition, and it boots normally if I don't touch anything, and just gets stuck on the first Samsung screen if I boot in recovery mode.
So it's doing something, I just can't tell what. Not sure if any kernel messages are getting lost behind that image, or perhaps they aren't even output to the framebuffer at all. I seem to remember seeing something about disabling the splashscreen so I'll go and have a look for that. Anyone got any other suggestions?
P.S. I also note there's a flash of screen corruption as the device starts up with my new kernel, I don't remember seeing that before. Is this a usual occurance?
I see from the Nexus S port that including adbd in the image seems to be the way to go for early messages, I'll need to generate a new Meego image and have another go later on.
Interesting, I can't see that I've done anything wrong, and my extra init shell script is not started. I am trying to use the "exec" keyword in recovery.rc to start a shell script which will pass control to the Meego rootfs. At the start of my shell script I start adbd (i.e. still within the initramfs), so I should be able to tell if it has started, and it doesn't appear to do so.
Therefore I did some Googling, and I've seen that in some cases the initramfs init does not implement the "exec" keyword (http://forum.samdroid.net/f9/new-init-exec-import-implemented-3280/). This is troublesome for me as it's what I'm trying to use, but at least would explain why I don't seem to leave the init process
I couldn't see the Samsung specific source for init anywhere, has anyone found any? I'm not happy to replace it using the standard Android source as I'm guessing there's code missing which allows the bootloader to tell init how the device was started so that it knows which of the .rc files to run. Has anyone looked into this?
Thanks
Looking at the code in that link it looks pretty straightforward, just a case of parsing the kernel command line (though I might just reverse engineer the existing init first to make sure I'm not missing anything).
Would still be easier to get the actual source code from Samsung, so I've emailed their Open Source group.
lardman said:
P.S. I also note there's a flash of screen corruption as the device starts up with my new kernel, I don't remember seeing that before. Is this a usual occurance?
Click to expand...
Click to collapse
I get it with CM
Does CM use a compressed initramfs? I'm using one of those and wondering if it's something to do with the (admittedly small) extra time required to move to init.
I don't have my Tab with me here, could someone post the output of /proc/cmdline please? You'll need to be root. Thanks.
Well it's booting you'll all be glad to hear.
More details to follow, but from memory the following were required:
Custom kernel to add btrfs support (as the image I'm booting is a btrfs partition on the external SD); kernel patch to allow compile-time cmdline to be added to the end of the bootloader cmdline (to enable console=tty0); replace Android init with init script to perform some basic setup then pivot_root to the Meego partition.
Next steps are to get the Meego system running usefully (which includes getting a terminal as currently I just have a login prompt but no way of inputting anything!) and also seeing whether I can get dual booting working with an Android system standard boot and Meego replacing the recovery boot.
Poor pic, but still: http://people.bath.ac.uk/enpsgp/Tab/PICT0040.JPG
Good stuff. Thanks for keeping us informed.
After you've got the groundwork for this done, how easy would it be to get Ubuntu running?
Try google http://lmgtfy.com/?q=ubuntu+on+galaxy+tab
Sent from my GT-P1000 using XDA App
brilldoctor said:
Try google http://lmgtfy.com/?q=ubuntu+on+galaxy+tab
Sent from my GT-P1000 using XDA App
Click to expand...
Click to collapse
That's using chroot, which I don't want. I want it running natively.
Sent from my Galaxy Tab
//Version 1.0
Flash any SBF file to your device *without* RSDLite (Mac or Linux)
*using sbf_flash created by [mbm]
**UPDATE: THIS DOES NOT WORK WITH RADIO SBFS. YOU CAN USE CWM TO FLASH RADIO IMGS.
**IF YOU ARE UNLOCKED WITH CWM, YOU REALLY SHOULD HAVE NO NEED TO FLASH FULL SBF FILES. SEE SAMCRIPP'S FRUIT CAKE THREAD
This guide is for Mac OS or Linux users only!! I didn't see any dedicated guide for flashing SBF files for Mac users so i thought I would contribute something to this wonderful community.
Pre-Guide Information (SKIP BELOW FOR ACTUAL INSTRUCTIONS)
The standard prerequisite for flashing SBF files to our devices is RSD Lite, and as we all know, the only platform made available for RSD Lite is Windows. Mac or Linux users have always been required to either run Windows using a virtual machine or find a Windows computer to use. In my opinion, all of these methods are time consuming and can sometimes be very frustrating. Now we can VERY easily flash any SBF file using a simple utility called "sbf_flash" (created by [mbm]). The creator of this wonderful little utility deserves a lot of credit because he was able to make the executable work on both Mac and Linux platforms which is no small feat considering Mac OS X uses the mach-o executable file format while Linux uses ELF. It is very interesting how he was able to accomplish this so if you are interested to find out how or interested in learning more about this nifty little utility, visit his blog.
[mbm]'s Optical Delusion Blog: http://blog.opticaldelusion.org/
DISCLAIMER: The following procedures require you to be somewhat comfortable using terminal and some basic commands. All the standard warnings apply as well. I am not responsible if anything happens to your device. It is your responsibility to ensure you are flashing an SBF that is compatible with your device. Check and then double check for good measure. I also recommend checking the md5sum of the file you choose. Check both the compression md5sum and the actual SBF file md5sum. Follow the instructions carefully and heed the warnings about downgrading.
** DO NOT TRY TO DOWNGRADE TO 1.8.3 IF YOU HAVE FLASHED AN OTA UPDATE OF 4.5.91 **
---------------------------------------------------------------------------------------------------------------------------------------------------
INSTRUCTIONS
SBF_FLASH GUIDE FOR MAC OS X (linux users too)
Required Files to Download:
- sbf_flash utility ---> DIRECT DOWNLOAD
- sbf file of your choice **make 100% sure the SBF file you choose is compatible with your device**
** no drivers needed, thats the beauty of this method. so clean **
**There are 2 sets of Instructions, choose one. Novice and Expert (Scroll below for Expert).**
Detailed Instructions (Novice):
GET READY: As always when flashing SBF files, remove your SIM and microSD cards and power the device on by holding the Vol+ and Power.
Step 1: Download sbf_flash and place it in an easily accessible directory (e.g. /Users/username/Documents)
*You have to rename the file "sbf_flash" to "sbf_flash.sh" (thank you n1ckr0th)
Step 2: Place the SBF file you have chosen in the SAME directory you put sbf_flash (e.g. /Users/username/Documents/).
Step 3: Open up a terminal shell.
Step 4: In terminal, change to the directory where you have placed both files:
* SKIP TO STEP 5 IF YOU KNOW HOW TO USE TERMINAL *
// how to change directories in terminal
* in the following instructions, ignore the brackets when typing in the commands
- the command [cd] is what you use to change the directory. so if the files are in /Users/username/Documents, you would type [cd Documents]
- the command [ls] lists all the files and folders in the current directory. type [ls] and make sure you see both files before proceeding.
Step 5: We first need to make sbf_flash executable (thank you ionstorm3) by doing the following steps:
* once again, ignore the brackets when typing these commands
- type [sudo chmod +x sbf_flash.sh]
- it will now prompt you for your password. enter it *note: [sudo] is a command which gives temporary admin privileges for the preceding command.
- sbf_flash is now executable. continue
Step 6: Flash the image onto your phone:
- type [sudo ./sbf_flash.sh nameofyourSBFfile] (example: if your SBF file is called "atrix.sbf", you would type [sudo ./sbf_flash.sh atrix.sbf]
- once again, it will prompt you for your password. enter it again.
- you are now done.
If you followed the above steps correctly, the SBF file will now begin flashing onto your device. Sit back, grab a brew, and relax.
*TIPS: when you are typing in the names of files or folders in terminal, you can hit the [tab] key after you have typed in the first few letters of the file or folder and terminal will autocomplete the rest. This is especially useful if your SBF file has a long name (e.g. OLYFR_U4_1.8.3_SIGNED_1g_1FF.sbf) in this case, if you just type OLYF then hit the [tab] key, terminal will autocomplete the rest of the filename for you. Very useful!
---------------------------------------------------------------------------------------------
EXPERT INSTRUCTIONS:
1. Download sbf_flash utility and place in easily accessible directory
2. Download SBF file of your choice and place in same directory
3. Open up a terminal shell and [cd] into that directory
4. Execute following command [sudo chmod +x sbf_flash.sh] - this makes sbf_flash exectuable (thanks ionstorm3)
5. Execute following command [sudo ./sbf_flash.sh nameofyourSBFfile] - this flashes your SBF file to your device.
6. Done son.
Well folks, that is it. In my opinion, this is the fastest and easiest way for Mac and Linux users to flash SBF files. Now we can finally do all our rooting/flashing/etc. on one machine. If you have any questions/concerns/problems, please feel free to PM me. Also, if you have any suggestions on improving this guide, let me know. Now it is time for me to give credit to those that deserve it.
CREDITS:
[mbm] for creating sbf_flash and making it work perfectly on both Mac and Linux platforms.
ionstorm3 - thank you very much for not only essentially providing me with the cream of this guide, but promptly responding to my initial concerns.
XDA Community: thank you for well……everything. this is such a great community with many helpful members.
This doesn't work for radio SBFs I believe?
Sent from my MB860 using XDA App
working with Ubuntu
I had no luck using sbf-fash until I updated the udev rules. it would just hang and not flash anything, after updating udev it works perfectly. I do not know if user on Linux other then Ubuntu will have this problem but if they are they may want to check out http://forum.xda-developers.com/showthread.php?t=921169 and look at step 5. This is a walk-through of getting adb setup and working under Ubuntu and is a very helpful post.
neer2005 said:
This doesn't work for radio SBFs I believe?
Click to expand...
Click to collapse
Not sure about that, I will have to test that out tonight.
neer2005 said:
This doesn't work for radio SBFs I believe?
Sent from my MB860 using XDA App
Click to expand...
Click to collapse
this is actually a very good question that I do not know the answer to. but i will do my best to find out
arvindrao86 said:
this is actually a very good question that I do not know the answer to. but i will do my best to find out
Click to expand...
Click to collapse
I can confirm that this (unless terminal lied to me) works with the 4591Radio.sbf file provided by kenn for his rom.
also, you might want to change the op to say that you need to either rename the sbf_flash file to .sh after you download it and change the third step to include the .sh extension (sudo ./sbf_flash.sh nameofradio) or remove it from the first step because it didnt work until i added the .sh and included it in all the commands.
n1ckr0th said:
I can confirm that this (unless terminal lied to me) works with the 4591Radio.sbf file provided by kenn for his rom.
also, you might want to change the op to say that you need to either rename the sbf_flash file to .sh after you download it and change the third step to include the .sh extension (sudo ./sbf_flash.sh nameofradio) or remove it from the first step because it didnt work until i added the .sh and included it in all the commands.
Click to expand...
Click to collapse
thank you for the confirmation of radio flashing and for the obvious flaw in my instructions.
Stop flashing with sbf... You guys have more safer methods using cwm.
Sent from my MB860 using Tapatalk
CWM for radios?
n1ckr0th said:
I can confirm that this (unless terminal lied to me) works with the 4591Radio.sbf file provided by kenn for his rom.
Click to expand...
Click to collapse
Didn't seem to work for me w/Debian Squeeze, I'm afraid.
Code:
debian:/# ./sbf_flash.sh 4591Radio.sbf
SBF FLASH 1.23 (mbm)
http://opticaldelusion.org
=== 4591Radio.sbf ===
00: RDL03 0x00000000-0x002FFFFF 9FC5 AP
01: RDL01 0x00800000-0x008407FF 36FF BP
02: CG05 0x00000000-0x013E3BF7 E0E7 BP
>> waiting for phone: Connected.
>> uploading RDL03: 100.0%
-- OK
>> verifying ramloader
-- OK
>> executing ramloader
-- OK
>> waiting for phone: Connected.
>> sending erase
-- OK
>> rebooting
AnalogXDA said:
Didn't seem to work for me w/Debian Squeeze, I'm afraid.
Code:
debian:/# ./sbf_flash.sh 4591Radio.sbf
SBF FLASH 1.23 (mbm)
http://opticaldelusion.org
=== 4591Radio.sbf ===
00: RDL03 0x00000000-0x002FFFFF 9FC5 AP
01: RDL01 0x00800000-0x008407FF 36FF BP
02: CG05 0x00000000-0x013E3BF7 E0E7 BP
>> waiting for phone: Connected.
>> uploading RDL03: 100.0%
-- OK
>> verifying ramloader
-- OK
>> executing ramloader
-- OK
>> waiting for phone: Connected.
>> sending erase
-- OK
>> rebooting
Click to expand...
Click to collapse
I assume that you can flash other sbf files??
Also for me running Ubuntu 11.04 I have no need to rename it to a .sh but I guess if it works it works, that is the important thing.. Just for myself what shell are you using, I use bash.
Worked for me in Mac OSX (at least the radio flash). Also, no need to add the .sh extension in OSX.
Thanks for posting this, I've been trying to figure out how to use the new sbf_flash. I wasn't aware of the need to mark it as executable.
Tao_Man said:
I assume that you can flash other sbf files??
Also for me running Ubuntu 11.04 I have no need to rename it to a .sh but I guess if it works it works, that is the important thing.. Just for myself what shell are you using, I use bash.
Click to expand...
Click to collapse
Yep, I used sbf_flash to unlock the bootloader. I'm using bash, via Xfce terminal emulator.
getabetterpic said:
Worked for me in Mac OSX (at least the radio flash). Also, no need to add the .sh extension in OSX.
Thanks for posting this, I've been trying to figure out how to use the new sbf_flash. I wasn't aware of the need to mark it as executable.
Click to expand...
Click to collapse
the .sh was only added for consistency throughout the instructions.
The author is [mbm], not "Optical Delusions" ... that's just the name of his blog. And no, it does not flash your radio.
16:03 < [mbm]> anyway, sbf_flash can't reflash baseband
19:21 < [mbm]> right, sbf_flash has never touched the bp
19:21 < [mbm]> it just skips over those sections of the sbf
It's a great tool, but I think this thread belongs in General.
eval- said:
The author is [mbm], not "Optical Delusions" ... that's just the name of his blog. And no, it does not flash your radio.
16:03 < [mbm]> anyway, sbf_flash can't reflash baseband
19:21 < [mbm]> right, sbf_flash has never touched the bp
19:21 < [mbm]> it just skips over those sections of the sbf
It's a great tool, but I think this thread belongs in General.
Click to expand...
Click to collapse
changed guide to reflect correct credits. and agreed. this thread can and should be moved to general.
neer2005 said:
This doesn't work for radio SBFs I believe?
Click to expand...
Click to collapse
Correct, sbf_flash has never flash radio. You will see RDL01 & CG05 don't even upload.
AnalogXDA said:
CWM for radios?
Click to expand...
Click to collapse
Sure. I posted one here for baseband version N_01.100.00R for example. Kudos to SamCripp for discovering we can now CWM the baseband.. in the past, before unlock (and when CWM was not in the recovery partition and ran via the charge_only_mode hack) we could not.
getabetterpic said:
Worked for me in Mac OSX (at least the radio flash)
Click to expand...
Click to collapse
No, it didn't. Prove it to yourself: check the baseband version in about phone. Unless [mbm] in the future adds support for talking to the BP (baseband processor) sbf_flash will not do radio. You will notice the baseband version in 'about phone' doesn't change as you flash different radios.
ceo.mtcl said:
Stop flashing with sbf... You guys have more safer methods using cwm.
Sent from my MB860 using Tapatalk
Click to expand...
Click to collapse
Agree 100%
Sent from my unlocked atrix.
This still worked like a charm so thank you.
Sent from my MB860 using XDA App
Any idea if this can be done for other Moto devices as well? What needs to be changed? I tried it as instructed with my Droid Pro using OSX 10.7.3 and it didn't work. Didn't brick my phone or anything. I can post my output if that would help.
BenSWoodruff said:
Any idea if this can be done for other Moto devices as well? What needs to be changed? I tried it as instructed with my Droid Pro using OSX 10.7.3 and it didn't work. Didn't brick my phone or anything. I can post my output if that would help.
Click to expand...
Click to collapse
Old thread here I know but I am looking for some confirmation and maybe someone will answer. I am wanting to flash my phone back but do not have a carried specific SBF (Alltel). I will have to use a Verizon SBF but I don't want to flash the radio. Are we sure that this will not flash the radio so I will not lose my data connectivity?
I ran through the steps with the phone not connected and this is what I see:
SBF FLASH 1.24 (mbm)
http://opticaldelusion.org
=== SBF.sbf ===
00: RDL03 0x82000000-0x8204CFFF B942 AP
01: RDL01 0x00150000-0x001FFFFF DEFA BP
02: CG03 0x00000000-0x00904367 6F6F BP
03: CG31 0xB0280000-0xB02847FF 0EB7 AP
04: CG33 0xB1900000-0xB24C07FF 5CC1 AP
05: CG34 0xB0700000-0xB07047FF 75F3 AP
06: CG35 0xB1000000-0xB13FFFFF 119D AP
07: CG39 0xB2A00000-0xC41C07FF A8ED AP
08: CG42 0xB0800000-0xB083FFFF AC60 AP
09: CG47 0xB1400000-0xB18FFFFF 5728 AP
10: CG61 0xB0B00000-0xB0B7FFFF 5D7F AP
11: CG64 0xB0000000-0xB00047FF 1768 AP
12: CG65 0xB0180000-0xB01847FF 7167 AP
13: CG66 0xD0000000-0xDFFFFFFF 9B93 AP
>> waiting for phone:
Any help???
First, please forgive me if this is posted in the wrong section. It seemed most appropriate.
Second, I take no credit for anything here except for writing the .bat file here used to do the work, as well as assembling the files as per the original post.
All credit goes to djmwj and his article found here:
http://rootzwiki.com/topic/8722-lenovo-ideapad-k1-rooting-guide-messy/
As the title states, it was very messy. The OP figured out how to make it go, but it was a bit fuzzy to follow. So, I thought I'd help folks out a bit and clean things up.
So, I took the instructions presented in the OP, and condensed them into one download with one .bat that does everything from start to finish, minus installing the respective drivers for ADB and NVFlash. However, the drivers are included in the download.
Instructions:
1. Extract K1Root.rar to the directory of your choosing.
2. Connect your tablet to your PC with the USB cable.
3. With your tablet off, press POWER+VOL_UP+VOL_DOWN until the screen turns on, but displays only black.
4. Windows should detect the device, but not install drivers.
5. Go into device manager, select the APX device, choose update drivers, and install the drivers from the aptly named NVFlash_Drivers folder.
6. Open up the NVFLASH_HOME folder and run the file K1Flash.bat
7. Make your desired choices when prompted, and enjoy.
Notes (PLEASE READ BEFORE USING):
THERE MAY BE BUGS! I used it on my own stuff before releasing, and all of the essential components work as they should, however, there may possibly be a minor hiccup somewhere in the script. This should not damage anything. If you have doubts, you're welcome to examine the .bat and check it for yourself.
Please be gentle. I am not a full-time developer. I just wrote this to help make the process simpler for people.
The OP suggests you download and read the partition table, and then name the backup files based on that. This script names the backup files based on the flash.cfg script referenced in the OP, which is what controls the flashes used anyway. So, there shouldn't be any irregularities, however, I can't speak for every device on the planet.
This does NOT use the latest OTA updates. The rooted files being flashed are the default ones from the original download. You can easily adapt this to any files generated from the latest OTA files by simply dropping them in the NVFLASH_HOME file.
To install the SU properly, you have to install ADB drivers midway through the script. There's probably a way around this, but I didn't find it to be too inconvenient.
The ADB drivers are also located in the NVFLASH_HOME folder. Just do like you did when installing drivers in step #5, but instead point to NVFLASH_HOME.
Um...um...
That should be it. Obviously, use at your own risk. Let me know if there are problems with the script, and I will fix them.
Oh, and party on, Wayne.
http://www.megaupload.com/?d=AG10XE25
EDIT:
Attached is an updated .bat file which fixes a few errors in the original script, plus adds more userability. Just extract to the NVFLASH_HOME folder and run.
digitalhigh said:
First, please forgive me if this is posted in the wrong section. It seemed most appropriate.
Click to expand...
Click to collapse
You may want to change the title to Ideapad K1, I don't know if this will work for the Thinkpad tablet.
Thanks for this, I just picked up this tablet ($250 at staples) and was worrying about having to tackle linux and "compiling" just to be able to get hulu.com working. You're a lifesaver.
gallahad2000 said:
You may want to change the title to Ideapad K1, I don't know if this will work for the Thinkpad tablet.
Thanks for this, I just picked up this tablet ($250 at staples) and was worrying about having to tackle linux and "compiling" just to be able to get hulu.com working. You're a lifesaver.
Click to expand...
Click to collapse
Wow. Yeah, I'm pretty sure the key used is just for the Ideapad. Thanks for pointing that out. My dumb a$$ must've blanked out and just used the group name when posting.
And just to be fair, the original poster does include everything needed to do stuff in windows as well - it's just very hard to discern from the post.
question
Is anyone working on a custom ROM for this tablet? I am hopeing that there will be at least a few custom roms available at some point in the near future.
jfkerekes said:
Is anyone working on a custom ROM for this tablet? I am hopeing that there will be at least a few custom roms available at some point in the near future.
Click to expand...
Click to collapse
We need to be able to root and unlock the bootloader first.
Does the root method work on the 121211 update?
Or is there a way to flash back to the older firmware?
the OTA update 12 12 11.... seems to be update.zip style with no .img files inside. just loose files like normal rom updates. doesnt seeem like you can drop the files in as suggested. or i have the wrong OTA....
oh and is this for LINUX as the OP or work in windows too??
Hi, I was wondering, is this procedure works for the Lenovo ThinkPad 1838-25U? I'm thinking to buy it to give a test ride, i sold my Transformer 101 to buy the Prime but it seems like Asus is taking vacations on the delivery shipments. Is this a good tablet? or is better to wait for another version?
READ THE POST
IDEApad not THINKpad. no it wont work.
First of all- thank you so much for creating this script! I have been putting off rooting this device due to the "messy" nature of the original post.
I was hoping you could help me troubleshoot, I have tried both the new K1 root application and the original .bat file. I know the drivers are working because the script makes it as far as creating and formatting partitions and successfully pushes the bootlooder.bin but then:
bootloader.bin sent successfully
file not found: recovery.img
failed executing command 2147483647 NvError 0x4
command failure: create failed
I've tried everything I can think of... any ideas?
Thanks again.
I found problem.
after root done follow step. I cannot factory reset and update any ota.
anyone can help me ?
taiz said:
I found problem.
after root done follow step. I cannot factory reset and update any ota.
anyone can help me ?
Click to expand...
Click to collapse
Yes you have to roll-back to 04 stock and then apply the OTA's
Backup of the stock lenovo .apks!
File 1:http://www.mediafire.com/?r7iskr3wrfx4u01
File 2:http://www.mediafire.com/?fymdv9e9kmj332s
File 3:http://www.mediafire.com/?w33k205ej4fpbcl
A big thanks to Khanning who was nice enough to walk me through the adb commands and bear with me when I couldn't get adb over usb to work.
This may fix your issues http://forum.xda-developers.com/showpost.php?p=21309379&postcount=50
Can someone help I used this and I installed drivers from the drivers folder fine ....I ran option 1 fine and it said completed but said something about nvflash error make sure drivers are installed ....but on my tablet it said phone update success ....when I try option three to flash image it just stays at nvflash started and goes no further and when I try to install Su it won't connect adb , probably cause adb drivers wouldnt install ....any advice ....device is booting and seems stock ....it did not wipe my files either
Sent from my HTC EVO 3D X515a using XDA App
maek_it_happen said:
Can someone help I used this and I installed drivers from the drivers folder fine ....I ran option 1 fine and it said completed but said something about nvflash error make sure drivers are installed ....but on my tablet it said phone update success ....when I try option three to flash image it just stays at nvflash started and goes no further and when I try to install Su it won't connect adb , probably cause adb drivers wouldnt install ....any advice ....device is booting and seems stock ....it did not wipe my files either
Sent from my HTC EVO 3D X515a using XDA App
Click to expand...
Click to collapse
It means you are not in APX mode. Read the PDF and follow the instructions for installing the APX drivers. This should fix your issues.http://forum.xda-developers.com/show...9&postcount=50
I just completed step 3 flashing the image went fine up to bootloader .bin sent successfully ...then it says
File not found recovery.img
Failed executing command 2147473647 Nverror 0x4
Command failure : create failed
Edit the link u posted is not working and the drivers are installed
Edit 2 I just downloaded ur v2 root tool in ur other thread ....for some reason ur flash me Command actualy went past the recovery img error I was having with this tool .... But yours is flawless
Sent from my HTC EVO 3D X515a using XDA App
maek_it_happen said:
Edit 2 I just downloaded ur v2 root tool in ur other thread ....for some reason ur flash me Command actualy went past the recovery img error I was having with this tool .... But yours is flawless
Click to expand...
Click to collapse
Glad to hear it worked for you.
TD
I recently got this device and looking for a way to root this device without having to roll back to the factory default rom and then having to update again using OTA.
Question, am I in luck, is that at all possible or do I have to really rollback and reinstall everything again?
Thanks!
Sent from my K1 using Tapatalk
Anyone have the root? Megaupload is down forever.
The attached archive includes 3 tools for those of you with .3.2.3.2 (or earlier) bootloaders.
Since other tools (and earlier version of these very tools) are available and working well,
this is mostly meant as an entry to an imaginary beauty contest. (JOKING!!!)
cuber.py
a generic gmpy2-free reimplementation of @vortox's signature.py
use this to generate your unlock.img
cuboot.py (uses cuber.py)
a Python-only reimplementation of @vortox's cuber
includes fixes to the kernel command-line and the device-tree
use this to convert a standard Amazon boot.img (>=.4.x.x)
upHDX (uses cuboot.py)
bash script to repack Amazon updates for TWRP
could be DANGEROUS, use with care
tested on Apollo for both 14.4.5.2 and 14.4.5.3
my unit is fully 14.4.5.3 now, except for aboot (which is 3.2.3.2)
should work on Thor as well
Those with bootloader .3.2.6 and lower can downgrade to .3.1.0
and upgrade the bootloader to the latest vulnerable version .3.2.3.2.
Those with .3.2.7 and higher appear to be out of luck with forged signatures, but I hear there's progress on rooting .4.5.2.
The python scripts have been tested on the following OS / Python combinations:
Windows: 2.7.9 and 3.4.3
Linux: 2.7.9 and 3.3.4
OSX: 2.6.? (cannot quite remember)
In addition to the tools themselves, I also included "educational" examples
(examples.sh for Linux/OSX, examples.bat for Windows).
These make use of the split.py script, which is otherwise unnecessary.
(The Windows example also shows that simply echoing your manfid/serial
combo to cuber.py -the way one does in Linux/OSX- won't work due to
the carriage-return character introduced by the echo command.
You'll need to handcraft a file matching the '0x%02x%08xn' format...)
Another batch file py..bat is meant as an extra aid for Windows users
to avoid trouble with setting paths and such. You should be able to simply
download and install your preferred Python version.
Open a command shell (cmd.exe), navigate to wherever you extracted the
archives, and type 'py PYTHON-SCRIPT ARGS' to run the Python scripts.
(This handholding intentionally does NOT work for the upHDX script.)
Hopefully, someone will find these simple tools useful.
EDIT: To unlock your bootloader (<=.3.2.3.2), you'll need adb and fastboot.
On Linux, most distributions package these separately. Look for android-tools-{adb,fastboot} or some such.
For Windows, you can get these from the official Android SDK (which is a **large** download,
with a lot more tools you won't need, if you don't already use them, but it's safe).
Alternatively, there's a very legit-looking project here an XDA, with a much smaller
download, fast install, and exactly the tools you need. I haven't used either... (-;
The actual unlock procedure is described here and here.
EDIT#2: I added another script 'cublock.py' to make unlock.img generation super easy both on Windows and Linux.
MD5( tools.zip) = c17fc91344bd3b4b040129a79a39741f
EDIT#3: Fixed issues with older versions of certain tools on Debian 7.
MD5( tools.zip) = 4f93ab667fd61db26c83675ce0bd6d9f
EDIT#4: Fixed a bug when 'cuber.py' is used directly from the command line.
MD5(tools.zip) = 67b4a6d65aa2b0aa3500b122c8a25290View attachment 3210856
XDA:DevDB Information
HDXtools, Tool/Utility for the Amazon Kindle Fire HDX 7" & 8.9"
Contributors
draxie
Version Information
Status: Alpha
Created 2015-03-13
Last Updated 2015-03-13
Thank for your works.
Can I use upHDX to remove bootloader, recovery from 4.5.3 and flash via TWRP?
Thanks
tuanda82 said:
Thank for your works.
Can I use upHDX to remove bootloader, recovery from 4.5.3 and flash via TWRP?
Thanks
Click to expand...
Click to collapse
Let's hope so. That's what I did, in any case.
I'm an adventurer; so, I ran './upHDX fw update-kindle-14.4.5.3_user_453011120.bin',
pushed the resulting update-kindle-14.4.5.3_user_453011120-upHDXfw.zip to my HDX 8.9
and installed it with TWRP.
Worked for me, but I cannot provide any guarantees, unfortunately.
It may be wise to omit 'fw', and doublecheck that you're happy with the contents of the
updater-script in the newly generated archive.
AND, -of course- make sure your bootloader version is at most .3.2.3.2!!!
draxie said:
Let's hope so. That's what I did, in any case.
I'm an adventurer; so, I ran './upHDX fw update-kindle-14.4.5.3_user_453011120.bin',
pushed the resulting update-kindle-14.4.5.3_user_453011120-upHDXfw.zip to my HDX 8.9
and installed it with TWRP.
Worked for me, but I cannot provide any guarantees, unfortunately.
It may be wise to omit 'fw', and doublecheck that you're happy with the contents of the
updater-script in the newly generated archive.
AND, -of course- make sure your bootloader version is at most .3.2.3.2!!!
Click to expand...
Click to collapse
Thanks. But your upHDX scripts is for linux user only. I am on Windows .
If you have time could you upload your xxxx_14.4.5.3_xxxx.zip? Thanks
draxie said:
The attached archive includes 3 tools for those of you with .3.2.3.2 (or earlier) bootloaders.
Since other tools (and earlier version of these very tools) are available and working well,
this is mostly meant as an entry to an imaginary beauty contest. (JOKING!!!)
cuber.py
a generic gmpy2-free reimplementation of @vortox's signature.py
use this to generate your unlock.img
cuboot.py (uses cuber.py)
a Python-only reimplementation of @vortox's cuber
includes fixes to the kernel command-line and the device-tree
use this to convert a standard Amazon boot.img (>=.4.x.x)
upHDX (uses cuboot.py)
bash script to repack Amazon updates for TWRP
could be DANGEROUS, use with care
tested on Apollo for both 14.4.5.2 and 14.4.5.3
my unit is fully 14.4.5.3 now, except for aboot (which is 3.2.3.2)
should work on Thor as well
Those with bootloader .3.2.6 and lower can downgrade to .3.1.0
and upgrade the bootloader to the latest vulnerable version .3.2.3.2.
Those with .3.2.7 and higher appear to be out of luck with forged signatures, but I hear there's progress on rooting .4.5.2.
The python scripts have been tested on the following OS / Python combinations:
Windows: 2.7.9 and 3.4.3
Linux: 2.7.9 and 3.3.4
OSX: 2.6.? (cannot quite remember)
In addition to the tools themselves, I also included "educational" examples
(examples.sh for Linux/OSX, examples.bat for Windows).
These make use of the split.py script, which is otherwise unnecessary.
(The Windows example also shows that simply echoing your manfid/serial
combo to cuber.py -the way one does in Linux/OSX- won't work due to
the carriage-return character introduced by the echo command.
You'll need to handcraft a file matching the '0x%02x%08x\n' format...)
Another batch file py..bat is meant as an extra aid for Windows users
to avoid trouble with setting paths and such. You should be able to simply
download and install your preferred Python version.
Open a command shell (cmd.exe), navigate to wherever you extracted the
archives, and type 'py PYTHON-SCRIPT ARGS' to run the Python scripts.
(This handholding intentionally does NOT work for the upHDX script.)
Hopefully, someone will find these simple tools useful.
EDIT: To unlock your bootloader (<=.3.2.3.2), you'll need adb and fastboot.
On Linux, most distributions package these separately. Look for android-tools-{adb,fastboot} or some such.
For Windows, you can get these from the official Android SDK (which is a **large** download,
with a lot more tools you won't need, if you don't already use them, but it's safe).
Alternatively, there's a very legit-looking project here an XDA, with a much smaller
download, fast install, and exactly the tools you need. I haven't used either... (-;
The actual unlock procedure is described here and here.
EDIT#2: I added another script 'cublock.py' to make unlock.img generation super easy both on Windows and Linux.
MD5( tools.zip) = c17fc91344bd3b4b040129a79a39741f
Click to expand...
Click to collapse
Thanks a lot for the good work but id like to let tell you that it will be great if you can explain all the entire work in layman's terms because there would be many people having hundreds of questions and concerns.
Just an advice if you feel worthy... No disrespect intended...
I would like it in layman terms...
And how to do it on Windows. This seems like confusion for me. I have no idea where to start.
I did it all in windows 8.1 64 bit edition.
With help from this post:
http://forum.xda-developers.com/showpost.php?p=58897784&postcount=67
get Python 2.7 for windows and install it >>https://www.python.org/download/releases/2.7/
btw I installed the 64 bit edition for both
get GMPY2 for Python 2.7 https://code.google.com/p/gmpy/downloads/list
Follow the post for step by step. I encountered some trouble with fast boot driver, I had to remove the driver and install a generic one I selected from windows then I manually installed it. Ran the fast boot command to unlock and I was unlocked. a lot easier than it looks.
Reckerr said:
I would like it in layman terms...
And how to do it on Windows. This seems like confusion for me. I have no idea where to start.
Click to expand...
Click to collapse
Appreciate it. Will attempt Saturday after a read through.
Works on Windows...
tuanda82 said:
Thanks. But your upHDX scripts is for linux user only. I am on Windows .
If you have time could you upload your xxxx_14.4.5.3_xxxx.zip? Thanks
Click to expand...
Click to collapse
Actually, I tested upHDX in Windows using Cygwin.
I had to select zip and unzip in the Archive group and python in the Python group
in the installer to get all the dependencies in place, and the only issue I faced was a few filename collisions
in the /system/media/audio/ringtones folder (case-sensitivity problem).
Code:
[COLOR="Lime"]>[/COLOR] diff -ru cygwin/ linux/
Only in linux/system/media/audio/ringtones: ANDROMEDA.ogg
Only in linux/system/media/audio/ringtones: CANISMAJOR.ogg
Only in linux/system/media/audio/ringtones: Hydra.ogg
Only in linux/system/media/audio/ringtones: PERSEUS.ogg
Only in linux/system/media/audio/ringtones: URSAMINOR.ogg
These could just be copied from the original update-*.bin after installation.
Reckerr said:
I would like it in layman terms...
And how to do it on Windows. This seems like confusion for me. I have no idea where to start.
Click to expand...
Click to collapse
If you could spell out what you mean by 'it', I might be able to help.
yujikaido79 said:
I did it all in windows 8.1 64 bit edition.
With help from this post:
http://forum.xda-developers.com/showpost.php?p=58897784&postcount=67
get Python 2.7 for windows and install it >>https://www.python.org/download/releases/2.7/
btw I installed the 64 bit edition for both
get GMPY2 for Python 2.7 https://code.google.com/p/gmpy/downloads/list
Follow the post for step by step. I encountered some trouble with fast boot driver, I had to remove the driver and install a generic one I selected from windows then I manually installed it. Ran the fast boot command to unlock and I was unlocked. a lot easier than it looks.
Click to expand...
Click to collapse
Of course, if you want to make it more difficult for yourself,
you can use the older version of my tool as well.
The new one is not limited to Python 2.7, but works on both current Python versions;
and does NOT require GMPY2.
Also, if you are looking to unlock your bootloader, the 'cublock.py' script is your friend.
You just pass in the manfid and serial (separately; no need to fuse them).
Whether you choose to install Python standalone or as part of Cygwin is up to you.
The latter also includes 'bash' and lets you convert the Amazon update to a TWRP-friendly ZIP.
draxie said:
Of course, if you want to make it more difficult for yourself, you can use the older version of ny tool as well.
The new one is not limited to Python 2.7, but works on both current Python versions; and does NOT require GMPY2.
Also, if you are looking to unlock your bootloader, the 'unlock.py' script is your friend.
You just pass in the manfid and serial (separately; no need to fuse them).
Whether you choose to install Python standalone or as part of Cygwin is up to you.
The latter also includes 'bash' and lets you convert the Amazon update to a TWRP-friendly ZIP.
Click to expand...
Click to collapse
I have Windows 7 and Nexus 2.0.5 with bootloader from http://forum.xda-developers.com/kin...p-flashable-3-2-3-bootloader-upgrade-t3025504 installed Python 2.7 and the adb and fastboot and driver package from post 1
Using
adb shell
cat /sys/block/mmcblk0/device/manfid
cat /sys/block/mmcblk0/device/serial
And unlock.py and then
adb reboot-bootloader
And
Fastboot -i 0x1949 devices
fastboot -i 0x1949 flash unlock <unlock file>
fastboot -i 0x1949 reboot
IT was very easy, I only had some driver problems in fastboot mode
Uphdx don't work on debian 7
Bruder Torgen said:
I have Windows 7 and Nexus 2.0.5 with bootloader from http://forum.xda-developers.com/kin...p-flashable-3-2-3-bootloader-upgrade-t3025504 installed Python 2.7 and the adb and fastboot and driver package from post 1
Using
adb shell
cat /sys/block/mmcblk0/device/manfid
cat /sys/block/mmcblk0/device/serial
And unlock.py and then
adb reboot-bootloader
And
Fastboot -i 0x1949 devices
fastboot -i 0x1949 flash unlock <unlock file>
fastboot -i 0x1949 reboot
IT was very easy, I only had some driver problems in fastboot mode
Click to expand...
Click to collapse
FYI - followed this process on an identical environment with identical results. Struggled a bit more with Windows drivers; if you're having trouble this might help (posts 8-10).
im running this version 13.3.0.2 and im a newbe with kindle what should I do
benyo8990 said:
im running this version 13.3.0.2 and im a newbe with kindle what should I do
Click to expand...
Click to collapse
Welcome to the HDX forums. How to proceed depends on what you want to accomplish. Read through the various threads to see what is available and the effort required. If your goal is to root and/or install custom roms you MUST disconnect from WiFi as Amazon will attempt to upgrade your tablet to the lastest Fire OS. Should that happen your options will be severely limited.
Two words of caution:
1) Kindles are not like other devices. Tough to tame and easy to brick. If you approach modding with a casual attitude you'll probably end up with a non-recoverable brick. READ, READ, READ before doing anything. Ask questions when you are ready.
2) There are no tidy fail-safe tutorials for the HDX. There is work and risk involved. You have to do your homework first. No one is going to hold your hand (sorry for the lecture - just trying to set expectations early).
More info please!
dpeddi said:
Uphdx don't work on debian 7
Click to expand...
Click to collapse
Given that it worked for me even in Cygwin on Windows 7, this sounds odd.
Nevertheless, I'd appreciate more info on how it fails (and which flavor of Debian 7
you are using; so, that I have a chance to reproduce your issue).
UPDATE: Nevermind. I fired up a VM with Debian 7.8.0-amd64-standard,
and found out for myself. Apparently, 'df' in 'coreutils 8.13' used here
doesn't support the '--output' option; AND, python 2.7.3 is more strict
about the input types to 'unpack'. I fixed these and the script worked.
I'll post the new version in a second.
DF --optional not supported, $m seems to not be set
Thank you for posting this awesome tool. I am running 13.4.5.2 with a twrp recovery and the most recent available (without breaking twrp) kernel.
My question is, if worst case scenario happens and I try to use cygwin to upHDX, it does not work, but I think it did, and I install a partially working update, am I bricked? Or, will it just write over my kernel and recovery with no hope of going back. As I type this, I am thinking the answer is, both are possible, but thought I would ask before breaking things.
Sent from my KFTHWI using Tapatalk
[Edit] If you know what you are doing, this script is very helpful. I especially enjoy how it explains everything it does as it does it. So, you can see the files it changes. I used cygwin and it worked perfectly. If you understand the Unix command tools, it is a piece of cake. I do not mean to belittle the risk involved, it is significant, however, if you read what is happening, and know this worked, and can be assured there is no issue with your recovery, you can still roll back if something goes wrong. Do not take this comment as minimal risk, the risk is substantial, and you need to wipe to go back. One of my devices did not take the update well (My fault), and, I had to go back. These devices do not handle wipes well. So, the moral of the story.
-This is an excellent and versatile tool,
-There is significant risk
-If you do your research, follow directions, and meet the requirements, you can get success. Have your cake and eat it too on your terms!!
-With this tool, I have the most recent update, root, and twrp (Amazon apps work too).
Thanks again for the tools.
[/Edit]
lekofraggle said:
My question is, if worst case scenario happens and I try to use cygwin to upHDX, it does not work, but I think it did, and I install a partially working update, am I bricked? Or, will it just write over my kernel and recovery with no hope of going back. As I type this, I am thinking the answer is, both are possible, but thought I would ask before breaking things.
Click to expand...
Click to collapse
I saw you managed fine, but just in case anybody else wonders,
the script will bail at the first sign of error and you'll know it.
Of course, this won't guarantee that things cannot go wrong,
but minimizes the chances that they go unnoticed.
NOTE, HOWEVER that:
This has only been tested on 4.5.2 and 4.5.3; and, I would strongly recommend against blindly running it on newer releases (as the pattern matching that's being relied upon for what to throw away --including the anti-rollback fuse stuff-- might easily get broken with relatively minor changes.
A good sanity check is to unzip both the original update and the newly created "sanitized" version, and compare them (e.g. via a recursive diff) to doublecheck if the changes are sensible.
So it happened day before yesterday, 8-22-17 @ ~5:50 PM, my Verizon S6 Edge (G925VZKE [64GB]) bricked out. No LED Light, nothing on Screen, nothing as if actually Hard Bricked. No booting, No download Mode, nothing. But it's not fully hard bricked actually. When I plug the device into my PC, Windows will either pop and say the device malfunctioned or it will read as "Exynos7420". I'm not quite sure what to do about it at the moment, I've read [a little] about what to do with phones in this mode using a "USB_Down_Load_32bit"/Multidownloader. I believe it to be stuck in a Diagnostic Mode I'm not versed in. This all happened while I was in the ADB Root Shell (su:s0) while the device was powered off and charging.
I am making this thread here for any devs you would want to use the knowledge and files here, to take the project further. As I cannot currently use my device at all. And I won't be getting a replacement S6 Edge for at least a month, maybe two. I love the S6, and will still choose it over most devices. I've been dedicated to researching and posting about the Samsung Exynos7420 Hardware since September 2016. That was when I came up with the plan for The Greyhat Root Project. You may recall my other thread once in the Original Development Forum & now in General. If you search "Greyhat Root" in google. My thread will be the first result. It gained a lot of traction, very very quickly. But is now dead, and the mods probably hate me for making a new thread. But I'm not trying to put new news out there this time.
It focused on how to use Kali Linux and Metasploit. It also focused on the articles at the time that was new exploit & malware research, that boasted of the possibilities we've now come to know as the Vault7 leaks. There's probably a reason I was a victim of the malware myself and I took down most of the posts. Most of the good file and resources I posted to that thread were either flagged by end users or removed by google. The real treasure of that thread is lost to the internet now, as that was the only backup I had of some of the critical files needed for the process. If you actually look through my individual posts all over, you will find some juicy tidbits of knowledge spread around this site that I've not compiled into one. A lot of it is still over my head as it was then, and partly why I took it down then. But I've been chipping away at that knowledge base everday for 10 months going on a year now. It's possible to root this device if One can take the knowledge of how to leverage the news worthy exploits from the past 2 years into a single repo/application. "Android-InsecureBankv2" is one example of such a platform. But as a teaching platform, it is not configured to provide a SuperSu Root Solution out of the box. It would still require modification of someone else's codebase w/Learning Curve.
No I have not managed to find a way to unlock the bootloader because I do not have a copy of IDA Pro or the Hex Rays Decompiler, and if I did, I still wouldn't know to use them fully. But I have managed to find quite a number of very possible attack vectors, if I can get some serious developers to take my sentiments seriously. I proved that when the posts about dirtycow were largely ignored due to device interest, and then @droidvoider helped make some of my ideas possible with the "Greyhat Root Console" he made. Realistically at this point I only wish I were an Assembler. I'm only one guy trying to poke at a Hardware/Software Package created by multiple departments of people in a conglomerate corporation. I only bring people together. I do know that in order to disassemble the Exynos7420 sboot, you're going to need to understand U-Boot on Arm64. A Uboot version dating back to either January 2016 or August 2015. I say those two dates because, The 4BOG7 files on my device date to August 2015, the 4AOJ1 files, to January 2016. Project Zero (who does a lot of tests on the G925v btw), posted in February 2017 about they found a way to bypass the KASLR feature of the stock kernel. A Kernel I do believe we can still flash to the device. It didn't gain much attention I don't think at the time because it was only one piece to the puzzle. That exploit wasn't patched until January. I know it sounds bad when I say it like this but, what this device truly needs is a friendly Botnet-C&C-Style rootkit that has it's client and server controlled by a User-Controlled, SuperSu-Style management application. Yes, it would be a rootkit you would never want to have someone else in control of. But if SuperSu were controlled by someone else other than the end user at the time, it would be just as bad. It's just a different approach to a yet unpublished methodology.
*
** The Device I refer to is currently flashed with:
******
** Full 4 File Firmware: COMBINATION_VZW_FA50_G925VVRU4AOJ1_VZW4AOJ1_CL5133452_QB6486176_REV02_user_mid_noship.tar
** BL: G925VVRU4AOJ1 ENG sboot.bin
** AP Kernel: G925VVRU4BOG7 ENG Kernel
** TrustZone Type: t-base-tui (Filenames suggesting Mobicore present as well)
******
Trying to enter Recovery Mode with the Combo firmware, in my experience, typically sends the device into a Panic and boots into "Upload Mode" if it does not simply reboot. The combination firmware does not supply a recovery.img that I've found. And inorder to recover the ENG Combination Recovery, you would have to disassemble the OJ1 ENG sboot.bin in IDA Pro and pull it out.
During the initial boot the device will enter its own recovery mode for a moment while it does its erasing stage. I used "nand erase all, re-partition, F.Reset Time, Phone Bootloader Update options in ODIN. During this breif moment with the "Erasing..." text on-screen, the phone is available in ADB Devices and shows up in recovery mode. Meaning ADB Shell should be accesible in recovery. If that's possible that means the device keystore should be accessible as well. The Recovery images tend to be bigger because the signatures are stored in the recovery from what I've read. Can't dirtycow patch anything it can see if your shell can't change it?
Using those files, I have full su authority anytime I am in ADB Shell, the shell runs within the "su:s0" context, and not the "shell:s0" context. Any and All changes are possible through the shell. Writing a new partition Table to '/dev/block/platform/15570000.ufs/sdb' using the "partx" tool, is probably what broke my phone. So in theory installing SuperSu in System Mode should work much the same as it did on G95x S8/Plus I'm gathering. @dragoodwael was correct in supposing "sdb" to be the bootloader overall, as I do now too. Once the reboot command was issued, I lost the ability to do anything at all. All thats possible now, is to find a tool that will communicate with the driver my PC's Device Manager loaded for my phone.
Every boot.img I've unpacked using Android Image Kitchen specified that a signature of "SEAndroid Type was found". BUT, the only boot.img/Kernel that did not specify that it was an "SEAndroid Type" while being unpacked, is the Stock boot.img from the 4AOJ1 Combination Firmware. Out of the 7 boot images I've unpacked, AIK determined the OJ1 Combination boot.img did NOT have an SEAndroid Signature on it.
boot.imgs I've unpacked:
1. N920A - PB2 Eng boot.img
2. N920A - FA51 Combi - PH1 boot.img
3. N920A - FA51 Combi - PL1 boot.img
4. G925V - FA50 Combi - OG2 boot.img
5. G925V - FA50 Combi - OJ1 boot.img
6. G925V - OG7 Stock boot.img
7. G925V - OG7 ENG boot.img
I'm not quite sure what that means yet, but I do know that the zip file I have that contains the 4AOJ1 factory Binary is not a tar.md5 like usual, it is just a normal .tar. What I'd LOVE to know is, can the 4AOJ1 stock boot.img be unpacked, then repacked, and retain its flashable characteristic. Because AIK does not register a standard signature. Does that mean the Oj1 boot.img uses a different mechanism for signature verification than a standard user binary, or is it simply signed with publicly available signing keys? It's a good question, what is different about its signature compared to other stock signatures. Even if we don't understand the signatures fully.
I'm also aware of the fact, that the Combination firmware doesn't actually contain a recovery.img to flash. Probably why the Device goes into Upload Mode and Panics when trying to boot recovery after using "nand flash all" and/or "re-partition" in ODIN. But if there were a Recovery Image for the OJ1 firmware, I imagine it would not have an SEAndroid signature on it as well. So there must be something to that.
I wonder what would happen if you tried to flash the OJ1 boot.img to the recovery partition as recovery.img like in the "EasyRecowvery" project, while using the full factory binary.
Is it possible that the newer "ustar" tar format used by Samsung in ODIN packages, could be using the custom fields available in a ustar header block to hold at least part of the signing mechanism? I believe so. And I say it because on my Device, it runs the Odin3 Engine (v1.1203), which looks an aweful lot like ODIN v1.12.3. Besides the naming conventions used there, ODIN expects to send/receive images within tar archives. Specifically USTAR format tar archives. So if the ODIN Engine on the phone is anything like the PC Client application, it expects USTAR format Tar archives as well. If it expects to read in a USTAR Header block, there are custom fields possible in known locations of the official tar files. Which when parsed correctly, should lead to finding the extra data after the payload 7-Zip refers to when the tar.md5 files are extracted. I'm of the mind the "Star" utility and not the the "Tar" utility is what we should be using to create and modify ODIN firmware the way our OEM's do. That is hypothesis on my part yes, but I don't think I'm very far off base.
Here is a man page on the "ustar" utility I found interesting and extremely in-depth: ustar(1) - unique standard tape archiver - Linux man page
If you want to see a list of files involved in all of this research, please refer to this folder here: https://drive.google.com/open?id=0B_EcHdXbjhT_dDRneE56WUg3Mlk
It contains all the files I've mentioned except for the OJ1 Firmware itself. This is all I'm posting for today, it's a sad day indeed. But I have to gather the bookmarks again to post the links to articles.