Took a while to work things out, but DirtySanta has been successfully extended to international versions of the LGE V20.
While I have tried to ensure this works for anyone, this may fail. I also do not provide any warranty! The result of a failure could include voiding of warranty and hardware damage. This is also one of the most complicated rooting procedures due to SE Linux, we've been unable to simplify things.
Be careful! Many of these commands have a high probability of resulting in a brick if mistyped. Be prepared to have your V20 out of commission for a day or two while you ask questions about the state your phone has ended up in.
Also Don't Panic! If something starts going wrong, stop. Better to have your daily driver out of commission for 24 hours, than have it out of commission permanently.
As of this time there are some sporadic reports of problems. Some people have camera trouble. If a cause can be identified these will definitely get fixed ASAP. Work is well under way, experimental fixes for this are out.
As preparation, I would like folks to be familiar with LGUP/LGBridge and how to use them. Using LGUP is also how to get back to stock. On the H990DS Bluetooth is implemented via kernel module and the kernel module has to be loaded off /system, therefore there is no choice but to write to /system.
Beware: Once past14 LGUP will recognize your device as a US996. Do not flash a US996 KDZ file! Doing so will brick you. See below for instructions on going back to stock.
Devices
H990DS (dual-SIM): Known working
H990N (dual-SIM): Known working
H990 (single-SIM): Known working
H990* (other): ALPHA reports of success needed.
There is now a v0.2.4 combined kernel. This version should work for all H990* variants and should hopefully have fewer issues due to being on a later kernel release. The quirk of some of the dual-SIM features showing up in menus should be fixed in v0.2.4.
v0.2.4 includes patches for all of the recently discovered kernel issues. The kernel Bluetooth patch is included, but the are also userspace patches for a portion of "BlueBorne". The "Broadpwn" vulnerability has also been patched. Yet more 802.11 patches have been added over v0.2.3a, unfortunately the fix for the KRACK attack is in the userspace program "wpa_supplicant" not the kernel.
Alternative instructions:
By @ahlok_hk here
Rooting and full bootloader unlock for the H990 versions of the LGE V20:
Ensure you have a backup plan: https://forum.xda-developers.com/v20/how-to/restore-v20-to-100-stock-bricked-devices-t3524903
Backup your phone data. LG Bridge/LG Backup is pretty reliable, but I strongly advise backing up everything onto a desktop/laptop computer. If you backup to SD card, the SD card must not be encrypted! (failures will destroy the key and the data)
Go to Settings -> General -> About phone -> Software info -> Android security patch level; if your phone is on an update after December 31, use LGUP to "refurbish" to an earlier firmware release (this will do a factory reset).
Ensure you have ADB/Fastboot files installed and working: https://forum.xda-developers.com/showthread.php?t=2588979
This also requires developer mode -> USB debugging to be enabled.
Ensure you have all relevant files prepared:
Installed backup plan.
Installed Terminal Emulator on device.
Downloaded DirtySanta's files and copied them to ADB directory.
Downloaded files, Put kernel and SU implementation (Magisk.zip and
SuperSU.zip work) into SD card; and TWRP into ADB directory.
Note: It may be necessary to temporarily disable anti-virus/anti-malware programs when unpacking the original DirtySanta. At least one has detected `dirtycow`/CVE-2016-5195 as malware (it can in fact act in that role).
Using dirtysanta's steps: Run "RUNMEFIRST.bat" <-- Do not close.
Run "step1.bat" <-- Wait until you can type something again.
Type "run-as con" <-- If you get unknown package error, means your latest security patch patched it out; go back to step 3. LGUP should be able to downgrade you to an earlier firmware update.
Type "chmod 0777 /storage/emulated/0/*"
Open Terminal Emulator, Type "id"
Look for something containing "untrusted_app". If not found, Start all over again. If found, continue.
Type "applypatch /system/bin/atd /storage/emulated/0/dirtysanta" into Terminal Emulator
Wait for RUNMEFIRST.bat console to prompt you to run step2.bat.
Run "step2.bat"
Save copies (put them somewhere safe where you'll remember them) of the files "abootbackup.img" and "bootbackup.img", which "step2.bat" saves in its directory, the latter is crucial in returning to stock.
At a command prompt run the following commands, but make sure to wait at least 30 seconds between each. Do not skimp on that delay as otherwise the likelihood is this will fail (this is the most unreliable step in this process); waiting longer than 30 seconds is fine.
Code:
fastboot flash recovery twrp-3.0.2-1-h990.img
fastboot flash recovery twrp-3.0.2-1-h990.img
fastboot reboot
Of all steps this is by far the most unreliable! If you have problems at the end, most likely you'll need to get back to the bootloader (hold power-UP and then insert USB cable) and repeat this step.
Boot in to TWRP.
Press and hold volume DOWN; press and hold power until the LG logo comes up, then briefly release power (0.5-1.0sec) and then hold power again. If you fail to get this right the first time, you will likely need to pull the battery out and start from power off.
You will then be prompted "Delete all user data (including LG and carrier apps) and reset all settings?"
Select "Yes" twice, and as long as TWRP installation was successful you'll get into TWRP and NO RESET will be done.
Inside TWRP flash "h990-kernel.zip" and then flash SU implementation (Magisk.zip or
SuperSU.zip). At this point the process should be complete. There won't be static on boot, you'll have root and nothing else should have changed.
If your phone's userdata got locked, there may be a need to wipe cache and data to regain access.
During all subsequent boots a red triangle with a warning about your device being corrupt will show up. The only method to remove that would be to get my kernel signed by LGE and I'm rather doubtful that will ever happen. Only thing we can do is to call it a badge of honor.
There is now a tool for writing KDZ files to phones. This is recommended in order to get up to date on security patches.
Going back to stock:
As with those whole rooting procedure, this is hazardous. Be careful, go slow and don't rush things.
Method 1a: (TWRP, strongly preferred!)
Boot into TWRP (DOWN + Power with a brief release during LG logo).
Copy the file "abootbackup.img" from your archive to your phone (adb push abootbackup.img /). This is the file you should have saved from step 15 above.
Run `adb shell` and type (or copy&paste) the following commands:
Code:
dd if=abootbackup.img of=/dev/block/bootdevice/by-name/aboot
sync
sleep 30
sync
Get into Download mode. Power off phone from TWRP. Press and hold UP, then power phone on (no need to hold power).
Load the appropriate KDZ file onto your phone via LGUP.
Method 1b: (TWRP, with file from another source)
This is simply a tweak of the above resulting from recalling there is a backup of aboot already on the phone itself.
Boot into TWRP (DOWN + Power with a brief release during LG logo).
Run `adb shell` and type (or copy&paste) the following commands:
Code:
dd if=/dev/block/bootdevice/by-name/abootback of=/dev/block/bootdevice/by-name/aboot
sync
sleep 30
sync
Get into Download mode. Power off phone from TWRP. Press and hold UP, then power phone on (no need to hold power).
Load the appropriate KDZ file onto your phone via LGUP.
Method 2: (fastboot)
Danger! This method is not recommended, except as an emergency fallback. Writes done via `fastboot flash` have be demonstrated to unreliable. This works if TWRP is unavailable, but avoid if possible.
Boot into fastboot mode. Any of these methods should work:
(if Android running normally) Run `adb reboot bootloader`
(from a powered down state) Press and hold DOWN, then plug in USB cable.
(powered down, USB plugged in) Press and hold DOWN, then power on.
With "abootbackup.img" in the current directory run the following commands, while waiting at least 30 seconds between them:
Code:
fastboot flash aboot abootbackup.img
(wait >30s)
fastboot flash aboot abootbackup.img
(wait >30s)
fastboot reboot
Get into Download mode. Press and hold UP. If the phone has already started to load Android, pull the battery, reinstall battery; then press and hold UP and power on.
Load the appropriate KDZ file onto your phone via LGUP.
Rescue from going back to stock problems:
Apparently it is possible to enable extra features in LGUP, documented in this thread. If you're forced to use approach back to stock approach v2, here is a method to rescue you. This may even have the potential to function as an alternative DirtySanta installation approach. This even works as a full back to stock method by itself! Thanks to @Prowler_gr for sharing!
Technical discussion
If you're not planning to build your own kernel and aren't curious about how things work, no need to read these long details.
What was my old tree is here. I've got a build hack, which I suspect is meant to be handled by other means (later compiler?) so some extras are here.
Now releasing version v0.2 here. With the extra hack for compilation and exfat is here.
My latest .zip makes use of the `fix-h990-cmdline` tool from here.
There are 3 major fixes needed for making working kernels for the H990.
First, the H990 has its own distinct version of the panel timings, which was added in this commit. Combined with the more robust graphics driver from CAF, this solves the "static" issue. The "static" issue is far more severe for the H990* than other V20 versions, the workaround of covering the proximity sensor does not work.
Second, the kernel command-line needs to be modified. Crucially this tells the Android runtime whether the device is single-SIM or dual-SIM. This was originally implemented in a combination of commit 1 and commit 2. Notice CONFIG_CMDLINE and CONFIG_CMDLINE_EXTEND add on to the command-line passed by the boot loader.
Third, the modem driver (files in /firmware) apparently gets its information on the modem chip by looking at a structure in the SMEM_ID_VENDOR0 portion of platform "smem" area. The original LGE boot loader puts appropriate values into this data structure, but the DirtySanta debug boot loader leaves important parts of the structure uninitialized. As such this area needed to be modified before modem initialization, done here.
Originally these values were added by hard-coding them. This works, but doesn't scale well. Even before my first kernel release I was pondering modifying things by reading them from the command-line. In order for this strategy to work, these additional arguments must be added to the Android boot image command-line. This additional step was implemented in `fix-h990-cmdline` in my lg-v20-tools. For a H990DS the string " model.name=LG-H990ds lge.sim_num=2 lge.dsds=dsds androidboot.bl_unlock_complete=false androidboot.authorized_kernel=true" is added, while for a H990 the string " model.name=LG-H990 lge.sim_num=1 lgs.dsds=none androidboot.bl_unlock_complete=false androidboot.authorized_kernel=true" is added.
With my current kernel source `fix-h990-cmdline` must be run on the boot image before the kernel will successfully boot. This is done inside the tools/ak2-core.sh script in the .zip file. The command is `$bin/fix-h990-cmdline /tmp/anykernel/boot-new.img`. `fix-h990-cmdline` could also be run on /dev/block/bootdevice/by-name/boot after the kernel had been installed.
Important note, modification of the boot image command-line must be done carefully. If a previous kernel already added the command-line options, care must be taken to ensure they're not present multiple times. `fix-h990-cmdline` was specifically written with this issue in mind, please don't break this. Also note fix-h990-cmdline will replace the values of "model.name", "lge.sim_num" and "lge.dsds" based upon the contents of the misc area; the values of "androidboot.bl_unlock_complete" and "androidboot.authorized_kernel" will be left alone if already present.
The most recent version of `fix-h990-cmdline` has been modified to allow specifying the model and SIM count on the command-line. `fix-h990-cmdline` will complain if the command-line disagrees with the misc area, but it will obey the command-line and lie to the kernel.
Thanks and warning:
This is near certain to void your warranty. While care has been taken to reduce the chance of producing a brick, there are no guarantees.
Thanks to:
@me2151 the original DirtySanta bootloader, crucial for this to work
@thubble for figuring out the last bit of the modem fix and (successful) guinea pig #2
@exadeci (successful) guinea pig #1
@Xenogenics helping others, posting some reasonable instructions
@USA-RedDragon for making everyone aware of LineageOS's source tree
A copy of the source tree used for building these is here. Two small hacks are used during the actual build process, this is an exact copy of what is built.
News:
v0.2.2: The kernel portion of BlueBorne is patched. Unfortunately there is apparently a userspace portion as well. Broadpwn (Wifi vulnerability) is patched.
v0.2.3: Adding the driver for the S5K2P7 camera sensor, seems LGE needs to work on their updates since they're required to release source for this updated driver, but haven't. This fixes the camera focus issue observed on some devices.
v0.2.3a: The internal fix-h990-cmdline utility was adjusted due to the quirk with single-SIM devices. This should make the dual-SIM menus disappear from single-SIM devices.
v0.2.4: Yet more 802.11 patches have been added (KRACK is in wpa_supplicant on /system, not the kernel). A tentative fix for the video recording issue has been found. There are distinct downsides to the fix, but at least something working is available
H990* Generic Kernel v0.2.4:
MD5: 5c37b2fa01417874fa6e4456a333792d
SHA1: 79033bad078991180b6f308c99527ef4cd6e1379
SHA512: c2167602edd93e7bab76e7e89093e2ebb1670163ccb812ec327b03d98931c57566a3ab565e81ca4b7de142771f22e6723f291df0c5cad82982a24d5da18b5011
H990* Generic Kernel v0.2.3a:
MD5: b9cd4c750e9bc8627d07243f7e4c3c82
SHA1: e16f348e11e765651564922823b9e38f27c41976
SHA512: 1965bec516d6b886aa283b24906a6bec1c3e8a9b39f1efd5f57c00eaa222940d3cc2420cee83712f47c17e0b397ab1b1d7254c5c43d40ca016e06630206f5505
H990* Generic Kernel v0.2.3:
MD5: fb32e04ec9f5f2fd21bf226db722947c
SHA1: e7ab1533106e0d11075e21b097629be307123879
SHA512: 0c58586c1a8a678d644912d2dd64d970cd0614a8c85bfaae787d1970b16bd03306bd3189f9b07ace80d0f9f9072fc7b6efbd4556da0b09d4ad205922b35aedd9
H990* Generic Kernel v0.2.2:
MD5: f85de33a3354973920b6ffc7baeb7d62
SHA1: 2a9dd897fd44efa13be0f4d2e17ef90ba896b399
SHA512: 3f4e8110b68ae58b38f3abc50d3633df9b45bf4a68120e37ea3934e78b659514d20a2ddbe2d35a30a23b9ed6285c47cacacd43676da82d678201e79748e57c8b
H990* Generic Kernel v0.2.1:
MD5: d08807bc5f3e14fbbcbadbf7013988d0
SHA1: 3b1871c974fe06a6125a47200dc0e35b12a20abc
SHA512: 6d84c27f5752b1313157bbebb917683ce37384032b3d72afc15fa3679839da325a1fdb0824aca28dda2d95161d0e4a0ec343e4e1f35fd0b3700e156d4d60f03f
Alternative kernel builds:
I'm carefully releasing source of my kernel builds (above) and others are welcome to build kernels modified to their preferences. They can also target any kernel issues they find and fix.
@jahlex has the "D.O.T.S." kernel here. This is built from stock LGE and targets camera issues. Due to being closer to LGE's source it may well provide some better hardware support.
@Leicxan has successfully built a werewolf derived kernel, here. For a number of people this works better.
Finally @emdroidle
Hi, great job on unlocking the bootloader @emdroidle!
I know this is a noob question but I'm not really familiar with custom ROMs, but does this mean I can flash existing custom ROMs for the other V20 variants or do we need to wait for them to support the H990DS?
Thanks!
thanks very much.
i rooted my H990N (Hong Kong version) successfully using H990DS-Kernel.zip.
i translated the root tutorial into chinese and modified the bat files (some in chinese too), and posted it here:
http://bbs.gfan.com/forum.php?mod=viewthread&tid=9163590
Thanks, will try it tonight.
faeterov said:
Thanks, will try it tonight.
Click to expand...
Click to collapse
Getting the error "LGUP can't load the model[C\Progrem Files(x86)\LGElectoronics\LGUP\model\com"
This post
https://forum.xda-developers.com/v2...ed-devices-t3524903/post70385757#post70385757
recomends using uppercut to avoid the error. Is this recomendation compatible with this root method?
Great guide. The thread title is a little funny though
Anyone can confirm it is working ??
Hamodi said:
Anyone can confirm it is working ??
Click to expand...
Click to collapse
definitely up and working. OP has been working on this for months, and I feel that it is rather rude to post this here.
you can have a go counting the number of success in the bounty thread here.
Thanks again to emdroidle for the crazy amount of work and time spent here.
SAILOR-HB said:
i rooted my H990N (Hong Kong version) successfully using H990DS-Kernel.zip.
i translated the root tutorial into chinese and modified the bat files (some in chinese too), and posted it here:
http://bbs.gfan.com/forum.php?mod=viewthread&tid=9163590
Click to expand...
Click to collapse
Uh, this may or may not have any effects, but if you go to Settings -> General -> About phone -> Common -> Hardware info -> Model number, you will likely find it reports your phone as a "LG-H990ds".
This is why I've got the instructions for information needed for adapting to new devices. This is also why that kernel wasn't listed as being for the H990N.
A few moments after this message is posted, there will be a new h990n-kernel.zip. As with others for which I lack the device, no guarantee it will work (it should, but reality...). From where you're at you can simply flash it in TWRP without repeating any other steps.
rubiicon59 said:
Great guide. The thread title is a little funny though
Click to expand...
Click to collapse
I thought it was appropriate. DirtySanta had already gotten most of the V20s, merely hadn't gotten these last few variants.
Hamodi said:
Anyone can confirm it is working ??
Click to expand...
Click to collapse
There are multiple confirmations. The big deal is this process is complicated. The step of installing TWRP has been shown to be unreliable due to fastboot not giving indications of completion.
faeterov said:
Getting the error "LGUP can't load the model[C\Progrem Files(x86)\LGElectoronics\LGUP\model\com"
This post
https://forum.xda-developers.com/v2...ed-devices-t3524903/post70385757#post70385757
recomends using uppercut to avoid the error. Is this recomendation compatible with this root method?
Click to expand...
Click to collapse
That is only needed for the step downgrading the firmware to a version vulnerable to DirtyCOW. It is irrelevant exactly what method is used to do that.
emdroidle said:
I thought it was appropriate. DirtySanta had already gotten most of the V20s, merely hadn't gotten these last few variants.
Click to expand...
Click to collapse
I Think It should be like this, Highlighting root in the tittle . [ROOT] H990DS H990N H990 DirtySanta
Regards
i have a grey screen on acces twrp why?
{
"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"
}
twrp say me a password why ?
@emdroidle , this are the dirtsanta files?
https://www.androidfilehost.com/?fid=457095661767122821
You should post them directly in your original post, in order to prevent people from downloading the wrong files.
will try is later tonight, thanks so much for this effort
I'm currently on step 16. I see the phone in fastboot mode
(1130) Fastboot mode started
But as I type
fastboot flash recovery twrp-3.0.2-1-h990.img
I don't see any feedback from the screen of my phone. Also the command line gets stuck on <waiting for device>
I waited 1 minute, then started another command prompt, again flashed recovery, with no feedback again from the phone or the CMD
FInally, after some minutes I type
fastboot reboot
and the sma results...
Should I just restart?
EDIT: nevermind, seems like I had to reboot my pc in order for it to install the drivers to run fastboot.
---------- Post added at 03:48 PM ---------- Previous post was at 03:08 PM ----------
MMMM, root failed, I got a corrupted screen.
Will try to go back to stock and retry everything, but all seemed to go well.
Its not corrupted screen .
When you see it put the phone with the screen on table for 30 sec
Hamodi said:
Its not corrupted screen .
When you see it put the phone with the screen on table for 30 sec
Click to expand...
Click to collapse
Come again?
ronaldyeo said:
definitely up and working. OP has been working on this for months, and I feel that it is rather rude to post this here.
you can have a go counting the number of success in the bounty thread here.
Thanks again to emdroidle for the crazy amount of work and time spent here.
Click to expand...
Click to collapse
I know its working with DS but shuold try it for single sim too
Non had test yet , will do this later tonight
---------- Post added at 04:32 PM ---------- Previous post was at 04:27 PM ----------
faeterov said:
Come again?
Click to expand...
Click to collapse
What you mean ?
Static screen will be with every reboot
Not sure if its with 990 too but it was with others version
Hamodi said:
I know its working with DS but shuold try it for single sim too
Non had test yet , will do this later tonight
---------- Post added at 04:32 PM ---------- Previous post was at 04:27 PM ----------
What you mean ?
Static screen will be with every reboot
Not sure if its with 990 too but it was with others version
Click to expand...
Click to collapse
I could get into twrp, so i wasnt able to continue with the mod. Went back to stock, will try again later on my phone H990DS.
Related
OFFICIAL ONEPLUS 2 STOCK RESET
SOURCE : OnePlus L2 Support Team
VERSION : OxygenOS 2.2.0
DOWNLOADS
1. OnePlus2 Stock Reset Oxygen OS 2.2.0 Google Drive | Mediafire
2. Qualcomm Drivers Version 1.00.11 Google Drive | Mediafire
INSTRUCTIONS
You are doing this on your own responsibility. I take no responsibility whatsoever.
(THIS WILL WIPE YOUR ONEPLUS INCLUDING INTERNAL SD)
Download both the files from above and extract them (WinRAR, WinZIP, 7ZIP etc). You should have 2 folders: "OnePlus2_14_A.11_151211" and "qc"
A. Install the Certificates followed by the Qualcomm drivers.
1. Restart your computer with Driver Signature Enforcement Disabled (Advanced Startup) Let me Google it For You
2. Open the folder "qc" and install the Test Certificate in the following Stores: Trusted Root, Trusted Publisher, Third-Party Root and Personal
3. Run the Qualcomm setup wizard (also located in the qc folder)
4. When completed, restart your PC again with Driver Signature Enforcement Disabled (Advanced Startup)
5. Turn off your phone and disconnect the USB cable from the phone.
6. Hold vol-up and plug in the USB(Do not press Power button). The screen will stay black but you will hear a sound from windows that a device is attached.
7. The driver should now automatically install. If not, go to device manager and right click "Unknown Device" and click "Update Driver" Search up the QC folder and press ok. The driver should now install. (Got the RELINK issue? Take a look here: http://forum.xda-developers.com/show...1&postcount=46)
B. Flashing Process
1. Open the OnePlus2_14_A.11_151211 folder and open "MSM8994DownloadTool.exe"
2. Look if your phone is detected in the list. everything is Chinese but you will see one row with different chinese text from the rest within the list. If not, recheck if driver is detected in Device Manager (If not, go back to Step A - Line 4).
3. First click the right square Chinese button. This will perform an integrity check on the downloaded files by verifying the MD5 hash values.
4. The system will seem to hang for a bit but should give you a pop up with the results of the above verification. When everything is ok. Press the start button. and let the progress finish. (If something is not ok, you will have to re-download the images. Google Drive can help extract only the necessary files.)
5. When it's done. Disconnect the USB cable and turn on the device.
C. Reset TAMPER Flag (Optional)
(This may potentially change your SmartPhone to a rather large paperweight and I will just laugh at you bearing no responsibility)
+ This part of the guide is not an Official Procedure and is in no way affiliated to OnePlus
+ It is advisable to do this before any of the above mentioned operations.
+ Prerequisites:
Root
HEX Editor with root features
Root File Manager
+ BEWARE: You are modifying partitions which cannot be restored regardless of what you flash. You have been warned AGAIN
1. In File Manager browse to the devinfo partition (dev/block/bootdevice/by-name/)
2. Open devinfo using the HEX Editor.
3. Modify the TamperBit (attached screenshot) from 01 to 00.
4. Save and reboot to fastboot.
5. Type fastboot oem device-info to confirm.
CREDITS
OnePlus Team for the Files.
@paultje162 for adaptation of Instructions. Refer his thread here if you are looking for an older version of stock reset (2.1.1).
@thedropdead for his work on Tamper Reset
If this thread has helped you, do press the THANKS button. Should you have issues, questions or doubts, write in this thread.
Just need to confirm that these files are actually official
Pm me the s3 support link
---------- Post added at 13:14 ---------- Previous post was at 13:10 ----------
And my friend
You need to install the test certificate first !
Edit:- file confirmed legit ! Totally official, way to go, @fareed_xtreme !
[email protected] said:
Just need to confirm that these files are actually official
Pm me the s3 support link
---------- Post added at 13:14 ---------- Previous post was at 13:10 ----------
And my friend
You need to install the test certificate first !
Click to expand...
Click to collapse
Thanks for spotting the error. I have fixed the heading. S3 Link PMed.
fareed_xtreme said:
Thanks for spotting the error. I have fixed the heading. S3 Link PMed.
Click to expand...
Click to collapse
Whenever you get drivers like this, dig into their folders and you'll find important documents and instructions to use
That is how I found out about this certificate
Is there any similar process por ONEPLUS ONE?
I only have fastboot mode, without recovery and bootloader locked (fastboot oem unlock doesn't work)
http://forum.xda-developers.com/showthread.php?t=2970390
@xbit
xbit said:
Is there any similar process por ONEPLUS ONE?
I only have fastboot mode, without recovery and bootloader locked (fastboot oem unlock doesn't work)
Click to expand...
Click to collapse
Quick search and: http://forum.xda-developers.com/oneplus-one/general/guide-unbrick-oneplus-one-t3013732
beaverhead said:
http://forum.xda-developers.com/showthread.php?t=2970390
@xbit
Click to expand...
Click to collapse
This didn't work for me:
fastboot oem unlock didn't work because I had a corrupt bootloader.
Spannaa said:
Quick search and: http://forum.xda-developers.com/oneplus-one/general/guide-unbrick-oneplus-one-t3013732
Click to expand...
Click to collapse
But this was great! My OPO is alive now. Thanks
Thank you!!!! this worked.
I was eventually able to get the restore program to recognize it and restore it so it could boot normally. Thank you!
Download from your Link
https://drive.google.com/folderview?id=0BxFd4Zc3_d1CWDdOSFFIVG42VTg&usp=sharing
the File:
OnePlus2_14_A.11_151211.rar
Extract it.
But where is the "QC Folder"
found only "OnePlus2_14_A.11_151211"
Your Link to:
http://forum.xda-developers.com/show...1&postcount=46
is wrong. (Not complete) Error 404
Wagi99 said:
Download from your Link
https://drive.google.com/folderview?id=0BxFd4Zc3_d1CWDdOSFFIVG42VTg&usp=sharing
the File:
OnePlus2_14_A.11_151211.rar
Extract it.
But where is the "QC Folder"
found only "OnePlus2_14_A.11_151211"
Your Link to:
http://forum.xda-developers.com/show...1&postcount=46
is wrong. (Not complete) Error 404
Click to expand...
Click to collapse
Yep, the qc folder is missing from the zip.
The link should be: http://forum.xda-developers.com/showpost.php?p=64674951&postcount=46
I suspect these are both down to copying & pasting the instructions from @paultje162's thread and I'm sure @fareed_xtreme will sort it out when he gets the chance.
Wagi99 said:
Download from your Link
https://drive.google.com/folderview?id=0BxFd4Zc3_d1CWDdOSFFIVG42VTg&usp=sharing
the File:
OnePlus2_14_A.11_151211.rar
Extract it.
But where is the "QC Folder"
found only "OnePlus2_14_A.11_151211"
Your Link to:
http://forum.xda-developers.com/show...1&postcount=46
is wrong. (Not complete) Error 404
Click to expand...
Click to collapse
Thanks for spotting the errors. I have updated them. It is indeed a miss on my part in regards to the QC. Hence I have uploaded it separately and updated the instructions.
Spannaa said:
Yep, the qc folder is missing from the zip.
The link should be: http://forum.xda-developers.com/showpost.php?p=64674951&postcount=46
I suspect these are both down to copying & pasting the instructions from @paultje162's thread and I'm sure @fareed_xtreme will sort it out when he gets the chance.
Click to expand...
Click to collapse
Yup, A copy paste is not the right way to copy a link. Haven't been around these threads for quite some time and guess i did not remember that the links are trimmed down. Thanks for the correct link.
Updated Information with UnTamper Guide
Hello
Doing the anti tamper method you did. Shouldn't this be easier by doing "fastboot oem lock" ?
I think it should have the same effects. Of course, this command must be done when an official ROM is on the phone, doing this in a custom ROM can cause unexpected behaviour, including bricking.
albertocastillo2001 said:
Hello
Doing the anti tamper method you did. Shouldn't this be easier by doing "fastboot oem lock" ?
I think it should have the same effects. Of course, this command must be done when an official ROM is on the phone, doing this in a custom ROM can cause unexpected behaviour, including bricking.
Click to expand...
Click to collapse
From my personal experience, if the Tamper Flag trips, then no matter how official you go it will not go back to Device Tamper= False.
The files in my First Post restores your phone back to an out of box phone state even locking the bootloader but it will not change the tamper flag. Those files are used by OnePlus Support to fix OS issues. Also the fastboot oem lock has not managed for me personally to get the tamper flag back to default (Same as in OPO once down, its down). So the only way for now for the OPT is by modifying the bit that handles the tamper flag.
You are right. Tamper Flag usually trips when you try to relock the bootloader when having root and other non-stock partitions (custom kernel, recovery etc). (Learned the hard way with my old OnePlus 2. Got it swapped for a new one though as the old one was faulty )
Hope this helps.
fareed_xtreme said:
From my personal experience, if the Tamper Flag trips, then no matter how official you go it will not go back to Device Tamper= False.
The files in my First Post restores your phone back to an out of box phone state even locking the bootloader but it will not change the tamper flag. Those files are used by OnePlus Support to fix OS issues. Also the fastboot oem lock has not managed for me personally to get the tamper flag back to default (Same as in OPO once down, its down). So the only way for now for the OPT is by modifying the bit that handles the tamper flag.
You are right. Tamper Flag usually trips when you try to relock the bootloader when having root and other non-stock partitions (custom kernel, recovery etc). (Learned the hard way with my old OnePlus 2. Got it swapped for a new one though as the old one was faulty )
Hope this helps.
Click to expand...
Click to collapse
Thanks for your reply. I noticed that these are the files that OnePlus team sends you when they want to remote into your device to flash the system. I noticed these are password encrypted. I have a session with them on Monday 6th.
I sent the files they sent me to decryption to get the password to a website that does this. However, they couldn't. My other plan was just to catch the password when having the remote session with them.
Since you already posted the files here, this is no longer needed. Seems you did this earlier than me.
The reason they want to do a full flash on my phone is due to the fact that I have a dual SIM issue. At the beginning both SIMs worked until I had to do a change on the second SIM network (it's an international SIM card that works in every country so you must set up the network manually). Since I tried to change the network. Something got messed up and now only one SIM works at a time. I tried restoring the network settings to automatic with no go. And I also tried to do hard restore on the phone to start over to ensure this would solve the issue.
This didn't solve the issue. So it probably means the settings were done in a partition which is not "/data". So a hard reset obviously wouldn't work. But a full flash surely will.
I asked them if I could do this myself by just sending me the files. I have a good expertise on fastboot, ADB and Linux, and I also understand the partition list and partition images. However, since the phone is not rooted or modified in anyway. I decided I will let them do it for me.
I do have a question thought. How did you find about the anti tamper thing? I assume you had remote session with them, and this is why you have those files. Did they "relock" this for you?
I assume they look at this when they get defective devices returned.
Thanks
albertocastillo2001 said:
Thanks for your reply. I noticed that these are the files that OnePlus team sends you when they want to remote into your device to flash the system. I noticed these are password encrypted. I have a session with them on Monday 6th.
I sent the files they sent me to decryption to get the password to a website that does this. However, they couldn't. My other plan was just to catch the password when having the remote session with them.
Since you already posted the files here, this is no longer needed. Seems you did this earlier than me.
The reason they want to do a full flash on my phone is due to the fact that I have a dual SIM issue. At the beginning both SIMs worked until I had to do a change on the second SIM network (it's an international SIM card that works in every country so you must set up the network manually). Since I tried to change the network. Something got messed up and now only one SIM works at a time. I tried restoring the network settings to automatic with no go. And I also tried to do hard restore on the phone to start over to ensure this would solve the issue.
This didn't solve the issue. So it probably means the settings were done in a partition which is not "/data". So a hard reset obviously wouldn't work. But a full flash surely will.
I asked them if I could do this myself by just sending me the files. I have a good expertise on fastboot, ADB and Linux, and I also understand the partition list and partition images. However, since the phone is not rooted or modified in anyway. I decided I will let them do it for me.
I do have a question thought. How did you find about the anti tamper thing? I assume you had remote session with them, and this is why you have those files. Did they "relock" this for you?
I assume they look at this when they get defective devices returned.
Thanks
Click to expand...
Click to collapse
Please note that the Tamper part of the guide is NOT done by OnePlus. Please note that OnePlus is in no way affiliated to the Tamper part of the guide. The Tamper guide is a result of comprehensive research conducted by thedropdead (information provided in the First Post). The guide is an easier interpretation of all the research that went in there.
OnePlus will only reflash this package which will re-lock the Bootloader only. Tamper Flag is not modified. So sit tight and let them reflash it for you.
You are right to assume I had a session with them earlier and that's how i have the files.
Thanks for your reply.
I would say that if the remote support doesn't untamper the device then it might mean they don't even look at it if the device is returned.
Thanks!
albertocastillo2001 said:
Thanks for your reply.
I would say that if the remote support doesn't untamper the device then it might mean they don't even look at it if the device is returned.
Thanks!
Click to expand...
Click to collapse
Remote Support didn't look into mine. However, not very sure about whether it is checked on returning it. Mine went untampered.
fareed_xtreme said:
Remote Support didn't look into mine. However, not very sure about whether it is checked on returning it. Mine went untampered.
Click to expand...
Click to collapse
Oh, then what happened? I thought the remote support tried to fix your phone. Since you said they didn't untamper the device after I expected they remoted to your phone. What happened then?
Thanks
[size=+2]As a convenience to the users here, I have created recovery-flashable versions of the SM-N900V (Verizon Samsung Galaxy Note 3) Stock ROMs from the following releases:[/size]
[size=+3]NC4 NJ6 NK1 OB6 OF1 PL1[/size]
These flashables are ONLY INTENDED FOR SM-N900V OWNERS WITH UNLOCKED BOOTLOADERS AND STANDALONE CUSTOM RECOVERIES.
These ROMS are NOT pre-rooted. You are responsible for doing that (flash a superSU .zip in the recovery following the ROM flash if you desire root). Or, use the custom recovery's offer to root for you.
These ROMs are NOT debloated. Almost all of the original bloat and crapware is enabled.
[size=+1]NOTE: Odin-flashable Modems are provided as separate downloads for those that want to mix-n-match.[/size]
[size=+2]::::: MODIFICATIONS FROM 100% STOCK:[/size]
A small number of preinstalled apps have been suppressed/frozen; specifically those involved in automatic recovery-partition regeneration, OTA, Knox, or carrier spyware. See notes at [*1]
Also, the following two "build.prop" properties were disabled:
Code:
ro.config.tima=0
ro.securestorage.support=false
This seems to produce more stable ROMs when bootloaders are mix-n-matched with different ROM versions.
A script is provided which allows reversal of all of the above modifications to produce a 100% stock ROM (should you want that). See the notes at [*3]
[size=+2]::::: DOWNLOADS:[/size]
ROMs - Courtesy of Androidfilehost.com
Flashable Modems - Courtesy of Androidfilehost.com
[size=+2]::::: INSTALLATION[/size]
- Wipe system, dalvik, cache, and data (do not wipe /data/media)
- Flash ROM
- (OPTIONAL: full stock behavior restore. See [*3] ) (if you don't understand what this is, don't do it.)
- (OPTIONAL: inject root using chainfire's flashable superSU .zip, or allow the custom recovery to inject root) See [*4]
These flashable .zip ROMs ONLY modify the "system" and "boot" partitions. No bootloader firmware, modem firmware, or recovery partitions are affected; nor are wipes performed on any other partitions.
A script is provided in /system/etc for the ROM suppressions to be completely reversed, resulting in an almost-identical-to-Odin-stock ROMs, including resumption of OTAs etc. [*2]
[size=+2]::::: FEEDBACK REQUESTED [/size]
Because of the bootloader firmware anti-rollback protections, it is impossible for me to test all combinations of bootloader vs. kernel+ROM versions. I am presently still on NC4 bootloader firmware and have run all of these on top of the NC4 bootloader (sometimes flashing the modem which matches the ROM version, sometimes not) If you use any of these with a unique combination of bootloader and kernel/ROM, please drop a success/failure report here. Make sure to report both the bootloader and modem firmware versions.
[size=+2]::::: APPLICATIONS (or, Why Would I Find These Useful)?[/size]
- You want to run a Rooted PL1 stock before a root method becomes available without flashing the PL1 bootloader firmware. Benefit of more security against malware, but all the flexibility of root.
- You want to work on attempting root exploits of the PL1 ROM/kernel without taking the plunge of potentially locking your device forever with an Odin full-PL1 stock flash. E.g., flash the PL1 stock ROM over prior bootloaders (NC4/NJ6/NK1/OB6/OF1). The device can be used as a daily driver while you test your code... assuming that it operates correctly (TESTERS WANTED!)
- You want to flash back to Stock "for a minute" to check something, but without having to completely backup, wipe the device, re-root, re-unlock the bootloader, re-install your custom recovery, and restore your "SD card" data.
- You want a ROM where GPS/NFC/BT "just works"
- You occasionally want to use those Samsung S-Pen or TouchWiz apps.
- You'd like to create your own version of debloated stock.
- You think you might have damaged your hardware doing something and want to "see if it still works on stock"
- You want to run a rooted-stock KitKat ROM despite the fact that your ROM will have giant gaping security holes in it (that can be elevated to root privilege from an app with absolutely zero Android privileges)
[size=+2]::::: FAQs[/size]
Q - I am going to sell/give away my device. Should I use this?
A - Probably not. Use Odin with a factory image instead. These flashes by themselves do not enforce consistent bootloader, modem, or recovery firmware.
Q - Why didn't you debloat XXX and YYY from these?
A - Laziness. And besides, everyone has a different idea of what "debloated" means. Moreover, I wanted something that could easily be toggled into a "100% stock" configuration.
Q - I flashed one of these ROMs and yet I still see the "Knox Warranty" message when I boot up. Are the boot images non-stock?
A0 - The boot images in these ROMs are pure stock, right from the Odin factory tar/.md5 blobs.
A1 - Does your bootloader version match the kernel/ROM version? At least with the NC4 bootloader, you get that message when booting any kernel which is not the NC4 Samsung kernel - even when they are validly signed Samsung kernels. So, the only time you do not get that warning message is when the boot image is unmodified AND it exactly matches the version of the bootloader. I suppose that is the same behavior for other bootloader versions. Sigh.
A2 - "Systemless" root injection modifies the boot partition. That certainly will break the signing as you have modified the original boot image.
There is a way to check to see if your boot image has been modified; here it is:
1) compute the md5sum of the "boot.img" file from the release
2) find out the size/byte length of the factory "boot.img" file ("ls -l boot.img")
3) dump the same number of bytes out of the boot partition and pipe those bytes into the "md5sum" utility:
Code:
dd if=/dev/block/platform/msm_sdcc.1/by-name/boot bs=FILELENGTH count=1 | md5sum
Q - I did the stock reversion process and I still have the "Custom" logo showing up on my phone during boot-up. Why?
A - Because you are using a custom recovery, or a kernel which is mismatched to the version of the bootloader firmware. These ROMs are intended for use with unlocked phones with a custom recovery in any event.
Q - I can't get Knox containers to work. Why?
A - Knox containers will not work on phones with a blown Knox Warranty flag. That's an irreversible change you made to your phone when you unlocked it and booted an unsigned kernel. Sorry.
[size=+2]::::: Revision History[/size]
0.95 remove umount /system at end of reversion script; undo Mobicore service suppression.
0.94 add ELM*{.apk|.odex|etc} to suppressions
0.93 correct chmod mode in restore script for bin/install-recovery.sh (PL1)
0.92 baseline
[size=+2]::::: FOOTNOTES[/size]
[*1] For example: bin/install-recovery.sh, LocalFOTA, SDM, Knox*, VMS, SysScope, et cetera. All the other commercial bloatware and Samsung apps remain. NOTE: because of the possiblity of running these kernels/ROMs on mis-matched bootloader(s) where TZ/Attribution failures could disable certain TrustZone capabilities, I have disabled the following properties in /system/build.prop:
ro.config.tima=0
ro.securestorage.support=false
These may be easily reversed and the device rebooted.
[*2] If you were returning to stock in order to sell or dispose the device, probably it is best to just use Odin with the factory images.
[*3] Using the custom recovery's Advanced->Terminal function, find the script name in /system/etc, i.e.
Code:
ls -l /system/etc/bftb0*
and then
Code:
. /system/etc/bftb0_README*
It is sort of unlikely that anyone would need to use this. It may even be the case that Verizon has stopped providing OTA updates on older releases anyway. But it's there if you want it.
If nothing else, this script is very easy to read and so it documents all the changes that make it slightly different from pure stock; if you want to reverse one particular suppression, just read through the script and perform those individual changes manually, and reboot.
[*4] Since about superSU 2.65, the SuperSU .zip installation method MODIFIES THE BOOT PARTITION! The same is true of "systemless" root installations performed by custom recoveries (e.g. TWRP). You need to be aware of this in one very particular application: Installing a new bootloader over the top of a pre-rooted ROM which has the stock kernel version matching the version of the to-be-installed bootloader/modem firmware.
Running twrp/developer mode (via the unlocked bootloader thread), s7 edge AryaMod rom, with NC4 modem.
Do I flash this via twrp or Odin to get on the PL1 modem?
I want to stay on aryamod. I just want to update my modem
@bftb0 Thank you for this thread Sir. You are always a missive help :good:
godrick15 said:
Running twrp/developer mode (via the unlocked bootloader thread), s7 edge AryaMod rom, with NC4 modem.
Do I flash this via twrp or Odin to get on the PL1 modem?
I want to stay on aryamod. I just want to update my modem
Click to expand...
Click to collapse
Then just flash the N900VVRSEPL1_Modem.tar.md5 modem using Odin. (In the AP slot)
The modems are in a separate folder titled "OdinFlashableModems"; they are meant to be flashed separately according to the whims of the user.**
**having said that - and to stay on topic (which is these Stock ROM flashables) - if any connectivity troubles are encountered, the first thing to be tried is matching the kernel version of the ROM with the same modem version. As in NC4 modem with NC4 kernel, OB6 modem with OB6 kernel, et cetera. Flash the ROM in TWRP, and the modem in Odin (I actually am right now going through a matrix of flashing tests; already it is clear that the NC4 modem can't be used with NJ6 or NK1 kernels, for instance.)
For these ROMs (discussed in the OP) it's probably a good practice to simply download both the ROM of a specific release and the matching modem and perform the first boot of the ROM with the releases paired together. After that folks should feel free to screw around with modems to their heart's content.
cheers
.
bftb0 said:
Then just flash the N900VVRSEPL1_Modem.tar.md5 modem using Odin. (In the AP slot)
The modems are in a separate folder titled "OdinFlashableModems"; they are meant to be flashed separately according to the whims of the user.**
**having said that - and to stay on topic (which is these Stock ROM flashables) - if any connectivity troubles are encountered, the first thing to be tried is matching the kernel version of the ROM with the same modem version. As in NC4 modem with NC4 kernel, OB6 modem with OB6 kernel, et cetera. Flash the ROM in TWRP, and the modem in Odin (I actually am right now going through a matrix of flashing tests; already it is clear that the NC4 modem can't be used with NJ6 or NK1 kernels, for instance.)
For these ROMs (discussed in the OP) it's probably a good practice to simply download both the ROM of a specific release and the matching modem and perform the first boot of the ROM with the releases paired together. After that folks should feel free to screw around with modems to their heart's content.
cheers
.
Click to expand...
Click to collapse
Flash modem from CP slot,
Power off phone, start Odin, turn on phone in download mode.. (vol. down + home + power) and then plug into computer. Hit Vol Up to switch into download mode. Wait for com: notification in Odin and hit Start in Odin.
The above is only for XXXmodem.tar.md5 files. For complete ROMs that also include modem, follow the same except flash from AP slot.
I don't know why, but booting from power off into download mode seems to insure modem only tars 'take'.
Sent from my SM-N900V using Tapatalk
@donc113
I'll admit that I've never come across an Odin guide of any technical depth. I've used both the AP and BL slots (not together) for bootloader firmware, and largely haven't had any major issues flashing modems in the AP slot.
I'm wondering if there is no other purpose for the "slots" other than to be able to sequentially flash firmware using multiple file sources "in a single go". (i.e., the slots are not functionally different from each other, and are mostly there because Samsung service centers have firmware files partitioned by BL/AP/CP/CSC functionality, and the "slots" simply remind their techs to "fill up all the slots" when a complete flash is necessary)
One thing that is certain is that having begun an Odin flash, you can hit the "reset" button in the application (after the phone issues a RESET), but you need to restart the phone again in Odin/Download mode to perform a second flashing operation. Thus (maybe?) the need for multiple slots if firmware is in multiple files?. I guess I could break up a factory image into multiple sets and experiment but that seems low on the priority totem pole right now.
roll your own Odin .md5 tarballs:
Code:
tar -H ustar -c -f Odin-flashable-XYZ.tar flle1 file2 [...fileN]
md5sum Odin-flashable-XYZ.tar >> Odin-flashable-XYZ.tar
mv Odin-flashable-XYZ.tar Odin-flashable-XYZ.tar.md5
bftb0 said:
@donc113
I'll admit that I've never come across an Odin guide of any technical depth. I've used both the AP and BL slots (not together) for bootloader firmware, and largely haven't had any major issues flashing modems in the AP slot.
I'm wondering if there is no other purpose for the "slots" other than to be able to sequentially flash firmware using multiple file sources "in a single go". (i.e., the slots are not functionally different from each other, and are mostly there because Samsung service centers have firmware files partitioned by BL/AP/CP/CSC functionality, and the "slots" simply remind their techs to "fill up all the slots" when a complete flash is necessary)
One thing that is certain is that having begun an Odin flash, you can hit the "reset" button in the application (after the phone issues a RESET), but you need to restart the phone again in Odin/Download mode to perform a second flashing operation. Thus (maybe?) the need for multiple slots if firmware is in multiple files?. I guess I could break up a factory image into multiple sets and experiment but that seems low on the priority totem pole right now.
roll your own Odin .md5 tarballs:
Code:
tar -H ustar -c -f Odin-flashable-XYZ.tar flle1 file2 [...fileN]
md5sum Odin-flashable-XYZ.tar >> Odin-flashable-XYZ.tar
mv Odin-flashable-XYZ.tar Odin-flashable-XYZ.tar.md5
Click to expand...
Click to collapse
The CP slot is also able to flash .bin files.
Sent from my SM-N900V using Tapatalk
Carrier unlocked
flashed rom .rebooted with t-mobile SIM, wih no option in setting to change APN
bftb0 said:
Then just flash the N900VVRSEPL1_Modem.tar.md5 modem using Odin. (In the AP slot)
The modems are in a separate folder titled "OdinFlashableModems"; they are meant to be flashed separately according to the whims of the user.**
**having said that - and to stay on topic (which is these Stock ROM flashables) - if any connectivity troubles are encountered, the first thing to be tried is matching the kernel version of the ROM with the same modem version. As in NC4 modem with NC4 kernel, OB6 modem with OB6 kernel, et cetera. Flash the ROM in TWRP, and the modem in Odin (I actually am right now going through a matrix of flashing tests; already it is clear that the NC4 modem can't be used with NJ6 or NK1 kernels, for instance.)
For these ROMs (discussed in the OP) it's probably a good practice to simply download both the ROM of a specific release and the matching modem and perform the first boot of the ROM with the releases paired together. After that folks should feel free to screw around with modems to their heart's content.
cheers
.
Click to expand...
Click to collapse
teeve said:
flashed rom .rebooted with t-mobile SIM, wih no option in setting to change APN
Click to expand...
Click to collapse
https://forum.xda-developers.com/showthread.php?t=2582747
Sent from my SM-N900V using Tapatalk
teeve said:
flashed rom .rebooted with t-mobile SIM, wih no option in setting to change APN
Click to expand...
Click to collapse
These are in fact Verizon Stock ROMs. If they were intended to be for multiple carriers (out of the box) they would not be in this specific forum, and I would have mentioned it.
That said, any hacks/mods that might have worked in the past on SM-N900V stock ROMs could be possible, with "some assembly required".
I don't have a T-mo SIM to test out the method described in the link @donc113 provided above. (I can tell you though that with a VZW SIM, on the PL1 ROM you only will see "LTE/CDMA" and "CDMA" under Settings->Mobile networks->Network mode. I suppose that could depend on what SIM was in when the phone booted, but I don't really know)
If you get it working, please file a success report. Don't forget to mention the version that you flashed - you omitted that in your Q.
cheers
unlocked Verizon Note 3 w/flashable "stock roms ?
bftb0 said:
These are in fact Verizon Stock ROMs. If they were intended to be for multiple carriers (out of the box) they would not be in this specific forum, and I would have mentioned it.
That said, any hacks/mods that might have worked in the past on SM-N900V stock ROMs could be possible, with "some assembly required".
I don't have a T-mo SIM to test out the method described in the link @donc113 provided above. (I can tell you though that with a VZW SIM, on the PL1 ROM you only will see "LTE/CDMA" and "CDMA" under Settings->Mobile networks->Network mode. I suppose that could depend on what SIM was in when the phone booted, but I don't really know)
If you get it working, please file a success report. Don't forget to mention the version that you flashed - you omitted that in your Q.
cheers
Click to expand...
Click to collapse
OF1. Will try the unlocked hack. Only have LTE/CDMA option as it stands.
Carrier unlocked
bftb0 said:
These are in fact Verizon Stock ROMs. If they were intended to be for multiple carriers (out of the box) they would not be in this specific forum, and I would have mentioned it.
That said, any hacks/mods that might have worked in the past on SM-N900V stock ROMs could be possible, with "some assembly required".
I don't have a T-mo SIM to test out the method described in the link @donc113 provided above. (I can tell you though that with a VZW SIM, on the PL1 ROM you only will see "LTE/CDMA" and "CDMA" under Settings->Mobile networks->Network mode. I suppose that could depend on what SIM was in when the phone booted, but I don't really know)
If you get it working, please file a success report. Don't forget to mention the version that you flashed - you omitted that in your Q.
cheers
Click to expand...
Click to collapse
I dont have a verizon SIM to try the method described in the link. But I flashed the OF1 modem, and when I first start the phone with the T-mobile SIM, it says T-mobile and there is signal bars - and then immediately the data connection goes away and the "not a verizon SIM" comes up:silly:
teeve said:
I dont have a verizon SIM to try the method described in the link. But I flashed the OF1 modem, and when I first start the phone with the T-mobile SIM, it says T-mobile and there is signal bars - and then immediately the data connection goes away and the "not a verizon SIM" comes up:silly:
Click to expand...
Click to collapse
I noticed after my initial reply that those instructions @donc113 referenced presumed there is a "global" mode toggle in the Settings menus, and that doesn't seem to be the case for OF1 (as you say) or PL1 (as I observed).
This isn't an area of expertise for me - I've always been on Verizon, so I never had much of a need to hack a phone to a new carrier. (I'd recommend that you have a complete backup of your EFS partition before you start messing around.) << read that part two or three times.
On PL1, there is this (needs to be executed as root if you don't start it from within an app such as "App Browser"):
Code:
am start -W -n com.test.LTEfunctionality/com.test.LTEfunctionality.LTEFunctionalityTest
And then scroll down to "LTE APN Setting". Hitting the "+" sign (upper right corner) allows you to add a new set of APN parameters. Thing is, I don't know if this is something that allows you to make only a temporary change or if they "stick" after you exit that activity.
There is a file in /efs (namely /efs/apn-changes.xml) which seems to hold APN configuration data, but I have no clue if that is consulted for configuration information, or merely a copy of data that really lives elsewhere.
If the phone isn't your daily driver, you could probably flash back to the NC4 ROM as an experiment to see if "Global" is still available in the settings menu. Not so much because you would want to use an old, insecure ROM, but just to see if you can successfully get it programmed to work with T-mobile for voice+data+sms+mms. At least if you figured out what the correct settings were supposed to be, you'd only be faced with where they are supposed to go in OF1/PL1 (Were you using this phone before on T-mobile? If so, what ROM?)
There's a ton of stuff under the hood with those hidden settings. Hundred if not thousands of tweakable parameters. (If you want your head to spin look under IMS Settings) I would be careful about randomly poking at things. Apparently there's a fair amount of stuff stored in NVRAM which has nothing to do with anything that gets flashed by Odin with factory images, so it is entirely possible to permanently mess up a phone if you aren't super careful about recording prior settings and watching every keystroke. Some of those "maintenance" menus seem to be really poorly programmed - not defensively - and you could make unintended changes simply by walking through a set of menu picks.
.
bftb0 said:
I noticed after my initial reply that those instructions @donc113 referenced presumed there is a "global" mode toggle in the Settings menus, and that doesn't seem to be the case for OF1 (as you say) or PL1 (as I observed).
This isn't an area of expertise for me - I've always been on Verizon, so I never had much of a need to hack a phone to a new carrier. (I'd recommend that you have a complete backup of your EFS partition before you start messing around.) << read that part two or three times.
On PL1, there is this (needs to be executed as root if you don't start it from within an app such as "App Browser"):
Code:
am start -W -n com.test.LTEfunctionality/com.test.LTEfunctionality.LTEFunctionalityTest
And then scroll down to "LTE APN Setting". Hitting the "+" sign (upper right corner) allows you to add a new set of APN parameters. Thing is, I don't know if this is something that allows you to make only a temporary change or if they "stick" after you exit that activity.
There is a file in /efs (namely /efs/apn-changes.xml) which seems to hold APN configuration data, but I have no clue if that is consulted for configuration information, or merely a copy of data that really lives elsewhere.
If the phone isn't your daily driver, you could probably flash back to the NC4 ROM as an experiment to see if "Global" is still available in the settings menu. Not so much because you would want to use an old, insecure ROM, but just to see if you can successfully get it programmed to work with T-mobile for voice+data+sms+mms. At least if you figured out what the correct settings were supposed to be, you'd only be faced with where they are supposed to go in OF1/PL1 (Were you using this phone before on T-mobile? If so, what ROM?)
There's a ton of stuff under the hood with those hidden settings. Hundred if not thousands of tweakable parameters. (If you want your head to spin look under IMS Settings) I would be careful about randomly poking at things. Apparently there's a fair amount of stuff stored in NVRAM which has nothing to do with anything that gets flashed by Odin with factory images, so it is entirely possible to permanently mess up a phone if you aren't super careful about recording prior settings and watching every keystroke. Some of those "maintenance" menus seem to be really poorly programmed - not defensively - and you could make unintended changes simply by walking through a set of menu picks.
.
Click to expand...
Click to collapse
I'm on Jasmine which is OF1 and I have a global mode selection.
{
"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"
}
Sent from my SM-N900V using Tapatalk
Took a look over in my AFH area at the file counts to see what the activity level was. (The Note 3 is an "old" device, 3 years is approximately infinitely old LOL)
Over 60 downloads of the ROMs (OF1 and PL1 mostly) and about the same count for modems.**
And yet not a single report here of something actually getting installed. I suppose (as XDA doesn't require a login) that lurkers vastly outnumber XDA contributors ???
Ahh, well; I put them up there so folks could use them. Hopefully that's the case.
** oddly, a fair number of downloads of the NC4 modem. No clue what that would mean.
.
I'm running into an error when flashing the ROM in TWRP:
Code:
This package is for device: SM-N900V,hltevzw; this device is hlte.
Updater process ended with ERROR: 7
Error installing zip file '/external_sd/ROM_STUFF/Roms/N900VVRSEPL1_flashable_OTAsuppressed_vo.95.zip'
Updating partition details...
...done
My phone is a N900V.
---------- Post added at 02:12 PM ---------- Previous post was at 01:29 PM ----------
*Update*
Nevermind, I managed to get it working by editing the \META-INF\com\google\android\updater-script, replacing all 'hltevzw' with 'hlte', and updating the zip.
pnuker said:
I'm running into an error when flashing the ROM in TWRP:
Code:
This package is for device: SM-N900V,hltevzw; this device is hlte.
Updater process ended with ERROR: 7
Error installing zip file '/external_sd/ROM_STUFF/Roms/N900VVRSEPL1_flashable_OTAsuppressed_vo.95.zip'
Updating partition details...
...done
My phone is a N900V.
---------- Post added at 02:12 PM ---------- Previous post was at 01:29 PM ----------
Nevermind, I managed to get it working by editing the \META-INF\com\google\android\updater-script, replacing all 'hltevzw' with 'hlte', and updating the zip.
Click to expand...
Click to collapse
Cool :good:
Just for info to anyone else that get that error:
Basically its an error you get if you are using the wrong twrp. In your case you are using an hlte recovery not N900V twrp recovery. But what you did will work :good:
Sczar said:
Just for info to anyone else that get that error:
Basically its an error you get if you are using the wrong twrp. In your case you are using an hlte recovery not N900V twrp recovery. But what you did will work :good:
Click to expand...
Click to collapse
^this.
The custom recoveries don't do any fancy hardware detection during the assert in
META-INF/com/google/android/update-script
; they merely check the value in the script against the property
ro.product.device
that is established by init from reading the /default.prop file when the recovery boots up. Wrong recovery? Wrong ro.product.device value.
The situation is somewhat muddled by virtue of the fact that there are ROMs that will install & run more or less correctly on multiple device types, so the devs either check for each compatible device in the assert statement in the update-script... or they simply omit the assert() in the script altogether.
Either of the latter can lead people to conclude that they installed the correct twrp version - "hey, I used it to install a new ROM and it worked."
I chose to use strict checking when I packaged these up.
In any event, here are the TWRP downloads for hltevzw
bftb0 said:
^this.
The custom recoveries don't do any fancy hardware detection during the assert in
META-INF/com/google/android/update-script
; they merely check the value in the script against the property
ro.product.device
that is established by init from reading the /default.prop file when the recovery boots up. Wrong recovery? Wrong ro.product.device value.
The situation is somewhat muddled by virtue of the fact that there are ROMs that will install & run more or less correctly on multiple device types, so the devs either check for each compatible device in the assert statement in the update-script... or they simply omit the assert() in the script altogether.
Either of the latter can lead people to conclude that they installed the correct twrp version - "hey, I used it to install a new ROM and it worked."
I chose to use strict checking when I packaged these up.
In any event, here are the TWRP downloads for hltevzw
Click to expand...
Click to collapse
this ^^
True. Its not a hardware detection. Its a command in the default.prop i was trying to simplify it as much as possible.
But as you explained in details ?
Thank you
bftb0 said:
In any event, here are the TWRP downloads for hltevzw
Click to expand...
Click to collapse
That is the TWRP I was using though (twrp-3.0.2-0-hltevzw-4.4)
Introducing:
SamFAIL!
[Size=DEPRECATED]DEPRECATED![/size]
This ENTIRE THREAD is old, busted, and has been deprecated for some time. Please stop reading it, and go to the link below this line of text:
https://forum.xda-developers.com/galaxy-s8/development/root-partcyborgrom-aqi6-deodexed-t3702988
It has some very clear advantages over this version:
- Supports All existing bootloader revisions
- Latest version(s) of Nougat
- Huge community of support
- Telegram channel
- Preinstalled audio mods, visual mods, looks really good
- Actually still works
- very debloated without compromising many touchwiz features. It's over 50% faster on my device
- Deodexed, xposed FULLY supported.
- Rooting method improved, essentially foolproof
I don't want to have this thread closed, but I will
A New Alternative Root Method For The US Samsung Galaxy S8! (G950U Snapdragons)
Rooting your s8 just got easier.
DISCLAIMER 1: Although this method does not trip the "Knox Flag" you are still taking a risk by rooting your device. We are not responsible for your blazing fast smartphone with root! Let's hope this one doesn't catch on fire!
DISCLAIMER 1.5: THIS IS NOT FOR EXYNOS!
First and foremost, SHOUTOUTS!
- @partcyborg for finding the root method!
- @me2151 for testing on Note 8 and facilitating root on the Note 8!
- @elliwigy for... Shenanigans! And thread template
- @Chainfire For opening the door to make this root useful. He will be missed! (no he is not dead, just retired.)
- @samsung for the amazing phone and leaving rediculous loopholes open for us to root!
Disclaimer 2: The method to root should be pretty straight forward as the hard work has already been done for you. With that being said, you will need to know how to download files from the internet, extract a zip file and to use ODIN. That is basically it! Oh yea, PLEASE BE SURE TO READ ALL THE INSTRUCTIONS THOROUGHLY BEFORE ASKING FOR HELP!
Once again...
READ THE ENTIRE SET OF INSTRUCTIOMNS BEFORE BEGINNING!
There are important things to note about this process that WILL likely trip you up if you expecting them. Some things are not intuitive and may sound unimportant to follow but trust me they are. Every single step added her is absolutely necessary.
Prerequisites:
- A working computer with a working USB drive that is capable of successfully flashing firmware to your device.
- Comsey ODIN and Normal ODIN (Found in Post #2 As well)(In case you give up and want to go back to stock)
- SamFAIL S8 Custom Hybrid Combo/Stock firmware package (also in Post #2)
- A functioning Snapdragon Galaxy S8 G950U/U1 or ANY other US Snapdragon based Galaxy S8 that can run the standard 950U firmware. Must be able to boot to download mode, and NO EXYNOS OR
- The CSC file for your phone(also in Post #2)(NOTE: You MUST use the CSC matching your device or your network will not function correctly. If your CSC is not in the downloads section you must download your devices firmware and extract the CSC from it and use that one. I will continue to add CSCs as I have time to download them but please be patient as they can take a while to download. Bonus points if you can send me individual .tar.md5 CSC archives so I don't have to download 4GB of ROM.
Part 1 Instructions:
0) BACKUP YOUR CRAP This procedure wipes your entire phone, so anything that you don't want gone for good back up somewhere NOT ON THE PHONE for the duration of this process. TECHNICALLY it should be safe to leave on a SD card, but checking one accidental checkbox in Odin will make you lose it. Take the SDCard out or copy the stuff to your computer.
1) Unzip the SamFAIL S8 ZIP archive. Inside there will be two tarballs (.tar files). If you have flashed a rom before these should hopefully look familiar. NOTE: There is no CP archive because the hybrid BL_ archive contains all drivers needed to operate your device.
2) Boot up Comsy Odin. Reboot your phone into download mode. Connect your phone to your pc and make sure that you get the Blue box that signifies proper connectivity and that the Odin log has said "Added!"
3) In the AP slot, place the AP tarball. There will not be a long pause like stock ROMs as there is no md5 signature to check.
4) In the BL slot, place the hybrid combo/stock firmware package. Again, you can place these in any slot and Odin will handle it just fine.
5) Click on the OPTIONS tab, and select the following checkboxes: Auto Reboot, Re Partition, F. Reset Time, NAND ERASE ALL.
After finishing the above steps, your Odin should look exactly like this:
{
"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"
}
6) Read step #5 again and confirm that you have everything selected EXACTLY as shown in the picture and written in the words. Check it again and when you are sure everything is correct press START.
7) Wait for ODIN to complete the flashing of the system partition. Naturally, ODIN and your phone will see this image is not signed and return FAIL. Your device will say "Secure Check Fail: system" or something close to it. THIS IS EXPECTED, DO NOT PANIC OR GIVE UP. Your flash may have failed, but it did not fail hard enough
At this point you may be wondering "What is going on and how does failing to flash get me root?"
The answer is because of a very simople to fix (pre-launch) issue with secure boot verification. I will explain in more detail when we are done and you have root but the short story is, yes they fail the flash when it does not match a known image, but they do so at the end, AFTER all of the data has been written to the disk!
it indicates that everything is ruined and you should bring them your phone right away. Fortunately we are smarer than that. Despite not saying so, while this screen is showing the device is in fact in download mode ready to receive new firmware.
This screen will likely say something like "System Failure" and there will be instructions displayed to take your device to the nearest repair store. Laugh at Samsung's silly attempt at subterfuge.
Now, lets put that data to good use with part II:
8) Reboot the phone into download mode again (hold down power, vol down, bixby) until the device resets back to a blue-green ("Download Mode Color") screen. If you have not seen or experienced a bad flash before, this screen may be new to you. You should see something that says "OPERATING SYSTEM UPDATE FAILED" and find that your phone will boot only to this state and nothing else. DO NOT PANIC! THIS IS EXPECTED and exactly what we want. Odin/Secure Boot are refusing to boot because you flashed unrecognized code, and wants you to flash code it recognizes. Lets give them what they want.
9) If you closed Odin or hit Reset after the first clash, open it again. Plug your phone back in if necessary and ensure that Odin sees you device just like last time.
10) IMPORTANT! IMPORTANT! It is IMPORTANT that you be sure to remember to do the following: Click the RESET button onthe bottom middle of the page. Alternatively, you can Uncheck "NAND Erase All" "Re-Partition", but its extra work to remember which ones.
WARNING: IF you fail to do this, Odin will happily erase your device and have to start from scratch. Worse though is the failure mode. If you don't notice is not obvious that it is caused by this, which will likely cause you and others unecessary grief.
11) Click on the BL row again and Load the same Hybrid Firmware Combination as last time. Be sure the checkbox next to it is selcted.
12) IMPORTANT: If you did not click "Reset", be sure that the AP_ROOTEED_YSTEM tar is NOT loaded. You can uncheck the check box next to it and it will not be sent as part of the coming flash. If you do not do this, you will fail again and it will be for real this time.
13) Click on the CSC row and load the CSC file you downloaded that matches your device and service plan. Be sure that the checkbox next to it is checked.
14) Double check that your screen and options now look like this or has the same options.
- NAND ERASE is UNCHECKED
- F RESET is CHECKED
- REBOOT is CHECKED
This part is basic ODIN flashing here guys... Not rocket science!
15) Press START and watch the LOG tab to see what is happening. If it says the words "Erasing..." you have failed to follow directions and ust start completely over with step again.
16) This is where the Matic happens... Odin will flash all of the fimrware files in the tarball, and will fihnd that all of them are 100% valid signed images by Samsung. Since Odin has a very poor memory, he completely forgets that you had just flashed a bad system image, and marks your secure boot flag as "Safe" and lets you proceed to boot!
17) Have a good laugh (at least i found if funny)
18) The phone will reboot to recovery and dump you there for one of two reasons:
a) You will see the progress bar advance over a feconds to 32% or so and then stop, printing an error about faling to find resize data. This is normal and happens with every flash of CSC OYN that I have ever seen. You are safe to advance to the nxt step.
b) The recovery will immediately exit with an error that says "Failed to mount /system (Invalid Argument)". This is unfortunately bad news as it means that the failed flash attempt was not successful in writing enough data to see the file system. Do not dispair yet though! This happens sometimes with this method. Start off by starting over from scratch. If that does not work, reach out to me and I will walk you through a few procedures that will eventually fix it.
19) If you made it past step 18, all you need to do now is execute a data wipe/factory reset. This is necessary and your device will not boot withiout it, as there is no userdata image file flashed through odin.
Now, wait for the device to boot up (it will take 3-5min like most new isntalls) and then you can try out your new root!
20) Once phone boots up, Setup your device as normal and proceed to the SuperSU app. It will ask you to update the SU Binary. Select Normal method and let it do its thing. A popup should show up to disable KNOX. Follow its instructions then SU should say it was Successful in updating and it needs to reboot(You may have to do it multiple times. I belive its 2 or 3 times then its good) ENJOY SamFAIL ROOT!
NECESARY CLEANUP
The reason that this works at all is that modern filesystems like ext4 (what android uses) are very robust in the face of errors on the disks. Particularly in the days of old when everything was on spinning platters, that may moving parts was a lot more prone to failure, so filesystems were designed to keep your data safe in the face of losing parts of the disk. Fortunately for us this allos us to successfully mount and load android off of an incompleted filesystem. To make sure that the device is table, and that future SamFAIL attmpts do not degrade into "Invalid Argument" errors, we need to do a filesystem repair.
Download fsck.ext4 and push it to your device to fix any errors that cropped up from the SamFail dirty flash.
Connect via adb (or shell on your device) and run the following
FROM YOUR COMPUTER WITH PHONE PLUGGED IN AND AD ENABLED:
Code:
adb push <localpath to fsck.ext4 /tmp/
Then on the Device:
Code:
su
chmod 755 /tmp/fsck.ext4
mount -o ro,remount /system
/tmp/fsck.ext4i -f $(find /dev -name system)
It is possible that oyu will see a LOT of errors reported. Do not worry though all of the stock os will have made it through ok. Press "a" to say auto-yes to all the questions and your filesystem will be healthy from here on out.
EPILOGUE
It is HIGHLY recommended that you follow this step with the flashing of either a custom rom or a full stock /system ROM using FlashFire. The image I provided that is pre-rooted essentially has no more work done to it than that, and I have no plans to do that work anytime soon. Unforutnately my experiments with using SamFAIL to flash more custom /system partitiuons made them a lot more unstable and frequently would not boot at all. Consider this a stepping stone that requires a little less work than SamPWND used to be before more automation work was done.
The AQH3 Image in post #2 has the "warning this device has been modded" message and i took a brief stab at it but wasnt able to get it locked down. If someone wants to do so i will havppily upgrade the rom to a better vesrion. Otherwise there are some really cool bnew roms out for the s8/s8+ now that I recommend checking out.
The more exciting prospect is that this can be used by ANY Samsung device with a permissive Selinux version without dm-verity. That covers a wide range of devices which we will be investifating.
DISCLAIMER 3:
* SamFAIL DOES NOT TRIP KNOX
* SamFAIL DOES NOT FIX THE 80% BATTERY CHARGE ISSUE
* Boot.img is SECURE which means you MUST use SYSTEM ROOT. (Similar to SamPWND)
* This means that MAGISK DOES NOT WORK
* Which also means SAFETY NET FAILS. So any apps you enjoy that require passing Safety Net will most likely not work while you are rooted with SamFAIL
* Again, similar to SamPWND, this root method uses a factory binary boot.img which is necessary to boot the modified system. THIS MEANS BATTERY ONLY CHARGES TO 80% (Thanks Samsung.)
* SamFAIL DOES NOT UNLOCK YOUR BOOTLOADER AND DOES NOT SIM UNLOCK YOUR PHONE.
* This *should* in theory, work for other Snapdragon Models of the Note 8. If you have another model and are successful please post so we can add "support" for other models.
Back to Stock?
- Download the full STOCK firmware of your choice.
- Flash it in ODIN/Comsey ODIN as you would any other time!
- It will take a few reboots for the "custom" splash screen to go away.
Donations:
As always, the devs have been hard at work recently to bring you root. Donations are definitely NOT REQUIRED but if you feel generous and want to spot the devs a few bucks for their hard work you can donate to this Paypal Address:
Donations
NOTE: this message is geared more towards the Note 8 users, for whom this root method is their first and only.
DOWNLOADS will be in POST #2
UPDATES will be in POST #3(RESERVED FOR FUTURE UPDATES)
As always, ENJOY ROOT and thank SamFAIL for making it all possible!
P.S. See why we called it SamFAIL now? Massive fail on Samsungs part.
SamFAIL Downloads
Rooted AQH3 Android 7.0 System for Galaxy S8 Snapdragon (Flashing in Odin)
AP_SamFAIL_G950U1_AQH3_ROOTED_SYSTEM.tar:
Hybrid Stock/Combination Full Firmware (minus userdata and system) For Rooted Devices.
AQI6 Stock, AQI1 Combo (for Flashing in Odin):
BL_SamFAIL_G950U1_HYBRID_AQI6_STOCK_AQI1_COMBOtar.tar
VZW CSC OYN for US VZW Customers on AQH3 (for Flashing in Odin):
CSC_OYM_SamFAIL_G950U1_AQH3_VZW.tar.md5
Staticly Compiled fsck.ext4 binary for fixing filesystem issues:
fsck.ext4
*YANK*
(reserved for future use)
Yay!
Nice!
Are there any custom ROMs for the Snapdragon variants (specifically the Canadian variant W8)?
Ad.Shk2 said:
Are there any custom ROMs for the Snapdragon variants (specifically the Canadian variant W8)?
Click to expand...
Click to collapse
i have 1 or 2 but not gonna upload em until theres more stuff done.. its basically got minor visual mods and deodex n theusual stuff
That sounds promising... I've been patiently waiting for custom ROMs for the Canadian variant... Good luck to you bro!
Sent from my SM-G950W using Tapatalk
Ad.Shk2 said:
That sounds promising... I've been patiently waiting for custom ROMs for the Canadian variant... Good luck to you bro!
Click to expand...
Click to collapse
but yea,just not enough done yet in order to release.. i hope note 8 root will kick offmore mods n such for us
I'll be going for Aosp based ROMs too, since it's for the Snapdragon
Sent from my SM-G950W using Tapatalk
Ad.Shk2 said:
Are there any custom ROMs for the Snapdragon variants (specifically the Canadian variant W8)?
Click to expand...
Click to collapse
There is one that supports at least everything thats part of CSC OYN:
https://forum.xda-developers.com/tm.../samsung-tmo-galaxy-s8-sampwnd-turbo-t3662719
Its listed under the tmoblle section because the developer has tmobile, but as our devices are multi-csc so is his rom
partcyborg said:
There is one that supports at least everything thats part of CSC OYN:
https://forum.xda-developers.com/tm.../samsung-tmo-galaxy-s8-sampwnd-turbo-t3662719
Its listed under the tmoblle section because the developer has tmobile, but as our devices are multi-csc so is his rom
Click to expand...
Click to collapse
The OP states: "this custom rom is only for tmo. i removed all other carriers config files..."
Also, what's CSC OYN?
Sorry about my illiteracy in this regard, I'm a Nexus/pixel guy which are a breeze to root and customize.
Sent from my SM-G950W using Tapatalk
Ad.Shk2 said:
The OP states: "this custom rom is only for tmo. i removed all other carriers config files..."
Also, what's CSC OYN?
Sorry about my illiteracy in this regard, I'm a Nexus/pixel guy which are a breeze to root and customize.
Click to expand...
Click to collapse
Aww that's a bummer, last I talked to him he was fine with other carrier use.
partcyborg said:
Aww that's a bummer, last I talked to him he was fine with other carrier use.
Click to expand...
Click to collapse
all he has to do is flash a csc after the rom lol if all he did was remove the other carrier stuff
Will this work for the S8 Plus?
NexusS4gFreak said:
Will this work for the S8 Plus?
Click to expand...
Click to collapse
yes if and when a modified system.img is created lol i dont plan on making it as i am already maintaining SamPWND root
NexusS4gFreak said:
Will this work for the S8 Plus?
Click to expand...
Click to collapse
elliwigy said:
yes if and when a modified system.img is created lol i dont plan on making it as i am already maintaining SamPWND root
Click to expand...
Click to collapse
I'm going to do my best to make one shortly but given I do not have an s8+ to test on I'm not so sure how effective I will be
Does this work? Anyone tried. I really want to root my Canadian model sm-g950w
Ad.Shk2 said:
I'll be going for Aosp based ROMs too, since it's for the Snapdragon
Click to expand...
Click to collapse
I think the usual comment about camera quality degrading still stands when using AOSP ROMs? Have yet to root the Samsung S8 but I'd like to do it soon, along with flashing a debloated ROM for my sister.
partcyborg said:
Aww that's a bummer, last I talked to him he was fine with other carrier use.
Click to expand...
Click to collapse
His rom has all the carrier info in it. He just doesn't update the op except the link to new rom.
Important notice! : iLLNiSS made me aware of a serious risk!
If you play with the firmwares manually and not with the flash all bat then DO NOT flash the blobs!
These are the actual bootloader files and stuffing up here will cause a hard brick!
I have to stress this out as it is serious thanks to not having working APX drivers a flshing programs for the Shield!
For starters, I uploaded a copy of the 7.2 developer firmware here:
7.2 developer ZIP on Dropbox
It is the full 1.1Gb update and not the 422mb block based one.
I have done some extensive tests since the first block based update wrecked my rooted Shield.
Some of it will end up in this post as info for everyone.
But lets start with what seems to be the problem for a lot of users right now who run a rooted Shield : Fixing the problem
A downgrade is officially not supported by Nvidia but my tests showed it works just fine if you only go back to the 7.1.
So far my tests showed differen sources for a Shield no longer working after the OTA.
1. The device had an unlocked bootloader and you got the 422mb block update.
This would have stuffed your bootloader and the Shield won't go past 1/4 on the progress bar for the update.
You are in luck as just flashing the 7.1 bootloader will fix it.
After that just dismiss the update and change the settings to manual updates.https://forum.xda-developers.com/editpost.php?do=editpost&p=78466377
2. Your device was already fully rooted and you got the full update that resulted in your Shield doing all sorts of thing but nothing properly anymore.
As long as your apps are still there and the Shield is still somhow usable you are lucky again.
A downgrade to 7.1 will fix it, I will explain the steps required further down.
3. You made bid mods, used Magisk or other rooting tools and now your Shield complains that your system is corrupt.
Bad luck if your bootloader is locked as you loose it all.
Lucky if the bootloader is unlocked as you might be able to keep most if not all during the downgrade.
General words of warning:
Even if your bootloader was unlocked from day one I can not garantee that the downgrade will keep all settings, apps, databases and so on.
For me it works fine as I kept all vital databases on external storage.
The procedures are all based on the developer firmware, on the stock firmware some things can still be done but then again you should not have more than software problems.
On the stock firmware the bootloader is locked by default and you can use some things required to owngrade due to the restrictions of a stock system.
General downgrade procedure for the developer firmware to get back to 7.1 :
If the update did get stuck on the progess bar early on and a reboot won't fix it so you can dismiss the update you just follow the steps.
If you can reboot into the 7.1 then just dismiss the update.
Trust issues or curruption warnings at boot but an otherwise working shield on 7.1 require to flash the 7.1 bootloader again.
In some cases it is possible to skip the corruption warning with a connected controller.
A reboot once you got to the homescreen will determine how bad it is.
Reboot goes fine: You are good.
Reboot keeps nagging with warnings other than the unlocked bootloader: Downgrade.
The downgrade is only required if you have problems or the Shield already runs on the 7.2!
In almost all other cases just flashing the 7.1 bootloader is sufficient.
Fixing a stuffed Shield by sideloading the 7.1 firmware while keping all apps and things:
Enable USB debugging and allow the connections for the computer if you still have access to the settings.
Otherwise you need to flash the 7.1 fresh and might loose vital things that need to install again.
Reboot into the stock recovery, if you use TWRP flashed on the Shield already then please flash the recovery from the 7.1 firmware first.
Hook up the controller and pressing A or B should get you into the normal recover screen past the dead droid.
ADB sideload XXX - where the xxx stands for the filename you have for the developer ZIP.
After the rebbot you should be back on your 7.1 homescreen and can dismiss the 7.2 update.
Also change the update settings while at it
Fixing a fully stuffed Shield and then downgrading to the 7.1 firmware:
If all went down south then you tried a few things and realised there is no way to get your data back and even less to prevent the 7.2 update.
Installing the 7.1 from scratch forces the setup wizard and before you can get anywhere you need to update to 7.2
So much easier to use the linked 7.2 update from above until Nvidia provides it on their download servers.
A vital thing to do is to keep the bootloader locked!!
Same for NOT having TWRP installed on the Shield!
If in doubt flash the 7.1 boot and recovery partitions first then go back into the stock recovery and wipe the cache.
Coming from a stock developer firmware with just an unlocked bootloader you are good to go.
Sideload the 7.2 update.
Unplug when the reboot starts and go into fastboot to lock the bootloader: Fastboot oem lock.
This is a vital step as the new kernel otherwise could ruin the completion of the install.
Ignore the double hassles and go through the wizard so you can enter the settings again to enable the developer mode and USB debugging.
Unlock the bootloader so you can do it all again Last time I promise!
Once you have both the bootloader unlocked AND the Shield in a usable condition past the setup wizard:
Reboot into the recovery to sideload the 7.1 firmware.
After the next reboot you are back on the 7.1 homescreen drirectly and can dismiss the update.
Possible tricks that can help you to prevent the installation of the 7.2 update if you come from a fresh 7.1 install instead:
Don't allow the reboot and instead use ADB to reboot into the recovery.
Wipe the cache - this will remove the scripts required to start the update after the reboot.
The next reboot should bring you back to the homescreen where you can stop the new download of the update and change the update settings.
TWRP, full root and new security measures in 7.2:
The 4.9 kernel used also makes use of a Fstab configuration that no longer includes the system partition.
This and other restrictions currently make the normal use of Magisk impossible.
With no system partition available to Magisk the changes in the boot process come to a stop and the Shield gets stuck during boot.
The added restrictions also make it very, very hard to manually add SU and busybox.
At least without getting the currupt system popup on every boot and finding out that a lot of things still don't work properly.
A final 7.2 firmware is said to be available on the download servers today.
If this final is no different from the current OTA then it will not be of any use for users requiring a fully rooted devices.
With the stock recovery still using the old kernel all attempts to use recovery functions to alter the system for rooting fail as well.
Can't blame the company as all this is part of Google revamp og security and closing backdoors and loopholes for possible attackers.
Personally I think it is Googles way of keeping control over devices they don't actually own.
Anyways I did make some little progress:
Plans for the near future:
Security is good but I like to know what my Android devices are doing and especially what Google likes to collect if I can not find ways to stop it.
So I will not try to use any backdoors or secrurity vulnerablilites in the new kernel to allow a full root on my Shield.
I will go the route I know best: Manual labour
The bootloader is already fixed to allow what we are used to from previous developer firmwares.
As SU and busybox can not be manually entered at this stage I will try to include them directly in the stock 7.1 firmware while renaming the OTA updater to have it a bit easier.
Assuming that works as expected I will do the same on the 7.2 firmware and compare the corresponding scripts and so on.
If the standard SU still works on an "unlocked" 7.2 I should be able to adjust the Magisk ZIP accordingly to implement it into the bootloader.
Only need to figure out if Magisk then has enough rights to work and the system is still happy to accept the changes.
I noly have the 16Gb 2017 model to work with but since the bootloader seems to be same for all Shield models I think if it works then it should do so for all models.
In the meantime I hope the infos here will help some pople to get their shield back without the need to sent it in.
Update 25/12/18: I got TWRP working on 7.2
This is only true for the 2017 model though as I have only this for testing.
Currently creating a backup to the internal storage.
If the restore works then I will upload the new TWRP - for the said model only!
Give me a day or two to fix it for the other models too.
There is progress on the rooting front as well.
Created new scripts for my kitchen to be able to handle the new file_context thing.
A fully pre-rooted and totally unsecure (in terms of ABD, DM-verity and such) is already cooked, just did not dare yet to try it out as I have a real life job too.
As for the pre-rooted firmware:
Things have changed quite a bit with the new kernel in terms of "just adding SU or Magisk".
Magisk might see an update for this problem soon, SU however seems to tally fail on two levels.
So far I was unable to do a full install of the modded firmware.
Flashed all at once and the boot just hangs.
Bootloader, reboot, then the rest seems to work.
At least for the basic install of the system.
If I add SU and busybox the system still ends up with a corrup notice during boot and then it fails.
Tune in over the next few days for progress updates at the end of the thread.
Major developments will be added right here.
Just a matter of finding the last restrictions.
Once that is done Magisk should be possible as well.
Ok, TWRP boot fine, does a backup but fails to restore the system to a bootable state.
Will now check if at least installing a zip works.
Well, it did not, so TWRP has to wait a few more days
I edited post 3 with instructions on how to "unbrick" and go back to 7.1.
Update 27/12/18: A friend of mine found some intersting stuff.
A 7.2 firmware offering a pure Android without any TV stuff but also a full root possible.
I hope he will share his finding here soon or allow me post it all in his name.
For now lets just say: It really works if done the rght way!
Full write rights, installing Magisk modules and all.
All thanks to an undocumented flaw in the device security structures, so even without any hidden backdoors or such LOL
Update: Whiteak was so kind to provide a working root solution in post 36, please check it.
I can confirm it is working as promised.
So the credits for this one go to Whiteak and the credits for the idea and use of the DTB file to Zulu99 - great idea!
To prevent any problems I advise to perform a factory wipe after the install and before the first boot.
Switch to the stock recovery to do this then boot as normal an enjoy.
A complete firmware with the required mods is sitting on my PC just waiting for idiot behing the keyboard to figure out how to pack it properly for flashing.
Once that problem is sorted and also TWRP working again things will get a lot easier.
Annoying update:
I was not able to confirm my web findings on the 7.2 firmwares bootloader but it seems other devices running the same type of kernel and bootloader and a bit lost now.
AVB is fully implemented on the latest level.
(Again I am working on confirming or denying these findings!)
This means any alteration to vital parts of the system will fail with a corruption warning or worse.
Custom recovery access is limited if not fully restricted.
But even if it works you still need a firmware to flash that either is able to disable all this crap, hoping the bootloader alone will allow it, or
to hope Nvidia will provide a future bootloader update with these restrictions removed.
We can not downgrade the bootloader and even if there is some old one out there that would actually be flashable the risk is high to end with a brick anyway.
The DTB, at least in my tests gives us the required system wide write access but I have no information about the AVM verfified boot other than that Zulu99's firmware works.
But if it was compiled with the NVidia developer suite then it will be signed accordingly so the bootloader accepts it.
Could not find any info on how his firmware was actually created.
It gives me the hope though that once I have a fully working TWRP again that my modded 7.2 will work as expected and with no restrictions anymore.
Thanks for the info.
Edit: Will use this post to list options to recover the Shield is all seems lost.
As a result of far too much rom cooking and mods I needed a 100% working way to recover the Shield in case things turn very ugly.
So lets sum up what I define as very ugly when playing with firmwares:
1. Firmware installed but the Shield just hangs on the logo.
2. Firmware installed and now the system is corrupt and even it is boots it takes forever to get around the nag screens.
3. Firmware downgrade attempted but now the Shield won't even boot anymore.
4. Anything that would qualify for a soft brick.
My worst case when I only got a flashing white screen after trying to restore a TWRP backup under 7.2.
There any many way that work for a variety of boot problems but it takes too long to list all cases I encountered with a list of fixes that work or a comment that only the below way works.
So just to be clear here: This is not for any recovery purpose other than fixing what can't be fixed through a factory reset or fresh flashing of the firmware!
1. Get the Shield into Fastboot mode: Connect wired controller and male to male USB cable.
2. Power the Shield up while holding A and B on the controller.
Keep holding until you see the fastboot menu on the screen.
3. Install the 7.1 recovery firmware for your Shield type after unpacking it.
With Fastboot connection working type: flash-all.bat and hit enter.
4. Keep an eye on the progess!
5. Once the Shield is finnished and reboots, hold the A and B buttons on the controller again to enter fastboot mode!
Do not let the Shield boot up other than into the fastboot mode!
6. Lock the bootloader! Fastboot oem lock
Confirm with the controller, then go down and select the recovery kernel.
7. Once the dead droid is on the screen press B on the controller to enter the real recovery.
If B does not work try A
8. Select the factory reset option to wipe all!
9. Once the wipe is done you can boot into 7.1 as normal again.
10. With a bit of chance you might even get directly to the homescreen if the previous setup was completed.
If you need the full seup wizard again and are forced to update to 7.2 then at least the update will work fine this time around.
In case you desire to go back to the 7.1:
If you just finnished the above only to end with the 7.2 then set it up and flash the 7.1 - you won't get the setup wizard again and can skip the update.
If you are on a working 7.2 that was update the OTA way but want to go back:
1. Install the 7.1 firmware.
2. Lock the bootloader.
3. Boot and then skip the update to 7.2.
Any idea what to do if the Shield sticks at the NVidia logo when you select Recovery from Fastboot? I reflashed boot and got the same result.
psycho_asylum said:
Any idea what to do if the Shield sticks at the NVidia logo when you select Recovery from Fastboot? I reflashed boot and got the same result.
Click to expand...
Click to collapse
It won't work from fastboot.
Fastboot operates on a different level and calling the recovery from there lets it end up in nowhere with no access to the system.
You need to boot into recovery through ADB as (for the new model) without a power button and usable hardware buttons we can't get into it otherwise.
Having said that, the fastboot way should still work with an unmodified bootloader.
When the dead droid is on the screen the recovery should be available after pressing the A button on the wired up controller.
But during my tests on 7.2 it did not always work, so you might have to try a few times and also try the B button.
Downunder35m said:
It won't work from fastboot.
Fastboot operates on a different level and calling the recovery from there lets it end up in nowhere with no access to the system.
You need to boot into recovery through ADB as (for the new model) without a power button and usable hardware buttons we can't get into it otherwise.
Having said that, the fastboot way should still work with an unmodified bootloader.
When the dead droid is on the screen the recovery should be available after pressing the A button on the wired up controller.
But during my tests on 7.2 it did not always work, so you might have to try a few times and also try the B button.
Click to expand...
Click to collapse
I have not been able to get to the dead droid screen.
Downunder35m said:
For starters, I uploaded a copy of the 7.2 developer firmware here:
7.2 developer ZIP on Dropbox
It is the full 1.1Gb update and not the 422mb block based one.
(snip)
Click to expand...
Click to collapse
Thanks for posting this, but please note that this firmware is only for the 2017 16GB model and cannot be used with a 2015 or Pro model.
I just got a 7.2.1 update that forced me to update. Wouldn't give me an option to skip it... As soon as I turned on my Shield, it said something about the 7.2.1 update and then rebooted and installed.
I was holding off on updating too so I didn't lose root. Now I'm unrooted and am unable to get Magisk working again until I can get my hands on a 7.2.1 bootloader... Bleh.
Weird, I am not getting the 7.2.1 at all here.
And since yesterday the OTA only tries the block based but not the full image.
AthieN said:
I just got a 7.2.1 update that forced me to update. Wouldn't give me an option to skip it... As soon as I turned on my Shield, it said something about the 7.2.1 update and then rebooted and installed.
I was holding off on updating too so I didn't lose root. Now I'm unrooted and am unable to get Magisk working again until I can get my hands on a 7.2.1 bootloader... Bleh.
Click to expand...
Click to collapse
I was able to downgrade using the 7.2 image after setting up the device on 7.2.1 OTA just make sure you disable automatic updates
Thanks downunder this kind of in-depth info is always appriciated man........i like to learn these kind of things, having bits here and bits there gives a better picture of the whole, while also giving us upto date current info.
Thanks for taking the time to write this :good:
---------- Post added at 07:35 AM ---------- Previous post was at 07:27 AM ----------
Edit
Hi downunder, could you confirm i have this correctly
With no access to fastboot thus no twrp or root, are you implying, assuming your able to inject root into stock firmware, that, i'd be able to flash this stock+root rom in STOCK recovery, which i do have access to?
Edit: im under the impression that stock firmware zips are checked by stock recoveries, so modifying a stock firmware zip tends to fail this check and thus wont install/flash.......which makes me think im misunderstanding here......or just hoping im not
If so, im interested
Edit
i just read your second post which near enought answers my curiousity, so that'll teach me to read beyond the first post before asking answered questions ........even if the post excites me............ahhh, who am i kidding, ill probabably do it again........the equivelancy of a mental post boner........not controllable
Sorry for the disgusting analogy
SyberHexen said:
I was able to downgrade using the 7.2 image after setting up the device on 7.2.1 OTA just make sure you disable automatic updates
Click to expand...
Click to collapse
Did I understand it correctly? You successfully downgraded from 7.2.1 to 7.2?
ErAzOr2k said:
Did I understand it correctly? You successfully downgraded from 7.2.1 to 7.2?
Click to expand...
Click to collapse
Yes,
Just ran flash all from the bootloader. For the newly released 7.2 developer_rooted factory image.
As long as we don't jump to Android 9 we should always be able to downgrade through a full factory firmware.
Once Android 9 comes this might not work anymore due to the massive changes involved for the boot and system checks.
@banderos101: Unless you really did something bad you should always be able to enter the fastboot mode to flash a full firmware.
If I have some time after xmas I will have another look on the options of signing the zip properly or simply to fake it.
Biggest problem will be to generate the corret SHA checksums ince all is installed so I can use the same checksums in the check files.
The bootloader needs them to identify the system and vendor as genuine.
The system needs them to confirm all is actually unmodified as otherwise all fails to boot at some stage.
Modding a proper userdebug firmware is not really that hard, but converting a release version that also is a true and secure user release...
Lets just say that it won't be an easy task.
As it looks like the kernel is a keeper I might have to figure something out unless TopJohnWu won't enjoy a break after his exams and works on a way to get Magisk working with out kernel.
At least I figured out why the recovery trick isn't working for me.
The system partition is not mounted for the sideload mode.
To apply an update the stuff is written directly onto the partition, so no file level access left to play with and break things
In comparison you could say the shield is now like a modern car with keyless operation only.
You know you can start it with ease, if you only could the remote that you left in the drivers seat when you locked the door
SyberHexen said:
Yes,
Just ran flash all from the bootloader. For the newly released 7.2 developer_rooted factory image.
Click to expand...
Click to collapse
Just wondering what is achieved by going back to 7.2?
What do you mean "going back"?
Right now the 7.2 is the official and latest firmware.
I was unable to get my hands in the 7.2.1 but guess it might have been a testversion for certain models only.
I wasted a few hours trying to fix the system image.
First stage was only to get the basic "features" back, like full ADB support, enabling the support to use SU and busybox....
Just what is required to actually allow these nice apps we like to gain root to work.
This backfired badly as right after the start the bootloader complained about the system being corrup and no override to get past this worked.
So of course I then removed the known restrictions from the bootloader...
As you guessed it the damn thing then did not even boot at all, just jumped right into the (locked) recovery mode.
A half decent comparision with my last manual root on a tv box that was a success showed I still did the right things...
If anyone wondered why we needed a new bootloader for the support of smart helpers an some codes stuff:
We didn't as all this could have been done with the 7.1 bootloader as well.
Since my root attempts so far all ended either in disaster or in a root access that failed shortly after/corrupted the system, I took a look of the general kernel changes that were published for other devices.
Before I could find anything meaningful I realised the 4.9 kernel is actually a requirement for Android Pie!
With that info sorted I started digging inti the new "security" features Pie can offer.
I will try to keep it simple and to the stuff that actually concerns us for rooting purposes:
The new boot process with Pie is aimed at being secure from the hardware level up and all the way into the system partion once the boot is completed.
So the hardware checks if the bootloader is actually usable - we had that for a long time, nothing new.
Once the bootloader starts and reaches the point of actually getting somewhere, all partitions required will be checks by either a hash check or a trusted certificate gererated at boot time that is compared to the previous certificate.
Only if that is fine the bootloader will call upon the system and vendor partitions.
The handover of control from bootloader to the system is made far more secure as well.
SELinux is called early on to ensure that only trusted apps and tasks can work but also to all a new control level.
System related apps no longer run as root or with special permissions.
Instead every single app and service runs as its own user!
And under SELinux conditions this means nothing can access anything that it is not entitled to unless included as a user for the other app.
And with that sorted the vendor stuff is called to ensure all hardware and vendor related stuff is still genuine - this include the required certs but also the recovery and bootloader hash codes and certs.
So if something is fishy either SELinux will stop us or the vendor stuff will just overwrite it all.
Once we finally reach the system stage the recovery is checked if called from within the system, if fully implemented it could mean that using an official update on a modded firmware will delete all data as the encryption from the old system is declared invalid.
Sadly it does not stop there because even with full rigths (faked or otherwise) to access the system partition with write access we still can not just change things.
If something belongs to a user (a secure app) than a change will corrupt the system.
To overcome all this without using vulnerabilities that so far no one has found, a compatible userdebug release has to be created from the official user firmware.
DM-Verity needs to be disabled as well as all partition encryption stuff.
The bootloader needs to be adjusted to reflect these changes and the required turst certificates generated and included in both system and boot images.
The only problem here is that the kernel won't allow these changes unless it itself is a userdebug kernel.
After that it is only the little efford to go through about 60 different scripts to remove or redirect the calls for all boot and system security related things.
If then by some chance all this actually boots up and goes all the way into a usable homescreen the entire stuff needs to be secured again.
This time so that the final system has a correct cert and checksum that matches those we need to include in the bootloader.
Anyone knows how to gain full access to the trusted keystore on the 4.9 kernel? LOL
For the moment I don't really care about all the stuff above.
I would be happy to figue out what to make out of these new fstab configurations without the vital partitions listed.
The real aprtitions used have not changed but it is impossible include them in the fastab, doing so causes the bootloader to fail.
Presumably because the kernel realised we try to get around the verification process.
This and some other minor things are also the reason TWRP fails so badly, same for the stock recovery by the way.
Since TWRP is toy a lot us like:
TWRP and 7.2....
Without a system partion in the bootloader fastab TWRP can not mount it.
Same for all other things TWRP needs to mount as it simply does not have the right to access these areas.
To make things worse, we need system access to even start TWRP through fastboot.
So, now matter if we flash or start it through fastboot: The bootloader and system will realise our recovery does not match the checksum.
What does al this now mean in terms a lot more people are able to understand?
Let me try...
Imagine the 7.2 in a running version would be just some encrypted file with a lot of folders in it.
And like PGP or other encryptions software we know there is a private and a public key.
With the public key you can see a lot and use most the encrypted file - but only to a level that is required, nothing above your low level clearance.
For every attempt to write into this file or to make changes we need the private key.
If you follow so far then lets just say the recovery (stock) and Fastboot can be, to some extent, used for this access.
But since every folder in the encrypted file also uses private and public keys it is like tracing a tree.
Although it is getting too long, let me give you the example of just adding SU to the sytem partition:
Adding SU into the system image is no big deal.
Singing this image to get a usable key and including this key into the keystore is.
Assume we would just be able to do it....
SU needs to be called quite early in the boot process.
It then elevates the access level for certain things and also intercepts all root related requests from apps and services.
Except of course those that already had these rights by default.
Problem here is that adding the scripts we need plus changing some others means violating the tree of trust on the device and we get locked out.
Finding a spot to add the required rights for SU might be still possible.
On the other hand it will be impossible to give SU any rights or access to "trusted user" owned parts, files, folders, partitions....
The entire concept of SU just fails.
I will have to check how much of the new features are active in the 7.2 kernel that hinder us.
If I find enough it might be possible it enough to call for a Magisk update.
But I guess it is of little use for just one set of devices, so maybe once more devices on the 4.9 kernel fail to work with Magisk it will be easier to spot a usable pattern.
In case someone else if already working ona mdified system: Please let me know how you made it boot after the changes
Shield Tv 16 2017 - OTA update 7.2.1 Ready for updating
Im on 7.1. I have been waiting for 7.2 developer image, which is now out and just noticed 7.2.1 is available OTA. I'm really confused what to do. I want to keep root without bricking my Shield. Should I Stay with what I have as it is running well.
I am not even sure if it is safe trying to update to dev 7.2 image (or if I would want to) by hooking to computer and using ADB Fastboot tools.
Is there any good reason to update to 7.2 or 7.21? and if so how would I go about doing it? Which program is good for flashing developer images or OTA updates. I used to use flash-fire, which seems to be obsolete now and have heard TWRP is incompatible rooting with SU with OREO updates????
Should I play it safe and stay with what I have rather than experiment and end up with a brick? (wouldn't be the first time)
Anyone know if 7.21 is some-kind of bug fix?
Alot of questions but hope someone has some answers.
Thanks for any info.
"You know you can start it with ease, if you only could the remote that you left in the drivers seat when you locked the door "
My fastboot issue
Yeah, i think i busted the microusb somehow with a faulty usb hub, whenever i plug the usb to my raspberrypi/windows box(for adb/fastboot) now, it turns off all usb ports on the pi aswell as the windows box, even when the shield is unplugged, some sort of earth problem maybe
......all i have is adb over network, adb reboot bootloader simply reboots back to system, adb reboot recovery works though.
ive read that fastboot over tcp(ethernet) had been introduced a couple of android versions ago, but i dont think its been implemented in our shields
infact heres a link
https://www.androidpolice.com/2016/...-capabilities-wireless-flashing-isnt-far-off/
Looks like it needs to be specifically added onto a build
As far as you making a stock root build, if you can, that would awesome, more then awesome, but if it becomes more work then you thought dont worry about it, its not like their making it easy
Also, sounds like 4.9/future android is gonna be a nightmare for root......... having the ability to root so that the option is there to see whats going on in the background of these devices, these devices posessing cameras/microphones/old+latest sensors/personal files/personal info, which reside on our personal beings or in our homes........is just one reason why i dont want to see root go away
So what is the purpose of the developer image of 7.2?
Rather, I know the stated purpose of the developer image, but if it is locked in the way described it sounds like the benefit is negated for typical developers.
(e.g. sometimes I debug an application without permissions in order to benchmark or debug a problem).
For casual users of the shield, using ad blockers and whatnot, is there any benefit to derive from installing the developer rom over stock? Does "adb root" still work?
What is left as the difference. It doesn't sound like they produced a userdebug build of the OS.
Thanks
The 2 new updates are horrible. I have gone back to 7.1. They have crippled my shield. I'll wait for a new update.
{
"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"
}
Team Win Recovery Project (TWRP) is an open-source software custom recovery image for Android-based devices. It provides a touchscreen-enabled interface that allows users to install third-party firmware and back up the current system, functions often unsupported by stock recovery images. It is, therefore, often installed when rooting Android devices, although it isn't dependent on a device being rooted to be installed.
Notes for themers: In addition to the udpated theme, we have introduced a theme version variable to the TWRP theme system. If the theme version does not match the version that TWRP expects, TWRP will reject the custom theme and load its stock theme. This change will ensure that people who update TWRP without updating their theme will still have a workable recovery. We have removed libjpeg support. The stock theme was only using a jpeg image for the splash / curtain. This change means that any custom themes will no longer be able to use jpeg images. It also means that tools used to repack recovery images with a different curtain / splash will need to be updated to use the new method.
Version number notes: For a while we’ve been using a 4 digit version number and reserved the 4th digit for device-specific updates. For instance, we find and fix a device-specific issue like decryption of data on Nexus 5, we would release that as a 2.8.7.1. After a while, some people would start asking where 2.8.7.1 was for other devices. So, going forward we have decided to change the numbering scheme to 3.0.0-2, etc. Our hope is that this version numbering scheme will more clearly identify that the 4th digit does not indicate a version change for the code base.
We need your help! The bulk of TWRP work is done by 3 people on a volunteer basis. We have pushed most of our device files to our github and we have a gerrit instance. If you have the ability, please help us maintain our official devices and/or add your device to our official device list. Thanks in advance!
DOWNLOAD:
Note this is a very early build. Feel free to report bugs.
twrp*.img (DO NOT FLASH OR TRY TO BOOT THIS, SOFT BRICK CAN OCCUR)
Fastboot Flashing Code (Boot only, not flash!)
Code:
[CENTER]fastboot boot twrp*.img[/CENTER]
BUGS:
/EVERYTHING > IT NOT EVEN BOOTS AND MIGHT SOFT BRICK YOUR PHONE
If you have found a bug, please consider posting it to our github issues log. It's pretty much impossible for us to keep up with the more than 40 threads that we have for the devices that we "directly" support. If you have a significant problem that cannot be answered in this thread, your best bet is to PM me directly, contact us via our website, or find us in our IRC channel below. If you see someone that's struggling, feel free to point it out to us. We need your help to help us keep track of all of our devices! Thanks!
SUPPORT:
Live support is available via #twrp on Freenode with your IRC client or just click this link.
Kernel source: Prebuilt stock kernel
RESERVED
The command is wrong, it should be:
fastboot boot recovery twrp*.img
Haven't tried it yet as I'm already rooted but may soon.
Dahenjo said:
The command is wrong, it should be:
fastboot boot recovery twrp*.img
Haven't tried it yet as I'm already rooted but may soon.
Click to expand...
Click to collapse
No, I haven't wrote it wrong.
You mean "fastboot flash recovery twrp*.img".
But like I wrote, we will for now just boot it
Our device got treble (A/B) so our recovery is intergrated into the kernel, which means that if you'll flash it you will not be able to boot anymore.
I'd like to hear from somebody if it works, I can't test it as I not yet unlocked the bootloader.
jeffreyvh said:
No, I haven't wrote it wrong.
You mean "fastboot flash recovery twrp*.img".
But like I wrote, we will for now just boot it
Our device got treble (A/B) so our recovery is intergrated into the kernel, which means that if you'll flash it you will not be able to boot anymore.
I'd like to hear from somebody if it works, I can't test it as I not yet unlocked the bootloader.
Click to expand...
Click to collapse
Sorry, I thought it needed 'recovery' in the command either to boot twrp or to flash it.
So when we have an official working TWRP what command will we use to install it?
Maybe some other brave soul will give it a try.
No it doesnt.
And booting TWRP is safe, as it won't install anything to you're phone! It is only temporary, as you boot it.
The Moto Z3 Play (almost the same specs) also use this method. You can take a look at their forum
Ok, thanks.
jeffreyvh said:
No it doesnt.
And booting TWRP is safe, as it won't install anything to you're phone! It is only temporary, as you boot it.
The Moto Z3 Play (almost the same specs) also use this method. You can take a look at their forum
Click to expand...
Click to collapse
Hi, thanks for bringing it up. I have tried to boot the TWRP but it does not work. It simply reboots to system.
Is there anything more I should do beside rebooting to bootloader and executing command?
washoq said:
Hi, thanks for bringing it up. I have tried to boot the TWRP but it does not work. It simply reboots to system.
Is there anything more I should do beside rebooting to bootloader and executing command?
Click to expand...
Click to collapse
As far as I know you shouldn't do more then this, I'll probably just unlock my bootloader
Ah and can you write me the exact command which you have been using?
Thanks for testing!
jeffreyvh said:
As far as I know you shouldn't do more then this, I'll probably just unlock my bootloader
Ah and can you write me the exact command which you have been using?
Thanks for testing!
Click to expand...
Click to collapse
Yeah, sure, this are commands I have used:
Code:
adb devices
adb reboot bootloader
fastboot devices
fastboot boot twrp-3.2.3-1-lake.img
Image file was in adb folder.
One more thing. After I've tried above I couldn't boot to system normally (it always booted to stock recovery). Only executing 'fastboot boot recovery twrp-3.2.3-1-lake.img' booted to system.
So I thought it is common problem when you need to use 'fastboot continue' to go to system but after using this command I was not able to boot system at all, even boot recovery command
was not working (it gave me an error). Eventually I was forced to do factory reset from stock recovery and it did the trick, system booted normally. So unfortunately I must say it is not safe to even boot this recovery.
However I am willing to help/test as long as I am able to recover using factory reset.
jeffreyvh said:
And booting TWRP is safe, as it won't install anything to you're phone! It is only temporary, as you boot it.
Click to expand...
Click to collapse
I tried this too last night (using command: 'fastboot boot twrp-3.2.3-1-lake.img') with same result requiring a factory reset, it boots to system then on next reboot got the "Can't Load Android System" error repeatedly with the only apparent option to do a factory reset which wipes everything.
However, I just saw in OP of this G6+ thread that flashing the gpt.bin from the firmware may fix partition table corruption likely causing that, so will try that first next time before doing a factory reset. Command is: 'fastboot flash gpt.bin'.
I suggest you take down the link until either you can unlock & test or one of us willing guinea pigs can, but I don't think posting it publicly totally untested was a good idea. You could PM myself, Washoq, or others who volunteer here with a private link, then when it's safely functional enough for a few of us then it post again publicly for fine-tuning. Appreciate your efforts but let's try to proceed more cautiously.
washoq said:
Yeah, sure, this are commands I have used:
Code:
adb devices
adb reboot bootloader
fastboot devices
fastboot boot recovery twrp-3.2.3-1-lake.img
Image file was in adb folder.
One more thing. After I've tried above I couldn't boot to system normally (it always booted to stock recovery). Only executing 'fastboot boot recovery twrp-3.2.3-1-lake.img' booted to system.
So I thought it is common problem when you need to use 'fastboot continue' to go to system but after using this command I was not able to boot system at all, even boot recovery command
was not working (it gave me an error). Eventually I was forced to do factory reset from stock recovery and it did the trick, system booted normally. So unfortunately I must say it is not safe to even boot this recovery.
However I am willing to help/test as long as I am able to recover using factory reset.
Click to expand...
Click to collapse
Hey, I see the problem. Like I already thought....
In my post is "fastboot boot twrp-3.2.3-1-lake.img" not include recovery!
Try this command and let me know, sorry if it sounds rude. But I told it was safe with my command, and you didn't use my command.
Thank you very much for testing, I really appreciate that!
Dahenjo said:
I tried this too last night (using command: 'fastboot boot twrp-3.2.3-1-lake.img') with same result requiring a factory reset, it boots to system then on next reboot got the "Can't Load Android System" error repeatedly with the only apparent option to do a factory reset which wipes everything.
However, I just saw in OP of this G6+ thread that flashing the gpt.bin from the firmware may fix partition table corruption likely causing that, so will try that first next time before doing a factory reset. Command is: 'fastboot flash gpt.bin'.
I suggest you take down the link until either you can unlock & test or one of us willing guinea pigs can, but I don't think posting it publicly totally untested was a good idea. You could PM myself, Washoq, or others who volunteer here with a private link, then when it's safely functional enough for a few of us then it post again publicly for fine-tuning. Appreciate your efforts but let's try to proceed more cautiously.
Click to expand...
Click to collapse
I edited the OP and putted there clear warnings
I leave the download link there yet for people who might wanna help me
jeffreyvh said:
Hey, I see the problem. Like I already thought....
In my post is "fastboot boot twrp-3.2.3-1-lake.img" not include recovery!
Try this command and let me know, sorry if it sounds rude. But I told it was safe with my command, and you didn't use my command.
Thank you very much for testing, I really appreciate that!
Click to expand...
Click to collapse
Not rude at all, no problem. It is actually my mistake. I wrote from my memory. I used command without 'recovery' as I copied it from your post.
Sorry for this. confusion. I will correct my post. So basically we are at the same place. Dahenjo confirmed that it does work like I described.
Still I am willing to test when you deliver new version with some fixes. Good luck
I also tried to boot the TWRP image, but nothing happened except a reboot of the g7 Plus to the system. Did I do something wrong?
Code:
C:\adb>adb devices
List of devices attached
ZY225CQ6T7 device
C:\adb>adb reboot bootloader
C:\adb>fastboot devices
ZY225CQ6T7 fastboot
C:\adb>fastboot boot twrp-3.2.3-1-lake.img
downloading 'boot.img'...
OKAY [ 0.880s]
booting...
OKAY [ 5.188s]
finished. total time: 6.068s
I would like to install Magisk. Is it possible to do this in a different way?
jeffreyvh said:
I edited the OP and putted there clear warnings
I leave the download link there yet for people who might wanna help me
Click to expand...
Click to collapse
So I got Moto to finally release kernel source. Where you have your device tree for lake? I got the kernel just about ready, but am curious what you used for device tree before I start my own.
Long story short, I'm trying to get TWRP working and bootable for you guys (I am picking up the device in the coming weeks). But I'd like to get things going for you guys in the meantime. I currently own Beckham and Evert (both very similar devices) so I know a little about these devices.
Jleeblanch said:
So I got Moto to finally release kernel source. Where you have your device tree for lake? I got the kernel just about ready, but am curious what you used for device tree before I start my own.
Long story short, I'm trying to get TWRP working and bootable for you guys (I am picking up the device in the coming weeks). But I'd like to get things going for you guys in the meantime. I currently own Beckham and Evert (both very similar devices) so I know a little about these devices.
Click to expand...
Click to collapse
Thanks for working on this, Joshua. OP hasn't said how they produced it, but it was untested causing a soft brick/factory reset for a few of us who tried it with the proper command line syntax for booting.
I was experimenting but am not a dev, began a porting guide but it didn't cover differences on newer A/B phones with recovery integrated into the boot.img so I couldn't follow it. However, along the way I tried booting both G6+ (evert) and Z3 Play (beckham) official TWRPs, which didn't work, just ended up back at bootloader, but didn't cause any further problems from simply booting.
I'll be glad to test if/when something is ready, and thanks again for helping us out. I already have root using this procedure without TWRP, but it'd be nice to do nandroids and I assume/hope we'll see some ROMs someday, perhaps RR for Lake.
Dahenjo said:
Thanks for working on this, Joshua. OP hasn't said how they produced it, but it was untested causing a soft brick/factory reset for a few of us who tried it with the proper command line syntax for booting.
I was experimenting but am not a dev, began a porting guide but it didn't cover differences on newer A/B phones with recovery integrated into the boot.img so I couldn't follow it. However, along the way I tried booting both G6+ (evert) and Z3 Play (beckham) official TWRPs, which didn't work, just ended up back at bootloader, but didn't cause any further problems from simply booting.
I'll be glad to test if/when something is ready, and thanks again for helping us out. I already have root using this procedure without TWRP, but it'd be nice to do nandroids and I assume/hope we'll see some ROMs someday, perhaps RR for Lake.
Click to expand...
Click to collapse
From what I hear it's just a ported version, which is fine. I'll finish putting together a device tree in the coming days and the kernel and should have a build for testing soon. I'll link it here when I got a build for testing so we can get a bootable build going.
Jleeblanch said:
From what I hear it's just a ported version, which is fine. I'll finish putting together a device tree in the coming days and the kernel and should have a build for testing soon. I'll link it here when I got a build for testing so we can get a bootable build going.
Click to expand...
Click to collapse
Thanks for your work. I am also willing to test when you have possibly working build.
Jleeblanch said:
From what I hear it's just a ported version, which is fine. I'll finish putting together a device tree in the coming days and the kernel and should have a build for testing soon. I'll link it here when I got a build for testing so we can get a bootable build going.
Click to expand...
Click to collapse
Hi, my build wasn't ported. I used the zImage from the stock kernel which I extracted. The device tree I made was based of the Z3 Play device tree. I probably know why it was causing this issue. It has something to do with encryption, when I'll have my new Linux Machine set up I'll take a look at this. And also this time I will be downloading the full omni source, instead of the minimal one required to build only TWRP. It could be the case that this is causing issues as well.
Nice to see some more devs coming over to this device. It's a pretty decent phone, the only downside for me is the battery but I'm glad we've got this rapidly fast 28W fast charging.
Anyways, when I'll have my Linux environment set up. I'll upload the device tree to GitHub including the extracted kernel image I've used.