mitigating cve-2015-3636 on cyanogenmod - AOKP Feature Development

hello friends
I am using cyanogenmod android lollipop custom rom on samsung s2 which has the pinpong and get_user vulnerability in it. I am temporarily able to mitigate pingpong by issuing the following command as su
Code:
#sysctl -w net.ipv4.ping_group_range="1 0"
However on every reboot the pingpong vulnerability re-appears. Please assist in mitigating both the vulnerabilities. All suggestions are welcome.

Related

Alternative to installing Better Battery Stats as system app

Starting with Android 4.4 (KitKat) Better Battery Stats (BBS) require installation as system app to be able to collect the stats.
BBS must re re-installed as system app after each ROM upgrade (upgrade that does not preserve third party system apps).
I have found an alternative to this - the required permissions can be granted to BBS when it is installed as a regular user app by running these commands in Android Terminal (or ADB shell session):
Code:
su
pm grant com.asksven.betterbatterystats android.permission.BATTERY_STATS
pm grant com.asksven.betterbatterystats android.permission.DUMP
After using these commands it might be required to restart BBS process (e.g. reboot the device). Permissions granted this way will be preserved across ROM upgrades (even across those completely overwriting /system partition).
This has been tested on CyanogenMod 12.1 nightlies (Android 5.1.1).
Update! This post on BBS thread describes a related method for granting (at least part of) the permissions without root.
Hi DavisNT,
I'm confirming that your adb code appears to be a successful workaround for the normal version of BBS downloaded from the Play Store when the phone is running Lollipop. I'm running the paid version of BBS, on the current CM12.1 Nightly (jfltetmo for my T-Mobilr SGH-M919 Galaxy S4).
Procedure:
1. Install BBS from the Play Store.
2. Use ADB (easy to cut and paste from here) or another terminal program (you'll be typing) to install the code.
3. Reboot the phone.
You'll notice that when you launch BBS, CM's "Privacy Guard" will see that BBS is trying to gain root access, and will prompt you to allow this. I selected "Always Allow" until I'm done my battery testing. You'll notice that you now see "#" up on the phone's status bar. That indicates an app is running with root access. You could probably quiescence this by choosing "Ignore" via Privacy Guard.
Could the developer please approve that this relatively easy workaround is kosher?
Thanks . . .
Moved to main thread to avoid orphan
For apk downloaded from xda change the code to
pm grant com.asksven.betterbatterystats_xdaedition android.permission.BATTERY_STATS
pm grant com.asksven.betterbatterystats_xdaedition android.permission.DUMP
I tried this method, but failed on the BATTERY_STATS permission, the error said this 'permission type is not changeable'
is this method still valid?
andycjw said:
I tried this method, but failed on the BATTERY_STATS permission, the error said this 'permission type is not changeable'
is this method still valid?
Click to expand...
Click to collapse
On what version of Android did this fail? And was 'su' used before 'pm grant'?
Same problem. I'm on CM, Android version 4.4.4. Used 'su' before.
bobcote said:
Same problem. I'm on CM, Android version 4.4.4. Used 'su' before.
Click to expand...
Click to collapse
Most likely this method works only on Lollipop and Marshmallow.
Looks like on KitKat BATTERY_STATS permission does not have development in its protectionLevel, but on Lollipop and Marshmallow it has.
I assume (please correct me if I am wrong, preferably with link to some authoritative documentation) that development in protectionLevel allows a permission to be granted by pm grant command.
Thanks
I can confirm that this method works flawlessly for the Sprint version of the Galaxy Note 3 5.0. Many thanks.
Guys where is the main thread? Pls ?
DavisNT said:
Starting with Android 4.4 (KitKat) Better Battery Stats (BBS) require installation as system app to be able to collect the stats.
BBS must re re-installed as system app after each ROM upgrade (upgrade that does not preserve third party system apps).
I have found an alternative to this - the required permissions can be granted to BBS when it is installed as a regular user app by running these commands in Android Terminal (or ADB shell session):
Code:
su
pm grant com.asksven.betterbatterystats android.permission.BATTERY_STATS
pm grant com.asksven.betterbatterystats android.permission.DUMP
After using these commands it might be required to restart BBS process (e.g. reboot the device). Permissions granted this way will be preserved across ROM upgrades (even across those completely overwriting /system partition).
This has been tested on CyanogenMod 12.1 nightlies (Android 5.1.1).
Click to expand...
Click to collapse
Does this method work on marshmallow?
Thank you
RoxAbout said:
Does this method work on marshmallow?
Thank you
Click to expand...
Click to collapse
Most likely yes. Feel free to test. [emoji2]
Can anyone post BBS apk please!! TQIA
Thanks dude. The command for xdaedition worked flawlessly on my RR rom. Android 6.0.1 Galaxy S3
Worked! Thanks.
Does this works on a non-rooted phone? if it works, is uninstalling as simple as accessing app under setting to uninstall?
Thanks.
nuthing03 said:
Does this works on a non-rooted phone? if it works, is uninstalling as simple as accessing app under setting to uninstall?
Thanks.
Click to expand...
Click to collapse
AFAIK This method should NOT work on non-rooted phones (but you can still try it :fingers-crossed: ). If it will work, uninstalling the app (via Settings - Applications) would also revoke the granted permissions.
Original Thread here: http://bit.ly/1ov1NNy
Can confirm that the workaround is OK on Samsung S6 with Android 6.0.1 (stock DTM/rooted).
Best regards
Glad I found this, thought BBS was bugged when it kept wanting the BATTERY_STAT permission despite having the XPosed module :\
Executing those 2 lines fixed the problem.... wonder why it's not like that by default. I even checked AppOpsXposed and didn't see anything about DUMP/BATTERY_STAT
Installing BBS into /system would break OTA, no? I've read somewhere the claim that it doesn't--maybe even in the app itself

Getting proper su at very early init via one of .rc files?

Hello dear Chainfire and community!
I have a rather obscure issue: I want to run a root script at very early init.
The script (predictably) runs afoul of Selinux policy (who'd have thought) and since it's a chinese phone no sources are available.
Good things:
I can unpack/repack boot.img without issue, and can add/start services from .rc
Phone is rootable and after proper boot, SuperSu works fine (and so does setenforce 0)
Bad things:
This is lolipop 5.0 so install-recovery.sh and anything else of that general kind is not available
Source (and thus opportunity to change sepolicy) not available
SuperSu daemon's normal start is waaaaay too late for what I'm trying to do.
Question:
Given that I can add my own service and run it as I please, is there a way to "kickstart" su functionality early-on (so I can set Selinux to permissive and run my stuff), without breaking functioning of supersu after boot completes?

Systemless root install from adb root shell?

Recently a few people have gotten insecure kernels for the AT&T model Galaxy S6 series phones that are actually flashable in Odin. The running problem with root is that any changes made to the system partition result in a bootloop.
I'm wondering if, since I can at least temporarily remount partitions as r/w from the adb root shell, can I directly install a systemless root? If not, could I install root to the system partition and then convert it to systemless somehow?
Here's the root thread on the AT&T Galaxy S6 Edge Plus forum:
http://forum.xda-developers.com/showpost.php?p=65510225&postcount=66
Any insight or assistance would be appreciated beyond words!
navalynt said:
Recently a few people have gotten insecure kernels for the AT&T model Galaxy S6 series phones that are actually flashable in Odin. The running problem with root is that any changes made to the system partition result in a bootloop.
I'm wondering if, since I can at least temporarily remount partitions as r/w from the adb root shell, can I directly install a systemless root? If not, could I install root to the system partition and then convert it to systemless somehow?
Here's the root thread on the AT&T Galaxy S6 Edge Plus forum:
http://forum.xda-developers.com/showpost.php?p=65510225&postcount=66
Any insight or assistance would be appreciated beyond words!
Click to expand...
Click to collapse
You can try flash fire you will have to sign up for the beta

[MODULE] Debugging modules: ADB Root, SELinux Permissive, Enable Eng

These modules are not meant for everyday use. They are intended for debugging and modification of a firmware. They significantly lower security of your device while active and even could softbrick it. You've been warned.
ADB Root
Magisk Module that allows you to run "adb root". adb root is not an ordinary root (su), it's adbd daemon running on your phone with root rights. adb root allows you to "adb push/pull" to system directories and run such commands as "adb remount" or "adb disable-verify".
Download v1.0: https://github.com/evdenis/adb_root/releases/download/v1.0/adb_root.zip
Source code: https://github.com/evdenis/adb_root
Support: Telegram
SELinux Permissive
This module switches SELinux to permissive mode during boot process. This module intentionally lowers security settings of your phone. Please don't use it if there is a better solution to your problem, e.g., magiskpolicy. The module will not work if your kernel compiled with always enforcing config, e.g., stock samsung kernels. It's not possible to enable permissive mode on such kernels.
Download v2.0: https://github.com/evdenis/selinux_permissive/releases/download/v2.0/selinux_permissive_v2.0.zip
Source code: https://github.com/evdenis/selinux_permissive
Support: Telegram
Enable Eng
This Magisk Module enables engineering build props. It allows to activate debugging parts of a firmware. Please, disable Magisk Hide for this module. If you don't know what you are doing, don't use this module. It can easily softbrick your device.
Troubleshooting
If your device doesn't boot then you need to reboot to TWRP recovery and
Code:
$ adb shell rm -fr /data/adb/modules/enable_eng
If ADB doesn't work that means adbd in your firmware is build without ALLOW_ADBD_ROOT. You can fix adb autostart either by installing "ADB Root" magisk module or by disabling this module.
Download v1.0: https://github.com/evdenis/enable_eng/releases/download/v1.0/enable_eng.zip
Source code: https://github.com/evdenis/enable_eng
Support: Telegram
Kexec tools for Android
This module adds statically linked kexec binary to your system. Aarch64 only. Kexec is a system call that enables you to load and boot into another kernel from the currently running kernel. Your kernel should support kexec.
Download v1.0: https://github.com/evdenis/kexec/releases/download/v1.0/kexec.zip
Source code: https://github.com/evdenis/kexec
Support: Telegram
GDISK/Parted for Android
The module adds statically linked parted/sfdisk/fdisk/gdisk binaries to your system. Aarch64 only. These utils are standard linux tools to edit the partitions tables on disks.
Download v2.0: https://github.com/evdenis/disk/releases/download/v2.0/disk-v2.0.zip
Source code: https://github.com/evdenis/disk
Support: Telegram
Is also valid for One Plus 5 ?
Inviato dal mio ONEPLUS A5000 utilizzando Tapatalk
tmviet said:
Is also valid for One Plus 5 ?
Click to expand...
Click to collapse
Hi, these magisk modules are device independent. Yes, you can use them on One Plus 5.
evdenis said:
Hi, these magisk modules are device independent. Yes, you can use them on One Plus 5.
Click to expand...
Click to collapse
Tks. A lot [emoji6]
Inviato dal mio ONEPLUS A5000 utilizzando Tapatalk
Thanks @evdenis, this module is great! I haven't gotten the 100% desired behavior (getting adbd with actual root perms) because I'm running a 32-bit architecture (armeabi-v7a) and you've supplied only the 64-bit version of adbd, but I've been using your module to swap out 32-bit versions of different versions of adbd I have lying around (older devices). I'm a n00b when it comes to building adbd from scratch using the latest sources with your patch so I'm planning on using the adbd that came with the device and using a disassembler and a hexeditor to NOP out some calls, such as the call to minijail_enter() and see if I have any success. The original device version of adbd doesn't seem to have the functions in it that you built with the patch, but instead appears to use a bunch of minijail library functions. The device is a rooted android 8.1.0 OS, but it is only rooted systemlessly so many of the ro.* build properties affecting adb are changed well after the OS-essential portion boots rendering my efforts thus-far using the original adbd ineffective I'm guessing. I can now issue the "adb root" command from my machine, but adbd on the device is always being launched with the following command line arg "--root_seclabel=u:r:su:s0" and never gains root permissions by default (the behavior I'm trying to achieve). I can manually use "su" but this doesn't help me with push/pull requests to protected parts of the OS and chainfire's "ADB Insecure" patches adbd successfully, but I still don't get the root perms.
Do you know if the system is starting the process with reduced permissions (i.e. adbd will never be able to gain root access on its own no matter what I modify) and I should go a different route like modifying something else in the system rather than adbd? Again, I've already modified the ro.* properties affecting adbd so it does attempt to re-launch itself as root, it just doesn't end up getting the root perms. Manually launching adbd after killing it from within a shell on the device doesn't seem to affect the permissions in ultimately gets.
If you are anyone has any insight as to what I need to do so that adbd gains root permission, that would be much appreciated.
bpaxda said:
I'm planning on using the adbd that came with the device and using a disassembler and a hexeditor to NOP out some calls, such as the call to minijail_enter() and see if I have any success.
Click to expand...
Click to collapse
It was my initial attempt to gain "adb root" on samsung s10. And noping a couple of calls is not enough on the phone. adbd binary on your device could be compiled without "adb root" branch. This is the case on samsung s10. If "adb root" branch exists one need to force should_drop_privileges() function to return false (https://android.googlesource.com/platform/system/core/+/refs/heads/master/adb/daemon/main.cpp#65) in order to get into the "adb root" branch of code (https://android.googlesource.com/platform/system/core/+/refs/heads/master/adb/daemon/main.cpp#151).
bpaxda said:
ro.* build properties affecting adb are changed well after the OS-essential portion boots rendering my efforts thus-far using the original adbd ineffective I'm guessing.
Click to expand...
Click to collapse
You could try enable_eng magisk module (https://github.com/evdenis/enable_eng). The module changes ro.* props to engineering build props. Depending on a firmware this could help to get "adb root". However, no guaranties that the module will not softbrick your device. In case of softbrick you will need to reboot to TWRP and delete the module, instruction is in the README.md.
bpaxda said:
I can now issue the "adb root" command from my machine, but adbd on the device is always being launched with the following command line arg "--root_seclabel=u:r:su:s0" and never gains root permissions by default (the behavior I'm trying to achieve).
Click to expand...
Click to collapse
Try to disable SELinux either with the magisk module or with a script.
Thanks for your response.
I think you're right. Despite having adjusted the ro properties post-boot, there was nothing in ADB that would change the privileges as if it has been compiled out. By sheer luck, I managed to grab adbd from an identical device that had a recent forced firmware update, but the "improved adbd" actually let me get closer. The updated adbd had code changes to its adbd_main function so that it at least looks at the properties "ro.secure" and "service.adb.root" not to mention new calls to minijail_capbset_drop(), minijail_change_gid() and minijail_change_uid(). Using magisk to dynamically replace my original adbd binary with this updated one actually worked in getting adbd to start root shells without needing to invoke "su"!
However its a weird type of root that can't read certain files like /verity_key but I can see some things I should be able to see as root. I'm no SELinux expert, but my guess is that if everything is functioning correctly, I may be getting an SELinux "restricted" root. In this case, it might be the most I can expect from an SELinux enabled kernel launching adbd as root. Let me explain: since I'm using Magisk, post-boot systemlessly, (the system boots restricted and then I use the mtk_su exploit, to gain root and disable permissive SELinux mode), I'm getting permissive root on a session by session basis. I think the nature of this type of root means the kernel is probably still locked down and thus whatever daemon may be responsible for launching adbd remains locked down. Does this sound correct to you? If so, I can live with that
I'd love to get TWRP on this device, but I'm not sure its possible since TWRP doesn't list my device as supported on their website nor can I get into fastboot mode (I didn't try that hard because I wanted to exhaust other options before flashing anything). Do you think enable_eng would work *after* the ACTION_BOOT_COMPLETE event is processed? I.e. my device is rooted after bootup by a script which runs the exploit, but it is well after the system is fully running and locked-down. Luckily Magisk has a utility to change ro properties, but some of those properties are not looked-at by the system this late in the boot stage. Do you think in this case "enable_eng" would work for me? Thanks again!
bpaxda said:
Let me explain: since I'm using Magisk, post-boot systemlessly, (the system boots restricted and then I use the mtk_su exploit, to gain root and disable permissive SELinux mode), I'm getting permissive root on a session by session basis.
Click to expand...
Click to collapse
I'm not sure that my modules will work with this rooting scenario. As far as I could understand, magisk by default replaces the init process, patches selinux policy before it is loaded and next, calls the original init binary. I don't think that it will be possible to alter selinux policy with different boot scenario for magisk.
bpaxda said:
Do you think enable_eng would work *after* the ACTION_BOOT_COMPLETE event is processed? I.e. my device is rooted after bootup by a script which runs the exploit, but it is well after the system is fully running and locked-down. Luckily Magisk has a utility to change ro properties, but some of those properties are not looked-at by the system this late in the boot stage. Do you think in this case "enable_eng" would work for me?
Click to expand...
Click to collapse
I'm not sure that enable_eng will work. adbd daemon check some properties such as ro.secure dynamically, but they could be cached after the boot. I don't know the ways to drop the cache and re-read these properties (altered with magisk) after the boot. Here are the main properties the modules changes https://github.com/evdenis/enable_eng/blob/master/system.prop
Thanks for making this tool! I'm just wondering if I need to modify my adb to use the module - I run "adb root" normally and get "adbd cannot run as root in production builds" still
Anyone know why when i install SELinux Permissive version 2.0 of the module it still states version 1 in Magisk?
I flashed this in Magisk and rebooted. Now my phone is stuck in a boot loop. Any ideas? I'm using Sony Xperia XZ1 compact.
cheeklitched said:
I flashed this in Magisk and rebooted. Now my phone is stuck in a boot loop. Any ideas? I'm using Sony Xperia XZ1 compact.
Click to expand...
Click to collapse
If you have twrp installed just uninstall and reinstall magisk.
Otherwise,
Boot to bootloader and flash your boot.img file
Code:
fastboot flash boot boot.img
Then let phone boot. Reboot to bootloader again. Flash magisk_patched.img
Code:
fastboot flash boot magisk_patched.img
During startup, as soon as you get to the Google logo, hold the volume button down. This should start the phone in safe mode. See if it loads. If not, reboot phone, and execute this in terminal/command prompt:
Code:
adb wait-for-device shell magisk --remove-modules
This should allow the phone to start up all the way. Enable whatever modules you want. You may need to flash magisk_patched.img again.
This has fixed multiple problems for me. It's redundant, but it tends to work.
I installed the Magisk selinux script, but after installing it no longer shows in Magisk, so how do I dissable/undo/uninstall the script? I installed a Selinux checker and it says it is on permissive, so the scrip must have installed, but I want to remove it. Is there an undo script, or can I manually delete the script in my root filesystem? THX
Hello guys
I used Redmi K20 pro with Eu rom 10.4, android 10.
I used the lastest version of this module but my devices was not found on ADB system on my computer.
So what I do now? I tried to fix it but I cannot find anything about it.
Recently, setting SElinux to permissive is not advised. I had a issue with V4A setting my SElinux to permissive permenantly, but editing the magisk module to set SElinux to enforcing instead of permissive also works.
This is probs the only module that actually sets SElinux properly.
Here's the modded magisk module with the same credited creator, but just sets SElinux to Enforcing instead of permissive
OMFG I THINK THIS IS WHAT IVE BEEN LOOKING FOR. TEH HOLY GRAILLLLL OMGOMGOMG THANK YOU THANK YOU THANK YOUUUUU
Will ADB Root work for Android 8.1?
evdenis said:
These modules are not meant for everyday use. They are intended for debugging and modification of a firmware. They significantly lower security of your device while active and even could softbrick it. You've been warned.
ADB Root
Magisk Module that allows you to run "adb root". adb root is not an ordinary root (su), it's adbd daemon running on your phone with root rights. adb root allows you to "adb push/pull" to system directories and run such commands as "adb remount" or "adb disable-verify".
Download v1.0: https://github.com/evdenis/adb_root/releases/download/v1.0/adb_root.zip
Source code: https://github.com/evdenis/adb_root
Support: Telegram
SELinux Permissive
This module switches SELinux to permissive mode during boot process. This module intentionally lowers security settings of your phone. Please don't use it if there is a better solution to your problem, e.g., magiskpolicy. The module will not work if your kernel compiled with always enforcing config, e.g., stock samsung kernels. It's not possible to enable permissive mode on such kernels.
Download v2.0: https://github.com/evdenis/selinux_permissive/releases/download/v2.0/selinux_permissive_v2.0.zip
Source code: https://github.com/evdenis/selinux_permissive
Support: Telegram
Enable Eng
This Magisk Module enables engineering build props. It allows to activate debugging parts of a firmware. Please, disable Magisk Hide for this module. If you don't know what you are doing, don't use this module. It can easily softbrick your device.
Troubleshooting
If your device doesn't boot then you need to reboot to TWRP recovery and
Code:
$ adb shell rm -fr /data/adb/modules/enable_eng
If ADB doesn't work that means adbd in your firmware is build without ALLOW_ADBD_ROOT. You can fix adb autostart either by installing "ADB Root" magisk module or by disabling this module.
Download v1.0: https://github.com/evdenis/enable_eng/releases/download/v1.0/enable_eng.zip
Source code: https://github.com/evdenis/enable_eng
Support: Telegram
Kexec tools for Android
This module adds statically linked kexec binary to your system. Aarch64 only. Kexec is a system call that enables you to load and boot into another kernel from the currently running kernel. Your kernel should support kexec.
Download v1.0: https://github.com/evdenis/kexec/releases/download/v1.0/kexec.zip
Source code: https://github.com/evdenis/kexec
Support: Telegram
GDISK/Parted for Android
The module adds statically linked parted/sfdisk/fdisk/gdisk binaries to your system. Aarch64 only. These utils are standard linux tools to edit the partitions tables on disks.
Download v2.0: https://github.com/evdenis/disk/releases/download/v2.0/disk-v2.0.zip
Source code: https://github.com/evdenis/disk
Support: Telegram
Click to expand...
Click to collapse
how can i make permissive enfocing because in 2022 i heard thats a BIG security risk and my custom ROM (havoc os) if selinux permissive

Troubleshooting wifi problems on S2 exynos5433 tablet ONLY discussion for users running any version of Android 10

The S2 wifi blobs have now been incorporated into the Aug 25 17.1 builds.
Please take 10 minutes to read all of post #1 and #2. lpedia and I have spent 5 days troubleshooting this together and want to present our wifi findings. DO NOT USE this thread to report any other problems, it's only for exynos5433 S2 tablet wifi. If this is unreasonable, then stop reading. Thank you.
If your device's wifi is not connecting after a restart and/or wake from sleep, and/or dropping out at random, this could be because the 17.1 code is using Samsung Galaxy S6 wifi blobs instead of its stock S2 wifi blobs. This commit was made in 17.1 at
gts2: Import Galaxy S6 BCM4358 firmware · universal5433/[email protected]
@lpedia has confirmed that LineageOS 17.1 on his T710 has the wifi problems when using S6 blobs, but not after the S6 blobs have been replaced with stock S2 blobs. This appears to fix both non-connection at boot and not reconnecting on wake from sleep. Random dropouts are less common and were not seen during the limited testing, so it's not certain that they're gone.
FAQ
Q1. Will changing from S6 wifi blobs solve all my wifi no reconnect or disconnect problems?
A1. This has only been tested on the T710, and there's no guarantee it will help the other devices. If you want to try, follow the instructions below. Before you try, make sure to back up all your data. The following should write the stock S2 blobs to the /system partition only, but if you make a mistake you could lose your data! Back up first.
It's an easy test to see if the stock S2 blobs will help or not. If your current rom does not connect to wifi after a restart, try our proposed solution. Before you do, reboot your current rom 5 times in a row. After each reboot, see if your wifi connects. After you install stock S2 blobs, reboot your device again 5 times in a row and see if wifi connects. This will easily tell you if the S2 stock blobs have solved this one particular problem or not.
As for wifi not connecting after long/deep sleep, you should notice over 2 or 3 days if wifi connects or not after deep sleep.
Q2. Will this work on SM-T710, SM-T810, etc?
A2. Same answer as A1. It should work on any S2 tablet exynos5433 device that uses the S6 wifi blobs that are the default in 17.1 or Android 10. These instructions are only for exynos5433 devices.
As the thread grows bigger, you can see who is responding back with either positive or negative feedback and what model they have.
Q3. Will this work on RR, Havoc or LineageOS (Android 10 or 17.1)?
A3. The instructions below replace the S6 blobs with the original stock S2 blobs. The instructions provided should work regardless if it's Havoc, RR or LineageOS. All these variant OSes share the same repo (i.e. code and blobs) on github.
Q4. Is this post relevant to Android 9 or LineageOS 16.0?
A4. NO. The github repos show that Android 9 or LineageOS 16.0 used the stock S2 wifi blobs. This was changed to S6 wifi blobs in Android 10 or LineageOS 17.1. I don't know why it was changed to S6 blobs as I'm not involved with that change.
Q5. Why do I need my model and code name?
A5. In order to follow the instructions below, you need to know your model number and it's code name. The model number or device name is settings, about tablet.
You can find the code name at (scroll almost all the way down to the bottom)
Samsung
This is the Team Win website and the official home of TWRP! Here you will find the list of officially supported devices and instructions for installing TWRP on those devices.
twrp.me
For example, SM-T710 is gts28wifi.
Q6. Does it matter if my wifi is 2.4Ghz or 5Ghz or a mix of both?
A6. When reporting back to us, please state whether your network is 2.4Ghz only, 5Ghz only, or a mix of 2.4Ghz and 5Ghz. In addition, if its a mix, please let us know if it's one wifi network (same ssid) or two separate wifi networks. That is, 2.4Ghz is one ssid and 5Ghz is another ssid.
Q7. If this works, how will this be fixed for the next release of code and the future?
A7. If enough people say it fixes their wifi problems, I can submit a git pull request to Anan to revert the S6 wifi blobs back to S2 wifi blobs.
Instructions
1. Make sure adb debugging is enabled in developer options. To enable developer options, tap settings, about tablet, build number 7 times until it says developer options unlocked. Go back to settings, system, advanced, developer options, enable android debugging and rooted debugging.
Note if you are running Magisk, see posts regarding Magisk if you cannot see rooted debugging.
2. You will need git. There are instructions and download links for installing git on Windows, MacOS, and Linux at Git Guides - install git | GitHub.
3. After you install git, follow the instructions exactly below.
Bash:
# make temporary vendor directory
mkdir temp
# cd to that directory
cd temp
# git the 16.0 stock drivers
git clone https://github.com/universal5433/proprietary_vendor_samsung -b lineage-16.0
# change directory to proprietary_vendor_samsung/<your device>/proprietary/system/vendor/etc
# or if Windows, to proprietary_vendor_samsung\<your device>\proprietary\system\vendor\etc
# where "<your device>" is your device's code, for example gts28wifi for the T710:
cd proprietary_vendor_samsung/gts28wifi/proprietary/system/vendor/etc
# start adb root
adb root
# remount /system as rw (it's read only by default)
adb remount
# start adb shell
adb shell
# delete S6 blobs from wifi directory
cd /system/vendor/etc/wifi
rm bcm*
rm nvr*
# There should be only .conf files left now
ls -al
exit
# you should be back at your desktop terminal prompt now
# now push all stock drivers to /system/vendor/etc/wifi
adb push wifi /system/vendor/etc
# check to make sure it got pushed okay
adb shell ls -al /system/vendor/etc/wifi
# now reboot Android
adb reboot
If the above does not work for you, or if it causes other problems, just reflash the last rom. That will overwrite the /system partition and everything will be restored.
If you do try this, please report back to this thread about whatever happened and include your device and what wifi network you are running.
Reserved.
Thanks for the instructions!
I had to boot my T810 (gts210wifi) into TWRP and mount /system from there before adb root and adb remount was possible. Everything else worked as described.
Observations after 5 reboots: WiFi available after reboot each time! Much better than before!
I will observe it now for a while regarding wifi-off after sleep or sporadical wifi-off.
Btw. for the random reboots of the unmodified linageos17.1 (ripee) I'm pinging my DNS-server all 2mins using Tasker. Fixed reboots since 2 month at least on my system.
Yogi555 said:
I had to boot my T810 (gts210wifi) into TWRP and mount /system from there before adb root and adb remount was possible.
Click to expand...
Click to collapse
The above might be due to you not having adb root enabled in developer options. I will update the instructions to make sure that's enabled.
Strangely the setting seems not there in my system. But I remember that in some system its available. Can the installed Magisk be the reason?
Yogi555 said:
Strangely the setting seems not there in my system.
Click to expand...
Click to collapse
It's there.
Short update: The S2 wifi blobs are a huge improvement. With S6 blobs I had reliable dropoffs at medium router-signal combined with heavy wifi-load (no dropoffs with full router signal). With the S2 blobs no single dropoff even at weak router-signal and heavy wifi-load for several hours now.
Again, to enable developer options, tap settings, about tablet, build number 7 times until it says developer options unlocked. Go back to settings, system, advanced, developer options, enable android debugging and rooted debugging.
As I said earlier, the routed debugging option is missing in my developer-options (with installed Magisk). Everything else is looking identical to the attachement of post 6. But maybe we should not cover this thread with the different ways to adb root. The really important thing is that the proposed fix works really great! At least for me and hopefully for everybody else who is willing to try it
Yogi555 said:
As I said earlier, the routed debugging option is missing in my developer-options (with installed Magisk). Everything else is looking identical to the attachement of post 6. But maybe we should not cover this thread with the different ways to adb root. The really important thing is that the proposed fix works really great! At least for me and hopefully for everybody else who is willing to try it
Click to expand...
Click to collapse
Thanks, @Yogi555! It's great to know that replacing the blobs works on one of the other S2 models! We could only test it on gts28wifi (T710).
@Yogi555, about the Rooted debugging option: my T710 doesn't show that option, either, and I think it's because I have Magisk installed (@retiredtab doesn't).
If the device is not rooted, "adb root" temporarily restarts the adbd daemon on the device as root (there's a timeout period after which it will remove root access again).
I'm guessing that if the device is rooted, that isn't necessary - because adbd is probably already running as root . The Rooted debugging option is therefore unnecessary, and isn't shown.
In either case, when you do "adb root" on the PC, there should be a prompt on the device asking you if you want to allow access. Did you see the prompt? If you don't explicitly allow it, root access won't be given.
Also, "adb root" works on Windows (for an account that's in the Administrators group) without needing to be Run As Administrator, but I think Linux requires the command to be run as root (eg, sudo adb root).
Update2: after the night the T810 with S2 blobs was immediately connected to wifi this morning. Great!
Regarding "adb root" with Magisk: I'm running it from Win10 PC. Independent if normal commandline or commandline as administrator - after "adb root" there is no output at all, but a sound like connecting or disconnecting a device. After "adb remount" next, an error is displayed:
Not running as root. Try "adb root" first.
remount failed
Maybe my adb is too old (version 1.0.40)
However "adb reboot recovery" works and "adb root" then in TWRP as well. So strange, but no problem
Yogi555 said:
Update2: after the night the T810 with S2 blobs was immediately connected to wifi this morning. Great!
Regarding "adb root" with Magisk: I'm running it from Win10 PC. Independent if normal commandline or commandline as administrator - after "adb root" there is no output at all, but a sound like connecting or disconnecting a device.
Click to expand...
Click to collapse
Did you check the device to see if it's prompting you to allow this access? The prompt times out fairly quickly, so you might not see it if you don't check straight away. It does give a notification sound.
The prompting came yesterday at the very beginning of the activity and I allowed it (including the always checkbox). "adb device" shows the device id.
I don't understand why you'd see anything different from what I see. I use a Windows PC, I have Magisk (version 23.0) installed on the T710, and have previously allowed adb root access "always".
What I see is this:
Code:
> adb version
Android Debug Bridge version 1.0.41
Version 31.0.2-7242960
> adb root
adbd is already running as root
> adb remount
remount succeeded
> adb root
gts28wifi:/ #
I think there could be something wrong with your Magisk configuration. What version is it?
Downloaded adb version 1.0.41. Now I get "ADB Root access is disabled by system setting - enable in Settings -> System -> Developer options"
Updated Magisk from 20.4 to 22.1. and App to 23.0 => No difference :-(
In Magisk App adb is not listed in Superuser-tab. Can I add it somehow?
Yogi555 said:
Downloaded adb version 1.0.41. Now I get "ADB Root access is disabled by system setting - enable in Settings -> System -> Developer options"
Updated Magisk from 20.4 to 22.1. and App to 23.0 => No difference :-(
In Magisk App adb is not listed in Superuser-tab. Can I add it somehow?
Click to expand...
Click to collapse
I think I know what's going on now.
I've just uninstalled Magisk, and (after the enforced reboot) I can now see the "Rooted debugging" setting in Settings > System > Developer Options > Debugging.
Mine was ON, but had been hidden by Magisk's presence, as I suspected.
If you uninstall Magisk, I think you will find that your "Rooted debugging" is OFF. If so, turn it on, then try "adb root" etc. You don't need to root the device in order to use adb root functions. If you want the device to be rooted, by all means re-install Magisk - but with that setting still ON.
I'll be very interested to hear what happens.
The simplest way to check that adb root has actually given you root access is to "adb shell". The prompt will end in a "#" if the shell's running as root. As mentioned in an earlier post.
Want to also quickly confirm in here that the S2 Blobs are working real fine for me as well.
lpedia said:
I think I know what's going on now.
I've just uninstalled Magisk, and (after the enforced reboot) I can now see the "Rooted debugging" setting in Settings > System > Developer Options > Debugging.
Mine was ON, but had been hidden by Magisk's presence, as I suspected.
Click to expand...
Click to collapse
I've just re-installed Magisk and proved to myself that Magisk 23 is hiding the setting. I found that Magisk 22 didn't hide it - I re-installed using a version 22 zip that I had on hand, checked the "Rooted debugging" setting, which was still visible, then updated to Magisk 23 via the app. After the reboot, the setting had disappeared again.

Categories

Resources