inject-hook-cflumen | Android library injection and function hooking

inject-hook-cflumen is a C++ library. inject-hook-cflumen has no bugs, it has no vulnerabilities and it has low support. However inject-hook-cflumen has a Non-SPDX License. You can download it from GitHub.

CF.lumen is an Android (root) app that changes the colors on your screen, its original purpose was primarily to save battery on AMOLED devices, provide a red-only night mode that didn't destroy your night vision, and to provide f.lux-like functionality on Android. It has existed in various forms since the Android 2.x days. In the 2.x days, Chainfire3D hijacked Android's entire GL rendering pipeline, by proxying the EGL and GL libraries. Some of its purposes were to run apps and games written with support only for specific GPUs to work on all the phones, and tweak shaders and select graphics settings. CF.lumen (CF3D Night Mode) was an add-on to that, tapping into CF3D's plug-in system. Chainfire3D never made it into the 4.x era, as apps and games stopped being GPU-specific and started supporting most (if not all) of the hardware out there. The most used graphics tweaks (forcing MSAA for example) also became options in Android's developer settings, and the need to tweak individual shaders almost disappeared as well. CF.lumen was released from its Chainfire3D dependency and re-implemented as a library LD_PRELOAD'd into SurfaceFlinger, which required modifications to /system. On 5.x and beyond, root itself moved away from modifying the /system partition, and apps soon followed wherever possible; CF.lumen was no exception. Since LD_PRELOAD could no longer easily be made to work, another solution had to be found. The answer was injecting the CF.lumen library into SufaceFlinger directly, and manually hooking the required (E)GL functions rather than letting the linker doing it for us (as was the case with LD_PRELOAD). evilsocket's ARM Inject provided the base code necessary to perform this hijack. I restructured the code to suit my needs, and added arm64, x86 and x86-64 support. Over time, linker structures were adjusted to reflect changes in Android, while maintaining compatibility with older versions. It took quite a bit of effort to get all that working semi-reliably. Android itself also gained functionality to apply color matrices to the rendered surfaces around this time, but the early implementations were not very efficient. Support for that functionality was named the compatibility driver, as though it was not the fastest, it was supported on all devices. The code released here was named the performance driver as it was significantly faster on many devices when it worked, though on some devices it just didn't.