Archive

Archive for the ‘Tech’ Category

Handcent SMS: Reset the blacklist password

July 1st, 2010

I recently forgot my blacklist password while using handcent sms so investigated how possible it would be to reset this password without reinstalling the application.

It turns out it’s pretty straight forward but your phone must be rooted for this to work and you must have enabled usb debugging.

The process goes something like this…

First on your phone navigate to Settings -> Applications -> Manage Applications -> Handcent SMS and click the Force Stop button to close handcent sms.

Next we retrieve the preferences file where the password is stored:-

$ adb pull /data/data/com.handcent.nextsms/shared_prefs/
com.handcent.nextsms_preferences.xml

Then edit the file you just pulled, find and remove the line that looks something like:-

<string name="hc_password">0cc175b9c0f1b6a831c399e269772661</string>

Next we push that file back to the device as follows:-

$ adb push com.handcent.nextsms_preferences.xml /data/data/
com.handcent.nextsms/shared_prefs/com.handcent.nextsms_preferences.xml

Now open handcent sms and the password should be removed ready for you to set another!

Obviously the above commands should be entered on one line, line breaks have been added to wrap the content…

Tech , ,

Extracting rom.zip from RUU update in Linux

June 24th, 2010

I’ve written a quick rough and ready tool that can extract the rom.zip file from a RUU update from HTC.

The instructions are located in the extractrom.c file itself and reproduced here for clarity:-

 * REQUIREMENTS
 * This program requires a patched unshield 0.6 to correctly support newer
 * installshield cab files.
 *
 * $ wget http://bit.ly/aWIjG2 (used bit.ly link for blog due to styling issues)
 * $ tar xzf unshield-0.6.tar.gz
 * $ cd unshield-0.6
 * $ patch -p1 < ../unshield.patch
 * $ ./configure --prefix=/usr && make && sudo make install
 *
 * COMPILATION
 * $ gcc -Wall -lunshield -o extractrom extractrom.c
 *
 * USAGE
 * $ ./extractrom /path/to/RUU.exe
 *
 * If successful it will create rom.zip in your current directory.
 *

