-bcf crashes when compiling ndk project

[gnaixx]

when i add obfuscator-ollvm into android-ndk-r14d and set -bcf
Android.mdk:

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
#so名
LOCAL_MODULE := native
#编译文件
LOCAL_SRC_FILES := jni_export.cpp
#本地依赖包
LOCAL_LDLIBS := -llog -g
#llvm 配置
LOCAL_CFLAGS += -mllvm -sub -mllvm -fla -mllvm -bcf
#编译动态链接库
include $(BUILD_SHARED_LIBRARY)

crash info

→ ndk-build
[armeabi-v7a] Compile++ thumb: native <= jni_export.cpp
/var/folders/vr/nlnk4jrj0sz31n6pzdp1h23r0000gp/T/jni_export-0f8f67.s: Assembler messages:
/var/folders/vr/nlnk4jrj0sz31n6pzdp1h23r0000gp/T/jni_export-0f8f67.s:7827: Error: r13 not allowed here -- `sub.w sp,r0,#8'
/var/folders/vr/nlnk4jrj0sz31n6pzdp1h23r0000gp/T/jni_export-0f8f67.s:7876: Error: r13 not allowed here -- `sub.w sp,r0,#8'
clang++: error: assembler command failed with exit code 1 (use -v to see invocation)
make: *** [/Users/xiangqing/Documents/project/droid-ndk/example/src/main/obj/local/armeabi-v7a/objs/native/jni_export.o] Error 1

[elinesterov]

I see the same issue using bogus control flow option.

[strazzere]

This is specifically an issue with llvm / android-ndk when compiling with thumb mode. You'll either need to disable thumb compilation (annoying) or patch the llvm to not generate this type of instructions; it's not actually an obfuscator-llvm issue.

Potentially try upgrading your ndk as well, though I'm doubtful that will fix this issue. If I have extra time later I can try to find the patch I needed to create for llvm to specifically work around this issue.

[kaitian521]

met the same problem

[kaitian521]

I set LOCAL_ARM_MODE := arm in Android.mk and it has no effect

[LeoonZHANG]

met the same problem with -mllvm -bcf

[zeroleo12345]

maybe the version missmatch.

when using android-ndk-r13b and latest code of obfuscator-llvm, it occurred this Error: r13 not allowed here -- `sub.w sp,r0,#8',

when downgrade obfuscator-llvm version to the highlight version, it work!

PS: i don't know why the latest obfuscator-llvm source from github not contain the commit and the log in the screen shot, what happen in these 2 year...
when i git clone -b llvm-4.0 https://github.com/obfuscator-llvm/obfuscator.git
the oldest log in like this:

[xelzmm]

met the same problem with -mllvm -bcf

do you have va_start in your code?

[lxjump]

met the same problem with -mllvm -bcf

do you have va_start in your code?

I met the same problem, and va_start is used in my codes.

[xelzmm]

met the same problem with -mllvm -bcf

do you have va_start in your code?

I met the same problem, and va_start is used in my codes.

Quick Solution:

disable bcf on functions using va_start

Long Answer:

using va_start might create dynamic allocation in llvm, in another words, the stack would be allocated and recovered dynamically somewhere in the middle of the function, not only at the beginning and the end.

when a bcf obfuscation applied to a function with va_start， it will break the stack management lifecycle, stack allocation and recovery would be not balanced in the machine code, but in fact, the unbalanced code should never be executed at runtime as it's in a bogus block.

sub.w sp,r0,#8

the code is trying to grow up the stack in the middle of a function, it is not broken for llvm. llvm assembler can process such code elegantly, but NDK use GNU assembler by default (you can see the argument -fno-integrated-as in the verbosed cmdline), which does not support such behavior. so the build failed.

notice that it only happens in the armv7 arch. it's probably a compatibility issue of GNU assembler.
there are some other possibilities to produce dynamic allocation in llvm, so the issue should not tagged with va_start.

[mateuszkosciuk]

Hey guys, any updates in this case?

[NewMai]

armv5 arch

met the same problem with -mllvm -bcf

do you have va_start in your code?

I met the same problem, and va_start is used in my codes.

Quick Solution:

disable bcf on functions using va_start

Long Answer:

using va_start might create dynamic allocation in llvm, in another words, the stack would be allocated and recovered dynamically somewhere in the middle of the function, not only at the beginning and the end.

when a bcf obfuscation applied to a function with va_start， it will break the stack management lifecycle, stack allocation and recovery would be not balanced in the machine code, but in fact, the unbalanced code should never be executed at runtime as it's in a bogus block.

sub.w sp,r0,#8

the code is trying to grow up the stack in the middle of a function, it is not broken for llvm. llvm assembler can process such code elegantly, but NDK use GNU assembler by default (you can see the argument -fno-integrated-as in the verbosed cmdline), which does not support such behavior. so the build failed.

notice that it only happens in the armv7 arch. it's probably a compatibility issue of GNU assembler.
there are some other possibilities to produce dynamic allocation in llvm, so the issue should not tagged with va_start.

armv5 arch still has the same problem.

[NewMai]

If we can tell the NDK to use the llvm-as, it should be fine.

[NewMai]

Addition, if we compile our code in debug mode or with -O0 optimization level, it will not trigger this bug.