Log in

Previous 10

Dec. 13th, 2009


A tiny intro to Python ctypes

If you've ever been interested in interfacing with shared libraries and DLL using Python, then there are basically three ways you can achieve it. One is to use Python/C API, second is to use SWIG and the third which I will demonstrate is to use ctypes. ctypes is a great companion to keep around as it allows one to call functions and extract data as C types from a shared library without leaving the pleasant world of Python. Without further ado, let me roll some code.

#include < stdio.h >
#include < stdlib.h >
#include < string.h >

char* getenv2(char * environment)

return getenv(environment);

int _init()
printf("%s\n","Loaded ctype shared library");
return 0;

from ctypes import *
from ctypes.util import find_library
import sys

ctype_sl = cdll.LoadLibrary('./libctypedemo.so.1') # load library

getenv_ = ctype_sl.getenv2(sys.argv[1]) # get 1st arg
ret = c_char_p(getenv_) # cast to char*
if ret:
print "\{0}={1}".format(sys.argv[1],ret.value)

gcc -Wall -fPIC -c ctypedemo.c
gcc -shared -nostartfiles -Wl,-soname,libctypedemo.so.1 -o libctypedemo.so.1 -lc ctypedemo.o
export LD_PRELOAD=./libctypedemo.so.1


$ python ctypedemo.py PATH
Loaded ctype shared library

value for PATH=/usr/local/bin:/usr/local/sbin/:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/sbin:/bin:/usr/games

Hope you enjoyed the tiny intro. Feedbacks are welcome (constructive or destructive otherwise).

Sep. 9th, 2009


This is nasty (Sockstress)

I was going through the details about socktress[0][1] on Slashdot[1] today. I could not believe that TCP/IP specification itself could be distorted yet again. By starting a 3-way handshake in userspace, an attacker would exhaust remote systems' connection table (similar to SYN Floods of the old days[2]) filling up with arbritrary SYN packets on the remote end. On receiving the first ACK from the remote end, the attacker would presumablyn gets hold of the packet in userspace using libpcap[3] and manipulates it however the attacker wishes because theoretically as the paper points out the kernel is suppose to panic and send RST to the remote end (the one the attacker is attacking) because fore sure kernel  didn't ask for an ACK packet now did it[4]? :-) 

The patch to fix SYN DoS in kernel[3] was invented by Daniel Bernstein. It basically did not establish (read: connection state in ESTABLISHED state/3-way handshake complete) the connection until a 3-way handshake was completed in totality - SYN, SYN/ACK, ACK and it used extra crufts to calculate if it was _really_ completed. And what about the one way before SYN flooding? I remember reading a paper about TCP/IP Sequence ID prediction. I do not remember majority of that paper but it essentially pinned down that a remote attacker could predict the sequence ID number of the next packet coming in and hence forge a prepared reply (a spoofed packet destined for somewhere else). 

All these brings me to the deep question seated within me. How much more problems/inherent weaknesses can TCP/IP itself handle? Do we need a new specification AND implementation? That I don't know and I do not have enough years on my belt to design one but it sure sounds like TCP/IP _really_  isn''t designed for today's network security standard of how easy it might be for an attacker to establish DoS. This sure isn't the 70s, 80s or the 90s when programmers were a happy hacker[6]. Thankfully, CISCO IOS and Microsoft Windows has released a patch today. :-)

[0] http://www.sockstress.com 

[1] http://it.slashdot.org/story/09/09/08/1839258/Microsoft-Cisco-Finally-Patch-TCP-DoS-Flaw

[2] http://insecure.org/stf/tcpdos/outpost24-sect-sockstress.pdf (A really good paper if you are interested in network security/programming and system administrator. It is also good for learning the intricacies of TCP/IP stack from a real-world perspective as TCP off-loading implementation _in_ hardware could possibly peruse this knowledge). 

[3] I remember someone implemented SYN cookies or "canaries"? code for Linux kernel (I read about this only couple of years ago after I got more interested in network codes). Yep. it is DJB :-) the inventor of syncookies; who can forget 44 vulnerabilities that his students found in unix kernel? :-)  http://marc.info/?t=110321890800003&r=1&w=2.

