Installing KitKat on Nexus 4 From a Factory Image.

Nexus 4 owners are a bit itchy these days. KitKat is out but nobody got it as an update yet. However, we are step closer to that since Google posted official factory images. If you are prepared to lose all your data, you might as well update OS yourself. I will describe this procedure on Windows and on non-developer’s computer.

NOTE: THIS PROCEDURE WILL DELETE ALL THE CONTENT ON YOUR PHONE.

We’ll definitely need to download Google’s USB drivers. Once you download and unpack the archive, you’ll need to go to Device Manager and find your Nexus device with an exclamation point next to its name. Right-click, Update Driver Software, and select location where you unpacked the driver zip file. Your device should then be named Android ADB Interface.

And we definitelly need ADB and Fastboot tools. While we can get them in Google SDK, I found that Minimal ADB and Fastboot works nicely and it is less fuss to install on a non-developer computer. Just execute installation and do standard Next, Next, Finish dance routine.

Last, but not the least, we need factory image itself. Once downloaded, I usually just unpack it in same directory as Minimal ADB and Fastboot (C:\Program Files (x86)\Minimal ADB and Fastboot on my computer) to avoid setting up the paths (yep, pure laziness).

Next order of business is enabling USB debugging. This means going to Settings, About phone and clicking Build Number 7 times. Your Nexus 4 will pronounce you a developer and you will get additional Developer options in Settings. There you must turn on USB debugging. As soon as that is done, device will ask you for confirmation.

Once allowed, we can go start Minimal ADB and Fastboot command line (or just reuse one automatically started after setup). There we will first check whether device is visible:

adb devices
 * daemon not running. starting it now on port 5037 *
 * daemon started successfully *
 List of devices attached
 04caa50d9f0c7784        device

Assuming device is visible, we’ll reboot into bootloader:

adb reboot-bootloader

Device will go down and you will be presented with a nice screen that probably says LOCK STATE - locked in the last line. We can change that with a simple unlock command:

fastboot oem unlock
...
OKAY [ 30.008s]
finished. total time: 30.009s

Moment of truth is upon us. Now we run update itself:

flash-all.bat
 sending 'bootloader' (2203 KB)...
 OKAY [  0.072s]
 writing 'bootloader'...
 OKAY [  0.333s]
 finished. total time: 0.409s
 rebooting into bootloader...
 OKAY [  0.003s]
 finished. total time: 0.005s
 < waiting for device >
 sending 'radio' (45537 KB)...
 OKAY [  1.437s]
 writing 'radio'...
 OKAY [  2.578s]
 finished. total time: 4.018s
 rebooting into bootloader...
 OKAY [  0.002s]
 finished. total time: 0.003s
 < waiting for device >
 archive does not contain 'boot.sig'
 archive does not contain 'recovery.sig'
 archive does not contain 'system.sig'
 --------------------------------------------
 Bootloader Version...: MAKOZ30d
 Baseband Version.....: M9615A-CEFWMAZM-2.0.1700.97
 Serial Number........: 04caa50d9f0c7784
 --------------------------------------------
 checking product...
 OKAY [  0.002s]
 checking version-bootloader...
 OKAY [  0.003s]
 checking version-baseband...
 OKAY [  0.002s]
 sending 'boot' (6336 KB)...
 OKAY [  0.202s]
 writing 'boot'...
 OKAY [  0.365s]
 sending 'recovery' (6884 KB)...
 OKAY [  0.238s]
 writing 'recovery'...
 OKAY [  0.411s]
 erasing 'system'...
 OKAY [  0.568s]
 sending 'system' (700500 KB)...
 OKAY [ 22.124s]
 writing 'system'...
 OKAY [ 42.031s]
 erasing 'userdata'...
 OKAY [  0.810s]
 formatting 'userdata' partition...
 Creating filesystem with parameters:
     Size: 14129561600
     Block size: 4096
     Blocks per group: 32768
     Inodes per group: 8144
     Inode size: 256
     Journal blocks: 32768
     Label:
     Blocks: 3449600
     Block groups: 106
     Reserved block group size: 847
 Created filesystem with 11/863264 inodes and 95427/3449600 blocks
 sending 'userdata' (137438 KB)...
 writing 'userdata'...
 OKAY [ 12.716s]
 erasing 'cache'...
 OKAY [  0.043s]
 formatting 'cache' partition...
 Creating filesystem with parameters:
     Size: 587202560
     Block size: 4096
     Blocks per group: 32768
     Inodes per group: 7168
     Inode size: 256
     Journal blocks: 2240
     Label:
     Blocks: 143360
     Block groups: 5
     Reserved block group size: 39
 Created filesystem with 11/35840 inodes and 4616/143360 blocks
 sending 'cache' (10984 KB)...
 writing 'cache'...
 OKAY [  1.042s]
 rebooting...

 finished. total time: 80.594s
 Press any key to exit...

Congratulations! Your device is a KitKat.

After this I prefer to make myself a developer and enable USB debugging once more. In a new Minimal ADB and Fastboot command line (because flash-all batch closed our last one), reboot to bootloader and lock it again:

