Skip to content

Instantly share code, notes, and snippets.


Daniel Micay thestinger

View GitHub Profile

Bionic CTS status for GrapheneOS

failures caused by broken tests uncovered by hardened_malloc that are skipped with hwasan:

  • malloc#memalign_multiple: hardened_malloc returns an error on non-power-of-two to catch bugs
  • malloc#memalign_non_power2: hardened_malloc returns an error on non-power-of-two to catch bugs
  • malloc#mallopt_decay: hardened_malloc doesn't support this and returns an error
  • malloc_iterate#invalid_pointers: debugging feature not supported by hardened_malloc
  • malloc_iterate#large_allocs: debugging feature not supported by hardened_malloc
  • malloc_iterate#small_allocs: debugging feature not supported by hardened_malloc
View pdf.js 2.2.228 dependencies
│ /home/strcat/projects/grapheneos/pdf.js
│ [PDF.js]( is a Portable Document Format (PDF) viewer that is built with HTML5.
│ git://
├─┬ @babel/core@7.4.5
│ │ Babel compiler core.
│ │
│ │
│ ├─┬ @babel/code-frame@7.0.0
View wxtest.c
#include <stdio.h>
#include <string.h>
#include <fcntl.h>
#include <sys/mman.h>
#include <unistd.h>
// Alternatively, /dev/shm/test, /var/tmp/test, /home/username/test, /home/.local/share/appname/test, etc.
static const char *const path = "/tmp/test";
static const char code[] = "\xeb\x1e\x5e\x48\x31\xc0\xb0\x01\x48\x89\xc7\x48\x89\xfa\x48\x83\xc2\x0e\x0f\x05\x48\x31\xc0\x48\x83\xc0\x3c\x48\x31\xff\x0f\x05\xe8\xdd\xff\xff\xff\x48\x65\x6c\x6c\x6f\x2c\x20\x77\x6f\x72\x6c\x64\x21\x0a";

Please read through again but also check out the upstream documentation on key attestation and the Auditor protocol documentation linked from that page while going through it. There's likely already be information there that's useful to you. I avoided trying to explain everything myself rather than delegating to existing documentation elsewhere like my protocol documentation in the app which shows the binary-level format of the attestation challenge and response.

Forgive me if this seems trivial to the security researchers out there, but I'm having a hard time wrapping my head around what having Remote Attestation actually does for the user, and what a user has to gain by setting this up for themselves by installing Auditor.

It provides you with hardware-verified information, and chains trust to the application which provides software-verified information. The whole point is that you are not trusting the OS or the user interface on the device to provide accurate information.

View Stock Pixel 3a processes
u:r:init:s0 root 1 0 22204 3316 0 0 S init
u:r:vendor_init:s0 root 522 1 7060 1828 0 0 S init
u:r:vendor_init:s0 root 523 1 6544 1228 0 0 S init
u:r:ueventd:s0 root 524 1 8976 1624 0 0 S ueventd
u:r:logd:s0 logd 534 1 21156 3460 0 0 S logd
u:r:tee:s0 system 535 1 19024 3616 0 0 S qseecomd
u:r:hal_keymaster_qti:s0 system 537 1 16104 3372 0 0 S android.hardware.keymaster@4.0-service-qti
u:r:vndservicemanager:s0 system 538 1 12296 2568 0 0 S vndservicemanager
u:r:citadeld:s0 hsm
View cfi.c
#include <stdarg.h>
#include <stdio.h>
void foo(unsigned n, ...) {
va_list args;
va_start(args, n);
for (unsigned i = 0; i < n; i++) {
printf("%d\n", va_arg(args, int));
View tidy.txt
/home/strcat/projects/hardened_malloc/chacha.c:49:14: warning: 5 is a magic number; consider replacing it with a named constant [readability-magic-numbers]
x->input[5] = U8TO32_LITTLE(k + 4);
/home/strcat/projects/hardened_malloc/chacha.c:50:14: warning: 6 is a magic number; consider replacing it with a named constant [readability-magic-numbers]
x->input[6] = U8TO32_LITTLE(k + 8);
/home/strcat/projects/hardened_malloc/chacha.c:51:14: warning: 7 is a magic number; consider replacing it with a named constant [readability-magic-numbers]
x->input[7] = U8TO32_LITTLE(k + 12);
/home/strcat/projects/hardened_malloc/chacha.c:52:14: warning: 8 is a magic number; consider replacing it with a named constant [readability-magic-numbers]
View gist:22174e845019930a9f4bae5a02e4d57b
% adb shell /data/local/tmp/malloc_info | xmllint --format -
<?xml version="1.0"?>
<malloc version="jemalloc-1">
<heap nr="0">
<bin nr="1">
View netd_maps.txt
5b6d4c0000-5b6d543000 r-xp 00000000 fd:00 433 /system/bin/netd
5b6d55b000-5b6d560000 r--p 0008b000 fd:00 433 /system/bin/netd
5b6d560000-5b6d561000 rw-p 00090000 fd:00 433 /system/bin/netd
5e731bf000-5e731c0000 ---p 00000000 00:00 0
5e731c0000-5e739bc000 rw-p 00000000 00:00 0
5e739bc000-5e739bd000 ---p 00000000 00:00 0
5e739bd000-5e741b9000 rw-p 00000000 00:00 0
5e741b9000-5e741ba000 ---p 00000000 00:00 0
5e741ba000-5e749b6000 rw-p 00000000 00:00 0
5e749b6000-5e74ab4000 r--p 00000000 00:10 20874 /dev/hwbinder
thestinger /
Last active Nov 3, 2020
Android Q privacy features in the context of the AndroidHardening / GrapheneOS work

Some of the privacy features that I developed in the past are now going to be standard Android features in the next major release. In some cases, the implementation that I worked on ended up being a direct inspiration for the upstream work. I also pushed them to enable permissions review by default, which may have had some influence on it finally shipping as enabled. It was seemingly implemented for some niche scenario and most of their privacy / security team didn't know about the feature existing when I talked to them about it in the past.

Most of my work has focused on improving security, and that focus will be somewhat increased in Android Q due to many of the privacy improvements being part of the baseline OS.

Android P had previously replaced some of the privacy features developed as part of the AndroidHardening project such as restricting access to the camera, microphone and sensors in the background.

Features that were not implemented by my past work: