access google contacts through python using google apis

An address book completely online, it can be accessed from net from mobile, from netbook, pdas...gud idea right !!. well here comes google's address book APIs. There is no argument that google's address book is the best online address book.
So lets go to live with it.... ( 1 hrs )
Google contact APIs are available for python, java, javaScript,... But to explain I think python is best as it is very simple.
Requirements : Google contact APIs for python ( google it to download ), Python 2.x( mine is 2.6 ), my operating system is ubuntu. PS: Net connection is a must.
Here as I am using Linux, the explenation is based on linux.
First set the path to the apis. For that, first untar the tar file to some place. Inside that there are two folders atom and gdata. set python path to that folders as follows.
Open a terminal and type,
PYTHONPATH=$PYTHONPATH:/folder/folder/.../ folder/gdata/
okie then enter into python. type python2.6 in terminal ( or python2.x, x is your version, type python and press "tab" ). Then do the following scripts.

import atom
import gdata.contacts
import gdata.contacts.service

gd_client = gdata.contacts.service.ContactsService()
gd_client.email = 'yourmail@gmail.com'
gd_client.password = 'yourpassword'
gd_client.ProgrammaticLogin()

feed = gd_client.GetContactsFeed()

for i, entry in enumerate(feed.entry):
     print '\n%s %s' % (i+1, entry.title.text)    
     if entry.content:
         print '    %s' % (entry.content.text)
     for email in entry.email:
         if email.primary and email.primary == 'true':
             print '    %s' % (email.address)

You can write it into a name.py file and run with python command or write each line one by one in python command line. Okie, you got your contacts. This is just for testing google Contact APIs. The APIs provides all the main functions like new, update, retrive,etc..
So the real code we can try in java and j2me as j2me is used for mobile, pdas and java is good for netbooks, touch pads etc.. So it is like a single contact book.
In mobile speed will not be a big problem as one contact set size will go only to some few bytes ( some 50, 60 bytes ). And even if GPRS is as slow as 1kbps( ie 1000bits = 125 bytes ). So it will load in a half second. It is more fast than mobile address book. mmmmm.... really the juice is worth the squeeze.

read more at :
http://code.google.com/apis/contacts/docs/1.0/developers_guide_python.html

Hack your Master Boot Record..

MBR,is the first 512 bytes of any storage system ( can be USB drive hard disk CDROM or any storage media ) is the place where the details about the partitions in that storage drive is kept. More than partition table MBR contains a code area, which contains the code to be executed and some other areas also.

That means when BIOS completes its routne checkups and POST (Power on self test) kind of stuffs, it then loads the code in the code area of the MBR. Loading means fetch the code and put it into the RAM :). Then loads the Program counter with the first address of this loaded code. So this piece of code will starts executing from the next cycle ( what is this cycle? :) )...

So now the ball is in our side. That small code can create magic. Normally it loads the basic OS kernel, it can be GRUB first stage.. ( google GRUB first stage to know it more ) ..

Want to see the MBR ( master boot record )...
If you are using linux, it is easy to see and analyse the MBR..

Before hacking the MBR we need its architecture.. just go through the MBR table given in this wiki link http://en.wikipedia.org/wiki/Master_boot_record

First take a terminal, log in to root and then run cfdisk. This will display the partitions. Check the partition whether it is sda or hda. In my system it is sda, so I am explaining for sda. For hda just change sda to hda.

• run this line in terminal dd if=/dev/sda of=/root/Desktop/afile bs=512 count=1 ( of can be any path and file ).
  
• run hexdump -C /root/Desktop/afile , you can see the canonical hex+ASCII display.
• to test whether what you got is MBR or not, just check the 01FE and 01FF addresses when you execute the above line. It will be aa and 55 respectively as shown in wikipage.
  
• Now lets go to code area ( 0000-01B7), hexdump the file and analyse the code area..
• the table of primary partitions is from (01BE-01FD), 64 bytes ( Four 16 byte entries )..
• 01BE-01CD; 01CE-01DD; 01DE-01ED; 01EE-01FD; <- four sixteen byte entries.
• 01FE and 01FF are explained earilier as 55 and aa.

For eg: in my system the following are the four 16 byte entries.

• 80 01 01 00 07 fe ff ff 3f 00 00 00 37 16 71 02
  
• 00 fe ff ff 07 fe ff ff 76 16 71 02 3f 14 a8 04
• 00 fe ff ff 83 fe ff ff b5 2a 19 07 ca 7a b5 05
• 00 fe ff ff 05 fe ff ff 7f a5 ce 0c 33 91 3b 00
  

In the above four, my first partition only is bootable which shows the first byte(80-bootable, 00-non-bootable).
For to crack the details of other 15 bytes, go to the above mentioned wiki page and refer to "layout of one 16 byte partition record" table.. :).

Next intresting area in the MBR is the code area(446 bytes)... so what is it ?
This code area contains bootstrap program. GRUB is an example for this. GRB contains three stages. Stage 1 resides in the 446 byte code area of the MBR. It loads Stage 1.5.
Stage 1.5 resides in a 30KB immediately following the MBR.
So lets see it in our system.

• run this line in terminal dd if=/dev/sda of=/root/Desktop/bfile bs=30720 count=1 as we do earlier. 30720 is 512+30KB ( to read the 30KB after first 512).
• analyse bfile from address 0200( where the 30KB stage 1.5 starts )...
• run this line to analyse the bfile, hexdump -C /root/Desktop/bfile | less
• On scrolling the output of above command, you can see some messages and other lines on the fourth column that you have seen rarely while booting...(fourth column is the character printout of the hex files ).
  
• hexdump the bfile with its different options ( man hexdump ).
• In the fourth column you can see a line like "/boot/grub/stage2" and "/boot/grub/menu.lst" which is the stage 2 file, and menu.lst is the file which forms the interactive OS selection in GRUB.

This is some of my views on MBR. Infact, efficent MBR editing programs are available. Editting with dd command is dangerous, but it is the best way to learn the MBR.