Updating The Sun JDK On Debian

The final version of sun-jdk-6 in Debian Wheezy before it was removed was 6u26. The latest from Oracle (excluding Java7) is 6u30, so I decided to manually install it myself.

In fact it couldn’t be easier, all you do is download the jdk-6u30-linux-x64.bin file and run it, which extracts it to a directory called jdk1.6.0_30, which you then rename to java-6-sun-1.6.0_30 and move to /usr/lib/jvm, you then delete the java-6-sun symlink and recreate it to point to the newer directory:

root@localhost:/usr/lib/jvm$ ln -s java-6-sun-1.6.0_30 java-6-sun

As alternatives is setup to point to /usr/lib/jvm/java-6-sun there’s no need to update anything for the files we need to build Android for example:

root@localhost:/usr/lib/jvm$ update-alternatives --get-selections | grep java
...
appletviewer                   auto     /usr/lib/jvm/java-6-sun/bin/appletviewer
firefox-javaplugin.so          auto     /usr/lib/jvm/java-6-sun/jre/lib/amd64/libnpjp2.so
java                           manual   /usr/lib/jvm/java-6-sun/jre/bin/java
javac                          auto     /usr/lib/jvm/java-6-sun/bin/javac
javadoc                        auto     /usr/lib/jvm/java-6-sun/bin/javadoc
javah                          auto     /usr/lib/jvm/java-6-sun/bin/javah

jar seems to have been replaced by fastjar on Debian, so there’s no need to link the Oracle version in /usr/lib/jvm/java-6-sun/bin/jar

Finally its a good idea to add this environment variable in ~/.bashrc – again pointing to the symlink, not the specific version:

export JAVA_HOME="/usr/lib/jvm/java-6-sun"

Apparently Cyanogenmod7 will compile using OpenJDK6 (and 7 with a patch) even though AOSP won’t compile with anything other than Sun JDK6.

I’ve also updated the blog to WordPress 3.3

Junos 10

Today I have been mostly installing Junos. Well actually I’ve wasted most of the day trying to get Junos 10.4 to work in Olive under VirtualBox. I understood that it required FreeBSD 7.1, so tried installing it under 7.1 and 7.4 to no avail.

In the end I cloned my Junos 9.0/FreeBSD 4.11 VM, allocated 512Mb instead of 256Mb and installed 10.4 as an upgrade, which also meant I didn’t have to bother removing checkpic.

I wasted a few rounds of installing due to using the export version, which doesn’t include SSH! Also part of the trick of getting it to work under VBox seemed to be to create a serial port as a named pipe – not sure why but that seemed to help get past the bootloader hanging, possibly as it had a TTY to allocate.

I also upgraded my 9.0 to 9.6 which has a bit of a more useful JWeb interface, and also requires 512Mb now.

All of this was to aide my development of a set of NASL scripts to do Junos security compliance auditing. It seems Tenable have worked around the UNIX-only limitation of Nessus’ ssh_cmd() function by putting in a special check for when uname -a fails – i.e. its either IOS or Junos (or unsupported). Of course in Junos shell mode, it will pass (as its FreeBSD) so you have to check that you’re in CLI mode to do the config checking.

Its only taken them four years of me asking for this, and I guess its come as a result of Nessus’s new IOS support for their own compliance plugin and local security checks for Junos patches etc.

Update: I’ve written 20 NASL plugins to do the Junos auditing now and I noticed I was hitting the SSH rate-limit setting in Junos, so my plugins were getting booted off. It was because for each plugin I was calling ssh_cmd() at least once and also a function that checks I could login with the correct level/privileges etc; so was making at least two SSH connection attempts per plugin, which soon hit the 10 connection attempts per minute limit that was configured.

So now I’ve moved all of my ssh_cmd() calls into one big include file which uses a single SSH connection to send 30 or so commands, and populates the knowledgebase with the results. The plugins then have that in their script_dependencies() and don’t use SSH at all, just a couple of calls to get_kb_item() which simplifies the code quite a lot and an entire scan can be done in 10secs!

Building An Android Kernel

As I’ve been compiling Cyanogenmod for the ZTE Blade, I thought I’d have a look at compiling the kernel instead of applying binary patches. I found this tutorial which kind of helped, here’s my simplified summary:

1. Pull kernel source from Github (currently weighs in at 1.7Gb):

git clone git://github.com/TomGiordano/kernel_zte_blade.git

2. Get the .config file – most tutorials say to get this from your phone which is running the kernel that you want to compile, but actually its already stored in git:

cp ~/kernel_zte_blade/arch/arm/configs/cyanogen_blade_defconfig ~/kernel_zte_blade/.config

3. Build the kernel:

make ARCH=arm CROSS_COMPILE=~/cyanogenmod/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi-

4. Build CM7 as usual, and to make things easier we’re going to copy a few files all into the same directory, including the split_bootimg.pl we downloaded:

