Android armeabi-v7a binaries, PTRACE, etc

[green-green-avk]

From #22:
Asked by @SilasMo:

Sorry for this newbie question. Is there a way of calling the host su binary from inside the container? Does sylinking it to the container work? I was trying to lldb on my phone but failed. I tried moving the lldb server binary to my phone, but in my little knowledge i think the binary was built from armhf not arm7-a(not sure if im lost).

---

Is there a way of calling the host su binary from inside the container?

How the error message looks like?

Does sylinking it to the container work?

I need some more time to understand the matter of this question.
I hope, I understand it right that it is about BROADCOM Endpoint Protection...
Please, confirm.

I was trying to lldb on my phone but failed.

It seems, PRoot is still unable to handle any other processes which use PTRACE including debuggers.

...i think the binary was built from armhf not arm7-a...

• https://developer.android.com/ndk/guides/abis
• https://stackoverflow.com/questions/19256461/android-ndk-eabi-how-to-make-ndk-know-to-use-hard-fp

Briefly

Android NDK armeabi-v7a ABI

• Thumb-2 and the VFP hardware floating point instructions.
• Passing floating point values via integer registers (-mfloat-abi=softfp).

armeabi-v7a Android device and a PRooted environment

As long as PRoot provides a chrooted environment (only the kernel is being shared between your sandbox and Android), you can do basically what you want: the only limitation is the device architecture and the kernel calls ABI.
(Floating point calculations are out of the Linux kernel scope.)

[SilasMo]

So its possible that the binary was compiled for a cpu with -mfloat-abi=hard support and not -mfloat-abi=softfp. So in this case if would have to compile the lldb server individuallly or maybe find the prebuilt one. I think i will have to resort to using gdb instead since the prebuilt one is available almost everywhere as long as it will accomplish the desired objective.

[green-green-avk]

But... You have root access, so you could use chroot. Isn't it? It resolves the problem with PTRACE.

Just to clarify: -mfloat-abi sets only ABI and technically only userspace ABI. As long as you DO NOT link to any Android own libraries, you are good. That is chroot for in your case.

Why not just install some armel or armhf distro (Debian for example) and give it a try?

It seems, your SM-T116: https://specdevice.com/showspec.php?id=537d-91bf-9285-894e5532a198 has both: VFP and NEON; so armhf should be perfectly Ok.
(You can always check the CPU features by cat /proc/cpuinfo as long as you have root access.)

[SilasMo]

So from what i understand, a proot environment shares the kernel with the host device and a chroot environment has its own kernel, processes and sockets? To me is seems like a chroot env is more of a totally different linux on top of a different host and if thats the case, is that possible to debug binaries on the host if both are like different machines?

But... You have root access, so you could use chroot. Isn't it? It resolves the problem with PTRACE.

Uhmmm i dont think my cheap tablet can deploy a chroot environment because it has limited resources. I noticed that when running radare in sid release of Debian, there were significant lags amd deploying a linux distro would destroy it in no time.

One more question, from what i have read chroot needs loop devices support to mount the linux images on them. Lets say your device does not support loop devices, is it possible to use proots approach of using rootfs diredtory not an image?

[green-green-avk]

So from what i understand, a proot environment shares the kernel with the host device and a chroot environment has its own kernel, processes and sockets?

No.

• chroot also uses the host's kernel: it's Linux native way to run a different environment on the same kernel. It requires root access.
• PRoot https://proot-me.github.io/ is a some kind of workaround for cases when root access is restricted. It intercepts calls via the PTRACE kernel facility which effectively prevents debuggers from work.

[green-green-avk]

One more question, from what i have read chroot needs loop devices support to mount the linux images on them. Lets say your device does not support loop devices, is it possible to use proots approach of using rootfs diredtory not an image?

Strange... Why not just put directory tree for chroot into some directory? What is the reason to use a separate filesystem?

[SilasMo]

It may be possible(maybe in a full normal linux distro). Im not sure if it works on android, i have never seen it before.