Dropsync deletion bug on Eclair (Android 2.1)?

Dropsync is a must-have Dropbox add-on for Android to sync files with remote folders. Since v2.4.6 though I’ve been tracking an apparent bug on my Barnes & Noble Nook eReader, which runs Android 2.1 (the bug is not reproduced on my Android 4.1 phone). The developer is strangely silent, despite my having supplied reproduction steps and logcat extracts, so I’m beginning to wonder whether it’s just me!

The bug is as follows:

If an eBook is removed from a Dropbox folder on a remote device, whilst Dropsync correctly deletes the local eBook file it does not delete the entry from /data/data/com.android.providers.media/databases/internal.db.

The two tables where eBooks get stored in that database are ‘products’ (for purchased eBooks) and ‘docs’ (for sideloaded eBooks). In my testing I am only using sideloaded content.

Anyone experiencing similar or can offer any suggestions I’m all ears.

Bye bye iPhone

So the time came to upgrade from my ageing iPhone 3GS (just too slow with only around 100MB RAM available to the user on iOS6); here are my reasons for leaving the Apple fold and getting an Android handset.

  1. The future is always-connected-cloud-fluffiness and Apple suck so, so badly at online services. iDisk, .Mac, Mobile Me, iCloud, iMessage – all have been beset by problems. 10 years after first dipping their toe, Apple continue to embarrass themselves with connected offerings.
  2. No matter how much Apple go on about ergonomics, their devices are too damn small. I have average size fingers and yet I make too many mistakes typing on their keyboard.
  3. The iOS feature set is severely lacking when compared with the latest iterations of Android, and even jailbreaking doesn’t get you everything any more (e.g. profiles – hello Apple? Nokia were doing this 10 years ago!!!).
  4. I’m sick of having to go through more and more hoops to jailbreak my phone and then retain that jailbroken state. As I’ve said before, it’s safer to be jailbroken than not, and Android manufacturers are open to the ideas that folk who pay for one of their devices actually own that device and have the right to do with it whatever they so choose.
  5. iOS7 looks like a child’s toy.

I’m sure I could come up with more. I’m sad to have to move elsewhere (I’m sticking with OS X so syncing is not gonna be nearly so simple) but I cannot in good conscience stay in the iOS playpen ecosystem.

For those interested in which device I’m replacing the 3GS with, I bought an HTC One. The software seems sane and the hardware looks like Apple made it!

Bug in Google search autocomplete when using Google Chrome browser

Well well well. In Chrome (Version 27.0.1453.110) just go to google.com and type “fouad el ” into the search field with autocomplete enabled (the default). You’ll find you cannot type anything further nor can you delete and in Chrome’s Activity Monitor window you’ll find that tab taking ~98% CPU. Only route forward is to kill the tab. Strange!

fuse-ext2 write support flaw on ext3 journaled partitions

So I have a 1TB drive with four partitions, only two of which are ext (both ext3 journaled) and the other two are ‘not recognised’ (the drive was from a Western Digital MyBook World Edition NAS drive). Using the pre-requisite 32 bit kernel, MacFUSE 2.0.3 and fuse-ext2 0.0.7, I found the following behaviour.

On connection to USB, I’d see a warning message that the drive was not readable and an offer to Initialise or Ignore. This seems reasonable given that no partition on the drive is supported by OS X out of the box. I chose Ignore, then issued the following fuse-ext2 command to mount the partition of interest:

fuse-ext2 /dev/disk1s1 /Volumes/nas -o force

The drive mounted normally and I could edit files. I could unmount, remount and find my changes still present.

However upon reattachment to a linux system (the WD NAS drive running busybox) I would find that my changes had been mysteriously reverted or, on a couple of occasions, the edited file would be truncated.

I am assuming that the cause of this behaviour is the stil-buggy read-write support in fuse-ext2. I found the exact same behaviour if I used the rw+ option instead of force.

The workaround I found was to mount the drive, unmount it and remount it; all changes made during the second mount session would then persist.

Hope this helps someone else out – what disquiets me is that despite a fair amount of searching out there on the interwebs I didn’t find any other posts or comments from anyone experiencing similar change-reversion issues on writing; surely its not just me!

OS X 10.6 versus Lexmark MX310dn printer (or, why Apple will never build world-class online services)