[4] If you were curious and flipped here, then you'd obviously know that the userspace started all this hohalla. Post to get an ACK'ed reply in attackers machine, having a libpcap event handler that notifies the userspace code of the incoming packets and sniff the header/payload and then reply back without ever hitting the kernels' tcp stack! This is a bit confusing to me since libpcap itself would need to interact with the kernel using normal execution syscall path via libc right? Or, am I dreaming?

[6] The original "hacker" term. Yes the one that describes someone as being curious, benign and prides in intellectual drive. Who knows some day our aliens overlords might try bringing with them a system that only an hacker understand :-)

Sep. 5th, 2009



 It has been a long time since I blogged. More so due to work reason. I have been busy at work implementing Django-based extraction and analytical platform along with helping refactor tracking system and analytics software amongst others.

When I first started playing around with Django early this year, I thought it was just another fad. I was so wrong! The framework is beautifully written using the concept of MVC (Model-View-Controller)*. You see, I am primarily an application developer software who had no interest in implementing web-based software. JEE software wasn't my cuppa tea but with Django, I am completely in control of each layer of interface down from database models right upto the template :). In essence, it has re-invigorated my interest in web-development and JEE as well.

I can only go so far as to say that Django is a beautifually mastered piece of framework which in days to come will only see a rise in its usage. Django framework is thankfully and proudly an OSS software!

* Except the Django developers call it MTV (Model-Template-View) heh.

Feb. 7th, 2009


No more LJ [I am back yay!]

Dear friends, LJ'ers and rest of the internet,

Its been a pleasure using LiveJournal for a whole year (and half) but due to my personal need, I will be no longer using LiveJournal for blogging. Instead I run wordpress which can be reached @ http://bokey.mine.nu/blog

I look forward to interacting with you all in my new blog :)

I will close this account on March 1, 2009.

I am back! :)


Nov. 17th, 2008


template shell sort

This has got to be fscking documented somewhere c'on Google you can do better!!! Ki$$ my @$$!!

//Shell sort (Knuth, Vol. 3, pg 84)

template<class T> void sort(vector<T>& v)
  const size_t n = v.size( );
  for ( int gap = n / 2; gap > 0; gap /= 2)
    for ( int i = gap; i < n; i++)
      for ( int j = i - gap; j >= 0; j -= gap)
           if ( v[ j + gap ] < v[ j ])
             T temp = v[ j ] ;
             v[ j ] = v[ j + gap ] ;
             v[ j + gap ]  = temp;

Nov. 4th, 2008


aussie partygoers

LMAO! http://au.youtube.com/watch?v=qm61svN4U5g


Nov. 3rd, 2008


Sigh.. it's been a while..

and time goes so quick... <sigh>


Oct. 30th, 2008



Was reading listening to itradio when I came across expired SSL certificate that they pointed out on good 'ol f5's website :P)



Oct. 28th, 2008


error 421 postfix fscking!

My postfix log kept reporting SMTP incoming data timeout. After confirming that it was all good over at canonical's mailing list server, i started poking my ISP. Knowing that ISPs are lazy people, I tried to Google insanely with having limited success on postfix's man page.

The error specifically was:
Oct 28 01:40:02 timbre postfix/smtp[13260]: 7FABBEBBBE: to=<ubuntu-users@lists.ubuntu.com>, relay=lists.ubuntu.com[]:25, delay=5660, delays=5358/0.01/1.1/300, dsn=4.0.0, status=deferred (host lists.ubuntu.com[] said: 421 chlorine.canonical.com SMTP incoming data timeout - closing connection. (in reply to end of DATA command))

After poking around Google for an hour or so, I finally found a hint by none other than the primary author of postfix himself, Wietse Venema on postfix list; I dropped my routers MTU to 1492 promptly, restarted daemon and my postfix started delivering mail without giving me any of the error above.

For a moment, I suspected that one of the router between timbre and chlorine was dropping ICMP packets because as mentioned in here, some of the broken firewall/router deny/reject ICMP packets (which have request for resizing MTU called "MTU discovery") so eventually, the request to scale down MTU wasn't being acknowledged by chlorine and bam! data timeout eventually reported by my postfix.

Oct. 27th, 2008


fscking gmail!

All day i have been getting this 'unable to reach Gmail' message. Its fscking annoying!

Previous 10


December 2009



RSS Atom
Powered by LiveJournal.com