[Q]Java Shell Root Access (segmentation fault) - Android Q&A, Help & Troubleshooting

Hi Guys,
So i've been trying to flash modules from within the phone without having to boot into the recovery,
and i found that i can just extract the update-binary and execute it through shell and it will do the trick!!
however,
know im trying to do that through my app,
i successfully got root access using Chainfire's libsuperuser,
however, whenever i send the commands to run update-binary i get "segmentation fault(core dumped)" Error.
the command i using in both shell and from within the app is "./update-binary 3 stdout ./modules.zip".
P.S. this might be irrelevent but when ever i add a number before stdout (e.g 7stdout) i get segmentation fault during shell as well,
other than that, i can't find the problem
This is a logcat of the process through strace, if we have a linux debugger here
Code:
08-24 17:06:43.568 8703-9188/com.thunder.kernel.lighter D/libsuperuser: [libsuperuser][SU*] execve("./update-binary", ["./update-binary", "3", "recovery", "./KernelLighter.zip"], [/* 24 vars */]) = 0
08-24 17:06:43.573 8703-9188/com.thunder.kernel.lighter D/libsuperuser: [libsuperuser][SU*] gettid() = 9202
08-24 17:06:43.573 8703-9188/com.thunder.kernel.lighter D/libsuperuser: [libsuperuser][SU*] syscall_983045(0x39a10, 0x399d4, 0, 0x40, 0x399d4, 0xbea729c0, 0xd8ec, 0xf0005, 0, 0, 0, 0, 0, 0xbea72960, 0x28dcf, 0x8c9c, 0x60000010, 0x39a10, 0, 0, 0xc764, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = 0
08-24 17:06:43.588 8703-9188/com.thunder.kernel.lighter D/libsuperuser: [libsuperuser][SU*] mmap2(NULL, 131072, PROT_READ, MAP_SHARED, 8, 0) = 0x4007e000
08-24 17:06:43.588 8703-9188/com.thunder.kernel.lighter D/libsuperuser: [libsuperuser][SU*] open("/dev/urandom", O_RDONLY|O_LARGEFILE) = 4
08-24 17:06:43.588 8703-9188/com.thunder.kernel.lighter D/libsuperuser: [libsuperuser][SU*] read(4, "B\300>7", 4) = 4
08-24 17:06:43.593 8703-9188/com.thunder.kernel.lighter D/libsuperuser: [libsuperuser][SU*] close(4) = 0
08-24 17:06:43.598 8703-9188/com.thunder.kernel.lighter D/libsuperuser: [libsuperuser][SU*] mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40119000
08-24 17:06:43.598 8703-9188/com.thunder.kernel.lighter D/libsuperuser: [libsuperuser][SU*] mprotect(0x40119000, 4096, PROT_READ) = 0
08-24 17:06:43.603 8703-9188/com.thunder.kernel.lighter D/libsuperuser: [libsuperuser][SU*] fcntl64(0, F_GETFL) = 0 (flags O_RDONLY)
08-24 17:06:43.603 8703-9188/com.thunder.kernel.lighter D/libsuperuser: [libsuperuser][SU*] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
08-24 17:06:43.693 8703-9188/com.thunder.kernel.lighter D/libsuperuser: [libsuperuser][SU*] +++ killed by SIGSEGV (core dumped) +++
08-24 17:06:43.693 8703-9188/com.thunder.kernel.lighter D/libsuperuser: [libsuperuser][SU*] Process 9202 detached
08-24 17:06:53.368 8703-8756/com.thunder.kernel.lighter D/libsuperuser: [libsuperuser][SU%] END

---

08-24 17:06:43.603 8703-9188/com.thunder.kernel.lighter D/libsuperuser: [libsuperuser][SU*] fcntl64(0, F_GETFL) = 0 (flags O_RDONLY)
Click to expand...
Click to collapse
I think this line is the important one. I think fcntl stands for flag control, also there is something about read only. Hope this helps somehow, I am not an android expert, but I do know a few things about linux...

---

I've read some man pages. Combined with what I know from Android I suppose the following: When you execute the command in the shell, there is nothing between it and the kernel / memory. If you execute it from within the app, you have to bypass some securit system put around Android apps which is checking the permissions of the apps. The app itself will not be able to write to the memory, therefore the process is generating a SIGSEV signal, which just says the process trying to write is not allowed to write. Without this, executed from the shell directly, you are allowed as you already have full access
You get a segmentation fault (I suppose SIGSEV as well) when you write something before stdout, because stdout is specifying a system device; the standard output. When the system can't find this device, it is missing an address to write to, that's why you get the segmentation fault as well.
Hope this hellps, I am not entirely sure.

---

I figured it was due to stdout but is there a way around it?
Sent from my HTC One X

---

As I already said, I am not an Android expert. But what you have to try is: I don't know if this is possible, but try to start a new shell instance form within the app, gain root access and execute the command there rather than directly processing the command from the app. That's what I do in a Linux GUI when trying to run particular commands.
EDIT: Another question: What does the command update-binary do exactly? Does it need stdout as parameter definitely? Also, as stdout is a virtual system device, that's likely the cause why it won't work from within the app. Is there an Android access right for virtual system devices like stdout which you need to sepcify for the app?

---

dansou901 said:
As I already said, I am not an Android expert. But what you have to try is: I don't know if this is possible, but try to start a new shell instance form within the app, gain root access and execute the command there rather than directly processing the command from the app. That's what I do in a Linux GUI when trying to run particular commands.
EDIT: Another question: What does the command update-binary do exactly? Does it need stdout as parameter definitely? Also, as stdout is a virtual system device, that's likely the cause why it won't work from within the app. Is there an Android access right for virtual system devices like stdout which you need to sepcify for the app?
Click to expand...
Click to collapse
You might have missed it,
But I'm running the command as root,
Thus it would already be in a different shell, the su.
I thought it could be permission but root only needs root permission and I have that.
The update-binary is found in all flashable zips,
It's what process the update scripts and flashes the zip,
I'm trying for a recovery less flashing technic.
Also the stdout parameter can be anything and it will still cause the error,
But from within a shell it will also work with anything.
Sent from my HTC One X