Kindle Fire Connectbot Followup

Just a quick followup to the previous article I had on getting connectbot to work on the Kindle Fire.

A lot of people have been asking for an unofficial apk of the changes I’ve made. Initially I hesitated - I wanted to follow the official channels. Initially, I posted this article with some links to my changes (admittedly pretty primitive) and posted a followup to the thread on the issue tracker.

Looking at the latest build snapshot (12/19) it still doesn’t appear that a fix has been incorporated into the main source. I do not expect that my off-the-cuff additions would be accepted, but there is enough demand that someone should have been able to address this properly by now.

So I’m offering my personal build of the connectbot source. Totally unmaintained, not warranty, use at your own risk. ;-);=connectbot-kindle-fire-mod-d83c275.apk

Getting Connectbot working on Kindle Fire

Ever since getting the Kindle Fire I’ve been dreaming of the day that I can get ConnectBot working.  The first hurdle is that this is not available in the Amazon market.  Luckily, being under the Apache License they did have code available on the google code site.

After installing the apk file, i started up a test connection.  Everything was going well until I got to the part where I enter the server name.  The virtual keyboard pops up, but instead of an enter key there is only .com.  I recognized this as the keyboard that comes up when you are in the web browser.  Unfortunately, unlike the web browser, there is no additional “go” button.

First thing I did was check the issues to see if this has been reported yet.  Yes it had, sounds like many people are itching to ssh from their Kindle Fire :-)

So I dutifully tagged the issue and waited for a fix…

After waiting a few days I couldn’t let it sit. I needed to dig in myself and see if i could find anything.  Seemed like a relatively easy problem

The Process

First I grabbed the code via git from their project page and setup my Android dev environment.  This included installing the Android SDK, installing JDK and installing Eclipse.

Once I got all my goodies installed I connected the Kindle Fire, waited for the “connecting USB” to finish…and…NOTHING!

After a little research I learned I first needed to install the Google USB drivers for this device.  Went into device manager and found the Kindle device with missing drivers, right-clicked and pointed to the ini file.

At this point I was able to do an adb devices and could verify that my Kindle Fire was detected

At this point I was still pretty much at a loss of where to being.  I knew just from playing around with the Kindle Fire that there definitely is a keyboard layout that had an enter key.  For some reason this layout was not using it though, it was defaulting to the same one used for entering websites.  Having the .com where enter should be is normally not a problem - when the keyboard collapses you can then click on the go button.  In this case, however, the keyboard does not allow for that option.

After doing some research I learned that there are many different inputType fields that will basically determine what keyboard layout was used.  Getting closer…

What I finally stumbled upon was, oddly, the default text in the input field “[email protected]:port”.  I was able to use this very unique string to search through the code to eventually come upon my first clue. I was lead to a “hint” (literally) in the __ element, inside of which I noticed the _android:inputType_ that was initially set to_ textEmailAddress_, I changed this to _textMultiLine_.  My theory being that if it had multiple lines there was some way to send a carriage return.

So far success…

Except now I get to the password line and I’m facing a “new” keyboard with the same issue: a .com where and enter should be.

So doing some more searching I use my same method of searching for the text hint, this time Password: Pretty quickly I found this one but it wasn’t quite the same.  I was lead to strings.xml which is essentially a “lookup table” for strings.  At least now I know that Password: _will be in the code somewhere as _prompt_password.  So digging some more I found a corresponding _.  _But this lead me to a field for key generation (probably needs to be "fixed" for everything to actually work).  This wasn't quite what I was looking for.

Browsing the “layout” folder, I was eventually able to find the file I needed. I found a console_password line in act_console.xml.  After adding a android:inputType=”textMultiLine” I was set.  I ran the file, sending it to my Fire and met with success this time when connecting to my server.  Using the following method I was able to take a screenshot of my victory.

The changes

The results

I still have little understanding of why what I changed did what it did, or what repercussions this might have on other Android platforms. I hope this does show, however, that with a little persistence to “scratch an itch” it is pretty easy to use some really basic research and techniques to modify Android source code to meet your needs.

Since this has sparked in interest in me for learning more about Android development.  I look forward to learning more about the ins and outs of the platform and how to properly submit and implement patches for bugs like this.

Since this was a quick and dirty hack, I look forward to input on the right way to do this.

Edit 2011-11-22: I forgot to actually describe the problem (lack of Enter key)…

A Simple OpenBSD Router For Your Virtual Machines

Why Do I Need A Separate Router For Virtual Servers?

I tend to use VirtualBox a lot at home for experimenting with different operating systems or trying out scenarios that are too dangerous to “do it live”. While I could just give these virtual machines a bridged connection, I like to try to keep things as close as possible to the original environment, especially for “forensic” inspections.

In order to do this I have come up with a very basic OpenBSD setup that allows me to adapt the router/firewall to the virtual machine rather then make modifications to the image. Using the PF firewall, we will be able to rapidly assemble a NAT’ing firewall. With additional research you, thanks to PF’s awesome documentation, you should be able to extend this to be a traffic logger, export to netflow and do many other things.

I have tried experimenting with many “embedded” Linux distros that are targeted more at a hardware appliance, but in the end all of the user friendly settings just ended up getting in the way. Using OpenBSD I am able to get a very low footprint OS with a well-documented and transparent firewall. I know precisely what PF is doing with my packets.