TL;DR Go here to download the correct driver that Apple refuses to auto-install, preferring instead to supply an outdated, non-working one.

So I recently bought this printer and set it up on my LAN. As one would expect, it was trivial to add in OS X and worked immediately.

The following day however (after the printer had gone to sleep) the Mac could no longer print, complaining that the printer was ‘offline’ (this was patently untrue). After blaming the printer for too long, putzing at it’s settings and gnashing my teeth, I started looking at the driver software on the Mac and in the Console logs. It became clear immediately that that was where the problem lay. Fixing it however was not as easy as it should have been..

I visited Apple’s long-standing printer info article and learnt that the Lexmark software had recently been updated with respect to the MX310dn, but thought “I just installed this printer – I don’t believe the software got updated in the last 24 hours”. So I got googling; the results amused me. One result gave me the results of searching for printer drivers at Apple’s support downloads page, which stated that the most recent download for Lexmark was V2.4. The next result however was for V3.0 Lexmark drivers for OS X, also from Apple’s Support site!

So then, Google was able to find me the Apple’s latest Lexmark printer drivers when Apple’s own site search could not. I think this is a perfect illustration of how Apple repeatedly fail in the online services space (iDisk, Mobile Me, iCloud); it’s just not in their genes.

To Jailbreak or not to Jailbreak..

Following my experience earlier this year with the iKee worm (which can only infect jailbroken iPhones) I thought it’d be worth expounding upon the pros and cons of jailbreaking.

Why not to jailbreak

  1. A stock iPhone is amongst the more secure computing devices out there, due to it’s security model. To my knowledge there’s not yet been a single ‘proper’ virus for it, that is, one that exploits a programming flaw in order to execute it’s code (compare this to the Android OS, where there are already botnets of infected phones). This is not to say that there will never be such a virus (since of course jailbreaks exploit just such flaws!) but the likelihood is vanishingly small, given the hurdles it would need to overcome. Jailbroken iPhones however are more susceptible for three reasons:
    • Jailbreaking at a fundamental level means to disable the iPhone’s ‘only Apple-signed software can execute’ security model. This makes a jailbroken phone susceptible to viruses.
    • Due to reliance on that model, the passwords of the two user accounts (root and mobile) are common to all handsets and are well-known (‘alpine’ and ‘dottie’).
    • Most power users who jailbreak will install OpenSSH, which increases the attack surface of the device since it will also become vulnerable to SSH-based over-the-network attacks.
  2. You can safely upgrade to the very latest version of iOS with impunity and benefit from all the latest new features (limited only by whether the age of your iDevice might make it too sluggish).
  3. You will have no issues with support when you have a problem with your device. The alert Apple Genius will drop you like a hot potato if they notice your device is jailbroken.

Why to jailbreak

  1. The other side of the coin of point 1 above is that it seems unlikely that anyone would go to the trouble of writing a malicious virus (as distinct from the iKee-style mischievous experiment) in the knowledge that it could only infect jailbroken phones – the worldwide population of infectable devices is just too small for it to be worthwhile.
  2. Jailbreaks depend upon finding and exploiting one or more flaws in the stock iPhone hardware/firmware/software. Once the relevant exploit(s) are published (including when the jailbreak is released) all stock iPhones become susceptible to a virus written using that method. Since a patch for the flaw(s) is usually released in the jailbreak community following the jailbreak, for these identified and specific flaws a jailbroken iPhone is actually less susceptible to penetration than a stock one!
  3. The benefit most often talked about, that being the freedom to install whatever software you choose on a device that you bought and paid for. We own the device after all and therefore it should be entirely up to us what we do with it; we don’t need an Apple-nanny to choose for us!


Turning the Nook Simple Touch with GlowLight into a general-purpose Android tablet

As is now well described all over the ‘net, eReaders such as the Nook Simple Touch with GlowLight (seriously B&N? Couldn’t you find a snappier name?) are just Android tablets with an eInk screen. As such, they’re ideal contenders for an extremely low-power general purpose tablet.

Getting root is simple enough, but to end up with a properly useable Android tablet there are a bunch of other tweaks that need to be followed. This post then is all about what else needs doing to achieve that end.