(pay some attention to the NOTES and TODO sections - at the moment the tool doesn't clean up its temporary directory...)

Example Usage:-

$ ./extractrom RUU_Bravo_O2_UK_1.20.207.1_Radio_32.36.00.28U_4.06.00.02_2_release_124865.exe
Extracting data1.cab...
Extracting data1.hdr...
Extracting rom.zip...
Done!
$ ls -lh rom.zip
-rw-r--r-- 1 kenny kenny 147M 2010-06-24 13:06 rom.zip

You can download it from here: extractrom-0.1.tgz.

Linux , , ,

Filtering traffic through a VPN

April 14th, 2010

Having recently purchased a subscription to iPredator I wanted to filter only certain traffic over the VPN and the rest, by default, over my normal ADSL account. My solution was to setup a SOCKS5 and HTTP proxy that went out over the VPN leaving the rest of the traffic to follow the default route as normal.

Please note this guide works for me on Ubuntu 9.10 (Karmic), your mileage may vary!

Step 1: Setting up the PPTP connection to iPredator

Firstly install the required packages:-

$ sudo apt-get install pptp-linux ppp

Obviously the first step is to actually get the VPN setup, so I created the peers file: /etc/ppp/peers/ipredator

pty "pptp vpn.ipredator.se --nolaunchpppd --nobuffer --loglevel 0"
name YOUR-USERNAME-HERE
remotename ipredator
file /etc/ppp/options.pptp
ipparam ipredator
nodefaultroute
persist

Next you have to populate your chap-secrets file with your password: /etc/ppp/chap-secrets:-

YOUR-USERNAME-HERE    ipredator   YOUR-PASSWORD-HERE        *

Finally edit the /etc/ppp/options.pptp file and uncomment the require-mppe-128 line. Now if you run “pon ipredator” and tail the syslog you should find that the VPN comes up although at the moment no traffic will route over it so go ahead and and run “poff ipredator”.

Step two: Setup the SOCKS5 server

Now we need to setup the SOCKS5 server, danted. First go ahead and install it:-

$ sudo apt-get install dante-server

Next edit the config file /etc/danted.conf and make it look something like this, changing 192.168.1.0/24 to your local subnet:-

logoutput: syslog

internal: eth0 port = 1080
external: ppp0

method: none
clientmethod: none

user.privileged: proxy
user.notprivileged: proxy
user.libwrap: proxy

client pass {
    from: 192.168.1.0/24 port 1-65535 to: 0.0.0.0/0
}

client pass {
    from: 127.0.0.1/32 port 1-65535 to: 0.0.0.0/0
}

client block {
	from: 0.0.0.0/0 to: 0.0.0.0/0
log: connect error
}

block {
	from: 0.0.0.0/0 to: 127.0.0.0/8
	log: connect error
}

pass {
       from: 192.168.1.0/24 to: 0.0.0.0/0
       protocol: tcp udp
}

pass {
	from: 127.0.0.1/32 to: 0.0.0.0/0
        protocol: tcp udp
}

block {
	from: 0.0.0.0/0 to: 0.0.0.0/0
        log: connect error
}

Finally since we will be controlling when this process starts we need to prevent it from starting at boot by running the following:-

$ sudo update-rc.d -f danted remove
$ sudo service danted stop

Step three: Setting up the HTTP Proxy

Firstly install the HTTP proxy (polipo):-

$ sudo apt-get install polipo

Now make your config file /etc/polipo/config look something like this, changing as appropriate:-

proxyAddress = "192.168.1.1"    # IPv4 only
proxyPort = 3128
allowedClients = 192.168.1.0/24
allowedPorts = 1-65535

socksParentProxy = "192.168.1.1:1080"
socksProxyType = socks5
chunkHighMark = 50331648
diskCacheRoot = ""
disableIndexing = true
disableServersList = true
dnsUseGethostbyname = yes
disableVia=true
censoredHeaders = from,accept-language,x-pad,link
censorReferer = maybe
maxConnectionAge = 5m
maxConnectionRequests = 120
serverMaxSlots = 8
serverSlots = 2
tunnelAllowedPorts = 1-65535

Finally since we’ll be controlling when this service starts, prevent it from starting on boot:-

$ sudo update-rc.d -f polipo remove
$ sudo service polipo stop

Step four: Setting up the VPN routes

Now that our services are configured we need to add the magic glue that makes their requests route out via the VPN – this will be done using an ip-up.d script and an ip-down.d script.

NB: Both these scripts assume that your proxy user has user id 13, please change accordingly if this is not the case.

Create the /etc/ppp/ip.up.d/ipredator script as follows (changing 192.168.1.0/24 as appropriate):-

#!/bin/bash

# Check for the iPredator VPN.
[ "$6" == "ipredator" ] || exit 0

# Setup the extra routing table for iPredator.
ip route add table 200 via $5
ip route add 192.168.1.0/24 dev eth0 table 200
ip rule add fwmark 0x50 table 200

# Mark all packets owned by the proxy user to go through iPredator.
iptables -t mangle -A OUTPUT --match owner --uid-owner 13 -j MARK --set-mark 80

# Start the daemons we use for this VPN.
service danted start
service polipo start

Next create the /etc/ppp/ip-down.d/ipredator similarly:-

#!/bin/bash

# Check for the iPredator VPN.
[ "$6" == "ipredator" ] || exit 0

# Stop the daemons we use for this VPN.
service danted stop
service polipo stop

# Remove the packet mangling rule.
iptables -t mangle -D OUTPUT --match owner --uid-owner 13 -j MARK --set-mark 80

# Remove the extra routing table for iPredator.
ip rule del fwmark 0x50 table 200
ip route del 192.168.1.0/24 dev eth0 table 200
ip route del table 200 via $5

Ensure both scripts are executable.

Step five: Testing the services.
To test firstly bring up the VPN by running “pon ipredator”, you should see the VPN come up and both polipo and danted should be started.

Check, by default, you get your ADSL IP:-

$ wget -q -O - http://www.whatismyip.com/automation/n09230945.asp

Next check that when routing via the proxy you get a different (VPN) IP:-

$ export http_proxy=192.168.1.1:3128
$ wget -q -O - http://www.whatismyip.com/automation/n09230945.asp

If it all works congratulations, you now have a http and socks5 proxy routing traffic over your VPN while all other traffic routes out via your normal connection.

IF it fails, I’m afraid you’re stuck going through the logs etc… Sorry!

Linux , , ,

Resetting unix passwords from a webpage

October 8th, 2009

Been a while since my last post due to being extremely busy here over the past few months.

Recently we came across a little problem where one of our customers had a dedicated mailserver (courier, exim4) but had no ability to change their own passwords.

So I came up with two scripts, one bash (to do the actual password reset) and one php (as a front-end to the bash script). These two scripts are designed to be used in tandem to provide adequate input validation and security.

You can find these two scripts here: chpasswd.sh (backend bash script) and chpasswd.txt (frontend php script).

Please note these are simple scripts, in both the lack of error reporting and lack of styling / CSS however they should be functional and with the use of su’ing to the user and avoidance of a setuid root script they should be secure.

If you implement these you are strongly advised to also implement some anti-bruteforce code or in the very least restrict access to internal use only.

Coding, Linux , ,

Ubuntu jaunty upgrade: Encrypted home not mounting

April 27th, 2009

The Problem
I took the plunge to upgrade my laptop to Jaunty yesterday and upon reboot the first thing I noticed was that my encrypted home partition was no longer being mounted. After enabling pam_mount’s debug option and tracing through the problem it turned out to be that mount.crypt was now unable to mount my encrypted partition.

mount.crypt fails to mount the partition because when it calls cryptsetup it fails to pass the keysize parameter so cryptsetup uses the default (256), which is fine if you used a 256 bit encryption key, but unfortunately I’d used a 128-bit encryption key so therefore cryptsetup fails to setup the encrypted volume correctly thus causing the subsequent call to mount to fail.

The Solution
Fortunately I don’t let little things like that stop me from getting things working. Firstly I created a patched libpam-mount package (LP: #367577) that does pass the -s option through to cryptsetup, this then allows mount.crypt to successfully mount the encrypted volume.

However, pam_mount was still not able to mount the volume when I logged in, thankfully it only required a config tweak to match the new options that are now passed to mount.crypt, so my new pam_mount.conf.xml config block now looks like this:-

<volume
    user="kenny"
    fstype="crypt"
    path="/dev/sda3"
    mountpoint="/home/kenny"
    options="cipher=aes,hash=ripemd160,fsk_cipher=aes-128-ecb,fsk_hash=md5,
keyfile=/home/kenny.key"
/>

(Annoyingly hash=ripemd160 has to be passed because cryptsetup defaults to that but mount.crypt defaults to and passes through “plain” unless told otherwise.)

Once this change was made (and the fixed packages installed), pam_mount was once again able to mount my encrypted home directory when I log in.

Linux , , , ,

Ubuntu, lirc and the Antec Black Fusion (15c2:0038)

March 30th, 2009

After getting my Antec Black Fusion, I just couldn’t get it to work in Ubuntu with lirc 0.8.4a, so I went ahead and created some simple packages for lirc 0.8.5pre1 which do appear to work with this case / device.

Notice: Please note in preparing these lirc 0.8.5pre1 packages I’ve dropped a fair few of the Ubuntu specific enhancements to lirc since this is intended as a fix solely for adding support for this device. Debdiffs welcome. ;-)

Firstly add my repository key to apt so that the packages authenticate:

$ wget -O - http://packages.kennynet.co.uk/repository.key | sudo apt-key
add -

(note: trailing dash)

Next grab the sources.list entries for my repository so you can download the 0.8.5pre1 packages:

$ sudo wget -O /etc/apt/sources.list.d/kennynet-testing.list
 http://packages.kennynet.co.uk/intrepid-testing.list

Now we’re ready to install the packages as follows:

$ sudo apt-get update
$ sudo apt-get install lirc lirc-modules-source

With these packages installed, you only need the following line in /etc/lircd.conf:-

include "/usr/share/lirc/remotes/imon/lircd.conf.imon-antec-veris"

I’ve also made a custom (somewhat hacky) startup script which’ll launch the required two lircd daemons for the two lirc devices created under /dev.

You can download the script here, just put it in /etc/init.d/: lirc-imon

Now make it executable and set it to run on startup:

$ sudo chmod +x /etc/init.d/lirc-imon
$ sudo update-rc.d -f lirc remove
$ sudo update-rc.d lirc-imon defaults 51

This’ll disable the default lirc init.d script and enable the lirc-imon one that I’ve created.

From then on I’d make sure it’s loaded the new modules / started lirc as follows then test it out using irw:-

$ sudo /etc/init.d/lirc stop
$ sudo modprobe -r lirc_dev lirc_imon
$ sudo /etc/init.d/lirc-imon start
$ irw

Press some buttons, they should now show up.

All works for me, let me know how it goes… there are numerous debug steps at each stage if it doesn’t work but I’ve left these out to try and keep the e-mail relatively short. We can go through those if you still experience problems. Please leave comments if you have any questions.

I’ll package the very latest imonlcd patch for lcdproc and upload that to my testing repositories soon and make another quick post.

Linux , , ,

Iomega StorCenter Pro 200rl root access

March 13th, 2009

So we got one of these NAS boxes at work and like all self respecting sysadmins we wanted root access on the box ideally with SSH, unfortunately the NAS server doesn’t support this. However it is trivial to obtain root access by using an Ubuntu live CD as follows.

Firstly boot off the live CD and once you have your live CD desktop open up a terminal window, we now need access to the system drive on the NAS box which we can acquire as follows:-

$ sudo apt-get install mdadm
$ sudo mdadm --assemble --scan
$ sudo mount /dev/md3 /mnt

Next we need to make sure we’re working on the NAS system drive for all our commands so let’s chroot into it:-

$ sudo chroot /mnt

To reset the root password we need to run:-

 # passwd

To enable SSH (which is already installed) on startup we need to run:-

# update-rc.d ssh defaults 16

Finally we cleanup and reboot the NAS server:-

# exit
$ sudo umount /mnt
$ sudo reboot

Don’t forget to remove/eject the CD when the Ubuntu live CD prompts you to.

Now once the NAS reboots into its native OS (which happens to be Debian) you’ll find you’ll be able to login to the box as root with all the power that comes with it.

Tech ,

PHP app Licensing Faux-pas

March 10th, 2009

One of the php web applications we use in the office requires a license to work, it locks its license to the hostname and ip address of the server on which it’s run.  When the license key is first entered it phones home to set the hostname and ip address on the licensing server and then stores a valid hash of the license.

We recently restructured our network and changed the ip address thus causing the app to complain the license was invalid, deleting the licensing file caused it to talk with the licensing server again but it was no use the licensing server still held the old ip address which was no longer correct. At this point I sent an e-mail off to their customer support team to get the information changed.

However, I couldn’t resist  taking a quick peek under the hood. To their credit the app is largely open source and readable except for the code that manages the license which is encrypted.  I removed the license file, fired up wireshark which logged the following conversation to their license server (anonymised to protect the guilty):-

GET /XXXXXX.php?license_key=Base64String&host_name=?Base64String&
host_ip=Base64String

Which generated the following reply:-

license-key|host-name|old-ip-address

On the face of it this seems quite easy to attack given it sends the current hostname/ip to the licensing server it’d be a trivial PHP script to send back what we assume the app would want to see:-

$key = base64_decode(urldecode($_GET['license_key']));
$host = base64_decode(urldecode($_GET['host_name']));
$ip = base64_decode(urldecode($_GET['host_ip']));

echo "$key|$host|$ip";

All that remains to do is set the script up on our server, and add an entry into our /etc/hosts file so that the licensing server domain name now points at our server. Once done after removing the license file I hit refresh and surprise surprise the app accepted the license response and things continued as normal.

This is particularly weak scheme since it doesn’t even run over SSL so capturing with wireshark is trivial. The other fundamental problem is that the class which converses with the licensing server is not encrypted so that would represent another point of attack which wouldn’t require setting up a fake licensing server – just hijack the response methods.

To their credit the license key itself is validated using a hash to determine what level of features you have access to but once you’ve bought one key you are then able to apply the methods above to copy the key to as many different locations as you wish.

Any comments identifying the application in question will be removed or censored, this is not an aid to bypassing licensing requirements more a discussion of the security implications of how this particular method was implemented.

Coding , ,

Web App config files

January 21st, 2009

So like most people when I write my web applications I create a config.inc.php of some description and put that in the directory with the application. However, when it comes to roll out the app this causes problems due to the config differences between the live and development environments so the config file needs to be changed once the new version has been put live.

This isn’t ideal so the first obvious thing to do is to move the config file out of the web application directory to somewhere else (for example: /etc/webapp.conf). Now when a version of the web app is released you simply just have to untar the web app tarball into the correct place and everything will just work without any post-install manual tweaking.

The problem with this approach is that it doesn’t work for multi-developer environments where a developer might need to tweak the config file for a new feature they’re testing, but the web app is now looking at the /etc/webapp.conf file no matter what developer it is.

The solution I then came up with was another config file, say called .dev-config.inc.php which is (optionally) kept in the same directory as the web app but excluded from your version control software so it’s never checked in. Then you simple change the web app to check for this file and if it doesn’t exist load the main config file so now a developer can create a config file for just their tree. For example:-

if(file_exists(dirname(__FILE__)."/.dev-config.inc.php")) {
    require_once(dirname(__FILE__)."/.dev-config.inc.php);
} else {
    require("/etc/webapp.conf");
}

Now once we have this setup everything works and developers can change the config files if they need too (e.g. database dsn’s) and the live system can be deployed by simply untar’ing a tarball.

The next thing I noticed was if I need to add a new config file option I need to add it in all the config files, even if it’s just a system config option that won’t change no matter what environment it’s in. This is a bit of chore given I’m just a lazy developer…

So the next change I make to the config file system is to reinstate the config.inc.php in the web app directory with one key difference, it now has the following design pattern and it is responsible for including our main config file:-

if(file_exists(dirname(__FILE__)."/.dev-config.inc.php")) {
    require_once(dirname(__FILE__)."/.dev-config.inc.php);
} else {
    require("/etc/webapp.conf");
}

$config = array(
    "A_CONFIG_OPTION"=>TRUE,
    "IS_THIS_OVERKILL"=>"MAYBE"
);

foreach($config as $const=>$value)
    if(!defined($const))
        DEFINE($const, $value);

Now this config file will first load our main web app config file (either /etc/webapp.conf or .dev-config.inc.php) and fill in all the missing (default/system) config options that weren’t needed to be changed in the per-environment config settings. Should that need change, simply just define them and this config file will not set them.

Questions
1. Is this over the top?
2. How does everyone else handle config files?
3. Do their methods solve the issues presented above?

Coding , ,

Dead Space with Arrow Keys!

December 22nd, 2008
Dead Space with Arrow Keys

Dead Space with Arrow Keys

Having received Dead Space for my Birthday I was disappointed to find that there was no way to use the arrow keys to play especially since I’m left handed and that is far more natural to me.

However, not being one to give up at the first hurdle Google lead me this page which gives instructions for playing Dead Space with arrow keys using GlovePIE to remap the keys as you press them. It’s a good workaround but it’s simply not ideal.

The file responsible for storing your key mappings is controls.rmp located under “C:\Documents and Settings\<your username>\Local Settings\Application Data\Electronic Arts\Dead Space”, so I began examing this file, how it changed depending what the keys were set to and after an hour or two of playing about I discovered not only the offsets storing the Up/Down/Left/Right key mappings but also the correct values for the arrow keys – AND THEY WORK.

To make these changes for yourself you’ll need a hex editor like XVI32, set the following values at the following offsets in the controls.rmp file (OFFSET:VALUE):-

5C: CB
AC: D0
14C: C8
23C: CD

Now save the file and load up Dead Space, you should find you’re now able to use the arrow keys to move around. Alternatively if that’s too much like hard work you can download my pre-modified controls.rmp file below which is set to use the arrow keys – simply customise the other keys how you would like.

Download: controls.rmp.

Update:
If you’d like to use the Enter/Return key as your reload key, make the following change using XVI32:-

E8: 1C

General, Tech , ,