While this setup was done on VirtualBox, it could easily be adapted to any virtual host environment that allows for Bridged and Internal NICs to be assigned.

Creating the Virtual Machine

For me, Virtual Box is my go to virtual platform for experimentation. The interface makes sense and gets out of my way when creating virtual machines. Virtual HDD’s and ISOs correspond to real files in your host machines OS, not an abstracted storage device.

For long running servers I prefer ESX, but for just playing around Virtual Box is the way to go.

  • Download and install Virtual Box for your OS

  • Download load “cd50.iso” from a mirror at This is the base install iso with no extras, we’ll be adding some software as part of the install process.

  • Create a new VM in VirtualBox

    • 32 MB RAM

    • 600 MB HDD (This leaves about 100 MB of free spaces for logs and additional packages)

  • Edit your network settings and add an additional NIC. Set the first one to Bridged or NAT and the second one to Internal

Base Installation

Though this is a text based installer (a dying breed) the install is very straight-forward with logical defaults. For the most part you can just hit enter.

  • “I” install

  • Choose Keyboard

  • Set hostname

  • Configure bridged/NATd nic for downloading installation files

  • Set your password

  • Start ssh - Yes

  • Start Ntp - Yes - set to your favorite ntp server (

  • Do you expect to run X Windows - No

  • Setup default user (your choice)

  • Set your timezone

  • Setup the disk

    • Which one is the root disk - wd0

    • Use DUIDs - yes

    • Use whole disk - whole

    • Use auto layout

  • Location of sets - http

  • Accept defaults for server, path locations

  • Set names - type “-x*” to deselect all of the X Windows packages

  • Set names - done

  • There may be a few additional questions about setting the time, adding non-free items to the boot process, just answer as necessary

  • At the end you’ll be dumped to a shell prompt, type “halt” to shutdown.  Power off and remove the virtual cd.  Power back up

First boot config

Surprisingly, we are nearly done. Only a few touches are needed to enable NAT and turn on the minimal firewall settings to allow traffic out.

Configuring Basic Networking

First we will need to setup our network interfaces. After going through the install your primary interface (em0) should already be setup, but lets review. Network configuration is done by editing the file /etc/homename.interface, for example /etc/hostname.em0. I have mine set as below, adapt as needed.

/etc/hostname.em0 - dhcp /etc/hostname.em1 -

Next we’ll set the nameserver, if you set your primary to use DHCP in the install process this will already be filled in by the values from your DHCP server.

/etc/resolv.conf - nameserver

And finally setting the gateway. Again, if you’ve set your interface to DHCP it will be set by the DHCP server and this file will not be created, otherwise:

/etc/mygate -

Now to restart the network interfaces and settings, run the following:

sh /etc/netstart

Turning on IP forwarding

IP forwarding is controlled by the sysctl mechanism. In *BSD, sysctl is basically a way to tweak various kernel settings. Being built into the kernel these pieces are generally more low level and higher performance than a “user land” application. For a one-time change you can use the sysctl command to tweak settings. To make these settings persist over reboots, we will be setting them in the /etc/sysctl.conf file.

Edit /etc/sysctl.conf with your favorite editor (vi and mg - MicroGnuEmacs are among those included). Find the line that says:


and remove the comment


Setting up PF the Packet Firewall

Now we have turned on the IP forwarding mechanism in the kernel we need to enable the PF firewall and tell it how to route traffic.

First, we will enable the firewall. This is done by simply editing /etc/rc.conf which is somewhat like a master settings file. In here you will find various settings relating to which applications should be running at boot and what settings they take. To turn off an application it is set equal to NO, otherwise it is a "” or some setting inside quotes, such as “en0”. The comments do a good job of explaining these options.

What we are looking for is the line:


set this to:


That’s nearly it!

Configuring PF

Now for the most difficult part. Seriously, this is pretty easy stuff right?

We will be editing the settings file for PF, /etc/pf.conf. At the top you will notice some default settings, leave these.

At the bottom of the file we will add the following line:

pass out on em0 from em1:network to any nat-to (em0)

What this will do is fairly easy to understand once you realize that the PF configuration is it’s own mini language ( or Domain Specific Language )

Rules are essentially built up like this: action direction on interface from/to destination

pass out on em0 - allow traffic outward from em0 (our “external” interface)

from em1:network - this is shorthand to say “whatever IP network we have assigned to em1”, em1 being our internal interface.

to any - we don’t care where the traffic is destined for

nat-to (em0) - perform NAT on the traffic to make it appear as if it’s coming from em0. With the parenthesis around em0 we are telling PF to continually update the IP of this interface, as it may change - for example with a cable modem

Finishing up

You could manually activate all of the changes we have made using the sysctl and pfctl commands, but I find it easier to just reboot. A quick reboot will also prove that all of the services will start up correctly.

I hope this little BSD firewall is useful to you. It can easily be adapted to be a DHCP server, DNS server, or provide many other network services. This will help you in building up your virtual network for testing or replicating an existing environment for experimentation with captured P2V machines.

Edit 2013-09-15 - I fixed a few spelling mistakes since this has frequently been a very popular post on this site. If you have suggestions or articles you’d like to see in this format please drop me a line at [email protected] or post a comment. Cheers

This is one of my more popular articles. If you have any suggestions for updates or new articles like this please don’t hesitate to leave a comment below, or email me directly at [email protected]