diffutils for windows 64-bit

Needed to diff large (> 1GB) text files as part of a toolset, but DiffUtils provided by gnuwin32 is 32-bit only ūüė¶ Of course I tried, but expectedly, it failed to diff the large files. Next solution: compile a native 64-bit version of diff. (Why is there no gnuwin64?) Anyway, I chose to compile on a x86_64 linux machine because I happen to have such a test machine around.

apt-get install mingw-w64
wget http://ftp.gnu.org/gnu/diffutils/diffutils-3.3.tar.xz
tar xJf diffutils-3.3.tar.xz
cd diffutils-3.3
# get diffutils-3.3-mingw64.patch and place it here
patch -p1 -i diffutils-3.3-mingw64.patch
./configure --host=x86_64-w64-mingw32 --prefix=/tmp/diffutils-3.3-mingw64
make && make install

Now, the goods are in /tmp/diffutils-3.3-mingw64/bin. Enjoy!

The file diffutils-3.3-mingw64.patch can be found under Resources. I would have gladly pasted the file here if not for the non-printable character found in the original source. If anyone knows the settings for diff to generate pure printable patch file do drop a comment below, thanks!

Further interesting read: MinGW 64 how-to


Pin deprecates nmake on windows

The latest release of Pin (version¬†2.12-56759) removed support for nmake (and the nmake.bat that came with it) ūüė¶ Instead, make is now the recommended way of compiling pintools. There are several ways to get GNU make: via Cygwin, MinGW, or download the setup for¬†Make for windows manually. I chose the latter because I have no love for cygwin, which also explains why there is no link for it ūüėõ Also, getting the entire cygwin just for make is a total overkill. I am already running MinGW from Git for Windows, so the setup alone will suffice.

There we go! Go ahead and make (or make TARGET=ia32, for those who are compiling 32-bit pintools on 64-bit OS). However, make clean still breaks (see link at bottom of post for possible explanation, however the proposed solution is still quirky for Pin), but we shall “make” do for now.

Below are the recent changes, for completeness:

Changes added _After_ Pin 2.12 / 54730
o The PinTools makefile infrastructure has been changed. It is now simpler to use and to modify.
For detailed information, read the documentation in source/tools/Config/makefile.config.
o Nmake is no longer supported on windows. Either use make or the example vcproj file in the
MyPinTool directory.
o Android support has been added. An Android tutorial is avaliable at: <android-kit-root>/AndroidTutorial.
o The directory tree under <pinkit>/source/include has been changed, the include files are now located at:
<pinkit>/source/include/pin and <pinkit>/source/include/pin/gen.

windows – make: Interrupt/Exception caught – Super User

Static routing on windows network using consumer router

I never really understood the presence of static routing on consumer grade routers. But recently, I got the opportunity to try out that functionality in office and tearing out my hair at the same time (read: networking n00b). Documenting the steps here to prevent further hair-loss.


ISP <—> Router A [] <—> Router B¬†[]

Router A
WAN IP: DHCP-assigned by ISP
Gateway: DHCP-assigned by ISP
Static route: (Destination), (Netmask), (Gateway), (Interface) LAN

Router B

Basically that is all for configuration on both routers for the illustrated setup. For windows machines that are directly connected to Router A [], an incoming rule has to be added to the hosts’ firewall to allow incoming ICMP redirect packets from the Router A, assuming the firewall is enabled.

On Windows Vista and above, the following command (run as administrator) will add the rule:

netsh advfirewall firewall add rule name="enable static routing" dir=in action=allow enable=yes profile=private remoteip=defaultgateway protocol=icmpv4:5,any

In English, the command “adds a rule with name ‘enable static routing’, for the¬†incoming direction,¬†that allows traffic to pass, at the same time enabling the rule, for the private profile, only from the default gateway, with ICMP v4 redirect packets”. Tweak as needed.

