Related
SAMSUNG GALAXY NOTE 3 - SUPPORTS ALL VERSIONS UP TO THE LATEST ANDROID BUILDS
SEE SUPPORT LIST FOR PUBLIC/PRO VERSIONS *HERE*
INT EXYNOS GSM (SM-N900) SUPPORTED
INT QCOMM LTE (SM-N9005) SUPPORTED
SPRINT LTE (SM-N900P) SUPPORTED
TMOBILE LTE (SM-N900T) SUPPORTED
US CELLULAR LTE (SM-N900R4) SUPPORTED
CANADA LTE (SM-N900W8) SUPPORTED
The Unified Android Toolkit brings together all the Nexus and Samsung Toolkits and supports many Nexus and Samsung devices. There is also an option at startup to run a Basic Android Toolkit which any Android device can use to install drivers, make app backups, install apk files, reboot the device into different modes and run a command prompt for manual input.
FUNCTIONS OF UNIFIED ANDROID TOOLKIT
* Install correct adb/fastboot drivers automatically on Windows xp/vista/7/8 32bit+64bit/Windows 10
* Backup/Restore a single package or all apps, user data and Internal Storage
* Backup your data from selectable folders [internal or external storage] to your PC for a Full Safe backup of data
* Unlock/Re-Lock your Bootloader [Nexus]
* Root Stock builds
* Various Root options using insecure boot image or custom recovery
* ALLINONE to Unlock, Root, Rename the Restore Files and install busybox [Nexus]
* ALLINONE to flash custom Recovery Root, Rename the Restore Files and install busybox [Samsung]
* [NEW] use SkipRoot boot image to Auto Root device, install Busybox Binaries and rename Recovery Restore files [selected devices]
* Install BusyBox on your device
* Perform a FULL NANDROID Backup of your system (Boot, Cache, Data, Recovery and System) via adb and save in Custom Recovery format on your PC which can be Restored via CWM Recovery [if insecure boot image available]
* Fix extSdCard write permissions from installed apps in Android 4.4+ [Samsung]
* Pull /data and /system folders, compress to a .tar file and save to your PC [if insecure boot image available]
* Dump selected Device Partitions, compress to a .zip file with md5 and save to your PC [if insecure boot image available]
* Extras, Tips and Tricks section
* Auto Update ToolKit to latest available version at startup (professional only feature)
* Program up to 10 Quickpick slots and run them very quickly (professional only feature)
* Mods section to automatically perform certain tasks on your device
* Download Google Stock Image directly to correct ToolKit folder for extracting and flashing [Nexus]
* Check md5 of stock image to make sure downloaded file isn’t corrupted before flashing [Nexus]
* Download Samsung Stock Firmware to PC for extracting and flashing via Odin [Samsung]
* Flash Custom Recovery or Google Stock Image to Device
* Flash any part of a stock Nexus image to device [boot, system, recovery] – Great for fixing broken parts of firmware
* Rename the Recovery Restore File present on some Stock Roms
* Boot into CWM Touch, TWRP, Philz Touch Recovery or Stock Recovery without Flashing it [Nexus]
* Flash Custom Recovery to Device
* Boot [Nexus] or Flash .img Files directly from your PC
* Install a single apk or multiple apk’s to your device
* Push Files from your PC to your device
* Pull Files from your device to your PC
* Disable forced encryption on Nexus6 and Nexus9 devices
* Install Root Checker app by Burrows Apps
* Install Backup/Restore app by MDroid Apps [calls log, sms, contacts]
* Install EFS/Partition Backup/Restore app by Wanam
* Dump selected LogCat buffers to your PC
* Dump BugReport to your PC
* Set Files Permissions on your device
* Open new Command Prompt for manual input
* Reboot device to Fastboot Mode or Android from fastboot mode [Nexus]
* Reboot device to Fastboot Mode [Nexus], Recovery, Android or Download Mode [Samsung] from adb mode
* Display Important Information about your device
--------------------------------------------------------------
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
--------------------------------------------------------------
SUPPORTED DEVICES AND LATEST SUPPORTED BUILDS *HERE*
DOWNLOAD THE SKIPSOFT UNIFIED ANDROID TOOLKIT *HERE* (FROM SKIPSOFT.NET)
NOTE: Key files are signed with a Digital Certificate from skipsoft.net but some ‘may’ get picked up as potentially harmful by Antivirus Programs and deleted. They are not harmful, this is a false positive given because of the compiler used. If this happens restore the file and exclude the folder from future scans to use it. This seems to happen mostly on AVG Free and Norton. If you are using the Auto Update feature on pro versions then you will need to disable the AV program or exclude the folder from scans before running the update again.
Credits: ChainsDD for Superuser, Chainfire for SuperSU and kernel patches, koush and the clockworkmod team for cwm and the universal driver pack, 1wayjonny for the adb/fastboot driver pack, Adam Lange for all his support and help with the insecure kernels, Viperboy for the Knox Disabler app, Stephen Erickson for the BusyBox installer app, BurrowsApps for the Root Checker app, NextApp for the SD Fix app, fOmey for TWRP for the Galaxy Gear.
--------------------------------------------------------------
WHAT IS THE DIFFERENCE BETWEEN PUBLIC (FREE) AND PROFESSIONAL (DONATE) VERSIONS?
THE PUBLIC VERSION OF THE TOOLKIT INCLUDES EVERYTHING YOU COULD NEED TO MANIPULATE AND ROOT YOUR DEVICE.
ACTIVATING THE PROFESSIONAL VERSION ADDS THE MOST USEFUL FUNCTION IN THE TOOLKIT, THE ABILITY TO CHECK FOR ‘AUTO UPDATES’ DIRECTLY VIA THE TOOLKIT AND HAVE THEM PUSHED TO YOUR PC RIGHT AWAY AS SOON AS THEY ARE UPLOADED WITHOUT NEEDING TO DOWNLOAD THE WHOLE TOOLKIT EVERY TIME. YOU WILL ALWAYS HAVE THE LATEST VERSION AS SOON AS IT IS MADE AVAILABLE. THIS MEANS SMALLER UPDATES CAN BE SENT OUT MORE FREQUENTLY, SUCH AS ADDING A SINGLE FUNCTION, FIXING A BUG OR ADDING COMPATIBILITY FOR A SINGLE CARRIER. THE SMALLER UPDATES WILL BE COMPILED AND RELEASED TO THE XDA COMMUNITY AS A FULL (PUBLIC) DOWNLOAD VERSION SO PROFESSIONAL VERSIONS ARE ALWAYS UPDATED SOONER.
THE PRO VERSION ALSO ADDS THE ABILITY TO CHECK FOR THE LATEST VERSION OF SUPERUSER AND RECOVERY FILES AND DOWNLOAD THEM DIRECTLY TO THE TOOLKIT.
THE ‘QUICK PICKS’ SECTION[/B] ALLOWS YOU TO PROGRAM UPTO 10 SLOTS WITH TASKS THAT YOU MAY PERFORM ON A REGULAR BASIS OR JUST WANT TO KEEP A SET OF TASKS IN 1 PLACE. THEN JUST SELECT THE SLOT AND IT WILL REMEMBER ALL YOUR SETTINGS FOR THAT TASK AND RUN IT.
PRO USERS CAN ALSO SELECT THE “ANY BUILD” OPTION IN THE BUILD SELECTION SCREEN TO ROOT ANY BUILD AS LONG AS THE VERSION IS SUPPORTED (USEFUL IF YOUR BUILD IS NOT LISTED).
MORE IMPORTANTLY DONATING SHOWS YOUR APPRECIATION AND ALLOWS THE TOOLKIT TO CONTINUE TO EVOLVE AND GROW.
AUTO REPLY LINKS FOR PAYPAL TO GET A CODE INSTANTLY CAN BE FOUND AT http://goo.gl/nyGqv
--------------------------------------------------------------
PLEASE READ THE *HELP* PAGE AT http://www.skipsoft.net/?page_id=1269 OR USE THE INFORMATION SECTION WITHIN THE TOOLKIT IF YOU HAVE ANY QUESTIONS. I HAVE TAKEN A LOT OF TIME TO WRITE IT AND SOMETHING ON THERE SHOULD ANSWER 99% OF PROBLEMS.
--------------------------------------------------------------
1. INSTALLING ADB/FASTBOOT DRIVERS
The first thing you need to do is to install the adb/fastboot drivers. These are needed so that you can unlock your bootloader, root your device and perform other adb/fastboot functions.
THE DRIVERS CAN BE INSTALLED DIRECTLY VIA THE TOOLKIT. OPTION 1 IN THE MAIN MENU.
If drivers are not installed or there is an exclamation mark next to the device:
Plug the device in to a usb cable directly connected to your motherboard.
In the Device Manager a new item, usually called Android 1.0 should pop up in the list.
Right click on the device item then left click on Update Driver Software. Select 'browse my computer' and then 'Let me pick from a list'.
If no adb interface driver appears in the list then untick 'Show compatible hardware' and find the Android or Samsung adb interface driver.
If you cannot find either of these click Have Disk, browse to the Toolkit install folder, drivers folder, click on android_winusb.inf and click Open.
Click OK and select Google ADB Interface.
Make sure you have USB debugging enabled in settings, developer options. In Android 4.2.2 or later you have to enable the developer options screen by going to settings, About on your device and click on Build number at the bottom 7 times until it says You are now a developer. If you have already enabled usb debugging then unplug/replug the usb cable.
On Android 4.2.2 or later when you replug the usb cable after enabling usb debugging for the first time you will get a popup asking you to authenticate your pc. Tick 'Always allow' then click 'ok'.
--------------------------------------------------------------
2. USING SKIPSOFT UNIFIED ANDROID TOOLKIT
When starting the Toolkit you will first be asked which device you want to work with. Working folders will be created and the device files downloaded. You will then be taken to the Model/Build selection screen where you can do a number of things (other than select your model/build): Type '00' to enter your activation code and enable pro features, 'i' will take you to the Information and Help Section, 'a' will give you information on how to add support for a new build.
Supported builds are listed in the Model/Build selection screen and typing the associated number (i.e. 11) will download needed boot and recovery files (stock and custom recovery) then check for and download the latest superuser files available and custom recovery (pro versions only), verify all the files and start the Main Menu. You can now use all the functions and tools the Android Toolkit offers. Pro users can select the "any build" option to root any build (useful if your build is not listed).
--------------------------------------------------------------
USEFUL INFORMATION
How to Hard Reboot the device
1. Unplug the USB cable.
2. Hold down the 'POWER' button for about 5-15 seconds until the device reboots
How to get into Recovery Mode
1. Unplug the USB cable.
2. Hold down the 'HOME' + 'VOLUME UP' + 'POWER' buttons for about 5-15 seconds until you see the Samsung logo on the screen.
3. Release all buttons straight away to enter Recovery Mode.
How to get into Download Mode (For Odin)
1. Unplug the USB cable.
2. Hold down the 'HOME' + 'VOLUME DOWN' + 'POWER' buttons for about 2-15 seconds until a WARNING! Screen appears.
3. Press the 'VOLUME UP' button to enter Download Mode.
--------------------------------------------------------------
*DISCLAIMER*
I take no responsibility for any fault or damage caused by using the Unified Android Toolkit. No warranties of any kind are given.
**FAQ**
Q. Help me I can't find my build in the Model Selection Screen
The Toolkit includes a selection of Insecure Boot Images to cover all the different builds available. As there are very many different builds it is impossible to include an image for every single build but some builds share the same Boot Image. If you have a build that isnt listed on the Model Selection Screen you can therefore use a similar build. The best way to go is up to the next available build as it should offer more compatibility with the build you are using but if that isn't available then try the next build below your one as it should still be almost identical as long as it is the same version (ie. 4.1.1).
The Model Selection Screen is there so that if a task in the ToolKit requires an insecure kernel [to perform adb root commands] and your phone doesnt already include one, a compatible boot image [with an insecure kernel included] can be flashed to provide adb root access.
If you have a Custom Rom flashed to your phone then it will most probably have an insecure kernel included so it doesn't really matter if your build is not listed on the Model Selection Screen and when asked [by certain functions] if you have an insecure kernel on your phone you can answer 'yes'. However if the function fails then your kernel may not be insecure in which case you can flash one from the ToolKit. If you need to do this make sure the right build [or closest available build] is set so you flash the right image for your phone.
----------------------------------------------------------------------------
Q. What is ADB Shell?
Adb shell is a linux command line tool (because android is based on linux) used to send commands to your android device. For S-ON devices, this is crucial for modifying files in the /system partition (where the rom sits) as you cannot modify anything in /system when the rom is running without S-OFF like removing system apps.
----------------------------------------------------------------------------
Q. Why do I need to back up my IMEI/EFS and how do I do it?
There well protected section of your device that is virtually immune to any kind of flashing and manipulation (unless of course you know how to access it). This part of the device contains information such as IMEI (or MEID and ESN in the case of CDMA devices), programming parameters for the device such as your account information (phone number, etc), data provisioning parameters, and a whole bunch of other things that, when not handled properly, can render a device completely useless. All of these are contained in the infamous \EFS folder. If anything messes with your EFS folder, unlike flashing a device (which could potentially lead to bricks as well) it could render your device completely useless as it will no longer be recognized by your carrier. If you are not planning on flashing anything to your device and want to stay on pure Stock then you may never have any problems but it is still advisable to backup this information just in case (better to be safe than sorry).
----------------------------------------------------------------------------
Q. Does flashing a custom image increase my flash counter?
Any image that is flashed via Odin that has been modified will increase the flash counter that can be viewed in the Download Mode on your device (if booted by holding the Volume Down, Home and Power buttons). You can reset the flash counter using an app by Chainfire called Triangles Away and can find instructions on how to use that in the Downloads section in the Toolkit.
----------------------------------------------------------------------------
Q. Will flashing Stock ROM via odin using the toolkit replace everything that was flashed before? recovery? etc?
Yes a Stock Image flashed via Odin will replace all your key partitions (boot, recovery, system) with the stock firmware. If you want to reset the phone back to an 'out of the box' state then you want to enter recovery and do a wipe first which will reformat your userdata partition.
----------------------------------------------------------------------------
Q. I flashed Custom Recovery but each time I reboot the Stock Recovery is back
There is an auto recovery restore system on certain Stock Android Builds that will reflash the Stock Recovery if you flash CWM on a Stock Rom.
Use Root Explorer to Mount the system folder as R/W (or use a free app from Google Play such as ES File Explorer). Rename the files /system/recovery-from-boot.p and /system/etc/install-recovery.sh (requires root). Now when you flash Custom Recovery it will NOT be overwritten after a reboot. You can also do this via the Toolkit.
----------------------------------------------------------------------------
Q. My AntiVirus program says the Toolkit files may be harmful
The exe compiled files are not digitally signed with a Microsoft certificate (as they cost money) so certain AntiVirus programs (mainly Norton and AVG Free) may pick it up as potentially harmful when it is not. They will pick up ANY file that doesn't contain a purchased Microsoft certificate in the same way. Just Restore the deleted file and exclude it from further scans and it will be fine. Or switch to a better AntiVirus program such as BitDefender.
----------------------------------------------------------------------------
Q. I flashed the Toolkit Boot Image, now my wifi + bluetooth won't work
The boot images are made from Stock with only needed changes made to the insecure boot images [modified adbd, default.prop and rc.local edited] and will work on all stock roms. If you flash them to a custom rom and the rom has been altered or uses a custom boot image then it will boot but certain modules may not load such as wifi or bluetooth. In this case you can use the boot image to root or perform adb root functions but will need to flash back the boot image for the custom rom to get other functions working again. This is not a fault of the Toolkit but a difference to stock in the custom rom.
----------------------------------------------------------------------------
Q. I am having trouble getting adb working with the drivers installed
Try switching your connection type from media (MTP) mode to camera mode (P2P). To do this open the notification area, click where it says connected as and change from MTP to PTP.
----------------------------------------------------------------------------
Q. I want to send my device back for warranty purposes
1. Follow the instructions to reset your flash counter with TriangleAway.
2. Download and flash a Stock Firmware image from the download section.
3. Boot into Stock Recovery and perform a wipe/factory reset
.
Your internal storage will be formatted and data and cache wiped. Your device should now be back to an out-of-the-box FULLY STOCK state with the flash counter [shown if you boot to download mode manually] reset and ready to send back.
----------------------------------------------------------------------------
Q. When connecting the phone I get 'USB Device not Recognized' and no serial number shows in the ToolKit
I actually had this problem recently and what fixed it for me was to make sure that the drivers have been installed, then shut my phone down plug the usb cable in and restart it. The phone booted up and the device was recognized and drivers installed correctly. May not work for everyone but worth trying.
----------------------------------------------------------------------------
Q. "Superuser/SuperSU has stopped" message after rooting
After updating Samsung device to newer builds of Android [4.3 and later] which contains the new security from Samsung "Samaung KNOX", you might face a problem if you tried to root your device.
This might happen because of KNOX security, it blocks/disables the Superuser app and you will see this notification after the first boot:
"Unfortunately, SuperSU has stopped" or "Unfortunately, Superuser has stopped" depending on the root method you used.
The easiest way to fix this problem is by installing the superuser apk file. Select option 6 from the Rooting Section and the Toolkit will attempt to extract the superuser.apk file from the root zip file in the Root folder and if successful it will then be installed. You can then run the app [Superuser or SuperSU] from the apps list. A warning message will pop up saying Samsung KNOX has been detected and ask if you want to try and disable it. Click OK, KNOX should be disabled and your device should now be properly rooted.
**UPDATES**
**VIDEOS**
mskip said:
**VIDEOS**
Click to expand...
Click to collapse
Glad to see you here, used your toolkit on S3. Thank you for your work
Many thanks
Used this with great success with the note 2, excellent tool, just updated (donated version)
Many thanks
One of the best tools ever now available for the Note 3 :laugh: what a great surprise :good:
Thank You for this great work and for your tools which made our life easier
Thank you! :laugh:
Cool, just got my Note 3 at the right time it seems
Thanks!
Nice work and many thanks :good:
Oops, wrong thread
Sent from my SM-N900T using Tapatalk
I used your toolkit with succes on the Note 2 but on the note 3 with buildnumber KOT49H.N9005XXUENB4 it won't install TWRP (yes I chose rename files) so no root or custom recovery.
Do you have any idea Mark?
this toolkit grows knox if i try to root note 3?
Finally for Note 3...
Hey guy,
I appreciate your hard work on this awesome program. I really do.
BUT, a donation amount should be at the behest of the donator.
At 4 GBP minimum I simply can't afford to donate to you. The thing that upsets me is the fact I wasn't even after the pro features, I simply wanted to show you my appreciation. It just seems like you're stopping yourself from letting people buy you a beer.
Any alternative donation methods? One's that don't restrict to the minimal amount of money.
Like I said, I don't really care about the pro benefits.
---------- Post added at 01:54 AM ---------- Previous post was at 12:55 AM ----------
Herzog56 said:
I used your toolkit with succes on the Note 2 but on the note 3 with buildnumber KOT49H.N9005XXUENB4 it won't install TWRP (yes I chose rename files) so no root or custom recovery.
Do you have any idea Mark?
Click to expand...
Click to collapse
You are probably being KNOX-blocked. Search XDA for turning off KNOX protections. This may help you actually: http://forums.androidcentral.com/samsung-safe-knox/366118-solution-how-permanently-remove-knox.html If not this then I don't know. Though I do remember seeing "Write protection" on download mode.
Maybe that's why you're having problems.
Image of that here:
hello,
or at the very root and flash a custom recovery without switching to flag knox 0x1? or is 0x0.
stevles said:
Hey guy,
I appreciate your hard work on this awesome program. I really do.
BUT, a donation amount should be at the behest of the donator.
At 4 GBP minimum I simply can't afford to donate to you. The thing that upsets me is the fact I wasn't even after the pro features, I simply wanted to show you my appreciation. It just seems like you're stopping yourself from letting people buy you a beer.
Any alternative donation methods? One's that don't restrict to the minimal amount of money.
Like I said, I don't really care about the pro benefits.
Click to expand...
Click to collapse
I understand your point about the minimum donation amount but had to set this because of people donating 1p just to get an activation code. There is a donation button right under my username on every one of my posts for users who do not want to donate much and there is no minimum amount set on that link.
Mark.
qxv1 said:
hello,
or at the very root and flash a custom recovery without switching to flag knox 0x1? or is 0x0.
Click to expand...
Click to collapse
Any custom image flashed sets the knox flag to 0x1.
Mark.
mskip said:
I understand your point about the minimum donation amount but had to set this because of people donating 1p just to get an activation code. There is a donation button right under my username on every one of my posts for users who do not want to donate much and there is no minimum amount set on that link.
Mark.
Click to expand...
Click to collapse
Bugger it I'll donate the full amount.
You seem like a good guy and 4 GBP isn't really all THAT much. I'll just have a cheap lunch tomorrow :victory:
mskip said:
Any custom image flashed sets the knox flag to 0x1.
Mark.
Click to expand...
Click to collapse
Pretty much, with the exception of using the mobile odin pro method Here. Still a chance to trip it or otherwise rape your device so I wouldn't recommend it unless you know what you're doing
mskip said:
Any custom image flashed sets the knox flag to 0x1.
Mark.
Click to expand...
Click to collapse
Ok, I get the idea but if I don't flash custom image just root, is it possible to keep Knox 0 ?
Thank you for your effort and job.
Not sure my question in subject is clear, so here's the thing...
I have dual-boot tablet with Android 5.0.1 and Windows 10 installed, and the model is Onda V80 Plus (32GB), if that matters at all.
I'm really having hard time rooting this device using standard methods (even with much of background knowledge and experience), so I was about to take a different route.
I installed Paragon ExtFS windows app which gives me read/write access to /system and /data android partitions (which have ext4 filesystem).
I was wondering if anyone knows if it's possible to gain root access in Android just by copying some files and changing some permissions or whatever from within Windows OS?
Basically, for those not familiar with ExtFS app, I can assign a drive letter to /system and /data partitions, and do whatever I want with them just like with any other drive or volume.
I'm aware that modifying ext4 partitions can render my Android OS unbootable, but I have a backup and would like to try it anyway as this is my last option.
When I look into SuperSU.zip file (which I always flashed through CWM/TWRP recovery to gain root access), I see many files which some lengthy script is copying all around, so I stopped after analyzing about hundred lines of code lol.
I really didn't find any method like this on the internet, so I wonder if that's even possible, and if it is, how would I go about it?
Thanks everyone.
Burs said:
Not sure my question in subject is clear, so here's the thing...
I have dual-boot tablet with Android 5.0.1 and Windows 10 installed, and the model is Onda V80 Plus (32GB), if that matters at all.
I'm really having hard time rooting this device using standard methods (even with much of background knowledge and experience), so I was about to take a different route.
I installed Paragon ExtFS windows app which gives me read/write access to /system and /data android partitions (which have ext4 filesystem).
I was wondering if anyone knows if it's possible to gain root access in Android just by copying some files and changing some permissions or whatever from within Windows OS?
Basically, for those not familiar with ExtFS app, I can assign a drive letter to /system and /data partitions, and do whatever I want with them just like with any other drive or volume.
I'm aware that modifying ext4 partitions can render my Android OS unbootable, but I have a backup and would like to try it anyway as this is my last option.
When I look into SuperSU.zip file (which I always flashed through CWM/TWRP recovery to gain root access), I see many files which some lengthy script is copying all around, so I stopped after analyzing about hundred lines of code lol.
I really didn't find any method like this on the internet, so I wonder if that's even possible, and if it is, how would I go about it?
Thanks everyone.
Click to expand...
Click to collapse
Root needs a custom kernel. Not something you are gonna do with a Windows setup the way you have it. Also you will most likely not find anything as that is most likely not an official version of Android as Google doesn't allow dual booting.
Thanks for a reply. But I don't see what does custom kernel have to do with what I try to achieve? If I could, in my Windows environment, replicate the modifications that script inside SuperSU zip does to /system partition, I should gain root access, right? In theory that is, since I'm aware lots of things can go wrong. I was hoping someone could explain a bit what SuperSU script is doing when run inside custom recovery, so I try to do the same thing. Again, if it's possible, and if it's worth the time spent. But I have time, and I'm always willing to learn something new.
Burs said:
Thanks for a reply. But I don't see what does custom kernel have to do with what I try to achieve? If I could, in my Windows environment, replicate the modifications that script inside SuperSU zip does to /system partition, I should gain root access, right? In theory that is, since I'm aware lots of things can go wrong. I was hoping someone could explain a bit what SuperSU script is doing when run inside custom recovery, so I try to do the same thing. Again, if it's possible, and if it's worth the time spent. But I have time, and I'm always willing to learn something new.
Click to expand...
Click to collapse
what su is doing is pulls the kernel and patches it. root access is defined in the kernel. what itnis doing in system is flashimg just the apk
Ok, I see. So if I ask someone who rooted the same model successfully to send me patched kernel, I could easily flash it in fastboot mode (my bootloader is unlocked). So only thing left to do would be to copy apk inside /system/app, and cross my fingers? I'll post my findings if I manage to do something worth writing about. Thanks.
I have same problem with you. I can't root my Onda V80 plus. I unlock bootloader, flash recovery for my device. Then, i put it into recovery mode and install supersu.zip over recovery. When i reboot this onda, it has stopped in onda logo.
bahuy2003 said:
I have same problem with you. I can't root my Onda V80 plus. I unlock bootloader, flash recovery for my device. Then, i put it into recovery mode and install supersu.zip over recovery. When i reboot this onda, it has stopped in onda logo.
Click to expand...
Click to collapse
I managed to root my Onda few days after my last post, but forgot to post my findings, sorry. I didn't used any of my hacker's skills lol, but I researched a bit more and found out what I was missing. The same issue is with you, so you have to disable verity before flashing recovery by typing in these commands:
Code:
adb root
adb remount
adb disable-verity
adb reboot
After rebooting install supersu.zip, and the next boot won't hang on Onda logo anymore. Hope this helps you.
btw, note that not just any adb version has verity command line switch. You have to download newer adb version!
Thank you! I trie a lots times, but i can't make successfully!
Basic root procedure would be: unlock BL -> disable verity -> flash (temp) recovery -> install SuperSU
Here are the links containing all the files neccessary for rooting Onda V80 Plus: Mega | MediaFire
Note the ReadMe.txt inside archive. It contains list of adb/fastboot commands needed to be executed in order to successfully root the device.
Thank you very much! I download your file and root successfully my Onda V80 plus! It works well for me.
Hello! I’ve come, because in my quest to root my recent Galaxy S Devices, I’ve hit a big fork in the road and I don’t have the knowledge base to answer the last few questions I have. I feel like I should know the answers here, but for some reason I am lost to what to do next. I don’t quite understand how the newer root methods work these days, since working with the system & recovery images isn’t as easy with the newer Samsungs.
I got together with a developer, @droidvoider, where together we came up with this idea to get a root shell capable of at least remounting the filesystem R/W before reboot. He coded it on 6.0.1, and I talked a whole lot while I tested it on 5.1.1.
The Greyhat Root Console post#63
droidvoider said:
Major update!
1. I have debugged the tool heavily and it appears to me that I can replace any file on the system. Testing files you can't normally read is done via code so it's slow going, let me know if you find any blocks now.
2. If you have any file that gives an error but then replaces, that's because it tried other contexts.. PUT THIS ACTION AS THE LAST ENTRY, it might not be changing back to install_recovery from some contexts
3) the su install thing is designed to give an error I didn't even try to get root with this, literally focused on getting the tool done only.
4) next is a console of sorts, with exec dcow patching.. muahahaha
https://github.com/droidvoider/CVE-2016-5195_GreyhatRootProject_Root_Console
Click to expand...
Click to collapse
droidvoider said:
post#41you start an apk with am or monkey ... Let me know if I missed any other questions I'm excited about my find
I have awesome news.. As soon as I started playing with ls -la / using both contexts with root I seen that inside /cache/recovery/ is some log files. I am pressed for time hard, however
Code:
ls -la /cache/recovery/
Attached you can see the full output acquired from ls under both contexts
Click to expand...
Click to collapse
I'll start with the fact that I do not have Cellular Service. I no longer own a Note 5 N920A. But I do still own an S5 G900V, S6 Edge G925V, and a S7 Edge G935V. They serve as Wi-Fi Only Devices, and they are owned by myself. So slightly selfishly, I concern myself only with modifications that allow the device to boot, working network services are not a primary concern of mine. As they can more than likely be configured after boot by someone smarter than me.
I know that normally DM-Verity, KNOX, Encryption, U/G IDs, and SELinux, play a big role in allowing a user to execute processes as the root user. I am running 5.1.1 Android on my S6e & 7.0 on my S7e. I have an Engineering Kernel and boots normally with ADB Root Shell access. I have an Engineering Sboot, and allows me a non Root ADB Shell while booted normally in Stock Recovery. Right now the Eng Kernel I have, sets SELinux to Enforcing Mode. If I use the stock factory binary kernel, I lose root adb shell access but gain Permissive SELinux Mode. How do I inject root from here in a stable fashion?
akiraO1 said:
post#112
But I did want to post my findings so far on my selinux adventures thus far with my note 7....
So I was able to change the root context permanently from ubject_r:rootfs:s0 to u:r:shell:s0.
This by itself isn't all that helpful except that I actually changed it, and it stuck when I rebooted the device.
I achieved this through dirtycow-ing the file_contexts file with my customs file_contexts file and the commmands restorecon -RFv / and chcon -Rhv u:r:shell:s0 / restorecon makes selinux reload the file_contexts file immediately, so it loads all or most of my custom contexts. then I do a chcon command to make sure it writes?
well thats all I have for now but im working vigorously and will keep posting my findings as I find them =)
Click to expand...
Click to collapse
Using "DD" on Android 6.0.1 post#18
droidvoider said:
Tool is working!!!
Android 64 bit universal dirtycow dd image write works for both push/pull.. I am tired so please see github readme, the Makefile and push_files.txt, pull_files.txt examples. I am going to get root, this is the first step.
https://github.com/droidvoider/Android_6.01__DD_Dcow
Click to expand...
Click to collapse
Page 4 for File and GHR Console
Page 5 further discussion of Console
Page 6 GHR Console
I'm going to go into some detail here about the Firmware I've been flashing just so everyone knows without having to ask. I'm almost really hoping maybe we could all muster one more attempt at rooting this Note 5 variant.
I really feel like I really might have something here, especially with the updated binaries of "Farm Root", "CVE 2016-5195 (dirtycow)", and bootimgtools (mkbootimg & unpackbootimg). All compiled for arm64-v8a. Thanks to @droidvoider for helping to compile those. I'm not a linux Expert by any means, but I'm on a mission, and I do know a few things. With all of the Security Bulletins that have come out since November, there should be plenty of Attack Vectors for using the LL Eng Kernel or DirtyCow to gain enough Kernel Privileges to maybe even unlock the dang bootloader. Or maybe bypass the signature check for one boot. LL-based UCU1AOGG Recovery Mode does not use DM-Verity when exiting, and the Combination Firmware doesn't seem to use it at all So....
Q1.) Can someone please help me get at least a systemless root installed? WITHOUT using a custom recovery? It might need to actually be a system root though looking at the Galaxy S8.
This should be possible using the LL Engineering Kernel & Engineering Sboot for the Factory Binary. Especially since the August builds are fully exploitable by DirtyCow, and with an eng Kernel that is half the battle we were using dirtycow for in the first place. Now we should be able to use DirtyCow to finish the root injection. Because the Factory Binary does not utilize DM-Verity that is obvious. So using the Factory Combination Firmware, there may actually be a way to legit boot a custom recovery I feel, even if only for one boot, that is plenty enough if prepared when that oneshot boot happens. Once installed with the full Combination Bootloader (ODIN BL file) I can then flash any N920A LL ODIN AP File. All the way back to N920AUCU1AOGG. Warranty Bit Intact, Official Status, Normal Rebooting. In fact, after everything I've done thus far, I have still yet to trip my KNOX Warranty (Still 0x00).
**************
** MM 6.0.1 **
**************
Here are the contents of the tar.md5's:
Code:
tar -tvf AP_N920AUCS3BPH4_CL7563702_QB10603229_REV00_user_low_ship.tar.md5
-rw-rw-r-- dpi/dpi 28746016 2016-08-10 00:31 boot.img
-rw-rw-r-- dpi/dpi 29413664 2016-08-10 00:32 recovery.img
-rw-rw-r-- dpi/dpi 4125403456 2016-08-10 00:33 system.img
-rw-r--r-- dpi/dpi 549536816 2016-08-10 00:33 userdata.img
tar -tvf BL_N920AUCS3BPH4_CL7563702_QB10603229_REV00_user_low_ship.tar.md5
-rw-rw-r-- dpi/dpi 1634576 2016-08-10 00:31 sboot.bin
-rw-rw-r-- dpi/dpi 1095680 2016-08-10 00:28 param.bin
-rw-rw-r-- dpi/dpi 2113808 2016-08-10 00:28 cm.bin
tar -tvf CP_N920AUCS3BPH4_CL7563702_QB10603229_REV00_user_low_ship.tar.md5
-rw-rw-r-- dpi/dpi 37269840 2016-08-10 00:28 modem.bin
tar -tvf CSC_ATT_N920AATT3BPH4_CL7563702_QB10603229_REV00_user_low_ship.tar.md5
-rw-rw-r-- dpi/dpi 3072 2016-08-10 00:32 NOBLELTE_USA_ATT.pit
-rw-r--r-- dpi/dpi 89608656 2016-08-10 00:34 cache.img
For this MM Stock Firmware, I've also come across this Modem for a Z3X Flash Box, that is used when direct unlocking this device. I do know, that when I have this CP installed, I do have access to the APN Editor, to Add/Modify/Delete APN's:
Code:
tar -tvf N920A_UCS3BPH4_CP_FOR_UNLOCK.tar
-rw-r--r-- 0/0 37269840 2016-08-10 00:28 modem.bin
******
**************
** LL 5.1.1 **
**************
I’ve happened upon the full ODIN flash-able SW Rev 3 Factory Binary for the AT&T Galaxy Note 5. It allowed me to do a full firmware downgrade from MM 6.0.1 to LL 5.1.1 without worrying about trying to downgrade my binary counter in download mode. It’s the only 5.1.1 build I’ve seen that isn’t a binary 2-(SW REV 2) & It contains these files:
Filename: COMBINATION_FA51_N920AUCU3APH1_CL6053901_QB10608083_REV00_user_mid_noship.tar.md5
Code:
tar -tvf COMBINATION_FA51_N920AUCU3APH1_CL6053901_QB10608083_REV00_user_mid_noship.tar.md5
-rw-rw-r-- dpi/dpi 1634576 2016-08-10 06:44 sboot.bin
-rw-rw-r-- dpi/dpi 1095680 2016-08-10 06:43 param.bin
-rw-rw-r-- dpi/dpi 2113808 2016-08-10 06:43 cm.bin
-rw-rw-r-- dpi/dpi 24660256 2016-08-10 06:44 boot.img
-rw-rw-r-- dpi/dpi 24754464 2016-08-10 06:44 recovery.img
-rw-r--r-- dpi/dpi 1537858544 2016-08-10 06:44 system.img
-rw-r--r-- dpi/dpi 4292768 2016-08-10 06:44 persdata.img
-rw-rw-r-- dpi/dpi 36163408 2016-08-10 06:43 modem.bin
-rw-rw-r-- dpi/dpi 3072 2016-08-10 06:44 NOBLELTE_USA_ATT.pit
Using ODIN v3.12.5, I flashed this firmware using the AP slot overtop of the Full 3BPH4, and after flashing the Factory Binary these are the build details that boot up with zero errors. Mind you, I have tried this with, and without, a sim card inserted. It is not lost on me either, that UCS3BPH4 (Stock) and UCU3APH1 (Factory) have the same build dates listed on them.
***
* Device := SM-N920A
* Android Version := 5.1.1
* Baseband Version := N920AUCU3APH1
* Kernel Version := 3.10.61 August 10th 2016
* Build Number := LMY47X.FA51_N920AUCU3APH1
* SELinux Status := Permissive
***
From @TechNyne66 I got the LL Eng Kernel from the 2APB2 build. I have yet to see any other UCE branded files.
Code:
tar -tvf N920AUCE2APB2.tar
-rwxr-xr-x 0/0 27326752 2016-02-11 01:42 boot.img
But flashing this kernel into the Factory Binary sets SELinux to Enforcing, which makes things a bit more difficult. And I don't know how to edit the Kernel in a way I can repack it for flashing. My attempts thus far have failed when trying to flash a repacked boot.img. Probably because I did not make the necessary build.prop tweaks, and because I didn't use the correct compression levels to repack. What I mentioned earlier about not understanding the filesystem all that well anymore, stems from not having a broad understanding of build/default.prop & the various .rc/init files.
This is also possibly due to Samsung using a customized header for the Kernel's Binary.
Q2.) Is there a way to update the UID/GID from 'dpi/dpi' to '0/0' without modifying the signature embedded into the tar.md5?
Q3.) Is there a way to extract the extra data from the end of the file?
Q4.) Can I examine the persdata.img directly, to see it's contents before flashing? I don't know how to view the img format and how to extract it.
My post is too long, so I'm moving to post #2
Since these are too long to fit in post 1, I was forced to double post. Here is the last bit about partition tables. The reports are long. Please, any solid advice would be helpful.
***************************
** PIT File Examinations **
***************************
Moving on, I have used "PIT Magic 1.3 Release", found here on XDA, to look at the partition tables of the .pit files included with the N920AUCS3BPH4 & N920AUCU3APH1 ODIN firmware packages. I have also included the PIT File examination from the unlocked European Firmware. Given that PIT Magic 1.3 is a few years old, the latest version I have is labeled 2012. I read about how difficult it was to get the format correctly back then, and I have no way of knowing if the PIT File format has changed since then. But it does still seem to give usable output. I just don't know how to use this output meaningfully yet.
If you could hack one of the apps that are included in the sepolicy and set the Androidmanifest.xml to include android:dubuggable="true" we can make a two stage app. read and replace as root with the cow and then reload your inits.
toolbox.c root trick:
I am working on a very very powerful tool now. I am taking farm-root toolbox.c and changing it to grab root + context but then fork a process into a loop and just keep those privs. Hopefully I can even control that loop from the command line still! Currently I can get root and system_server, install_recovery.. But today after work we find out if I can hold on to it in a loop.
recovery-from-boot.p
I researched this today because we can read/patch this file with dirtycow. This file replaces the stock recovery every time you boot if they are different. I don't know if it also uses the hardware signature verification process, if so that's a key that's hidden in the partition image (hopeless for us i bet)
So if we replace recovery we have to crush this file with dirtycow.c
This sounds very interesting, i have a damaged g935f with dm-verty faied and frp lock so there is no way to use this device unless i flash with no-verity firmware but cant as frp stops me flashing root, hopefully you can use this exploit with the factory combination firmware to replace the boot loader with twrp or other custom bootloader to fix this issue, there is lots of people with same the problem im sure
verg0 said:
This sounds very interesting, i have a damaged g935f with dm-verty faied and frp lock so there is no way to use this device unless i flash with no-verity firmware but cant as frp stops me flashing root, hopefully you can use this exploit with the factory combination firmware to replace the boot loader with twrp or other custom bootloader to fix this issue, there is lots of people with same the problem im sure
Click to expand...
Click to collapse
Can you get booted at all? If you can' t get booted I won't be gaining access to that phone until someone smart works out the encryption, no one has on the note 3 yet not even hashcode (that he ever released). While the bootloader is locked.... The sboot.bin = signed by hardware key. If that key is not present there is an undisclosed backup key embedded in the partition, one must be present and neither are known. Minus the presence of those keys, chain of trust fails.
S7 is worth saving if it can be saved tho
droidvoider said:
Can you get booted at all? If you can' t get booted I won't be gaining access to that phone until someone smart works out the encryption, no one has on the note 3 yet not even hashcode (that he ever released). While the bootloader is locked.... The sboot.bin = signed by hardware key. If that key is not present there is an undisclosed backup key embedded in the partition, one must be present and neither are known. Minus the presence of those keys, chain of trust fails.
S7 is worth saving if it can be saved tho
Click to expand...
Click to collapse
No bud, the phone wont boot a normal firmware as the certificate is screwed and imei 0000000000, but it will boot with combination firmware, all i need to do is gain root and disable 'frp lock' via z3x box or another method and car repair the phone... Im not fussed about the warranty being void to be honest... I have ADB but not root fix phone
My tool will likely be helpful to you because that sounds good enough as long as you can get to a prompt that is CVE-2016-5195 / SVE-2016-7504 vulnerable. Anyone who isn't patched beyond Sept 2016 on any Android in the last 10 years will be able to use the tool I'm building to do amazing things. I am designing it precisely for people like you and Delgoth who have large investments in phones that could simply be repaired with enough access.
I am thinking now to fork off a child process anytime I can capture root + "any_new_context"... This will be forked into a child process then kept in a loop. If there is a new root + context that happens along through toolbox, we will grab that also.. (but I won't grab two of the same for example root + system_server I just need once)
I am hoping I can control this loop from the command line but since I am not the caller of the process for which I am capturing I am not sure that would work. This is new code to me, not sure of any examples of something like this. If I have to control it through values I set in files it adds a little more time. The great news is I am not having binary size problems so I can add quite a bit of code while still keeping toolbox much less than the currently installed version on my Note 5. File size must match exactly otherwise patching causes seg fault and seg fault ruins the fun (reboot to cure but irritating)
anyway just needed to come up for air I have a ton done, need to get toolbox fired up to test angle.. any c programmers that want to help or anyone with awesome ideas please feel welcome I could use help
Ah cool the combination firmware i have is:
COMBINATION_FA60_G935FXXU1APB5_STEP1_OLDFW\COMBINATION_FA60_G935FXXU1APB5_CL7345605_QB8752841_REV00_user_mid_noship.tar
The kernel is 3.18.14-7345605 Thu 25th Feb 2016 so it should be exploitable I'd love to get my S7 Edge working again
droidvoider said:
My tool will likely be helpful to you because that sounds good enough as long as you can get to a prompt that is CVE-2016-5195 / SVE-2016-7504 vulnerable. Anyone who isn't patched beyond Sept 2016 on any Android in the last 10 years will be able to use the tool I'm building to do amazing things. I am designing it precisely for people like you and Delgoth who have large investments in phones that could simply be repaired with enough access.
I am thinking now to fork off a child process anytime I can capture root + "any_new_context"... This will be forked into a child process then kept in a loop. If there is a new root + context that happens along through toolbox, we will grab that also.. (but I won't grab two of the same for example root + system_server I just need once)
I am hoping I can control this loop from the command line but since I am not the caller of the process for which I am capturing I am not sure that would work. This is new code to me, not sure of any examples of something like this. If I have to control it through values I set in files it adds a little more time. The great news is I am not having binary size problems so I can add quite a bit of code while still keeping toolbox much less than the currently installed version on my Note 5. File size must match exactly otherwise patching causes seg fault and seg fault ruins the fun (reboot to cure but irritating)
anyway just needed to come up for air I have a ton done, need to get toolbox fired up to test angle.. any c programmers that want to help or anyone with awesome ideas please feel welcome I could use help
Click to expand...
Click to collapse
Do you have your toolbox on github? And is it commented decently? If so, I can look into helping with your code. I ask about comments because Ive not really looked into the whole. But if we figure out what parts samsung and at&t stripped down the AOSP toolbox, there could be a vector for completely patching the toolbox binary installed on our device.
Most root methods I see around, use busybox and su.
But our note 5 actually uses toolbox instead. Meaning, adapting a root method to use toolbox instead of busybox, eliminates that extra disk space taken up by the busybox binary, that needs to be patched in memory.
I needed to finish another piece of code before I started on toolbox, and that code is finished and on github. I need to be able to replace a list of files and know they are exact byte for byte, that's the code that I made available, which is in itself cool. Now I'm testing how to control the toolbox loop but so far if I get input from the command line the child executes one task then dies. I don't really want to fork fork fork fork things.. I need better control logic. soon i will solve it then upload a great starting point
edit: I realized there is places I can post snippets of code.. Here's the code I'm playing with but please realize some things may not work, not belong or I may have started making variables I never used.. (this is the pile of code I am using for testing).
I test code in Ubuntu first otherwise there wouldn't be enough time in a day:
gcc -o fork_u fork_u.c
./fork_u
http://pastebin.com/7nFxGcnY
Update: It's not exiting after executing a command at all. I messed up that if statement that checks for x. I am not a C programmer by trade I took it in college 20 years ago. Now I'm relearning it, so be warned on that
====>] We have changed directions back to replacing the bootloader see the next post [<====
I am exuberantly confident we can take the bootloader after the testing I've done today. This is the basics of the bootloader
https://www.xda-developers.com/galaxy-s7-bootloader-lock-explained-you-might-not-get-aosp-after-all/
===>] I need someone to copy their bootloader in both locked/unlocked status so I can find what to change. [<===
I am starting to suspect I can't simply copy an unlocked bootloader from another device. I am fairly certain that I need to pull the sboot from the device, patch it and then push it back. I need to actually look at the source code and perform any steps it does as well, such as deleting stuff.
I need someone who is vulnerable to dirtycow with an unlocked version of the Note 5 to pull their sboot in locked/unlocked status. This means they would run the hack I'm using on their device, overwrite toolbox, dumpstate and app_process temporarily to pull the partition.
====>] Plan B is downgrading then attacking an earlier version of the phone [<====
I believe I can write the original sboot.bin and system.img to the Note 5 now to do a forced downgrade. If that is true we could be dealing with trying to root an Android 5.0 device instead of Android 6.0 .. This opens the door on a million exploits!!
Plan B is all I have for now let me know if anyone can help with Plan A
**** Warning **** This is the most dangerous developer tool I've seen in a very long time. You can easily smoke your device with this without even trying.
====>] farm-root updated for Note 5 [<====
Ok guys it works for recovery or boot. It will pull an image or push an image.
https://github.com/droidvoider/Note5-Root-Farmer
toolbox directory compressed for recovery and boot, matches above code
boot push / pull --- aosp toolbox directory
recovery push / pull --- aosp toolbox directory
-DFARM_BOOT changes from recovery to boot in the shared.c
-DFARM_PULL is for pulling in toolbox,c / bridge.c, no define means compile to push.
-DDEBUG is for logcat messages, recompile minus this option to reduce binary size a lot
===>] What was wrong? [<===
When I got this working at first a couple weeks ago I thought I checked the path but I didn't. That and the updates to dirtycow are the only differences between mine and freddies version. (except that I also added push boot.img)
partitions:
/dev/block/platform/15570000.ufs/by-name/RECOVERY
/dev/block/platform/15570000.ufs/by-name/BOOT
directory containing sym links: (shell is allowed to ls -la inside this directory and view partition links!)
/dev/block/platform/15570000.ufs/by-name/
===>] So why can't we do this to the bootloader? [<===
I am now focusing just on this idea!!
Notes: I have a suspicion that if we used the bootloader from another device the numbers won't match, such as mac, and that will be permanent hard brick. I need someone to copy their bootloader partition both locked and unlocked using a tool I create for that purpose. (anyone got a friend who will help out?) Obviously this will not be an AT&T version.
===>] Basic instructions [<===
Download and unzip to a Ubuntu directory (android sdk + ndk needed)
Plug in your device and make sure you can adb shell
Add a screen lock pin to your device first
In terminal change to the directory first then make log
Open another terminal then you compile the sources for pushing or pulling as follows
make pull_boot, make pull_recovery, make_push_boot, make_push_recovery
You will be hung on "waiting for process to complete"
On your phone enter your pin, then go to settings, remove the screen lock pin..
close settings
On your phone again now go add back a lock screen pin.. close settings.
repeat the lockscreen thing it will go...
===<> Breaking my rule and playing with it now <>===
I tried boot.img altered with Assayed kitchen modified heavily but no changes, I think it was written back on reboot I bet recovery-from-boot.p really replaces this.
So I tried with recovery.img from Assayed kitchen modified heavily, I got a big blue error telling me to take my phone to AT&T
(if you get an error use heimdall to flash the specific file(s) or use odin to flash your AP file from the firmware.)
Continue Notes: I have confirmed I am replacing the boot.img and recovery.img completely freddie knocked it out of the park fellas. I have only tried heavily modified versions, I have not tried modifying the pulled version yet. If I flash anything not factory the phone has an error screen telling me to take it to at&t. pwr+vol. down I have to release and retry but eventually I get it to reboot, then download mode. Then simply flashing back what I replaced with farm-root gets me back up again.
If I flash recovery.img from t-mobile note 5 twrp it won't give me the error message until I attempt to enter recovery! After that it will always give the error. I tried putting twrp as the boot.img but that fails too, it does look like it almost loads something then I get the chain of trust error.
continuation of notes: I've still only tried heavily modified versions but I have unpacked the boot.img and recovery.img I've pulled, they are complete. If I flash recovery.img first then reboot without entering recovery it doesn't error. (until you enter recovery then it won't allow boot)... So instead I flashed boot.img also. Now boot.img isn't replaced on startup, I get the blue error message and this time I have to flash both recovery.img and boot.img to get the phone working again. (what does that mean?, mostly it confirms we wrote to both partitions which I have also confirmed through pulling / testing after writes) one thing is for sure this is a lot more fun then having nothing.
edit: nevermind on this idea I want to stay focused on unlocking the bootloader or downgrading it to Android 5.01
Update on status:
I can hard code toolbox to replace a list of files that you create right now, I am confident this includes bootloader, system, and a ton more.. So if anyone wants to do the leg work and find out which partitions are which, gather up a file list to replace and deliver that to me (the text version not the real files) .. I will hard code that out for you.. (i think that's freedom for you, see later bye)... Everyone else please realize I am having fun.. I tried to write toolbox to read what to change from /data/local/tmp/ but as suspected it can't read from there.. Today I will try to use dumpstate to copy a file list to /data/cache so that I can read it as install_recovery.
--- When I read what to change from a file we just need one toolbox for everything.. (no more separate toolboxes)
--- When I can communicate with toolbox in this manner I can move on to the next tool which is controlling the loop
Update:
toolbox is very limited on what it can open for reading if anyone is working on another project following along here for ideas you need to use the farm-root bridge idea. and by that I do mean even patching arbitrary file tests have failed now also, so there will be no eliminating bridge/dumpstate process
Updated again: Haven't had a tremendous amount of time to play lately but I sat down and tested my way through my final idea for farm-root. Bridge reads what to pull/push from a text file and then also pushes a text file to cache/recovery for toolbox to read. The file will have the dd if/of statements. Instead of performing 1 operation bridge will loop it will either wait..pull...wait or push...wait..push.. toolbox dd pulls or dd writes, waits for bridge and they loop between one another doing the work.
(still uncertain about dealing with 4gb file size but I realized that I don't need a sig verification. So I can unpack system, make it quite small then repack. This should smash down the version problem then we will need to do a follow flash of OJ1 AP, CP, CSC files...)
....thanks for your help with things lately @Delgoth you've hurtled this project ahead and are likely the reason it's here at all. I'm not forgetting the other things you mentioned I'm just at a wait and see pattern on what we need to force this downgrade, then get root
droidvoider said:
Update on status:
I can hard code toolbox to replace a list of files that you create right now, I am confident this includes bootloader, system, and a ton more.. So if anyone wants to do the leg work and find out which partitions are which, gather up a file list to replace and deliver that to me (the text version not the real files) .. I will hard code that out for you.. (i think that's freedom for you, see later bye)... Everyone else please realize I am having fun.. I tried to write toolbox to read what to change from /data/local/tmp/ but as suspected it can't read from there.. Today I will try to use dumpstate to copy a file list to /data/cache so that I can read it as install_recovery.
--- When I read what to change from a file we just need one toolbox for everything.. (no more separate toolboxes)
--- When I can communicate with toolbox in this manner I can move on to the next tool which is controlling the loop
Update:
toolbox is very limited on what it can open for reading if anyone is working on another project following along here for ideas you need to use the farm-root bridge idea. and by that I do mean even patching arbitrary file tests have failed now also, so there will be no eliminating bridge/dumpstate process
Updated again: Haven't had a tremendous amount of time to play lately but I sat down and tested my way through my final idea for farm-root. Bridge reads what to pull/push from a text file and then also pushes a text file to cache/recovery for toolbox to read. The file will have the dd if/of statements. Instead of performing 1 operation bridge will loop it will either wait..pull...wait or push...wait..push.. toolbox dd pulls or dd writes, waits for bridge and they loop between one another doing the work.
(still uncertain about dealing with 4gb file size but I realized that I don't need a sig verification. So I can unpack system, make it quite small then repack. This should smash down the version problem then we will need to do a follow flash of OJ1 AP, CP, CSC files...)
....thanks for your help with things lately @Delgoth you've hurtled this project ahead and are likely the reason it's here at all. I'm not forgetting the other things you mentioned I'm just at a wait and see pattern on what we need to force this downgrade, then get root
Click to expand...
Click to collapse
If toolbox is becoming limited, Toybox is also a partner binary that is used on the system beside toolbox.
Also if you can shrink the system partition and keep it persistent. You can shrink it from 4gb to 3.5 safely and then possibly reclaim that 500mb for your own private partition. My installed stock system uses 3.4gb of 4. That hidden partition should then remain even after a factory reset. As long as the device was not repartioned by odin or otherwise. Or as long as a new PIT isn't flashed.
This is where you can store your hacks, and have access to on device when first booting to recovery from a fresh flash.
toybox, good idea
I forgot about toybox when I get this code working I will rerun some of the test code on it to see how powerful it is.
New logic for root-farmer
root-farm will now only have 1 bridge and maybe 2 toolboxes (depending on final binary size for toolbox)
Now the files to PUSH/PULL are in a text file. Bridge copies it to cache and then toolbox can read it also.
PULL example: <= everything before the '|' is one execv command used by toolbox. => | <=== following this character is bridge copy leftvalue => | right value
of=/cache/recovery/bota0_pull.img if=/dev/block/platform/15570000.ufs/by-name/BOTA0 bs=10m|cache/recovery/bota0_pull.img|/data/local/tmp/bota0_pull.img
So push will only push a files.txt, pull_files.txt/push_files.txt is copied to /data/local/tmp/ then bridge decides if this is a push or pull depending on the text file format. After that it's pretty much business as usually toolbox uses the dd command as root+install_recovery to over write or copy anything
This code snippets are not complete. They are meant to show you what I did to test my theories.
toolbox_working example
bridge will copy files.txt to /cache, toolbox will pick it up and then spit the contents out into logcat -- success
unfinished_test_code
that's the parsing, it echos the commands it doesn't actually dd anything.. but you can see it echo what it should be copying, or dd'ing.
updated (adding sources per a users request):
brdg.c.tar.gz == linux proof of concept for bridge, i make copies, test stuff from blocks of code like this then port to android
This morning something dawned on me. If I can write to the first partitions known to the computer worlds as MBR1 512kb limit MBR2 extended mbr.. Then I already own this device. Now I need twrp with the correct addresses for my device, I simple write twrp on the device and wipe the rest.
While I think that is true 100% I have different passions then simply winning. If anyone is willing to try it I will port farm-root over to point at those partitions instead, and also to replace them in one go.
Those waiting for the finished tool I get to play today a little since I had to work Sunday! we should have a template at minimum this evening. I'm adding to sources one is the partitial conversion it will be called Android_Dirtycow_root_farmer from now on.. (because it isn't specific to any device any more it will work with any 64bit dirtycow vulnerable device)
the test zip?, man I forgot what I tested with that just type make test and watch logcat.. tests are always safe, reboot afterwards though.
Tool is working!!!
Android 64 bit universal dirtycow dd image write works for both push/pull.. I am tired so please see github readme, the Makefile and push_files.txt, pull_files.txt examples. I am going to get root, this is the first step.
https://github.com/droidvoider/Android_6.01__DD_Dcow
More info on it
I updated this thread with some info first/last posts only
https://forum.xda-developers.com/no...g-dirtycow-t3559637/post71102343#post71102343
What about root right now?
If I can get system_server + root, then switch to install_recovery + root I can fork both these processes away and send commands to them through a text file just like I sent the options for push/pull. This code wasn't only to eliminate the need for multiple toolbox / bridge binaries.. It was to create a command shell that I can issue any command. Remember my examples above?
.....Work study: take the examples I created and create a loop that doesn't close but instead waits for changes to a text file. Then execv those changes returning to wait again for more changes.
I have to be away for 1 to 4 weeks I just found out.. I might be able to check messages, I dunno. not away but same as.. have fun
Im going to go over all this, this weekend. Hopefully I can work out what data to write.
If we can patch /sbin/sverifysignature then we maybe able to disable the sig check. Right now my device is without a DT_Hash, I have busybox installed and linked to /system/xbin
I also have the su binary in xbin but its not linked so apps dont know it's there. But they both persist through reboots no problem. I am currently half way rooted, with zero hiccups so far.
Im close but im running 5.1.1 with an eng kernel and eng sboot. I dont currently have a CSC installed.
The problems im running into are that most apps have always done root the same way, the way that doesnt work on this device. Root is possible, but the age old standard root injection doesnt fly here, we have to do it manually this time because the standard root install scripts expect privs we dont have in certain places. That doesnt mean we can't root, it just means we have to edit the scripts and run them from some place other than TWRP. Which is still possible.
So here is what I have:
Dm Verity verification failed... Message when entering recovery. No effect on operation.
ADB root on boot, and when charging offline.
Busybox 1.22 fully linked from /system/xbin
Chainfire supersu 2.76 su binary placed in /system/xbin unlinked, I dont know how to link it like I did with busy box.
Even though dm verity fails, I can mount the entire filesystem read/write, and all my changes are still in place after normal reboot. I can modify my system and dm verity does NOT undo my changes. I can even pull my boot img from /dev/block/sda5
What do I have in my hands right now?
Hello,
I am new to xda, but with what I would say a good understanding of computers in general, and good knowledge of c programming (if that matters)
I am structuring a guide for myself to be as foolproof as possible when attempting flashing my new phone. Please fill in any voids, comment, or answer questions if you can. This should prove useful to other users as well as it's not so model-specific.
1) It appears that the custom recovery of choice in most situations and for the time being is TWRP (correct?).
2) If I can get a backup of EVERY partition on my stock phone (as it came from the factory) using TWRP, could I conceivably restore ALL of them and be in a factory default setting? Excluding stuff like eFuse and similar mechanisms.
3) If the phone supports fastboot, unlocked bootloader and there is a compatible TWRP for it, would it be possible to boot the TWRP recovery through fastboot (without flashing that particular partition to phone), open a shell and take backups of all partitions on the phone? That should give us a file for each partition.
4) If one accomplishes step 3 successfully, in what scenarios would he/she NOT be able to bring the phone back to life after software bricking?
Minor questions:
a) "To have root" on a phone, is basically the same as having a root account on a BOOTED OS partition (like the admin accoun on a booted windows machine, or a root account on a linux machine)? If that's the case, booting a different partition (for example the recovery partition) could also give you root priviledges without affecting the booted partition, correct?
b) Why do some custom ROMs require a certain version of the stock/OEM rom to be installed PRIOR to flashing, since they are going to replace those partitions anyway?
c) How is Xiaomi's Anti Roll Back (ARB) feature implemented, if one restores all partitions to stock from step (3) ? There must be some other places of storing of information on the phone, besides internal memory, correct?
I've seen the Recovery System class in Android SDK or API (however it is called) and I thought about modifying its System Partition without touching the Bootloader to unlock or flashing the TWRP Image. I did not test it out yet on my device (my device is Huawei Honor 9X), but I think that it is a cool idea to modify its content on the System Partition.
What I already know is that it is required to have a so-called signed OTA package, but I am unsure if this requires the system OTA certificates from /system/etc/security/otacerts.zip or the self-signed package. Since my device settings do not support installing packages from the storage (it is because of the dload folder), I would need to have a hand coded app (what I really like) to install these packages myself.
Another problem could arise: the Bootloader may check for the files, which, for example, an app that came from nowhere or a patched libc.so file via its checks (since my phone does not have A/B partitioning, I think it does that). From what I already read somewhere is that any Recovery trusts any package that is signed, but I didn't trust that and searched the Internet, where I literally didn't find anything useful to that. I hit another dead end, but that didn't stop me from doing so.
Since my computer already dual-boots Ubuntu and Windows 11, I could mount any system.img file and check file-per-file if it may modify the system's behavior, but I am anxious about that because I already bricked several phones in the past that I don't want to watch another one getting either soft-bricked or hard-bricked.
So to come into conclusion: is it possible to modify any file on the System without unlocking the bootloader or flashing a custom recovery, or is this required to do so before modifying on the System partition? I am not ready to flash Magisk onto my phone nor flash the TWRP because there are no official image(s) for my device.
BeChris100 said:
I've seen the Recovery System class in Android SDK or API (however it is called) and I thought about modifying its System Partition without touching the Bootloader to unlock or flashing the TWRP Image. I did not test it out yet on my device (my device is Huawei Honor 9X), but I think that it is a cool idea to modify its content on the System Partition.
What I already know is that it is required to have a so-called signed OTA package, but I am unsure if this requires the system OTA certificates from /system/etc/security/otacerts.zip or the self-signed package. Since my device settings do not support installing packages from the storage (it is because of the dload folder), I would need to have a hand coded app (what I really like) to install these packages myself.
Another problem could arise: the Bootloader may check for the files, which, for example, an app that came from nowhere or a patched libc.so file via its checks (since my phone does not have A/B partitioning, I think it does that). From what I already read somewhere is that any Recovery trusts any package that is signed, but I didn't trust that and searched the Internet, where I literally didn't find anything useful to that. I hit another dead end, but that didn't stop me from doing so.
Since my computer already dual-boots Ubuntu and Windows 11, I could mount any system.img file and check file-per-file if it may modify the system's behavior, but I am anxious about that because I already bricked several phones in the past that I don't want to watch another one getting either soft-bricked or hard-bricked.
So to come into conclusion: is it possible to modify any file on the System without unlocking the bootloader or flashing a custom recovery, or is this required to do so before modifying on the System partition? I am not ready to flash Magisk onto my phone nor flash the TWRP because there are no official image(s) for my device.
Click to expand...
Click to collapse
@BeChris100
Prior to your next posting please read the guidances that are stuck on top of every forum like
Note: Questions go in Q&A Forum
If you are posting a Question Thread post it in the Q&A forum. Technical discussion of Android development and hacking. No noobs, please. Device-specific releases should go under the appropriate device forum...
forum.xda-developers.com
I've moved the thread to Android Q&A.
Thanks for your cooperation.
Regards
Oswald Boelcke
Senior Moderator