mkdir ~/custom_kernel
cd ~/custom_kernel/
 
cp ~/split_bootimg.pl .
cp ~/kernel_zte_blade/arch/arm/boot/zImage .
cp ~/cyanogenmod/out/host/linux-x86/bin/mkbootimg .
cp ~/cyanogenmod/out/target/product/blade/update-cm-7.1.0-RC1-Blade-KANG-signed.zip .
cp ~/cyanogenmod/out/host/linux-x86/framework/signapk.jar .
cp ~/cyanogenmod/build/target/product/security/testkey.* .
 
unzip update-cm-7.1.0-RC1-Blade-KANG-signed.zip

6. Unzipping the KANG has given us the META-INF and system directories and boot.img file, which we must now unpack:

./split_bootimg.pl boot.img

6a. Optionally copy across the .ko files mentioned in modules.order to system/lib/modules/2.6.32.9-perf/ the highlighted ones are probably not neccessary:

grep -v test modules.order | sed 's|^kernel/||g'
 
arch/arm/mach-msm/reset_modem.ko
crypto/ansi_cprng.ko
drivers/scsi/scsi_wait_scan.ko
drivers/net/wireless/libra/librasdioif.kodrivers/input/evbug.koarch/arm/oprofile/oprofile.ko

7. Recreate the boot.img with the new kernel:

./mkbootimg --cmdline 'androidboot.hardware=blade console=ttyMSM2,115200 g_android.product_id=0x1354 g_android.serial_number=Blade-CM7' --base 0x2600000 --kernel zImage --ramdisk boot.img-ramdisk.gz -o boot.img

6. Zip up the new boot.img and old META-INF and system directories:

zip -r rom.zip META-INF boot.img system

7. Sign the zip:

java -jar signapk.jar testkey.x509.pem testkey.pk8 rom.zip rom-signed.zip

8. Generate an md5sum of the signed zip so users can check it downloaded properly:

md5sum rom-signed.zip > rom-signed.zip.md5sum

And here’s the screenshot of the running ROM with my kernel:

Click for fullsize

Click for fullsize

Compiling CM7 on Fedora

I decided to have another go at compiling CM7, this time using Fedora 13 on real hardware rather than an virtualised Ubuntu 10.10, which also means adb/udev is already working from when I rooted the ZTE Blades.

I downloaded and installed the Oracle/Sun JDK 6u24 (which includes the JRE).

Setting up “alternatives” to point to the Oracle JDK instead of OpenJDK/GCJ doesn’t work 100% as at least javadoc, appletviewer and javah have to be manually symlinked:

ln -s /usr/java/jdk1.6.0_24/bin/javadoc /usr/bin/javadoc
ln -s /usr/java/jdk1.6.0_24/bin/appletviewer /usr/bin/appletviewer
ln -s /usr/java/jdk1.6.0_24/bin/javah /usr/bin/javah

None of the below tutorials explained why “alternatives” doesn’t work:

Just for good measure I added the following to ~/.bashrc

export JAVA_HOME="/usr/java/jdk1.6.0_24"

After that the compile worked, except it got stuck at some point with a javadoc problem, a quick “make update-api && mka” fixed that.

The cyanogen wiki instructions are incomplete regarding making an AVD using your ROM. Also CM7 now uses the 2.3.3 v10 API, so the last stage should really be:

cd ~/android-sdk-linux_x86/platforms/
cp -R android-10/ android-10-cyanogen/
cp ~/cyanogenmod/out/target/product/generic/*.img android-10-cyanogen/images/
 
cd ~/.android/avd/
cp -R Gingerbread.avd/ cyanogenmod.avd/
cp Gingerbread.ini cyanogenmod.ini

Edit ~/.android/avd/cyanogenmod.ini to read:

target=android-10
path=~/.android/avd/cyanogenmod.avd

Edit ~/.android/avd/cyanogenmod.avd/config.ini to read:

hw.lcd.density=240
skin.name=WVGA800
skin.path=platforms/android-10-cyanogen/skins/WVGA800
vm.heapSize=24
hw.ramSize=256
image.sysdir.1=platforms/android-10-cyanogen/images/

Then you end up with:

CM7

Android Emulator

I’ve setup Eclipse and the Android SDK as I fancied tinkering with CM7 and maybe write an App or two.

Below is a screenshot of a 2.3.3 Gingerbread “AVD” running in the emulator, with my “Hello World!” icon:

Android Emulator

I tried to compile the Cyanogenmod 7 ROM and kernel for the emulator using these instructions on the wiki, however after downloading a few gigs worth of Git repo’s, and a few hours crunching away, it wouldn’t compile.

It seemed to get stuck near the end whilst creating symlinks to Busybox. I think it was stuck in recursive symlink hell – i.e. creating symlinks pointing to other symlinks that pointed to a non-existant file, probably meaning that busybox hadn’t compiled by that point.