Automated Source Code Verification

I haven't been aware of automated source code verification tool prior to reading http://graphics.stanford.edu/~seander/bithacks.html. There, I found that a freely available source code verification tool is in fact exists: http://www-2.cs.cmu.edu/~uclid/. This would improve my ability in finding security bugs in my code :-).

Productive Reading vs Consumptive Reading

After being on the "consumptive reading" side (without being aware) for a couple of months I realized that there are actually two types of reading habit which I have to be always aware of in order to avoid wasting my time on not so important things. They are consumptive reading and productive reading.

I defined consumptive reading as reading information which has no immediate benefit outside of knowing "something is happening and have no immediate consequences on oneself". It does add to one's knowledge but have no immediate effect or impact in productivity (measured by useful output). To put it bluntly, it's "distraction" that consumes ones energy. On the other hand, productive reading is reading information which has immediate effect on ones work, which adds value to ones work by either shorten the time required to finish ones work or helps in other way(s) or will help on other "not so immediate" work.

It's rather easy to recognize consumptive reading. Ask yourself whether what you're currently reading adds immediate value to what you're working on. Whether it improves your skillset or specific knowledge. If it's not, then what you're doing is consumptive reading. If you're not in your "leisure time". Then, it's better to avoid doing consumptive reading because it eats into time available for productive reading or other activities which much more useful for you.

Recognizing these two types of reading "habit" is important in the age of "information overload" like now because we have very limited time to live and we should not waste it. This is not about money or anything. It's about appreciation to life itself. To live life to its fullest :-).

Open Question on DJBX33A Hash Function

Where did Daniel J. Bernstein obtain his 33 constant in the DJBX33A hash function? As we know the DJBX33A (Daniel J. Bernstein "Times 33 Addition") algorithm works like this:

hash_t bernstein_hash(const unsigned char *key)
{
 hash_t h=0;
 while(*key) h=33*h + *key++;
 return h;
}

