Getting mainline running on the Samsung Gear 2 - part 2 (eMMC)

Introduction In part 1, I got the kernel booting and providing debug output, to the point where I could figure out that the kernel was failing to find the rootfs. The kernel logs suspiciously did not show proper enumeration of the eMMC flash, so that’s what we need to fix. Initial hypothesis We know that the eMMC controller is at least somewhat working, as the Wi-Fi/bluetooth chip is connected to it via SDIO and the kernel logs show that it’s being enumerated as mmc1.

Getting mainline running on the Samsung Gear 2 - part 1

Introduction After putting my work on the Galaxy Gear S2 on hold due to how tricky it is to work on without a reliable USB connection, I’ve decided to hack on easier targets first. The main results of this work are a patched kernel tree hosted here and a much-expanded postmarketOS wiki article here. An AsteroidOS port is also work-in-progress, but blocked by having to split all of the libhybris-related changes out, as this is the first mainline watch supported.

Fuzzing Android binaries under Qemu - part 1

Introduction For over a year now, I’ve been working on-and-mostly-off on researching Samsung smartwatches. I’ll document my efforts here at a later date (including a new tool for flashing Samsung devices that’s hopefully less broken than Heimdall). As part of that effort, I wanted to find out whether a binary Samsung ships in the recovery partition for flashing firmware can be exploited to achieve RCE. This could be useful as a way to bypass bootloader locks (judging by pictures extracted from the bootloader binary, this only affects US Verizon models).

Using a bridged LXD network

The regular network configuration created when simply running lxd init --auto is quite simple and usable. Unfortunately, it has one major drawback - NAT. Because LXD creates it’s own private network you have to deal with port forwarding, and some services (pi-hole for example) take issue with not being able to use an address that is part of the network their clients are on. In addition, this setup makes the containers impossible to easily reach over IPv6.

Setting up a wireguard server running on an OpenWRT router

Motivation I’ve been trying to find a decent DIY VPN solution for quite a while now. They all seem easy to configure at first, but the weirdness and workarounds just kept piling up until I realized that I’ve been to busy cursing at $VPN_SOLUTION to get any sleep. Wireguard is a relative newcomer to the scene, having been widely known for only about a year now. It’s approach to building a VPN is rather unique in that it doesn’t force you to set up an entire PKI just to connect your phone to the VPN (looking at you, OpenVPN…).

Bypassing pesky SSH-blocking firewalls

I’m writing this on a bus with onboard Wi-Fi. The network works (and is decently fast!), but the provider blocks SSH for some reason, which means I can’t push my code to github without reconfiguring my remotes to use HTTP. Fortunately, bypassing the firewall is fairly simple: Install your tools: sudo apt install tor proxychains # Disable tor service if you don't want to start it on boot sudo systemctl disable tor In my case the provider also blocked the default tor relays, so I had to obtain some bridges from bridges.

Building LineageOS 14.1 for the S4 value edition (GT-I9515 or jfvelte)

While there’s plenty of documentation on how to build LineageOS for officially supported devices, there’s hardly any documentation on how to build for an unofficial device and/or on systems which have <16GB RAM and a slower CPU. A lot of the workarounds might be useful for other devices as well. I’ll assume that you’re using Ubuntu 16.04, though I’m sure other distros will work with slight modifications. Installing dependencies Install some packages:

Building code::blocks on ubuntu 16.04

I’m currently creating a snap package for the code::blocks IDE. On the way, I ran into a little snag, namely the build failing with: make -j2 CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash /home/david/dev/snap/snap-codeblocks/parts/codeblocks/build/missing aclocal-1.13 -I m4 /home/david/dev/snap/snap-codeblocks/parts/codeblocks/build/missing: line 81: aclocal-1.13: command not found WARNING: 'aclocal-1.13' is missing on your system. You should only need it if you modified 'acinclude.m4' or 'configure.ac' or m4 files included by 'configure.ac'. The 'aclocal' program is part of the GNU Automake package: <http://www.

Installing snapcraft on debian sid

Canonical’s snapcraft tool unfortunately currently isn’t packaged for debian. In this post I’ll describe how I got a build of it to work on my machineā„¢. Note that this is a messy process which will give any of the “don’t make a frankendebian!” guys eye cancer, and for good reason. What you’ll need patience free time a machine running debian sid (stretch/jessie might work, haven’t tested) How to Step 1: Install (some of the) dependencies sudo apt update && sudo apt install -y build-essential dpkg-dev wget git debhelper pkg-config python3-docopt python3-fixtures python3-jsonschema python3-libarchive-c python3-lxml python3-magic python3-progressbar python3-pymacaroons python3-requests-toolbelt python3-responses python3-simplejson python3-setuptools python3-tabulate python3-testscenarios python3-testtools python3-xdg python3-yaml squashfs-tools xdelta3 Step 2: Clone the latest snapcraft The stable version (2.

Fixing chromium in debian unstable

For some (in my opinion pants-on-head-retarded) reason the maintainers of the chromium package in debian have chosen to disallow loading of extensions from the chrome store. They claim that this will pave the way towards “distro-packaged” extensions, but as of yet I haven’t seen a single one in the repos, not even ublock. What’s worse, the only notice you get is if you upgrade from a version before this “fix” was applied.