KUNAI-static-analyzer icon indicating copy to clipboard operation
KUNAI-static-analyzer copied to clipboard

Segmentation fault creating basic blocks

Open Fare9 opened this issue 1 year ago • 1 comments

There's a segmentation fault creating the basic blocks for the method android.support.v4.os.ResultReceiver->writeToParcel(android.os.Parcel,int), probably some strange structure makes the program to crash. The next code represents the smali from the method:

void android.support.v4.os.ResultReceiver->writeToParcel(android.os.Parcel,int)
00000000  1d 00                   monitor-enter v0
00000002  54 02 df 00             iget-object v2, v0, Landroid/support/v4/os/ResultReceiver;->mReceiver Landroid/support/v4/os/IResultReceiver; (223)
00000006  39 02 09 00             if-nez v2, 9
0000000a  22 02 6c 01             new-instance v2, android.support.v4.os.ResultReceiver$MyResultReceiver (364)
0000000e  70 20 e1 07 02 00       invoke-direct {v2, v0}, void android.support.v4.os.ResultReceiver$MyResultReceiver-><init>(android.support.v4.os.ResultReceiver)
00000014  5b 02 df 00             iput-object v2, v0, Landroid/support/v4/os/ResultReceiver;->mReceiver Landroid/support/v4/os/IResultReceiver; (223)
00000018  54 02 df 00             iget-object v2, v0, Landroid/support/v4/os/ResultReceiver;->mReceiver Landroid/support/v4/os/IResultReceiver; (223)
0000001c  72 10 da 07 02 00       invoke-interface {v2}, android.os.IBinder android.support.v4.os.IResultReceiver->asBinder()
00000022  0c 02                   move-result-object v2
00000024  6e 20 40 07 21 00       invoke-virtual {v1, v2}, void android.os.Parcel->writeStrongBinder(android.os.IBinder)
0000002a  1e 00                   monitor-exit v0
0000002c  0e 00                   return-void
0000002e  0d 01                   move-exception v1
00000030  1e 00                   monitor-exit v0
00000032  27 01                   throw v1

Probably generation of basic blocks crashes due to the catch block that surrounds the whole function.

Fare9 avatar Sep 02 '23 11:09 Fare9

The problem comes from the throw instruction, this instruction is considered as a conditional jump, and when the function determine_next is called, it returns the by default next instruction (the fallthrough), but since the instruction is at the last address of the method, it returns an incorrect address. The current commit is a work around that makes the code not to break: https://github.com/Fare9/KUNAI-static-analyzer/commit/114c8556c199e056472e908814f3722f145bd774, maybe a more beautiful solution would be to remove throw from conditional jumps, since this instruction target is calculated through exceptions. If you have any comment @sunniAngela just comment here, and maybe we can do a better solution.

Fare9 avatar Sep 03 '23 18:09 Fare9