loader/loads kernel and device tree via pongoOSsyscfg/tool to extract configuration information from syscfg partition on deviceshx-touchd/touch screen support daemonhcdpack/tool to heuristically extract Bluetooth firmware from binaries
Kernel can be obtained from our fork of linux-stable:
https://github.com/corellium/linux-sandcastle
The Sandcastle Linux ramdisk is built using buildroot. Our customizations are here:
https://github.com/corellium/sandcastle-buildroot
You can generally install APK files with adb install foo.apk. However, the following
limitations apply:
- pure Java APKs will generally work if they don't need unsupported hardware,
- APKs containing only ARMv7 binaries (32-bit) will not work,
- APKs containing ARMv8 binaries (64-bit) will require a rebuild of those binaries.
Binary libraries need to be built for 16kB page size. First, try these options when the library is linked:
-z common-page-size=0x4000 -z max-page-size=0x4000
If the linker is wrapped with C compiler, most likely you'll need this:
-Wl,-z,common-page-size=0x4000 -Wl,-z,max-page-size=0x4000
To check if stuff went well, use readelf -l on the library:
-
if there's no RELRO segment, check that the LOAD segments with different attributes do not occupy the same 16kB page in any place (a good tip-off is 4000 in the ALIGN column on all of them),
-
if there is a RELRO segment, make sure that it either starts or ends on a 16kB boundary; sometimes compilers put RELRO at start of the RW segment (and RELRO should then end at a 16k boundary) and sometimes they put it at the end (and RELRO should then start at a 16k boundary).
Basically the idea is that files that are incorrectly built end up having executable, read-write and read-only data in the same 16k page.
If this doesn't help, check the source of the library for blatant uses of 4096, 0x1000 or 12 for PAGE_SIZE, kPageSize, PAGE_SHIFT, PAGE_BITS, etc. (comparatively rare, but Chromium is a good example).