Yes, it potentially requires configuration on the clients. A more transparent alternative is to dish out static routes to clients via DHCP server and eliminating the need to configure the firewall, but that is out of the scope of this post. Which brings me back to my original thought: if a user need to configure so many items, on both routers and clients, will it be better to provide an option to serve routes via DHCP? Without which, is this whole static routing even suitable for a home user on a home router?

Netsh Commands for Windows Firewall

DHCP option 121

Installing Windows 7 SP1 on dual boot system

I had problems installing win 7 sp1 on the dual boot system which has ubuntu installed. The error was 0x800f0a12, which meant nothing to me.

According to source from MS, this was “due to the automount policy for your machine being set to disable”. Whatever that is, the solution is simple:


2. automount enable

3. Restart

4. Install SP1

Works for me, and it’s all that matters.

Windows 7/2008 R2 Service Pack 1 fails with 0x800f0a12

Using doskey to setup alias

This is obviously old, but still useful nonetheless. I’m using it as an alternative to adding a directory to PATH, but there are many more use-cases. The 2 steps below will store the aliases (“macros”, in windows speak) in a file and setup the command prompt to load them every time it is started.

Put the aliases in %userprofile%\mymacros.txt:
VBoxManage="c:\Program Files\Oracle\VirtualBox\VBoxManage.exe" $*

In HKEY_CURRENT_USER\SOFTWARE\Microsoft\Command Processor, create/edit a string value “AutoRun”:
doskey /macrofile="%userprofile%\mymacros.txt"

The aliases (macros…) should be ready the next time the command prompt is started.

Doskey reference

Scaling the Great Firewall of China

It’s not news: China blocks a myriad of web sites which are deemed unsuitable for its citizen. But I’m not its citizen. On the occasional trips to China I suffer withdrawal symptoms from the lack of facebook, youtube and other random sites. Not to mention the epic distress suffered from keywords/URL filtering and strange results for things related to Tibet/Tiananmen (oops!).

VPN is a fine solution, but me being lazy, I prefer using softwares already present on my systems. SSH tunneling seems to fit the bill just nice. OpenSSH outside China (checked), Putty on laptop (checked), ready!


  1. Under Session, enter hostname.
  2. Under¬†Connection > SSH > Tunnels, enter source port,¬†select ‘Dynamic’ and click ‘Add’.
  3. Select ‘Open’ and log in with username and password.
  4. Halfway done; leave the window open.

OpenSSH (for *nix only)

    ssh -C2qTnN -D source_port_number username@remote_host.com

Browser (edit: only Firefox at the moment)

  1. Generally, look under options/preference > network > proxy to enter the address ‘localhost’ for¬†SOCKS5 proxy using the source port number chosen.
  2. edit: (For Firefox) Enter about:config in the address bar, go (and promise you’ll be careful), enter¬†network.proxy.socks_remote_dns in the filter bar and set the value to true.
  3. Surf on past the Great Firewall of China!

China happens to be the unfortunate example; insert country-that-does-funky-things-to-network-traffic here.

edit: Among the mainstream browsers, only Firefox allows remote DNS resolution via SOCKS proxy right now.

edit: Empirically, setting keepalive to 2 seconds on client-side seems to improve connectivity (China).

Loading symbols in IDA Pro

IDA Pro has included symbol loading facility some time back. But different installations had yield different results; sometimes symbol loading works, sometimes it didn’t. This has led me to scratch my head for an extended period of time until now.

What happened is when IDA ask the following:

IDA Pro has determined that the input file was linked with debug information. Do you want to look for the corresponding PDB file at the local symbol store and the Microsoft Symbol Server?

it made use of its dbghelp.dll and symsrv.dll to load the symbols. We are supposed to accept Microsoft’s terms for using their symbols, but since symsrv.dll is used directly by the plugin the prompt to accept the terms is not displayed, the license cannot be accepted, and hence the symbol loading fails.

The solution is to include an empty symsrv.yes file alongside symsrv.dll in IDA’s directory to indicate that we’d gladly accept the terms that never appear.