It’s worth noting that the Nook was at firmware revision 1.1.5 and that the nooter (the adopted name for software packages that perform the rooting process on a Nook) used will depend on the particular Nook in question and it’s firmware revision.

1. Rooted with this nooter.

2. Installed SearchMarket from AppBrain website. This is necessary since the Nook uses Android 2.1 (Eclair) and the search functionality in it’s Market app is not supported by Google’s newer Play store.

3. Install Nook Touch Mod Manager. This app allows one to repurpose the Nook’s built-in hardware and software buttons, making it easy to switch between the Nook’s software and the Android Home screen. It also means one can uninstall ButtonSaviour (an on-screen soft button app).

4. Install NookColor Tools to enable non-market app installs.

5. Disable update notifications in Market app settings. Android 2.1 is long in the tooth and one will not wish to update many of the installed apps to newer versions that might no longer support that OS version. Also might reduce power drain.

6. Install DropBox & DropSync. In a future post I’ll describe how I brought my eBook library under my control instead of Barnes & Noble’s.

7. Disable OTA upgrades. Crucial! The last thing you want is to lose root due to the device auto-upgrading it’s firmware.

8. Enable multitouch. This is of arguable benefit, but some folks can’t do without it. Instructions here and recompiled kernels here.


Annoying bug with Barnes & Noble’s Nook for Mac application (and how to work around it)

So version v3.0.0fc9774 of the Nook for Mac application has an occasional but quite annoying bug in that, on launching, it hangs at the splash screen and will not respond to input, though according to Activity Monitor it is not Not Responding, so it hasn’t crashed as such.

The workaround (that I picked up from this thread) is to right-click the grey area of the application’s workspace, then click ‘Reload’ on the menu that appears. This should reload the splash screen and then get past it to loading your library. Hope this helps others.

My experience with the Ikee iPhone worm

TL:DNR summary

Change your iPhone’s  root and mobile account passwords immediately after installing OpenSSH! In fact, ideally do so using MobileTerminal before installing OpenSSH.

Long version

So I’m pretty embarrassed. I found out in December (by complete chance) that my iPhone 3GS was infected with the Ikee worm, and had been ever since July 7th 2011 (5 months!). I happened to be browsing the phone’s crashlogs (at /System/) and noticed recent and repeated crashes by a process named poc-bbot. “A filename containing ‘poc’ and ‘bot’? Gotta be fishy” I thought. And Google very quickly confirmed my fears; poc-bbot is the main binary of Ikee.A, .B and .C.

Now I’ve never seen the gurning fizzog of Mr. Astley as my lockscreen background, so evidently the virus never managed to deploy it’s payload. My hypothesis is that it was written when iOS3 was current, and changes in iOS4 rendered it ineffective.

The good news is that removal is quite trivial, and the only cost to me appears to have been poor battery life for the last 5 months. But how did it get in? I consider myself pretty diligent regarding security. Well, this worm operates by scanning IP address ranges looking for iPhones and, when one is found, attempting to log in via SSH using the default root password, alpine.

If your phone is not jailbroken you won’t even have an SSH server installed, let alone running so the worm only affects jailbroken phones. Checking datestamps of various files shows that I jailbroke my phone on July 6th 2011 and installed OpenSSH, then the following day changed the passwords for the two accounts. Evidently then I was infected in this 12 hour-or-so window between installing the SSH server and changing the default password.

Now why didn’t I change the passwords first you ask? Well, there is but one app for iPhone that provides a local terminal window – MobileTerminal – and for reasons unclear the version available in one of the default Cydia repositories does not run on iOS  and higher. Consequently at the time I thought that it was no longer supported and I was SOL. The only other way to change the password was to log in via SSH using the default password, then change it immediately; this was the route I chose but I was foolish not to do so immediately after installing OpenSSH.

Moral of the story? Either isolate the phone from the internet before starting up OpenSSH, or try harder to get MobileTerminal installed!

Ports used by Wi-Fi Sync (Jailbroken iPhone app)

Just a quick post to record the hard-won knowledge of just which ports Wi-Fi Sync uses for communicating with the server app running on your iTunes computer:

Wi-Fi Sync 1.1a uses port 48281 (TCP and possibly UDP)

WiFi Sync 2.0ß (build 97) uses port 14867 (TCP)