adb reboot-bootloader

fastboot oem lock
 ...
 OKAY [  0.010s]
 finished. total time: 0.011s

Simple power button press later and our device is exactly where we started; minus lost data and plus an android version.

Rolling Your Own

Probably every programmer had a phase when he started to develop his own encryption algorithm. It was probably early in his professional life when he learnt about XOR and the magic it does. Most programmers soon after realize that they are not cryptographers and that their algorithm is shitty at the best. Those who don’t usually work on DRM later (and those things are never broken, are they?)

Professional programmers know that any person can invent a security system so clever that she or he can’t think of how to break it. They heavily rely on a published standards and make their applications work accordingly. Cryptographers take care of encryption algorithms, programmers take care of implementation part and the world is a more secure place.

But it makes me wonder, are we approaching this all wrong? In a spy-happy world where NSA seems to influence security standards and where bulk decryption seems to be a reality, I would argue that own encryption has some benefits.

Since bulk collection relies on all data being in similar format, anything you can do to foil this actually makes you invisible. Let’s assume that AES is broken (don’t worry; it is not). Anyone relying on standard AES would be affected. But if some wise-ass just did XOR with 0xAA there is high probability that his data would skip the collection.

Mind you stupid encryption is still stupid. And if you are targeted by NSA there is high probability that they will get the data regardless of what you do. If you are using some homegrown encryption, it will be broken. However, they will be unable to take this data in an automatic manner. Enough people doing this would mean they need to dedicate human resources for every shitty algorithm out there. And you are probably not important enough to warrant such attention.

Probably smarter choice would be using two encryption algorithms, back to back. You can use Rijndael to encrpyt data once, then use another key (maybe derived via Tiger) with a Twofish. I am quite comfortable saying that this encryption will not be broken by any automatic means. System might have huge gaping holes, but it will require human to find them.

Of course, once you start doing your “twist” on encryption method you suddenly become completely incompatible with all other “twists” out there. Implementations will become slower (yep, double encrypting stuff costs). Implementing two encryption algorithms will not really protect you against targeted attach where e.g. trojan can get used to steal your password and circumvent all that encryption. Nobody will bother to do cryptoanalysis on your exact combination so you are pretty much flying in the dark. And probably another bad thing or two I forgot.

However, there is something attractive in rolling your own encryption using standardized cipher blocks for data you deem important (e.g. password storage). Not only that it is an interesting defense but it also gives you an enjoyment of doing something you know you shouldn’t.

PS: Never take cryptography advice from a random guy on the Internet.

Android X86

My Android phone has died on me last week. Suddenly I had an issue. Bunch of stuff I had on it was not available anywhere else. Not on Windows and especially not on crusty Nokia 6300 I used as a replacement. I had to get another Android. My choice fell onto running Android x86 in VirtualBox.

First step was creating virtual machine. Upon creation I selected Linux 2.6, increased memory to 1024, and got 8 GB disk ready. After machine was created, I disabled absolute pointing device (System) and changed network adapter type to PCnet-FAST III (Network).

I started machine with Android x86 live CD (android-x86-4.3-20130725) and went for installation. There I was met with slightly annoying partition creation (New, Primary, Bootable, Write, Quit) and disk format selection (ext3). I installed GRUB and went for writable system partition. One reboot later (don’t forget to remove DVD) and my new Android device is ready.

Before I could do anything I had to go to Machine menu and disable mouse pointer integration (; remember host key for exit) in order to click-through setup options. And then I noticed that my network wasn’t working and screen was a bit weird size-wise. So I rebooted and selected Debug mode upon next boot.

There I went on to edit /android/system/etc/init.sh (remember vi) and I added new line with netcfg eth0 dhcp near the end (just before return 0). For fixing up graphics, solution was in editing /mnt/grub/menu.lst (vi again) and appending vga=842 (34A) to kernel line. This gave me resolution of 1152x864x16 and that one worked perfectly for me.

Short reboot later (reboot -f) my new Android was ready.

BitLocker on Asus N56VJ

I am a big fan of full disk encryption. It is more of a political issue for me than security one. While I probably have no data that other would find worth stealing a laptop for, I value my privacy and I don’t want just anybody snooping around. And anyway, full disk encryption is always a good policy when having company’s data around. I don’t want to be one to leek company’s private info just because I read it on my personal laptop.

On my Asus N56VJ this proved slightly more difficult than expected. As soon as I would enable bit locker, Windows would go into Recovery and stayed there. Result was unusable system. After fiddling with Windows and BIOS options, I have found problem. Asus’ quick BIOS initialization left computer in an unhappy state that didn’t properly initialize USB drives.

Solution was just going to BIOS and changing Fast Boot to Disabled (together with already Enabled Legacy USB Support).

Visual Studio Express 2013

Visual Studio 2013 Express is available for download.

As always, most changes are reserved for higher tiers (e.g. Professional and Ultimate) but some did survive into Express edition.

Go and try it out. It is free.