Hello,
I have a device called RATEL CELL R1020 with OS android 8.0 oreo.
I tried some applications for rooting this smartphone like kingroot, kingoroot, etc but failed. This device can't unlock bootloader, so I see rooting with exploit in youtube like thomasking. Please anyone here help me to rooting my smartphone?
4.4.78perf+ kernel
this attachment is screenshot of the system
Thankyou
j4nn said:
@arifincaesar, do you have your phone's firmware in a downloadable form? Can you obtain linux kernel source code for your phone?
I could imagine adapting this (exploit source code here) for your phone, but the kernel binary that is running on the phone is a must pre-requisite. Obviously it would be only a temp root.
Click to expand...
Click to collapse
arifincaesar said:
there is no way to get firmware of this phone sir..
and there's no way to unlock bootloader..
i think the only way to backup firmware this device is exploit and getting root access without ubl..
there is just said 4.4.78-perf+
Click to expand...
Click to collapse
In my opinion, there is no exploit that would not need offsets within kernel image in advance.
Because of that you need a copy of kernel binary that is running on the phone.
Obviously it is not possible to back up kernel partition from the phone, so you would need the original fw (the same version that is running on the phone) and a way to extract the kernel from the fw package.
Without that you are out of luck, sorry...
Since there is linux kernel running on the phone (android uses linux kernel) you have legal options to request corresponding kernel source code, because linux kernel is distributed under gpl license.
But even if you obtained the kernel source, you would still need the binary, because most likely the new build from source would not be binary identical. The source code would just make it easy to decide which exploit could work, so it would make sense to adapt it for the kernel binary.
j4nn said:
In my opinion, there is no exploit that would not need offsets within kernel image in advance.
Because of that you need a copy of kernel binary that is running on the phone.
Obviously it is not possible to back up kernel partition from the phone, so you would need the original fw (the same version that is running on the phone) and a way to extract the kernel from the fw package.
Without that you are out of luck, sorry...
Since there is linux kernel running on the phone (android uses linux kernel) you have legal options to request corresponding kernel source code, because linux kernel is distributed under gpl license.
But even if you obtained the kernel source, you would still need the binary, because most likely the new build from source would not be binary identical. The source code would just make it easy to decide which exploit could work, so it would make sense to adapt it for the kernel binary.
Click to expand...
Click to collapse
is that bug when i had activated oem unlock in dev options but cannot unlock with fastboot mode?
j4nn said:
In my opinion, there is no exploit that would not need offsets within kernel image in advance.
Because of that you need a copy of kernel binary that is running on the phone.
Obviously it is not possible to back up kernel partition from the phone, so you would need the original fw (the same version that is running on the phone) and a way to extract the kernel from the fw package.
Without that you are out of luck, sorry...
Since there is linux kernel running on the phone (android uses linux kernel) you have legal options to request corresponding kernel source code, because linux kernel is distributed under gpl license.
But even if you obtained the kernel source, you would still need the binary, because most likely the new build from source would not be binary identical. The source code would just make it easy to decide which exploit could work, so it would make sense to adapt it for the kernel binary.
Click to expand...
Click to collapse
can you help me please?
arifincaesar said:
can you help me please?
Click to expand...
Click to collapse
Interesting. Getting kernel space R/W primitives is a nice first step.
But without kernel binary, that still may be difficult - with kernel 4.4.78 version, KASLR would be there for sure.
j4nn said:
Interesting. Getting kernel space R/W primitives is a nice first step.
But without kernel binary, that still may be difficult - with kernel 4.4.78 version, KASLR would be there for sure.
Click to expand...
Click to collapse
hehe i keep watching your work for exploit sir
if there something new exploit i'll try to my phone
thx before
@arifincaesar, try this please:
Code:
cd /data/local/tmp
echo -e '#!/system/bin/sh\ncase "$1" in\n*model) echo G8441 ;;*) echo 47.1.A.8.49 ;;esac' > getprop
chmod 755 getprop
PATH=`pwd`:$PATH ./bindershell
That should try the offsets defined for xz1c. It's a blind try, but let's see.
Please post the log in a text form (copy it via clipboard from the terminal), using the CODE tags in the message (can be used with the # icon in advanced post).
Code:
cd /data/local/tmp
echo -e '#!/system/bin/sh\ncase "$1" in\n*model) echo G8441 ;;*) echo 47.1.A.8.49 ;;esac' > getprop
chmod 755 getprop
PATH=`pwd`:$PATH ./bindershell
i can't believe, it work bro i swear :v
is that my phone rooted?
nope i think my phone is not rooted yet..
i check from root checker it say "sorry root access is not properly installed on this device."
@j4nn heres the output
bindershell - temp root shell for xperia XZ1c/XZ1/XZp using CVE-2019-2215
https://github.com/j4nn/renoshell/tree/CVE-2019-2215
MAIN: starting exploit for devices with waitqueue at 0x98
PARENT: Reading leaked data
PARENT: leaking successful
MAIN: thread_info should be in stack
MAIN: parsing kernel stack to find thread_info
PARENT: Reading leaked data
PARENT: Reading extra leaked data
PARENT: leaking successful
MAIN: task_struct_ptr = ffffffcfe0d68000
MAIN: thread_info_ptr = ffffffd04aa3c000
MAIN: Clobbering addr_limit
MAIN: should have stable kernel R/W now
kernel slide invalid (0x4ffabc7b50)
kaslr slide 0x0
selinux set to permissive
current task credentials patched
got root, start shell...
Cell:/data/local/tmp # id
uid=0(root) gid=0(root) groups=0(root),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc) context=u:r:shell:s0
Cell:/data/local/tmp # cd
Cell:/ # ls
ls: ./cache: Permission denied
ls: ./init: Permission denied
ls: ./init.environ.rc: Permission denied
ls: ./init.rc: Permission denied
ls: ./init.recovery.qcom.rc: Permission denied
ls: ./init.usb.configfs.rc: Permission denied
ls: ./init.usb.rc: Permission denied
ls: ./init.zygote32.rc: Permission denied
ls: ./init.zygote64_32.rc: Permission denied
ls: ./postinstall: Permission denied
ls: ./ueventd.rc: Permission denied
ls: ./verity_key: Permission denied
acct bt_firmware bugreports charger config d data default.prop dev dsp etc firmware lost+found mnt oem persist proc res root sbin sdcard storage sys system vendor
1|Cell:/ #
@arifincaesar, well, as expected, detecting KASLR slide failed, therefore selinux could not be disabled and security context has not been patched either.
Without a kernel binary, it is difficult to implement a full temp root exploit.
I guess it could be doable, unfortunately I do not have the time for it.
j4nn said:
@arifincaesar, well, as expected, detecting KASLR slide failed, therefore selinux could not be disabled and security context has not been patched either.
Without a kernel binary, it is difficult to implement a full temp root exploit.
I guess it could be doable, unfortunately I do not have the time for it.
Click to expand...
Click to collapse
hehe thanks for information sir..
@arifincaesar, see PM please...
j4nn said:
@arifincaesar, see PM please...
Click to expand...
Click to collapse
ok sir, thank you very much for helping me.. T_T
pm sent
cve-2019-2215 based temp root exploit for ratel cell r1020
Here is a temp root exploit tailored specifically for RATEL CELL r1020 phone as described in the OP (Android 8.0 with security patch level of January 5, 2018). The exploit uses CVE-2019-2215, which can get you a temporal root shell very quickly and reliably (it's nearly instant).
Unfortunately RATEL CELL r1020 firmware is not publicly available, so it had not been possible to get a kernel image for analysis.
Luckily the first stage of the exploit designed for sony xperia xz1/xz1/xz1c worked, providing kernel space R/W primitives.
Eventually kernel memory dump has been retrieved (after KASLR bypass done in a generic way), so implementation of the final stage to bypass selinux and patch credentials to get root could be done.
Please find the result of my work attached here, it obviously is not tested as I do not have that phone, but I assume it would work as using similarly calculated stuff worked with my xz1c phone.
Please see the xperia phones exploit here for usage howto, including possibility to setup magisk from the exploit (modified script without sony specific stuff is already included). Just download the Magisk-v19.3-Manager-v7.1.2.zip from the linked post and use together with stuff from ratel-cell-temp-root.zip attached here.
EDIT: Updated ratel cell temp root with v2, supposed to work also with ratel cell having May 1, 2018 security patch level.
Please post the log (in [ CODE ] tags) and/or screenshots from your testing, possibly including even magisk setup, if bindershell exploit worked.
If you like my work, you can donate to me via paypal (including card payment) or bitcoin - for details just follow the "Donate to Me" button please. Thank you.
Thread closed per OP request.
MOD ACTION:
Thread reopened per OP's request
j4nn said:
Here is a temp root exploit tailored specifically for RATEL CELL r1020 phone as described in the OP (Android 8.0 with security patch level of January 5, 2018). The exploit uses CVE-2019-2215, which can get you a temporal root shell very quickly and reliably (it's nearly instant).
Unfortunately RATEL CELL r1020 firmware is not publicly available, so it had not been possible to get a kernel image for analysis.
Luckily the first stage of the exploit designed for sony xperia xz1/xz1/xz1c worked, providing kernel space R/W primitives.
Eventually kernel memory dump has been retrieved (after KASLR bypass done in a generic way), so implementation of the final stage to bypass selinux and patch credentials to get root could be done.
Please find the result of my work attached here, it obviously is not tested as I do not have that phone, but I assume it would work as using similarly calculated stuff worked with my xz1c phone.
Please see the xperia phones exploit here for usage howto, including possibility to setup magisk from the exploit (modified script without sony specific stuff is already included). Just download the Magisk-v19.3-Manager-v7.1.2.zip from the linked post and use together with stuff from ratel-cell-temp-root.zip attached here.
Please post the log (in [ CODE ] tags) and/or screenshots from your testing, possibly including even magisk setup, if bindershell exploit worked.
Click to expand...
Click to collapse
yes, it work sir thank you so much here is the log
but i think there other problem i will posting it later here
Code:
Cell:/data/local/tmp $ ./bindershellnew
bindershell - temp root shell using CVE-2019-2215, tailored for RATEL CELL R1020
https://github.com/j4nn/renoshell/tree/CVE-2019-2215
MAIN: starting exploit for devices with waitqueue at 0x98
PARENT: Reading leaked data
PARENT: leaking successful
MAIN: thread_info should be in stack
MAIN: parsing kernel stack to find thread_info
PARENT: Reading leaked data
PARENT: Reading extra leaked data
PARENT: leaking successful
MAIN: task_struct_ptr = ffffffd4316e9b00
MAIN: thread_info_ptr = ffffffd471268000
MAIN: Clobbering addr_limit
MAIN: should have stable kernel R/W now
attempting kaslr bypass: leaked ptr 0xffffff8a82608658
kernel base=0xffffff8a81480000 slide=0xa79400000
selinux set to permissive
current task credentials patched
got root, start shell...
Cell:/data/local/tmp # getenforce
Permissive
Cell:/data/local/tmp # id
uid=0(root) gid=0(root) groups=0(root),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc) context=u:r:toolbox:s0
Cell:/data/local/tmp # uname -a
Linux localhost 4.4.78-perf+ #1 SMP PREEMPT Tue Mar 6 11:00:11 CST 2018 aarch64
Cell:/data/local/tmp #
Hi there sir @j4nn .
I'm yusuv, ratel cell user. I've been following this thread.
And lately seems the exploit works as intended.
The things is, ratel cell not only have the January patch on all the devices. I've tried the exploit and its stuck on the build number prop and it won't go any further.
Afaik, ratel have 2 ROM builds, one patch is January which is you build the exploit for, the other one is May 1, 2018 patch. With also different build number.
On behalf Ratel Cell user with the may patch. I'm here to ask you, is there any way for us with the May patch being able to root our device?
Thanks in advance.
Dear sir @j4nn.
can you help us on how to install custom recovery in Ratel Cell, if you are willing to help, we will be very grateful.
Related
I'm working on a project that requires an android port of the USB/IP project. I managed to build the required modules for the phone kernel (using the NDK) and build the user space application (using crosstool-ng for glibc requirements) but I cannot find any information on the net how to set the correct permissions for the usbip userland application. When I execute the usbip binary I get "sh: usbip: permission denied" although I'm logged in on the phone as root (su) and the permissions are correct.
Any help will be appreciated.
Hi,
I try to have my own insecure boot.img for my Galaxy S3 (GT-I9300) on Jelly Bean.
I have repack boot.img with ro.secure=0 and ro.debuggable=1, but it doesn't work on JB (it works on ICS).
Do you know why it doesn't work ? Have you a solution ?
PS : I wouldn't use Insecure Adbd by Chainfire, even if he has worked fine and I love his work.
Best regards,
adbd binaries from release builds of JB ignore the ro.secure setting. You can unpack the initrd of the Perseus kernel to use the JB adbd binary I built that doesn't drop root privileges, or extract adbd.png from adbd Insecure and use that binary in your initrd.
Sent from my GT-I9300 using Tapatalk 2
qwerty12 said:
adbd binaries from release builds of JB ignore the ro.secure setting. You can unpack the initrd of the Perseus kernel to use the JB adbd binary I built that doesn't drop root privileges, or extract adbd.png from adbd Insecure and use that binary in your initrd.
Sent from my GT-I9300 using Tapatalk 2
Click to expand...
Click to collapse
First, thanks you for you reply.
If I understand, two solutions :
1 - Use adbd binary built by you (but I don't understand : that doesn't drop root privileges -> That means our own read ro.secure value ?)
2 - Use adbd.png (not an image file ?) to replace the original one
It's right ?
If I understand, two solutions :
1 - Use adbd binary built by you (but I don't understand : that doesn't drop root privileges -> That means our own read ro.secure value ?)
Click to expand...
Click to collapse
adbd is started as root by init; however, it will usually switch user to the "shell" account, which is, well, not as powerful as root. I'm sure you see it when you run "adb shell" currently
If you look at adb.c, line 899 you'll see that if ALLOW_ADBD_ROOT is not defined then adbd will not even look at the ro.secure property to determine whether it should then drop its root privileges; it will always do so (the function always returns 1).
ALLOW_ADBD_ROOT is only defined when the build target is set to a debug one, not a release one. With ALLOW_ADBD_ROOT defined, only then adbd, through the now more "complete" should_drop_privileges function, will look at the ro.secure property to determine whether it should drop its privileges.
Instead of changing Android.mk to always define ALLOW_ADBD_ROOT, I changed "return 1" into "return 0" because I don't want to change the ro.secure property, but I don't want adbd to drop privileges. I don't know if it does it now, but the SysScope service on Samsung phones that checks for root may also look at the ro.secure property and I don't want to give it another reason to mark my device as Modified.
2 - Use adbd.png (not an image file ?) to replace the original one
It's right ?
Click to expand...
Click to collapse
adbd.png is the adbd binary in Chainfire's adbd Insecure apk. It has the .png extension so that some tool in the SDK won't attempt to compress it. It also doesn't drop privileges and is JB compatible. Just offering it as an alternative
Best regards
You are so helpful for me with your explanations about adb.c.
I'm so stupid, I haven't look the source code. Shame on me, I use and build apps for GNU/Linux for over 10 years and I don't look that.
Thanks man !
There's a lot of nifty tools that will automatically root my phone with pre-packaged system images (CF-Auto-Root et al). However, I'd prefer not to load my phone with firmwares from internet strangers. Also, I try to avoid apps whose code I can't see (e.g. SuperSu).
What I'd like to do is take the system preloaded on my Galaxy Note 4 by Samsung (or the recovery image) and modify it manually so that I have root access. As I understand it, this should be a fairly reproducible process. (Chainfire wrote somewhere that he has a script that automatically generates rooted images from vendor images as new versions are released.)
Please, help me do it manually. Assume I have some general Linux knowledge (your typical Ubuntu user), but no Android development skills.
bump
bump
You can't. You will have to use one of the SU binaries and SU packages. Other then that you will have to find an exploit in the base system and then code a whole new binary and app.
Yes he has a script, but that is only after years of working on the exploit for root.
Axure said:
There's a lot of nifty tools that will automatically root my phone with pre-packaged system images (CF-Auto-Root et al). However, I'd prefer not to load my phone with firmwares from internet strangers. Also, I try to avoid apps whose code I can't see (e.g. SuperSu).
What I'd like to do is take the system preloaded on my Galaxy Note 4 by Samsung (or the recovery image) and modify it manually so that I have root access. As I understand it, this should be a fairly reproducible process. (Chainfire wrote somewhere that he has a script that automatically generates rooted images from vendor images as new versions are released.)
Please, help me do it manually. Assume I have some general Linux knowledge (your typical Ubuntu user), but no Android development skills.
Click to expand...
Click to collapse
1º Download source code or unpack boot.img with unpackbootimg tool,
2º then unpack the ramdisk,
3º edit default.prop
Code:
ro.secure=0
ro.debuggable=1
persist.service.adb.enable=1
4º $ cd ramdisk
5º $ find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
6º mkbootimg with the proper settings
7º ???
8º profit
What is Kexec?
"Kexec", which is short for 'Kernel Execution' is derived from the Linux Kernel call "exec". It allows the "live" booting of a new kernel "over" the currently booted kernel without taking the device down for a reboot. This is extremely useful on locked bootloader devices, as a user with root authentication can boot a custom kernel without rebooting, and undergoing the security checks enforced by the bootloader. On unlocked devices, it can be used to "multi-boot" kernels on a device without requiring the kernels to be installed to the /boot partition.
Whilst Kexec is extremely useful, it also can be extremely hard to implement, as it needs to take all devices down, and bring them back up along with the new kernel, this can lead to some serious bugs, like devices not working after soft-boot, kernel corruption, device hangs, etc. This make it very device specific, and hard to get fully working, as it requires retrieving kernel crash logs, (often) UART serial output, and a ton of debugging.
What about this whole "Hardboot" thing?
The solution to this was written (initially) by Mike Kassick, who had the idea to "Hardboot" a kernel. Which is when a kernel is loaded into memory, a flag is set, the device is taken down for a full reboot, then the flag is read out by the primary kernel very early in the boot sequence, at which point, the "primary" kernel directly loads the new "secondary" kernel/ramdisk/passes arguements/etc.
This is much easier to implement than the normal Kexec SysCall, as it jumps to the new kernel before most devices are initiated, and in doing this, we allow the secondary kernel to initialize all the devices on its own, and not have to worry about taking them down.
Many people unknowingly make use of Kexec in the form of MultiROM, so, today, I thought I would do a write up on how to use it in practice.
Necessary Components:
* Boot.img (alternatively, the zImage-dtb/ramdisk you want to use)
* Unmkbootimg
* Kexec Binary (can be found in your specific devices MultiROM zip)
* Kexec Hardboot enabled Kernel installed (most custom kernels have it)
* Root Access
Downloads:
All the Binaries I've cross compiled/found can be downloaded here: https://www.dropbox.com/sh/7g5jcofv8j2gwg9/AAA-2b-wLiHq2z0nCMIHSHooa?dl=0
All the Linux Binaries you'll want/need are here: https://www.dropbox.com/sh/qcho8bhaoi8cdkc/AACGvmIQlb_3I9OQtNMqIQwva?dl=0
If you use Windows/Mac, just find the binaries equivalents for your platform.
How to use it?
1. Take the aforementioned Kexec Binary, and place it in /system/bin using ADB or A File Explorer, granting it permissions drwxdr-xdr-x (or chmod 0755 it)
2. Over on your desktop, make sure you have Unmkbootimg in an Executable location, and that you've blessed them as executable (chmod 0755 filename). Then run
Code:
unmkbootimg /path/to/your/boot.img
This will dump a zImage (rename it to zImage-dtb now, for semantics sake), and a ramdisk, labeled initramfs.cpio.gz (Initial RAM File System, in the form of a cpio.gz archive).
Now, put the kernel and ramdisk in a folder on your SD Card via MTP/ADB Push, I called mine "kexecstuffs".
3. Now open a mobile terminal, or an ADB Shell, and run
Code:
su
cd /sdcard/PathToYourFolder/
kexec --load-hardboot zImage-dtb –initrd=initramfs.cpio.gz --mem-min=0x20000000 --command-line="$(cat /proc/cmdline)" --boardname=shamu –dtb
Now, lets dissect the different arguments we are passing to Kexec:
--load-hardboot = Tells Kexec to make use of the Kexec Hardboot kernel function, and take the device down for a full reboot as opposed to soft-booting, like that used in the standard Kexec Linux SysCall
zImage-dtb = Name of your kernel file
--initrd = Points to the ramdisk to be used when booting the new kernel, if not set, the current ramdisk in the /boot partition. Most archive types are supported.
--mem-min = A reasonable value in memory where the kernel is loaded, serves as space for Kexec to do its work
--command-line = What arguments are passed to the new kernel, using "$(cat /proc/cmdline)" allows you to pass the currently booted kernel's arguments to the new kernel, which is what we want in the case of Shamu
--dtb = Defines that the board makes use of an Appended Device Tree, can be passed without a value (which will rely on Tasssdar's “boardname” value), or can have a compressed DTB image as its value
--boardname = Tasssdar's way to handle different DTB styles, we just need to pass “shamu” to it, and it'll use our DTB style
Now that we have successfully loaded the kernel into memory, lets execute it!
4. In that same Mobile Terminal/ADB Shell, run:
Code:
kexec -e
Although this guide is for the Nexus 6 (shamu), it should work all devices supported bu MultiROM, or on any device with a kernel that supports Kexec/Kexec Hardboot.
I hope this helped you to better understand what Kexec is/how to use it.
Hello everybody !
I'm a noob on Android and I have a strange problem. I rooted my Wiko Pulp Fab (Lollipop 5.1) with KingRoot (after so many tries with other solutions) and now when I get root internet seems doesn't work.
I intend to use Linux Deploy and it can't download distribs (I tried use domain names and IPs, no difference)
And when I connect to my phone's shell with adb I have the same problem.
Normal user in shell, connection work:
Code:
[email protected]:/ $ ping wikipedia.fr
PING wikipedia.fr (78.109.84.114) 56(84) bytes of data.
64 bytes from wikimedia2.typhon.net (78.109.84.114): icmp_seq=1 ttl=56 time=17.9 ms
64 bytes from wikimedia2.typhon.net (78.109.84.114): icmp_seq=2 ttl=56 time=29.8 ms
64 bytes from wikimedia2.typhon.net (78.109.84.114): icmp_seq=3 ttl=56 time=30.1 ms
64 bytes from wikimedia2.typhon.net (78.109.84.114): icmp_seq=4 ttl=56 time=30.0 ms
64 bytes from wikimedia2.typhon.net (78.109.84.114): icmp_seq=5 ttl=56 time=29.1 ms
...
Root in shell, connection doesn't work:
Code:
[email protected]:/ # ping wikipedia.fr
connect: Bad file number
2|[email protected]:/ # ping 78.109.84.114
connect: Bad file number
I tried ping and other binaries, it doesn't work.
What's wrong ? I heard that is a C message error about socket usage, but how can I fix it ?
Maybe it is a problem with KingRoot ? I tried many many solutions to root my phone but nothing work. I tried to install "su" myself with adb or fastboot but it doesn't work (I don't know very much Android yet, I'd just beginning learn few days ago).
Many thanks for your help !
EDIT
I found a solution so I publish it here, maybe it can help !
If this error appear, it is probably beacause SELinux is in enforce mode. SELinux is a security module who restrict users.
To display refused operations:
Code:
# dmesg | grep -i denied
To activate SELinux permissive mode:
Code:
# setenforce 0
That's all !
The issue is that with LP root now needs a kernel change to make root work properly. King root is a joke and should never be used
zelendel said:
The issue is that with LP root now needs a kernel change to make root work properly. King root is a joke and should never be used
Click to expand...
Click to collapse
OK so what can i do ? Where can I found doc about kernel change ?
remipassmoilesel said:
OK so what can i do ? Where can I found doc about kernel change ?
Click to expand...
Click to collapse
The ingest issue is that this OEM doesn't comply with gpl laws so you may not even be able to find the source code for the kernel. Let alone having an unlocked bootloader to flash the kernel.
I'll be honest. With these small companies your best bet is just use the phone as it comes.
In fact I have downloaded the whole source code, available online. I tried to build it once but finally I'm not sure of what can I do with that.
Do you think I can build my own /system image with a su binary or that will be not enought ?
remipassmoilesel said:
In fact I have downloaded the whole source code, available online. I tried to build it once but finally I'm not sure of what can I do with that.
Do you think I can build my own /system image with a su binary or that will be not enought ?
Click to expand...
Click to collapse
You found the kernel source code? You do know that the kernel source and android source are different. Also you will need to have an unlocked bootloader to even flash it.
zelendel said:
You found the kernel source code? You do know that the kernel source and android source are different. Also you will need to have an unlocked bootloader to even flash it.
Click to expand...
Click to collapse
I think I have both, kernel and android: http://www.wikogeek.com
So what can I do ?
1) Build all and obtain the 3 img files (boot.img, ....),
2) Mount the img files and insert su binary and others custom files,
3) Push the img files to the phone with fastboot
Is that correct ?
I have one question more. With Fastboot, can I push just some files or I can just overwirte the whole partition ?
Thanks for your help.
I found a solution so I publish it here, maybe it can help !
If this error appear, it is probably beacause SELinux is in enforce mode. SELinux is a security module who restrict users.
To display refused operations:
Code:
# dmesg | grep -i denied
To activate SELinux permissive mode:
Code:
# setenforce 0
That's all !