taglist – Source code browser plugin for Vim

Tili drew my attention to “taglist” — a source code browser plugin for Vim. Yes! It is a neat thing to have if you plow through large source files in Vim. The source code browser it makes available is pretty bland and a far cry from source code browsers available in full-feature GUI-based IDEs, but, for Vim aficionados, it adds another degree of sophistication, control and power to their overall Vim experience — and if you juggle with code in Vim on a daily basis, you know that that is something to be had absolutely. And, as usual, for my snap-loving fans, I’ve got a treat.

$16’000 bounty for holes in 6 major applications.

Woah. This zapped in like lightening.

iDefense is putting up the biggest bounty ever for individuals to detect critical holes in as many as six different major software systems that form the backbone of the Internet’s infrastructure. There are six bounties of $16’000 each for any remote hole detected in latest stable versions of the following applications: Apache, BIND, Sendmail, OpenSSH, IIS, MS Exchange.

The few security researchers referenced in the article express their doubt that there will be any submissions, stating that all of the six applications listed are really really difficult to have remote holes in them and that the amount offered is just not worth the time and expertise that would need to be expended on finding holes. I am pretty excited, nonetheless. Yes, the odds of anyone finding a critical remote bug in any of these is substantially low, and that each one of these applications has gone through a long history of major bug fixes and has matured over the years like no other application, they are still pieces of software and prone to bugs.

BSA’s crackdown on software piracy in PK: The 35-day grace period

The title of a brief column on the second page of Dawn’s Metropolitan section today caught my attention by surprise. It read “Deadline for installing illegal software”. That is certainly not what you get to read everyday in Dawn.

According to the column, the Business Software Alliance (which I’ve long known as a group trying hopelessly yet persistently to crack down on software piracy in the subcontinent) granted a 35-day grace period to companies in PK using pirated or illegal software to acquire licensed versions of the software being used. Not only that, the BSA also stated that all past copyright infringement acts will be forgotten if companies opt to purchase licensed software within the grace period and get rid of illegal/pirate software. Today’s column highlights BSA reminding the companies that the grace period ends 30 May and that they will continue the crackdown on piracy from the first of June.

I’ve kept a tab, on and off, on BSA ever since their coming into the picture, but I have to admit I was totally oblivious of this grace period. Despite that, I think the decision to roll out the 35-day grace period with the incentive that all previous copyright infringement cases will be overlooked for individual companies in question if they get rid of the pirated software and quickly buy and start using licensed software is a wonderful way to get companies which are making dough by using illegal software in their business to buy and use licensed software. As with any initiative in PK, it remains to be seen how many companies actually have paid heed to this and moved out over to licensed software, and how many have shrugged it away.

The ground realties leave no doubt in what the reaction of major companies in PK would be to BSA’s 35-day grace period initiative. I would love to see how this turns out still.

Hex escape strings in Python: Shellcodes

Those of you who write proof of concept exploit code in Python might have run into trouble trying to interpolate some hex value in between NOP sleds in Python. Consider the following code as an example:

code = "%X" % (130 + length(var), )
shellcode = '\x00\x00\x00\x00' + '\x%s' + '\x00\x00' % (code, )

Python won’t let you do that. It will spit back an “invalid \x escape” error and die. A friend today ran into a similar problem. I tried a couple of variations of %s and %X but to no avail. I then did what I do when I am stumped over a problem: went over to #python on irc.freenode.net to seek advice. A kind soul pointed out the solution.

shellcode = '\x00\x00' + ('\\x' + code).decode('string_escape') + '\x00\x00'

Unfathomable (Random Musings #22)

After all the pain, suffering and sorrow, after so much prayer, so much believing, it ends in an instant, reminiscent of the way one get rids of an addiction — in a jerk. In an instant — and that is it.

FreeBSD `ls’: Colour-coded directory/file listing(s)

I recently got access to a FreeBSD box online. It is hosted in one corner of Junaid’s small room. It is online and I access it remotely.

The default shell on FreeBSD isn’t BASH, but since I like BASH a lot, I have installed and configured it as the default shell. I have configured and tweaked a lot many other things as well. Of many discrepancies I noticed (I’m a fervent user of Slackware Linux), one that I found a workaround to last night has to do with the “ls” utility. For some unknown reason, the “ls” on FreeBSD does not support the “–color=” argument, which I believe the GNU version of “ls” does to colour code output of “ls”. I spent a day baffled by the lack of the –color switch, looking for a way to enable colouring. I know, I know, I should’ve looked at the man page for ls. It is just that Junaid did a massively minimal install of FreeBSD which did not install man and info pages. I had to re-run “sysinstall” to get back the man pages. It was then, reading the man page, I noticed the CLICOLOR environment variable to enable colour-coded output.

So, in short, if you want to enable colour-coding in the output of “ls”, export the following variable:

export CLICOLOR="yes"

Since I use BASH, I’ve placed that in ~/.bashrc.