[Code snippet courtesy of http://en.literateprograms.org/Hash_function_comparison_(C,_sh)]. I wonder if the value was obtained from some sort of mathematical formulae or based results of numerous experiments? Well, yeah. Hashing is still a sort of black-art even now. But, I think there should be some sort of logical explanation.

Gmail Binary File Attachment Bug and Its Fix

If you're attaching a binary file to an email bound to a Gmail account or if you're attaching a binary file to an email outgoing from a Gmail account, be very careful. If your binary file contains the 0Dh, 0Ah byte sequence, Gmail very probably would treat it as text attachment instead of binary attachment which will result in Gmail truncating/deleting the 0Dh byte.

This is bug really annoying, especially if the file requires a "binary precision", it will become unusable. The fix is quite easy, just make Gmail unable to "peek" into the attachment by compressing the file with Winrar or other file compressor. A side note: WinZip or other Zip compressor still enables Gmail to "peek" into your attachment(s).

Idul Fitri, Astronomi dan Navigasi

Untuk sesaat mari kita kesampingkan masalah penentuan 1 Syawal tahun ini dan merunut kembali pendekatan "logis" perhitungan penanggalan Hijriyah dan sejarahnya. Penanggalan Hijriyah adalah "lunar calendar". Artinya penanggalan berdasarkan posisi bulan terhadap pengamat di bumi. Mengapa bulan diambil sebagai patokan perhitungan waktu? Alasannya sederhana, karena posisi bulan relatif mudah di amati dan presisi pengamatan yang cukup akurat sekalipun tidak menggunakan alat bantu. Hal tersebut adalah salah satu alasan peradaban masa lalu menggunakan bulan sebagai patokan. Selain itu, efek dari posisi bulan dapat diamati secara tidak langsung melalui pasang-surut air laut di daerah pesisir.

Penanggalan pada dasarnya adalah pengamatan benda langit, jadi subjek ini merupakan bagian dari ilmu astronomi. Astronomi dapat kita temui pada peradaban masa lalu karena penentuan waktu (penanggalan) merupakan bagian yang penting dari sebuah peradaban. Untuk menentukan hari2 yang penting dan hal-hal lain yang bersifat ritual, penanggalan sangat penting. Hal itu menyebabkan ilmu astronomi selalu berkembang di tempat-tempat dengan peradaban maju.

Kegunaan lain dari ilmu astronomi adalah dalam hal navigasi. Terutama navigasi di laut. Bintang-bintang tertentu mempunyai posisi yang berubah terhadap horizon tergantung posisi kita di bumi (posisi terhadap garis lintang dan bujur). Misalnya, posisi bintang "Polaris" bergerak mendekati horizon jika kita bergerak dari belahan bumi utara ke arah equator. Selain itu, pengamatan terhadap bulan dapat menjadi alat bantu perhitungan waktu untuk kapal-kapal yang berada di laut pada malam hari.

Sekarang, apa hubungan antara astronomi, navigasi dan idul fitri? Hubungannya ada pada pengukuran yang akurat terhadap posisi benda langit terhadap horizon. Salah satu alat (tanpa mekanisme digital dan bantuan satelit) yang paling akurat dalam menentukan posisi benda langit terhadap horizon adalah sextant (http://en.wikipedia.org/wiki/Sextant). Sextant adalah alat navigasi yang ditemukan pada abad ke-18 (http://www.mat.uc.pt/~helios/Mestre/Novemb00/H61iflan.htm).Alat ini digunakan untuk pengamatan benda langit dengan akurat untuk membantu navigasi di masa lalu sebelum GPS ditemukan dan saat ini digunakan sebagai back-up untuk navigasi global sebab tidak membutuhkan suplai listrik dan tetap berfungsi jika satelit GPS mati/tidak dapat dihubungi.

Sextant dapat mengukur posisi benda langit terhadap horizon dengan akurat. Sehingga selain untuk navigasi, sextant juga dapat digunakan untuk membantu perhitungan penanggalan. Jika langit dalam keadaan mendung, sextant dapat melakukan pengukuran dengan menggunakan "artificial" horizon yang "built-in" pada alat tersebut.

Penentuan hilal pada penanggalan Hijriyah, adalah penentuan posisi bulan terhadap horizon (CMIIW). Di luar dari kontroversi berapa derajat kah yang "valid" (government-ego excluded), sextant dapat digunakan jika seandainya kita berada di tengah laut pada saat mendekati idul fitri untuk membuat keputusan sendiri di luar dari pengaruh pemerintah. he..he..he..



Selamat Idul Fitri :-)

How to use Google Patent search

Google patent search (http://www.google.com/patents) is a very valuable search tool. Sometimes it helps reverse engineering task.

I found this method particularly useful:

1. Search based on the specific subject. It doesn't matter if the patent application document that you found is not yet correct because usually patents covering stuff in a very specific subject refers to each other by patent numbers. For example patent A refers to patent B through patent B's number.

2. From the patent B's number found in step 1, search your intended patent application. The patent number format is: YEAR/PATENT_NUMBER. For example patent number 207272 in year 2008 would be: 2008/0207272. Now, to search this patent, use the patent number (minus the slash), i.e. 20080207272 in google patent search.

That's it you're good to go.

Microsoft VC++, C99 Standard and __func__ Macro

Apparently, even VC++ 2010 included in Visual Studio 2010 still adheres only to part of the C99 standard. This is really irritating because you have to define different macros if you are debugging your function with the C99 __func__ "predefined" macro.

The list of supported ANSI macros in Visual Studio 2010 can be found at http://msdn.microsoft.com/en-us/library/b0084kay%28v=VS.100%29.aspx.
You will see that in the aforementioned link, Visual Studio 2010 provide an M$-specific macro, i.e. __FUNCTION__ if you want to refer to the current function name in your routine inside that function. It doesn't provide the C99-sanctioned __func__ macro. This would lead to failure during compilation if you try to use the __func__ macro in your code.

On the other hand, GCC supports C99 standard, at least in this particular case (__func__ macro), as shown here.

IDA Pro GUI Plugin "Trivial" Bug

If you are using IDA Pro (probably version > 5.4) plugin template to develop a GUI-based plugin, you'll probably encounter this bug: The GUI of the plugin suddenly vanish after the plugin activated (run() function invoked)

This "trivial" bug manifests if you don't change the default value of the plugin flags in the plugin_t structure.
The default value for the plugin flags is PLUGIN_UNL which means: Unload the plugin immediately after calling 'run'. This flag may be set anytime. The kernel checks it after each call to 'run'. The main purpose of this flag is to ease the debugging of new plugins.. This explanation comes from loader.hpp. Now, to avoid the "suddenly vanishing GUI" bug,
you should change the plugin flag to suit your need. For example:

...

//--------------------------------------------------------------------------

//

//      PLUGIN DESCRIPTION BLOCK

//

//--------------------------------------------------------------------------

plugin_t PLUGIN =

{

  IDP_INTERFACE_VERSION,

  PLUGIN_DRAW,          // plugin flags

  

  init,                 // initialize



  term,                 // terminate. this pointer may be NULL.



  run,                  // invoke plugin



  comment,              // long comment about the plugin

                        // it could appear in the status line

                        // or as a hint



  help,                 // multiline help about the plugin



  wanted_name,          // the preferred short name of the plugin

  wanted_hotkey         // the preferred hotkey to run the plugin

};

...

The PLUGIN_DRAW flag means:

...

#define PLUGIN_DRAW 0x0002      // IDA should redraw everything after calling

                                // the plugin

...

Qemu CPU Freeze Bug in Slackware 13 x86_64

So, I have this requirement to debug BIOS in Qemu, so I need to "freeze" the CPU on Qemu in the very first instruction. I've tried using Qemu version 0.9.x, 0.12.x and 0.13.x in Slackware 13 x86_64, passing the "-s -S" (without quote) as qemu parameter but none of them worked.

In frustration, I tried version 0.14.1 and it finally worked as expected. The following is a modified slackbuild script (originally coded by Andrew Brouwers for Slackware 13 i486) to build Qemu 0.14.1 in Slackware 13 x86_64.

#!/bin/sh

# Slackware build script for qemu

# Copyright 2009, 2010  Andrew Brouwers 
# All rights reserved.
#
# Redistribution and use of this script, with or without modification, is
# permitted provided that the following conditions are met:
#
# 1. Redistributions of this script must retain the above copyright
#    notice, this list of conditions and the following disclaimer.
#
# THIS SOFTWARE IS PROVIDED BY THE AUTHOR ''AS IS'' AND ANY EXPRESS OR IMPLIED
# WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
# MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
# EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
# PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
# OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
# WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
# OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
# ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

# Modified by the SlackBuilds.org project

PRGNAM=qemu
VERSION=0.14.1
ARCH=${ARCH:-x86_64}
BUILD=${BUILD:-1}
TAG=${TAG:-_SBo}

CWD=$(pwd)
TMP=${TMP:-/tmp/SBo}
PKG=$TMP/package-$PRGNAM
OUTPUT=${OUTPUT:-/tmp}

if [ "$ARCH" = "i486" ]; then
  SLKCFLAGS="-O2 -march=i486 -mtune=i686"
  LIBDIRSUFFIX=""
elif [ "$ARCH" = "i686" ]; then
  SLKCFLAGS="-O2 -march=i686 -mtune=i686"
  LIBDIRSUFFIX=""
elif [ "$ARCH" = "x86_64" ]; then
  SLKCFLAGS="-O2 -fPIC"
  LIBDIRSUFFIX="64"
fi

set -e

rm -rf $PKG
mkdir -p $TMP $PKG $OUTPUT
cd $TMP
rm -rf $PRGNAM-$VERSION
tar xvf $CWD/$PRGNAM-$VERSION.tar.gz
cd $PRGNAM-$VERSION
chown -R root:root .
chmod -R u+w,go+r-w,a-s .

# --libdir isn't recognized and isn't needed anyway
CFLAGS="$SLKCFLAGS" \
CXXFLAGS="$SLKCFLAGS" \
./configure \
  --prefix=/usr \
  --enable-system \
  --enable-user \
  --audio-drv-list=alsa,oss,sdl,esd

make OS_CFLAGS="$SLKCFLAGS"
make install DESTDIR=$PKG

find $PKG | xargs file | grep -e "executable" -e "shared object" | grep ELF \
  | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null || true

# move any generated man pages to their proper location
if [ -d $PKG/usr/share/man ]; then
  mv $PKG/usr/share/man $PKG/usr
  gzip -9 $PKG/usr/man/man?/*.?
fi

# Add docs, and if present, built documentation to the proper location
mkdir -p $PKG/usr/doc/$PRGNAM-$VERSION
cp -a TODO README LICENSE COPYING COPYING.LIB MAINTAINERS \
  $PKG/usr/doc/$PRGNAM-$VERSION
if [ -d $PKG/usr/share/doc ]; then
  mv $PKG/usr/share/doc/qemu/* $PKG/usr/doc/$PRGNAM-$VERSION/
  rm -rf $PKG/usr/share/doc
fi

cat $CWD/$PRGNAM.SlackBuild > $PKG/usr/doc/$PRGNAM-$VERSION/$PRGNAM.SlackBuild

mkdir -p $PKG/install
cat $CWD/slack-desc > $PKG/install/slack-desc

cd $PKG
/sbin/makepkg -l y -c n $OUTPUT/$PRGNAM-$VERSION-$ARCH-$BUILD$TAG.${PKGTYPE:-tgz}

The changes that I made to the original slackbuild script as follows:

...
VERSION=0.14.1
ARCH=${ARCH:-x86_64}
...
./configure \
  --prefix=/usr \
  --enable-system \
  --enable-user \
  --audio-drv-list=alsa,oss,sdl,esd
...

I added "--enable-user" switch to configure script invocation.

That's it. After these changes, Qemu works as expected. I was using coreboot binary as a test case for "-s -S" Qemu parameters and it worked.

Hydrogen Peroxide Use in Medical and Rocketry Applications

So, what this Hydrogen Peroxide have to do with programming? Well, nothing actually. At least nothing directly related. It's just I can't keep this thing in my mind so it's better to write it out.

I went to a doctor to treat my wound and I found out that he used H2O2 (Hydrogen Peroxide) to clean the wound. I found it rather surprising because I didn't know H2O2 is also used as "cleaning agent" in medical application previously. All I knew about H2O2 was it's use in rocketry (http://en.wikipedia.org/wiki/Armadillo_Aerospace).

If you look at http://en.wikipedia.org/wiki/Hydrogen_peroxide. This chemical compound has a lot of uses. Still, it's just incredible to think that you can use the same compound to treat your wound and to do rocketry.

Building Qemu 0.12.3 for Slackware 13 x86_64

The Qemu package slackbuild file from slackbuilds.org ( http://slackbuilds.org/repository/13.0/system/qemu/) by default compiles for x86 (i486) target. This will cause a build error on Slackware 13.0 x86_64 systems. In order to build the package from the source, you have to change the target in the slackbuild file to:

...
ARCH=${ARCH:-x86_64}
...

This way the package build should be successful in Slackware 13 x86_64 systems.

Unusual way to learn Compiler Design

Compiler design is probably a rather boring subject without a real-life example. However, it's a very important subject in the field of reverse code engineering. How to learn it in an entertaining way? well, if you haven't read The Art of Disassembly, then you should read it now. You can download it from many places on the net, for example:The Art of Disasembly

Chapter 2 in the book specifically explains about compiler design for x86 architecture. The book is a bit old. However, the knowledge contained in it is very fundamental.

_CRT_SECURE_NO_WARNINGS Error Message in Visual Studio 2010 (VC++)

Using "legacy"/"unsecure" I/O functions in Visual Studio 2010 would trigger error similar to this:

1>emufuncs.cpp(672): warning C4996: 'fopen': This function or variable may be unsafe. Consider using fopen_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
1>          C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\stdio.h(234) : see declaration of 'fopen'

which results in this error:

1>peutils.cpp(64): error C3861: 'dont_use_fgetc': identifier not found
1>peutils.cpp(224): error C3861: 'dont_use_fseek': identifier not found
1>peutils.cpp(229): error C3861: 'dont_use_fread': identifier not found
1>peutils.cpp(247): error C3861: 'dont_use_ftell': identifier not found

If you insist on using the "legacy" code, the solution is to define the following preprocessor definitions in your Visual Studio 2010 project properties:

USE_STANDARD_FILE_FUNCTIONS;_CRT_SECURE_NO_WARNINGS;

The preprocessor definition can be accessed in this menu: Project|Properties(Alt+F7)|Configuration Properties|C/C++|Preprocessor|Preprocessor Definitions.

After defining USE_STANDARD_FILE_FUNCTIONS;_CRT_SECURE_NO_WARNINGS; in your Visual C++ project, you should be good to go.

Happy coding.

Visual Studio 2010 Code Editor Bug (Applies to C++ Code Editing)

Visual Studio 2010 Code Editor has stability issues in several platforms (mine is Windows 2008 Server SP2 - x86) as described here. In that description, the guy was having a slow response in IntelliSense.

Unfortunately for me, I was not only experiencing the lag, but also frequent crashes which was very irritating. The cause is a dependency on Windows Automation API.

The Bug Fix can be downloaded at http://support.microsoft.com/kb/971513/. Apparently, Visual Studio 2010 has dependency on Windows Automation API v3.0 which didn't ship with Windows Server 2008 SP2 or Windows Vista and previous Microsoft OSes.

Hopefully, this helps poor souls out there who gets irritated during C++ development in VS2010.

Goodluck :-)

Developing Software for Embedded Systems

Developing software for embedded system is particularly challenging. Therefore you have to make sure:

1. You know how to get debugging messages out of the system during development. Otherwise countless nightmare will wait for you.

2. Always place a "failsafe" code inside your brand new code so that the system would always recover to a point where you would be able to restore the system back to previously known working condition.

Now, let me explain point 1. Because not all embedded system contains a display, the debugging messages usually forwarded to an UART. The reason is simple, UART is a very simple digital device to initialize. In present day x86 systems, UART usually resides in the SuperIO chip or in the southbridge chipset. A display is far more difficult to initialize compareed to UART and sometimes does not available in the target system. By using an UART, it is also easier to do debugging once the system is deployed.

Let's move to point 2. In some systems, you have to remove some sort of flash chip and flash it somewhere else to recover from a bad software. Therefore, in order to reduce the hassle, it's better to provide "failsafe" code whenever possible.