UPDATE - I have built the required kernel modules ( magic: 3.0.8+ SMP preempt mod_unload ARMv7) for ICS.
Download: archos-ics-gsm.zip
Remember these are only the kernel level drivers and a bit more hacking is required if you want to used these in the android environment.
Happy Hacking!
[ORIGINAL POST]
Hi
Here is the required kernel module (usb_wwan.ko) to enabled the modem functionality at the kernel level for Huawei 3G Dongles on the archos G9.
I don't know if anyone will find it useful but I thought I'd share it anyway
It was built from the archos-g9-gpl and is compatible with kernel version "2.6.35.7+ #1 SMP PREEMPT"
Notes:
Huawei USB 3G Modems actually require 2 modules to function usb_wwan.ko and option.ko. Archos already ship option.ko in /lib/modules on the device so this was the only one missing.
To use:
1. insmod usb_wwan.ko
2. insmod option.ko
3. Use usb_modeswitch to initialize the modem
The modem can be then be found at /dev/ttyUSB*
See this post for a quick guide into making a ppp connection using this driver
Thanks
I'm very interested in this. So I have a Huawei EC168 air card from a little cdma provider named Alltel (who is now partially owned by Verizon), would installing this allow it to function? I mean do you know if this is a universal driver or is it meant for GSM only?
I'm a bit of a noob at this. I've got the first two commands to run and usb_wwan.ko is just in my /mnt/storage
What are the specific switches I need to get the usb_modeswitch command working? -H just results in "No default vendor/product ID given. Aborting."
Btw I'm running everything through Terminal Emulator as I don't have adb or anything like that up and running currently on my computer.
Edit: I can't mess with this until I get hdd mounting working again. That was the whole reason I bought this tablet.
If anyone can help with that my topic is here. http://forum.xda-developers.com/showthread.php?p=22722509
I'm unsure whether this is a CDMA driver but you can give it a go.
From the command line I copied usb_wwan.ko to /lib/modules on the device and then did then following (the command should work equally as well in terminal emulator, with out the adb shell bit obviously )
Code:
adb shell insmod /lib/modules/usb_wwan.ko
adb shell insmod /lib/modules/option.ko
Then I Usb Mode Switched to the modem. I my case a Huawei E1752 [O2 UK Branded]
I discovered the correct target product [0x1436] (which isn't included in the 12d1_1446 config file) after plugging it into linux an listing my USB devices using lsusb in a terminal window.
Code:
adb shell usb_modeswitch -s 6 -v 12d1 -p 1446 -V 12d1 -P 1436 -M 55534243123456780000000000000011062000000100000000000000000000 > /dev/null
Obviously the usb modeswitch parameters are unique to your device and you can of course specify a configuration file using the -c switch instead of using the switches I have here.
After this I had access to the modem on the /dev/tttyUSB*
I gave the modem about 1 minute to initialize and then ran
Code:
adb shell /system/bin/pppd /dev/ttyUSB0 115200 nocrtscts nocdtrcts local usepeerdns defaultroute noipdefault ipcp-accept-local ipcp-accept-remote user cmnet password cmnet debug kdebug 7 connect "/system/xbin/chat -v -t 500 -s -f /data/media/gprs_start"
This brings up a PPP connection on ppp0. Although it didn't register as any sort of connection in android, it does however allow me to use the android web browser on this connection.
Note:
You do need 2 additional files which I have attached - The gprs_start script which I copied to the /data/media directory and is run by pppd and ip-up which you need to place in your /etc/ppp directory. This handles setting the correct dns servers after you have connected
This method is a little rough and I have been experimenting with the android ril interface but I'm having some problems keeping the connection alive for any length of time after starting the ril-daemon and I found the connection was at it's most stable when the ril-daemon is stopped.
Hi
trevd said:
It was built from the archos-g9-gpl and is compatible with kernel version "2.6.35.7+ #1 SMP PREEMPT"
Click to expand...
Click to collapse
Hi. how you install this kernel?
Add link
I didn't manage to get the full kernel to build because there was errors in the makefile last time in downloaded the source
out of more speculation than anything else I copied the makefile from the gen8 gpl source.
This didn't complete the build, it failed on ffmpeg but it did build kernel modules which is all I really needed for this.
I might have another go now that I understand a little more about the build process and makefiles.
Sent from my HTC Sensation XE with Beats Audio using xda premium
trevd said:
I didn't manage to get the full kernel to build because there was errors in the makefile last time in downloaded the source
out of more speculation than anything else I copied the makefile from the gen8 gpl source.
Click to expand...
Click to collapse
Current kernel sources are fine- compilation went without any problems. Included linux.config seems to be the recovery kernel config though (2.5 MB zImage, quite some modules built).
Compiled using crosstool-ng 1.9.3 on xubuntu 10.10 x86 (in VirtualBox)
hi, very interested in this, I have an Archos 80 G9 16GB Turbo and a Huawei USB 3G dongle as well. But I'm coming from windows mobile, just my first android device. Anyone willing to give some more info & instructions on how to get it working all together? Is it required to have a rooted device?
Maybe a little app can be created to automate the installation/usage of non archos USB 3G dongles?
CIAO!
VOODOOS!L
Hi Voodoos!l
Rooted Device is required. Apologies for the light instructions post 3 explains slightly more
It still may not be enough if your coming from a windows only environment!
I Assume at least some basic knowledge of:
Android Debug Bridge (ADB)
Composite Usb Devices (usb_modeswitch)
Android/Linux Kernel Modules (Installing insmod /lsmod etc)
Point to Point Protocol (How to start a connection)
I did write a quick and dirty app to do the mode-switching and then start the connection, I can give you the code if you want, it's nothing special, It just runs the commands from android using Superuser.
I've not had chance to work on this lately and I think a better route to go down is to hack the UsbKeyManager.apk which is what Archos use to turn on there own 3G Dongle. We should be able to modify it to accept any dongle. I had begun testing with HoneyComb but was waiting for ICS to appear before continuing.
i have archos 101 g9 can you have a video to do this?i have pen k3565 vodafone
@ trevd
i am very insteresting by a video or photos
and a todo for Dummys
Hi Guys.
I'll get the drivers compiled for ICS later on and see If I can get smoother solution for you folks to play with.
@jamespvz Is this the one you have http://3g-modem.wetpaint.com/page/Huawei+K3565+%28Vodafone%29? can you confirm that this is the one made by Huawei and not ZTE?
TIP: The Huawei one has the code K3565-H
Thanks
Trev
yes is that pen
Hi all.
I'm following this thread too because I need a 3g adapter but I found that the archos one is 7Mbps, while I'd like to have a 14Mbps one. Trevd, I hope that you will find the solution for me and the other archos fans!
If you suggest me a good adapter, I'll buy it and then help you with tests.
Thanks.
Bye
Hello
this work with ICS 4?
Regards, Robert
file is corrupt archos-ics-gsm.zip 554 byte ... resend please
h47e said:
file is corrupt archos-ics-gsm.zip 554 byte ... resend please
Click to expand...
Click to collapse
The file is not corrupt, i'ts correct 404 error html. But not zip, really.
# usb_modeswitch -s 6 -v 12d1 -p 1446 -V 12d1 -P 1436 -M 55534243123456780000000000000011062000000100000000000000000000
Looking for target devices ...
No devices in target mode or class found
Looking for default devices ...
No devices in default mode found. Nothing to do. Bye.
# ls -la /dev/tty*
crw-rw-rw- 1 root root 5, 0 Apr 21 18:04 /dev/tty
crw------- 1 root root 249, 0 Apr 21 18:04 /dev/ttyGS0
crw------- 1 root root 249, 1 Apr 21 18:04 /dev/ttyGS1
crw------- 1 root root 249, 2 Apr 21 18:04 /dev/ttyGS2
crw------- 1 root root 249, 3 Apr 21 18:04 /dev/ttyGS3
crw------- 1 root root 252, 0 Apr 21 18:04 /dev/ttyO0
crw------- 1 root root 252, 1 Apr 21 18:04 /dev/ttyO1
crw------- 1 root root 252, 2 Apr 21 18:04 /dev/ttyO2
#dmesg
[ 2338.794708] hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad?
[ 2338.795043] hub 1-0:1.0: unable to enumerate USB device on port 1
Bus 002 Device 013: ID 12d1:1446 Huawei Technologies Co., Ltd. E1552 (HSPA modem)
3g stick ON
** Update ****************
************************
Posted a .zip with scripts for both Windows and *nix users to automate the process.
Linux:
-----
Unzip the contents of the attached ICS404root.zip anywhere on your computer and run the script aptly named "runme_root_script.sh". It should take care of the rest. Make sure you have USB Debugging enabled and you put the phone in Camera mode, not mass storage device.
Windows:
---------
Unzip ICS404root.zip wherever you want and then run "rootscript.bat". Make sure you have USB Debugging enabled and you put the phone in Camera mode, not mass storage device.
*************************
*************************
Credit to miloj for finding this technique on the Transformer. (See the thread noted below and be sure to thank him!) I modified it to work on our devices.
http://forum.xda-developers.com/showthread.php?t=1704209
I'll put together a script to automate this process shortly, but if you're antsy like me, here's the lowdown:
1. Download the following files:
su: http://db.tt/ShPzea6I
debugfs: http://db.tt/bGFh43LZ
2. Save the two files downloaded above on /sdcard. (ie: mount your sdcard in windows and copy them over, or "adb push" them to /sdcard).
**Make sure you have your phone on Mount Camera mode, not as a mass storage device; otherwise, you won't be able to access your /sdcard directory via adb. **
3. In a linux terminal/Windows command prompt:
Code:
adb shell
[email protected]_maserati:/ $ cd /sdcard
[email protected]_maserati:/ $ cp su /data/local/12m/
[email protected]_maserati:/ $ cp debugfs /data/local/12m/
[email protected]_maserati:/ $ cd /data/local/12m
[email protected]_maserati:/ $ chmod 755 debugfs
[email protected]_maserati:/ $ chmod 755 su
[email protected]_maserati:/ $ mv batch batch.bak
[email protected]_maserati:/ $ ln -s /dev/block/mmcblk1p20 batch
[email protected]_maserati:/ $ exit
adb reboot
4. While you are waiting for the phone to reboot, type the following into your terminal/command window:
Code:
adb wait-for-device shell
5. Once you're back into the android shell:
Code:
[email protected]_maserati:/ $ cd /data/local/12m
[email protected]_maserati:/ $ rm batch
[email protected]_maserati:/ $ mv batch.bak batch
[email protected]_maserati:/ $ /data/local/12m/debugfs -w /dev/block/mmcblk1p20
(The following is entered at the "debugfs:" prompt)
debugfs: # cd xbin
debugfs: # write /data/local/12m/su su
debugfs: # set_inode_field su mode 0104755
debugfs: # set_inode_field su uid 0
debugfs: # set_inode_field su gid 0
debugfs: # quit
[email protected]_maserati:/ $ cd /data/local/12m
[email protected]_maserati:/ $ rm su
[email protected]_maserati:/ $ rm debugfs
[email protected]_maserati:/ $ exit
adb reboot
Done deal. Now you've got the "su" binary pushed to your /system partition and set with the proper permissions for execution. Download the Superuser app from the market and you're good to go. Make sure you update the su binary within the Superuser app as well to make sure you're up to date.
Awesome! Were you able to upgrade to the latest leak and not lose root? Btw, what carrier are you on? I figured out how to get tethering fully functional on rogers but the process requires root...
Sent from my XT894 running ICS
You bet. I had to fastboot the leaked .208 update over top of the .206 update yesterday because I messed up my /system partition; I had used the OTA Rootkeeper to keep root permissions when upgrading from .219 but had foolishly disabled it right before I bungled everything up.
So to sum it up, this method didn't require anything to be done before updating to the .208 leak; since it has nothing to do with the technical details of the kernel itself, I'm fairly certain it should work for the .200 or .206 leaks as well. Root permissions were obtained from a completely stock system.
I'm in Canada with Bell but it doesn't matter because I imported the phone from the US; Verizon is the only carrier that has this phone. At any rate, this method is pretty universal, it is preying on a vulnerability present in the stock init.rc file and I bet it would work on other phones such as the RAZR as well.
So we can confirm this is 100% working with Fastbooting back and moving to 208? If so I will probably jump on this immediately.
I am trying to do this method but I cant adb to detect my phone. Im on the .208 leak. Can anybody help?
Have you enabled USB Debugging in the Settings->Developer Options menu?
Rick#2 said:
Have you enabled USB Debugging in the Settings->Developer Options menu?
Click to expand...
Click to collapse
Yep.
Not able to reboot, trying manually...
Code:
debugfs: /data/local/12m/su: Permission denied
debugfs: su: File not found by ext2_lookup
debugfs: su: File not found by ext2_lookup
debugfs: su: File not found by ext2_lookup
Had to reboot manually twice. This is the only error message I received. Tried Superuser, but it stops.
I'm on .200 btw.
droidian1441 said:
Yep.
Click to expand...
Click to collapse
I'm having the same issue. I'm on the 208 leak. I start command prompt in windows then type "adb shell" and I get the "device not found" message. I enabled usb debugging and my phone is connected as mass storage.
Likewise, Reboot requires su access, manual only. When I go and run the write command in debugfs permission denied. Any ideas what would cause this? Based on the code shown in the first post, SU had been already acquired(# vs $), which makes me wonder here.
Die Bruine said:
Not able to reboot, trying manually...
Code:
debugfs: /data/local/12m/su: Permission denied
debugfs: su: File not found by ext2_lookup
debugfs: su: File not found by ext2_lookup
debugfs: su: File not found by ext2_lookup
Had to reboot manually twice. This is the only error message I received. Tried Superuser, but it stops.
I'm on .200 btw.
Click to expand...
Click to collapse
Looks like you're doing something wrong with the debugfs command; you don't want to enter /data/local/12m/su at that prompt.
Running su from any partition other than /system will lead to a permissions error, so you don't want to bother trying to execute it from the /data/local/12m location.
(The following is entered at the "debugfs:" prompt, ie: after executing /data/local/12m/debugfs -w /dev/block/mmcblk1p20; see step 5.)
Code:
debugfs: # cd xbin
debugfs: # write /data/local/12m/su su
debugfs: # set_inode_field su mode 0104755
debugfs: # set_inode_field su uid 0
debugfs: # set_inode_field su gid 0
debugfs: # quit
Grizzy3 said:
I'm having the same issue. I'm on the 208 leak. I start command prompt in windows then type "adb shell" and I get the "device not found" message. I enabled usb debugging and my phone is connected as mass storage.
Click to expand...
Click to collapse
Ive got the same situation over here. I can stick without root, just the fact that I would have it again would be just the single reason to do it. Lol.
Sent from my DROID4 using Tapatalk 2
Code:
debugfs 1.42 (29-Nov-2011)
debugfs: cd xbin
cd xbin
debugfs: write /data/local/12m/su su
write /data/local/12m/su su
/data/local/12m/su: Permission denied
Rick, that's what we're putting in. From the code you posted it shows that you had root access already. Do you have any other suggestions on this? Because that's the in and out I get.
---------- Post added at 04:57 AM ---------- Previous post was at 04:53 AM ----------
Problem resolved. Need to run the following code:
Code:
chmod 755 debugfs
chmod 755 su
Then continue with rooting.
gdeeble said:
From the code you posted it shows that you had root access already.
Click to expand...
Click to collapse
Not sure where you're making this assumption from. I just wrote the "#" symbol in there to signal where to start entering commands... though I suppose you're correct in pointing out that the "#" shows up on a root prompt. A smarter choice probably would have been "$".
Trust me, I'm not an idiot. I wouldn't have gone through the hassle of writing up the guide in the first post if it didn't work.
Didn't mean it that way, just looked like it already had root, which was what confused me. But thanks again for this. :-D
Tried it again. This time no errors and the phone rebooted. But now Superuser keeps on FC .
Reinstalled superuser, updated and busybox. Now rooted! Thnx.
BTW, you might wanna update the OP. Do not batch the commands under windows. I tried several times. I think there is something wrong with the timing. Manually entering all the commands in a shell works. But putting them in a batch will enter them too fast for ADB to handle (under Windows shell) I guess.
Die Bruine said:
BTW, you might wanna update the OP. Do not batch the commands under windows. I tried several times.
Click to expand...
Click to collapse
I don't know, it seemed to work fine for me with the script I made. Anyways, glad it worked out for you.
Now that we can re-root as well as (somewhat convolutedly) fastboot ourselves back on track, we're good to go.
droidian1441 said:
Ive got the same situation over here. I can stick without root, just the fact that I would have it again would be just the single reason to do it. Lol.
Sent from my DROID4 using Tapatalk 2
Click to expand...
Click to collapse
As stated in the guide, you need to be in camera mode not mass storage.
Sent from my DROID4 using XDA
I was trying to do it manually last night before the OP posted the batch file, and it was not working because I was in MTP instead of PTP. SO make sure you use PTP.
Put your phone in camera (PTP) mode for the USB connection and it should work fine. Also, after it completes, download Superuser from the market.
I ran Titanium Backup after everything and it told me it needed to fix my su binary permissions or something like that... I let it do its thing... Either way, IT WORKED!!!!!
I put it in camera mode and made sure usb debugging is enabled. Then I ran the script for windows. Still getting the device not found error throughout. Really don't know what's going on.
At first, I am not liable for any harm or damage that may happen to your device!
If you have su and didn't trigger knox, I CANNOT guarantee that running this script won't cause 0x1!
Requirements:
1) P905/viennalte/Qualcomm based model ONLY (won't work on Exynos devices. MIGHT work on other Qualcomm LTE deices from Note Pro and Tab Pro series or even S5 / Note 3 etc - feel free to repost but give credits AS THIS METHOD SEEMS TO BE COMPLETELY NEW! ) running 4.4.2 stock;
2) root access with SuperSU (using cf-root - credits to chainfire);
3) busybox installed (I do recommend this paid installer: https://play.google.com/store/apps/details?id=stericson.busybox.donate , MOST PROBABLY free version will be more than enough, too, but I haven't tested it as I have license...)
4) Android Terminal Emulator installed ( free at: https://play.google.com/store/apps/details?id=jackpal.androidterm )
Installation:
1) download file permissive_via_kmem.sh using below link and put it in the root of internal memory (so it will be placed in: /sdcard/permissive_via_kmem.sh)
2) run Android Terminal Emulator
3) at command line, type:
Code:
su -c /sdcard/permissive_via_kmem.sh
(give it an access if requested)
4) voila.
Alternative: if u have init.d support just put the file in /system/etc/init.d to make permissive on every boot
Additional info for advanced users:
1) samsung decided to compile kernels for newer 4.4.2 roms with a flag (a kernel variable) forcing selinux enforcing mode
2) as kernel itself cannot be modified after compiled, it was impossible to set permissive mode using shell or even by repacking kernel's ramdisk, at least on Qualcomm LTE devices
3) custom kernel can do the job, but samsung's sources are broken, at least for P905, and it refuses to boot at all...
4) however, there is a workaround...
5) we cannot change kernel binary to run with different flag out of the box BUT we can obtain it's placement (address) directly in kernel memory space on running kernel and write different value DIRECTLY into the memory, hacking the kernel to make it think that the flag was different
6) for this purpose i believe we have to disable restrictions to access kernel pointers (done via sysctl)...
7) ...then read the output of /proc/kallsyms which will provide a list of all kernel variables along with their addresses in kernel memory space...
8) ...filter out a boolean variable selinux_enforcing which is responsible for all the troubles...
9) ...and write raw 00 byte into the address where the variable value is stored, via /dev/kmem.
Download:
http://www12.zippyshare.com/v/89625246/file.html
Noob question
Could you explain to a newb what this does?
I've read this article on it and still can't fathom what benefits I'd have from changing it to permissive: http://www.androidpolice.com/2013/10/31/kitkat-feature-spotlight-selinux-defaults-to-enforcing-rather-than-permissive-other-new-security-features/
And thank you.
cavkic said:
Could you explain to a newb what this does?
I've read this article on it and still can't fathom what benefits I'd have from changing it to permissive: http://www.androidpolice.com/2013/10/31/kitkat-feature-spotlight-selinux-defaults-to-enforcing-rather-than-permissive-other-new-security-features/
And thank you.
Click to expand...
Click to collapse
Check this
Well, if i'd try to express it in a simple way, from the user's point of view permissive mode is equal to selinux turned off at all, except it is logging (and only logging...) all the warnings caused by security violations, which would result in an error in enforcing mode. Permissive mode let you avoid strict security policies defined by manufacturer (and NSA - yeah, the real spies - which is maintaining general selinux rules), but also gives the possibility of establishing possible issues which may appear after switching to "really secure" enforcing mode.
And if you are asking about the exact, disturbing (ofc if security is not your main priority...) effects of enforcing mode that may affect end-users, we may start from: troubles with write-access to some (mostly external, but i have personally fought with with an issue of non-writeable internal sdcard, too) medias (well, to be honest, I do hope that my discover will help in building 100% working custom recovery...), troubles with non-working system mods resulting from bad selinux file labels, troubles with wiping partitions (ie. wiping cache or even swapping modded system lib sometimes has to be followed by triggering restorecon command on that filesystem (restore selinux context), which is leading to ie. losing root access, which may be fixed by flashing supersu again, etc etc, non working apps (especially related to modifying sensitive system parameters or resources), unchangeable system properties, unreachable functionalities, blah blah blah.... This topic had been widely discussed on xda and over the internet.
On the contrary, if you like to use your device as-is and you're not interested in modding/tweaking it, you will probably not need this mod, as you will gain nothing - but lose a little bit of security... For heavy modders, although, it's a must-have.
Btw can anyone confirm if it's working? I assume that I was looking for solution for some time, made some other changes to the environment meanwhile, so I cannot be 100% sure that above script alone is absolutely enough (but in theory it should...), however, even if it is not, it's just a matter of 1-2 days to figure out what additional, previously-well-known steps, such as running "setenforce 0", may be required in addition.
And as a brief summary: YES, my selinux is now really Permissive, both when running getenforce command and in system settings!
Wysłane z mojego SM-P905 przy użyciu Tapatalka
After following all steps getenforce still returns enforcing and in system it also shows enforcing.
If I try running setenforce I get permission denied.
Ok, can you enter:
Code:
su
printf '\x00' | su -c dd of=/dev/kmem seek=$( printf '%d\n' '0x'`cat /proc/kallsyms | grep ".*\ selinux\_enforcing" | cut -f 1 -d " "` ) bs=1 count=1 conv=notrunc
into terminal and tell me what's the output and/or the enforcing state??
Wysłane z mojego SM-P905 przy użyciu Tapatalka
As requested
Output:
/dev/kmem cannot open for write: permission denied
getenforce still returns Enforcing
[email protected]:/ $ cd /dev
[email protected]:/dev $ ls *mem*
ashmem
kmem: Permission denied
mem: Permission denied
ramdump_audio-ocmem
ramdump_smem
smem_log
1|[email protected]:/dev $
Same result in # mode
RaSand said:
As requested
Output:
/dev/kmem cannot open for write: permission denied
getenforce still returns Enforcing
[email protected]:/ $ cd /dev
[email protected]:/dev $ ls *mem*
ashmem
kmem: Permission denied
mem: Permission denied
ramdump_audio-ocmem
ramdump_smem
smem_log
1|[email protected]:/dev $
Same result in # mode
Click to expand...
Click to collapse
I assume that you have ran the command as root (ie didnt forget about 'su' before the main command)...? Your logs show non-root mode, but ur saying about '#' mode at the end, guess you mean su... Assume that all we do here requires root shell first to be opened, and the output even if similiar, may vary in details between non-root and root mode, so don't forget to get privileges before running anything below...
If so, I guess default policy prevents writing to /dev/kmem in enforcing mode by setting its selinux context to a special one, dedicated only for /dev/kmem and /dev/mem.The working solution is to repack kernel (not same, but, indeed, a lot easier, than recompile - changes won't affect the kernel binary code, but it's ramdisk part, only) with modified policy defaults, which will treat /dev/kmem as a genuine device, not a "sensitive" one. I can provide the one repacked for my own purposes, however, befoure such an intrusion we may want to try other solutions I can think of (again, cannot test it as I ve added many different mods in many different places, I would need to go back to stock to test it, but I need my device 100% steady and configured for my job this week. Hope you'll help me in solving this out, it shouldnt take long...).
Notice: Again, ALL BELOW COMMANDS SHOULD BE RUN IN ROOT MODE. That means you shall enter "su" command alone before trying any of those steps, and the Terminal will switch to a root shell, which is confirmed by switching the last sign in the prompt from '$' to '#'.
Notice 2: if it is written - after some steps - to try switching to permissive mode again, it should be done by running the command from MY PREVIOUS POST only, as it is equal to longer version from the script, just closed within shorter one-liner command... the command should change the mode to permissive itself and no further steps are needed.
1) run following:
Code:
ls -lZ /dev/kmem >/sdcard/info.txt
and paste the exact output (which has been saved at /sdcard/info.txt) here so I can gather further info about issue. Dont make a test of the main script here as nothing has been changed. After that...
2) we can try to set different context (a default one for dev files) manually. Again, it might be impossible as of selinux policy, but worth trying. Enter as root:
Code:
busybox mount -o rw,remount /
chcon u:object_r:device:s0 /dev/kmem
if error, paste it here. If no error, test if permissive mode script is working.
3) we can try to modify selinux policy in temporary ramdisk file to prevent giving /dev/kmem a special context and then restore context of whole /dev to it's "defaults", however, those "defaults" would be our modified ones. Possible issues: not sure if the restoring default context will make use of modified policy or would it use only the policy loaded on-boot (and as the ramdisk is temporary, policy modifications will disappear too within reboot). After getting root, enter:
Code:
busybox mount -o rw,remount /
sed -i "s:^.*\/dev\/[k]*mem.*$::g" /file_contexts
setprop selinux.reload_policy 1
restorecon -R /dev >/dev/null 2>&1
after that - if no errors - check if the switching works.
4) if none of the above is working, guess we'll need to repack stock kernel with a ramdisk content modified in the same way as in step 3. When embedded in kernel, the changes to the policy rules will be seen every boot and they will affect /dev/kmem in a persistent manner. This will let you write to it for sure. I will provide a ready repacked boot.img, so we can avoid repacking at all. This however is not a very satisfying solution, as my goal was not only to achieve permissive mode, but to achieve it without any changes (even if they are much less disturbing than recompiling kernel from source) to boot partition. But hey, first check out on-the-fly solutions above, as they are much less intrusive to a device, coz won't require reflashing kernel/boot partition.
EDIT: remount command added to step 2, repeat if you had error with changing the context.
Thanks for your effort.
[email protected]:/ $ su
[email protected]:/ # ls -lZ /dev/kmem >/sdcard/info.txt
/dev/kmem: Permission denied
1|[email protected]:/ #
info.txt is empty
chcon: Could not label /dev/kmem with ubject_r:device:s0: Permission denied
2|[email protected]:/ #
waiting for code for 3)
same result in step 2 with added remount
---------- Post added at 04:55 PM ---------- Previous post was at 04:30 PM ----------
It swallowed all commands in 3) BUT re running the script didn't change anything. After please wait.... done it still says selinux is set to Enforcing. Sorry.
getenforce returns enforcing
setenforce to 0 or Permissive doesn't change a bit.
seems it has to be done the hard way
better luck next time
RaSand said:
[email protected]:/ $ su
[email protected]:/ # ls -lZ /dev/kmem >/sdcard/info.txt
/dev/kmem: Permission denied
1|[email protected]:/ #
info.txt is empty
chcon: Could not label /dev/kmem with ubject_r:device:s0: Permission denied
2|[email protected]:/ #
waiting for code for 3)
same result in step 2 with added remount
---------- Post added at 04:55 PM ---------- Previous post was at 04:30 PM ----------
It swallowed all commands in 3) BUT re running the script didn't change anything. After please wait.... done it still says selinux is set to Enforcing. Sorry.
getenforce returns enforcing
setenforce to 0 or Permissive doesn't change a bit.
seems it has to be done the hard way
better luck next time
Click to expand...
Click to collapse
Your errors are quite strange, as it seems that you don't even have permissions to check the simple content of a directory...
Try to run commands from step 1 - 3 again, but with slight modifications (below), so theyll run in separate, undoubtly-rooted shell... Test also with modded command (you can try it alone before in the very beginning...)
Also: please run 2 and 3 in reversed order, ie. first step 3 and if not working, without rebooting, run step 2...
Btw are you using SuperSu 1.99? If no - after trying all below options, upgrade SuperSu from the Play Store, run it to update the binaries, reboot. check commands again. If still the same, install update to /system using option from its menu (it will do some cleanup and ask to reboot, after that you have to run option again, this time it will perform installation, after which you have to reboot again - after boot run SuperSu and check if the option is greyed out, if yes, everything went fine) and check all steps once again...
Here we go.
Main command:
Code:
su -c printf '\x00' | dd of=/dev/kmem seek=$( printf '%d\n' '0x'`cat /proc/kallsyms | grep ".*\ selinux\_enforcing" | cut -f 1 -d " "` ) bs=1 count=1 conv=notrunc
Step 1 v2:
Code:
su -c ls -lZ /dev | grep kmem >/sdcard/info.txt
Step 2 v2 (formerly step 3 ):
Code:
su -c busybox mount -o rw,remount /
su -c sed -i "s:^.*\/dev\/[k]*mem.*$::g" /file_contexts
su -c setprop selinux.reload_policy 1
sleep 3
su -c restorecon -R /dev
Notice: I am not sure if setprop selinux.reload_policy 1 is enough to force sammy's android (which is a really giant b***ch to hack when compared to any other android...) to reload the policy, this may really work, but only if the policy is reloaded on-line using new defaults. Later I will look for that information...
Step 3 v2 (formerly step 2 - please run directly after step 2v2, without rebooting...):
Code:
su -c busybox mount -o rw,remount /
su -c chcon u:object_r:device:s0 /dev/kmem
Notice: step 3 - when ran fine - might now print some errors that it cant access some stuff in /dev - this is absolutely ok. But formerly I disabled the output at all (not to confuse you with some strange errors), but it resulted in lack of possibility to find out if the command ran AT ALL or if it escaped because of no permissions on the very beginning.
Before we go on here let's get a few things out of the way.
1) please advise where i should get supersu 1.99 from. I'm on 1.94 and in my country (GE) there is no newer version available in the play store.
2) first thing I usually do when I start the terminal is type "su"
3) I'm an old man. So please be patient
that said let's give it another try
---------- Post added at 06:42 PM ---------- Previous post was at 06:11 PM ----------
This is starting to test my temper. I guess I will put the steps into files and run them with gscript. Hang on. Might take some time
---------- Post added at 07:30 PM ---------- Previous post was at 06:42 PM ----------
Guess I had it for today. No changes whatsoever.
Here is what I did
installed supersu to /system. Option is greyed out now
made a new script for every box of code. Main and step 1 to 3
Made copies and added some echo lines so I could see if scripts work and/or finish correctly
executed scripts with gscript in the given order
No echo in step 1 to 3
ran original code
same result.
don't know what else to try.
sorry
RaSand said:
Before we go on here let's get a few things out of the way.
1) please advise where i should get supersu 1.99 from. I'm on 1.94 and in my country (GE) there is no newer version available in the play store.
2) first thing I usually do when I start the terminal is type "su"
3) I'm an old man. So please be patient
that said let's give it another try
---------- Post added at 06:42 PM ---------- Previous post was at 06:11 PM ----------
This is starting to test my temper. I guess I will put the steps into files and run them with gscript. Hang on. Might take some time
---------- Post added at 07:30 PM ---------- Previous post was at 06:42 PM ----------
Guess I had it for today. No changes whatsoever.
Here is what I did
installed supersu to /system. Option is greyed out now
made a new script for every box of code. Main and step 1 to 3
Made copies and added some echo lines so I could see if scripts work and/or finish correctly
executed scripts with gscript in the given order
No echo in step 1 to 3
ran original code
same result.
don't know what else to try.
sorry
Click to expand...
Click to collapse
Stay cool. I am a (quite) young man, but I have patience, too ;]
No output when running *something* as su = faulty su installation (maybe)...
Please download SuperSu 1.99 (flashable cwm version) from here: http://forum.xda-developers.com/showthread.php?t=1538053 and put it somewhere on internal sdcard
Download my "almost-working" TWRP recovery image: http://www53.zippyshare.com/v/30690424/file.html
Put it in internal mem so its path will be /sdcard/twrp2.img
Run terminal emulator (CAREFULLY WITH THE PARTITION NUMBERS!)
Code:
su
dd if=/dev/block/mmcblk0p15 of=/sdcard/recovery.backup.img
sleep 1
dd if=/sdcard/twrp2.img of=/dev/block/mmcblk0p15
sleep 1
sync
reboot recovery
In recovery, flash downloaded supersu zip. Reboot.***
Try commands again.
Maybe your busybox is bad? Can you tell me the output of command busybox written alone without further params?
***(btw the recovery may be useful, but it is not-fully-working, however, it is working AT ALL... be aware of issues:
- it cannot write backups to exfat external cards, vfat/fat32 only
- it may mess the selinux context, especially for cache partition after wipe. solution: from twrp run advanced -> console (or terminal? dont remember) and run
restorecon -R /cache
- if u ever have a bootloop after flashing a (even reliable...) zip, you should get back to twrp, click mount menu, mount everything, switch to advanced -> console and run:
restorecon -R /system
restorecon -R /data
restorecon -R /cache
selinux contex will be fixed BUT it will mess context for su binary, so in the end flash supersu again and reboot, everything will be ok.
If you want to revert, just do:
dd if=/sdcard/recovery.backup.img of=/dev/block/mmcblk0p15
).
And last but not least, kernel which I have promised (BUT if you use it, I will lose my only tester heheee):
http://www46.zippyshare.com/v/63874309/file.html
Please be aware that there are some other tweaks included (like unsecure adb, faster filesystem mount options but with higher risk of data loss, etc).
Put b4.img to /sdcard/b4.img
Run:
Code:
su
dd if=/dev/block/mmcblk0p14 of=/sdcard/boot.backup.img
sleep 1
dd if=/sdcard/b4.img of=/dev/block/mmcblk0p14
sleep 1
sync
reboot
You can revert to stock by dd if=/sdcard/boot.backup.img of=/dev/block/mmcblk0p14 (or by flashing full stock by odin). Would be glad if you can confirm that mode is permissive using this repacked kernel (HOPE IT WILL!!!!) and after some time you'll flash the backup back, to help me solving the case, as i suppose that there IS possibility of permissive without the kernel flash and I need a tester ;} It would be reeeeeeaaaaaaaally nice...
BE AWARE THAT:
- it's for note pro 12.2 LTE ONLY!!!! also called viennalte or SM-P905... It WON'T work on other devices and it may damage them (for example, coz of different mmcblk numbers...)
- messing the mmcblk0pxx number may cause an unrecoverable harm to your device (especially if you overwrite bootloader partitions or your efs partitions where unique imei is stored), it's 14 for kernel (boot) and 15 for recovery
- your knox WILL be tripped (if it hasnt been tripped yet... but it's not very probable )
- on the very first boot screen, a warning messages may appear in the left-top corner, about some warranty stuff. Ignore them, they'll disappear after reverting boot/recovery to stock.
Regards.
Just done flashing twrp and supersu(now 1.99)
i will not give up that easy, don't worry.
Just to be on the safe side i downloaded b4. Maybe you should remove it for the moment.
Looks like fun being the most important part of the team.lol.
btw. Knox was tripped about 2 hours after i got the device
busybox is v1.22.1 (2014-01-25 17:27:18)
---------- Post added at 10:05 PM ---------- Previous post was at 09:15 PM ----------
This it what happened after the last command in step 2 was executed
Could not label /dev/cpuctl with ubject_r:cpuctl_device:s0: Operation not supported on transport endpoint
Could not access /dev/kmem: Operation not supported on transport endpoint
Could not access /dev/mem: Operation not supported on transport endpoint
Could not label /dev/pts with ubject_r:device:s0: Permission [email protected]:/ #
After this I will reboot
127|[email protected]:/ # dd if=/sdcard/b4.img of=/dev/block/mmcblk0p14
18468+0 records in
18468+0 records out
9455616 bytes transferred in 2.044 secs (4626035 bytes/sec)
[email protected]:/ # sync
[email protected]:/ #
---------- Post added at 02:08 PM ---------- Previous post was at 02:00 PM ----------
One would expect to have a new kernel after the above, but guess what
[email protected]:/ $ su
[email protected]:/ # getenforce
Enforcing
[email protected]:/ # setenforce Permissive
127|[email protected]:/ # getenforce
Enforcing
[email protected]:/ #
and the kernel set the warranty bit for kernel change, but it didn't make it to block 14 as I still have the stock kernel
RaSand said:
After this I will reboot
127|[email protected]:/ # dd if=/sdcard/b4.img of=/dev/block/mmcblk0p14
18468+0 records in
18468+0 records out
9455616 bytes transferred in 2.044 secs (4626035 bytes/sec)
[email protected]:/ # sync
[email protected]:/ #
---------- Post added at 02:08 PM ---------- Previous post was at 02:00 PM ----------
One would expect to have a new kernel after the above, but guess what
[email protected]:/ $ su
[email protected]:/ # getenforce
Enforcing
[email protected]:/ # setenforce Permissive
127|[email protected]:/ # getenforce
Enforcing
[email protected]:/ #
and the kernel set the warranty bit for kernel change, but it didn't make it to block 14 as I still have the stock kernel
Click to expand...
Click to collapse
Your two posts above confirm that SU version was not the issue, as it is still preventing from modyfing anything related to kmem, sorry for effort, attough hope you'll at least enjoy included, almost-working twrp, as it seems to be only one capable of flashing zips and doing backups and restoring them on p905 floating around (if you use exfat card for everyday use, my recommendation is to use another one, ie. 8 gig, which are cheap as hell, format it to fat32 (in android it's recognized as vfat) and use it for exclusively for backup purposes, at least until someone establishes a better solution. It's not that bad after all plus it gives you real possibility of experimenting with the device without need to worry about configuring it again from the beginning if something fail. Btw please be aware if in any case, after restoring backup/flashing zip/clearing cache you'll receive a bootloop AND/OR after booting you/apps won't be able to write to any part of internal memory (like /sdcard or /cache), just get back to twrp, use console and run restorecon commands for all partitions AND -as restorecon will break su - reflash su. ALSO - if anytime TWRP on exit will prompt you with a proposition of rooting the device itself - don't do that, the only proper way of fixing su is reflashing it from the genuine zip (or with odin, but avoid that as cf-root includes older version). Uh, isn't it a offtopic? Sorry..
The kerne IS stock (as to the binary part) but with modified ramdisk (repacked) including changed policy of accessing /dev/kmem. If you have kernel warranty bit warning on boot, you have flashed it succesfully ( the message will disappear when you flash back FULLY-stock kernel back - also, i dunno why but it says "kernel is not enforcing" but it's not YET true! It will say the same even if I repack kernel without any changes, so it's quite misleading...), although kernel version/compilation number nor any extra features will not change in the system coz the kernel base is absolutely the same (and it has to stay the same until Samsung release sources that work, coz current one won't).
To really, really confirm that you have flashed my kernel and that the policy of writing to memory has been removed, please open /file_contexts file (it lies in the very root of the filesystem) in any text editor within Android, and look for lines with /dev/kmem or /dev/mem. They should be commented out by "#" in the beginning - or deleted at all (dont remember which one method I did use...). If so, you can be sure that you have flashed repacked kernel succesfully (and also that I have uploaded the proper one, with changed policy...).
If you have checked above, you may be sure that after every boot to Android, now, the new policy (without restrictions to /dev/kmem, which were commented out/deleted) will be loaded. I don't think that restorecon -R /dev will be no longer necessary after that, as the /dev directory is virtual and created on every boot, so its previous, restricted security labels are not preserved between reboots and they are assigned according to current policy, only - but you can run it to check if you see any errors for /dev/kmem (and you should NOT see them... there might be other, like for /dev/cpuctl etc, but it doesnt matter...).
After that, there should be no further doubts that you have unlocked /dev/kmem for writing!
On this step you still need to run the command from my post on top of the topic, this one:
Code:
su
printf '\x00' | su -c dd of=/dev/kmem seek=$( printf '%d\n' '0x'`cat /proc/kallsyms | grep ".*\ selinux\_enforcing" | cut -f 1 -d " "` ) bs=1 count=1 conv=notrunc
setenforcing alone WILL NOT WORK EVEN NOW, only the script above helps. I guess you avoided that after flashing kernel, coz of misleading boot warning...
Then check enforcing status. Now it really should work.
If we achieve a success, I'd rather release a fully-featured-repacked-kernel, with built-in kmem script, so it will be permissive from the very beginning (PLUS it will be in a good mood to close possibility of further writing to /kmem after that one single write, as it is really serious security hole, to be honest, to let anyone write to any part of memory directly..., and also include init.d support out-of-the-box as well).
Sorry for letting you wait that long. I was out in woods all day and did not even take the Tablett with me. Besides that there was no service whatsoever.
After running your script, wich for whatever reason I didn't do yesterday, I do have permissive selinux. As you suggested I play with it a couple of hours till bedtime and re flash stock after that to do more testing if you come up with new ideas and need a tester.
bee back in the morning, or maybe before I lay my tired head to rest.
congrats for the job you did till now.
edit:
Just checked file_contexts and the lines for kmem and mem are commented out. So for the moment I'm definitely on your kernel. Thanks again
RaSand said:
Sorry for letting you wait that long. I was out in woods all day and did not even take the Tablett with me. Besides that there was no service whatsoever.
After running your script, wich for whatever reason I didn't do yesterday, I do have permissive selinux. As you suggested I play with it a couple of hours till bedtime and re flash stock after that to do more testing if you come up with new ideas and need a tester.
bee back in the morning, or maybe before I lay my tired head to rest.
congrats for the job you did till now.
edit:
Just checked file_contexts and the lines for kmem and mem are commented out. So for the moment I'm definitely on your kernel. Thanks again
Click to expand...
Click to collapse
good, thank you for testing and hope enforcing linux won't bother you again ;] you're probably a second man on the planet who is running your machine in permissive
and don't worry about anything, it's not a race or something. i am most thankful that you found a time to run all the suggested stuff, and for patience.
please however note that leaving open /dev/kmem shall be considered as a serious security hole! it allows root app to write ANYTHING to ANY part of memory. Well, that's was an obligatory warning, however, I was never scared too much with security issues and until now nothing bad happened so..
Let's summarize:
- now I am sure that my script is working BUT only after giving it possibility of writing to memory via /dev/kmem
- writing to /dev/kmem is possible only after changing the security policy, which lies in kernel's ramdisk
- the final appropach shall also CLOSE the access to /dev/kmem just after changing the selinux mode for security reason
- the aim is to make a complete modification which will make use of only one area of the device ie. system OR kernel, not both, as it is too intrusive:
- find a way to reload policy when device is on-line, so writing to /dev/kmem will be possible (it's a preferred method, no need to flash anything and no need to watch ugly warranty message - but I doubt if it's possible - it would be an equally dangerous security issue, there is no practical difference between letting write to memory and between letting to open the possibility of write to memory and then letting write to memory ... or
- implement the memory write technique straight in the kernel's ramdisk.
I will be back with new stuff, soon.
Before you surprise us with new stuff, could please change the command to revert to stock kernel in post #12. Somebody might get into trouble by just running the command and put the kernel in the wrong block. And while you are at it. It should be if=/ not if-/ in the code field.
RaSand said:
Before you surprise us with new stuff, could please change the command to revert to stock kernel in post #12. Somebody might get into trouble by just running the command and put the kernel in the wrong block. And while you are at it. It should be if=/ not if-/ in the code field.
Click to expand...
Click to collapse
Thank you, changes made, no one should flash the wrong block device (although flashing boot to recovery - which is possible, as the boot partition size is 2meg smaller than recovery - shall result in nothing but... booting the device when entering recovery mode ;] - that's just fyi, of course, mistakes corrected...)
esgie said:
Thank you, changes made, no one should flash the wrong block device (although flashing boot to recovery - which is possible, as the boot partition size is 2meg smaller than recovery - shall result in nothing but... booting the device when entering recovery mode ;] - that's just fyi, of course, mistakes corrected...)
Click to expand...
Click to collapse
Esgie, is there any further developments with this script? I've given it a shot and even after running the script, SELinux remains in Enforcing mode.
I see that you have the modified kernel for SELinux in permissive mode, but I really like the approach of having this script rather than using a modified kernel, so I'm wondering if in your process of getting the kernel to work, there might be something you've discovered that would make this script work as well.
Thanks.