Posts | Tags | Archive

Preserving the Xposed Framework through a ROM flash

The Xposed Framework is a neat Android program that enables user-made modules to change the behaviour of the lower-level Android OS. It does this by modifying /system/bin/app_process to add some hooks into it.

The issue is that when flashing a new ROM, the modified app_process is reverted back to the original version, disabling the Xposed Framework until it's restored.


The Xposed Framework installer now includes the option to flash a zip file to install the framework instead of patching app_process directly. The method detailed in this post will still work, but the new way to make sure the framework is installed after flashing a new ROM is to simply flash the Xposed installer zip right after flashing the ROM.

The solution to this is a script that will automatically back up the existing app_process before a flash, then restore it after the flash completes.

The script does exactly that. To enable it, download it to the Android device, move it to /system/addon.d/, and give it executable permissions.

This can be done on the device with a few different programs, but it's much easier to do from a computer with adb.

Download the script and push it to the SD card of the Android device with

adb push /sdcard/

Once the file is on the device, log into it (using adb shell) and run the following commands:

su  # Get root permissions
cp /sdcard/ /system/addon.d/  # Copy the file to the correct folder
chmod 755 /system/addon.d/  # Make the file executable

After logging out of the device, the Xposed framework will stay installed and active even after flashing a new ROM. Note that this should only really be used in situations where the ROM isn't changing too much (like flashing a new nightly ROM).

In situations where app_process would actually be changed by the flash, this script could cause issues as it would restore an incorrect version of the file. If this happens, delete app_process and app_process.orig in the /system/bin/ directory, then reflash. The script won't interfere, allowing the flash to update app_process to the correct version. After rebooting, install the Xposed Framework again.

Limit download speed by IP or MAC address


This article will focus on setting strict speed limits on misbehaving devices on your network. This can be a housemate incessantly torrenting, your kid downloading movies on iTunes, or anyone else clogging up your network with their overzealous bandwidth gobbling.

If you're looking for help with the QOS (quality of service) settings that come baked into most router firmwares, this article is not for you.

This article assumes you have a router running OpenWRT, DD-WRT, Tomato, or any other firmware that uses tc to manipulate traffic control settings.


First, you'll need to get shell access to the router. With most custom router firmwares, this is as easy as selecting a radio button. Other firmwares might give you the ability to enter commands via a web interface. Whatever works.

Once you have shell access, follow the steps below. Note that bits of the commands you might want to change are included in brackets.

  1. Using ifconfig, find the interface to apply the limits to. You'll want to use either the internal or external default gateway (the interfaces all the packets go though). Keep in mind which interface you use as the filtering rules will be reversed.

    • Internal gateway: to src = uploading, to dst = downloading
    • External gateway: to src = downloading, to dst = uploading
  2. Remove all existing rules on the interface (interface = br0)

    tc qdisc del dev br0 root
  3. Set up the connection (Ex: connection speed = 20mbit)

    tc qdisc add dev br0 root handle 1: cbq avpkt 1000 bandwidth 20mbit
  4. Add the limiting rule (Ex: speed limit = 10mbit)

    tc class add dev br0 parent 1: classid 1:1 cbq rate 10mbit allot 1500 prio 5 bounded isolated
  5. Filtering - Add the users to apply to rule to

    • By src IP (Ex: IP =

      tc filter add dev br0 parent 1: protocol ip prio 16 u32 match ip src flowid 1:1
    • By dst IP (Ex: IP =

      tc filter add dev br0 parent 1: protocol ip prio 16 u32 match ip dst flowid 1:1
    • By src MAC (Ex: MAC = M0-M1-M2-M3-M4-M5)

      tc filter add dev br0 parent 1: protocol ip prio 5 u32 match u16 0x0800 0xFFFF at -2 match u16 0xM4M5 0xFFFF at -4 match u32 0xM0M1M2M3 0xFFFFFFFF at -8 flowid 1:1
    • By dst MAC (Ex: MAC = M0-M1-M2-M3-M4-M5)

      tc filter add dev br0 parent 1: protocol ip prio 5 u32 match u16 0x0800 0xFFFF at -2 match u32 0xM2M3M4M5 0xFFFFFFFF at -12 match u16 0xM0M1 0xFFFF at -14 flowid 1:1



Preventing Wine from registering mimetypes

When installing Wine for Linux, the install script insists on associating all text files with its built-in notepad.exe

As someone who uses Vim almost exculsively, this is definitely not the desired behaviour.

To stop this from happening, run the following command before installing Wine.

export WINEDLLOVERRIDES='winemenubuilder.exe=a'

This sets the path of the winemenubuilder library (the library that creates mimetype associations) to something invalid, preventing the associations from being made when Wine installs.

Once Wine is installed, it won't try to associate notepad.exe again. However, if needed, the library can be properly disabled via the libraries tab of wineconf.

© Carey Metcalfe. Built using Pelican. Theme is subtle by Carey Metcalfe. Based on svbhack by Giulio Fidente.