This is default featured slide 1 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 2 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 3 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 4 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 5 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

Saturday, May 31, 2008

Turn your Windows Mobile phone into an iPhone

Whether we admit it or not, we're all at least a little in love with the iPhone. However, a lot fewer of us are $500-in-love with the iPhone. If your clunky old Windows Mobile phone is just sitting around collecting iPhone jealousy dust, you can either scrounge together 500 leafy Sacagaweas, or you can customize your Windows Mobile phone to emulate several of the iPhone's more interesting features, like the iPhone's home screen, flick-scroll contacts, and the fancy slide-to-unlock.

Today I'll highlight a couple of methods for skinning your Windows Mobile phone to look and feel like an iPhone.* Hit the jump to see some videos of the Windows Mobile iPhones in action and to find out how to achieve the same results.

* NOTE: No, no matter what you do, it still won't be an iPhone, and I agree, you shouldn't try to make an orange into an Apple (har har). But some of the iPhone's features as implemented using the methods described below are, frankly, either better or more intuitive than the Windows Mobile default, and I'm thrilled to bring even an ounce of that usability to my smartphone.

There are actually two methods I'm going to highlight, both of which give good results, neither of which are the definitive tools for the job (the Windows-Mobile-as-iPhone community is surprisingly active). One method is relatively simple, the other requires a little more legwork.

Part 1: The easy way

The easy method revolves around a skin (see the video for a closer look) which you can download here (look for the link). From your download, you'll want to copy the following files to a folder on your Windows Mobile phone (you should to be connected to your computer via ActiveSync):

  • launcher.exe
  • config.ini
  • GFX folder

After you've copied the files onto your smartphone, you can give it a quick test by navigating to the folder you've copied them to with File Explorer and running the launcher.exe. Launcher should give you the iPhone-like home screen. However, you will notice by default that the buttons on the home screen won't all point to something you can use, since each button points to a program, and some of them won't match anything on your Windows Mobile device. Luckily, this just requires some tweaking that we'll get to below.


Now download Slide 2 Unlock, the app that will give you that clever iPhone lock screen. This one's an installable .cab file, so copy it to your Windows Mobile phone and install it. It should install itself in your Program Files directory.

Now back to customizing the programs in our iPhone launcher. You can edit the application that each button points to by editing the config.ini file that resides in the same directory as launcher.exe. Since you can't open it directly from your device, just copy it back to your desktop and open it in your favorite text editor. It should look something like this:

[Button Config]text=\Windows\tmail.execalendar=\Windows\calendar.exeetc...

In order to edit the programs that each button launches, just find the button in the config.ini file and edit the path to the to-be-launched application. For example, I don't need to tap the Clock button to see my clock settings. Instead, I've mapped clock to run Slide2Unlock, which has a big, beautiful clock. To accomplish this, the new line in the config file looks like this:

clock=\Program Files\Slide2Unlock\slide.exe

If you wanted to take things even further, you can customize the images in the GFX folder that you copied to the same directory as launcher.exe. Inside are all of the small BMP graphics that make up your interface. Just copy your own buttons into the GFX\Icons folder with the same name as the button you want it to replace (the names are hard-coded, so you have to keep with the same naming scheme). To change the actual text, you'd need to edit the images in GFX\Res (it does get a bit tedious if you take the customization to this level).

That's really all there is to it. Once you've customized one button, you should get the idea of how you could customize any of the buttons (both visually and behaviorally). That said, here are my recommendations:

  • Leave SMS, Calendar, Photos, Camera, Calculator, and Notes as-is. These all pretty much link where most of us would want them to out of the box.
  • windows-live-mobile.pngMap the Maps button to either Google Maps Mobile or Windows Live Search. (According to Gizmodo, Windows Live Search is better—at least on Windows Mobile devices.)
  • Map the Clock button to launch Slide2Lock (as described above).
  • This is certainly personal preference, but I prefer the Settings button to launch the Wireless Communication manager tool. If you use your regular Settings tools more than I do, you might want to keep this the same.
  • I remapped Phone to open up the flick-to-scroll contacts app, iContact. (You can always just hit the Call key to get to your phone dialing skin.)
  • Map web to whatever browser you prefer, from the built-in IE to Minimo or Opera (Safari may be in Windows, but don't look for it any time soon in Windows Mobile).
  • ppod.png
  • Point your iPod key toward your favorite media player; for example, if you downloaded it once-upon-a-time, the pPod/iPod skin for Windows Mobile.

To be honest, I'm not entirely sure yet what to do with Stocks or Weather, since I don't actually know of any good and free Windows mobile apps that cover those areas; if you do, please tell us about them in the comments. Otherwise, you could certainly change the icons and programs they launch altogether if the mood strikes you.

Finally, there's a great iPhone dialer skin available in the zip file made available in this more comprehensive, more complicated WinPhone tutorial (more below—you can also see it in action in the video below). If you download the file, you should find the installable .cab file in the Dialpad folder.

Part 2: The harder way

The method I described above, however convoluted it may seem, is actually very easy, especially in terms of Windows Mobile customization. If you want to really go all out into skinning your WinPhone to look more iPhoney (isn't that Steve Jobs' nickname?)—from every detail down to the keyboard and calculator—check out the download and instructions available here. I had less luck setting up my phone with this method (your mileage may vary), but as you can see from the video, the results are a bit more comprehensive. If you've got the time to install and troubleshoot, and you really want to iPhone your WinPhone, you might want to give it a go.

And that's that. While I can understand that this whole process might seem a bit frivolous to some, I stand before you as a man who does not like Windows Mobile. The 15 minutes it took me to set up my phone using the first method will be well worth the payback I get in the long run from improved usability. If you love the iPhone interface and still don't see the point in tweaking you Windows smartphone thusly... well, June 29th is just a stone's throw away.

Adam Pash is a senior editor for Lifehacker who is into the iPhone. His special feature Hack Attack appears every Tuesday on Lifehacker. Subscribe to the Hack Attack RSS feed to get new installments in your newsreader.

Hack a Mobile Phone with Linux and Python

A mobile phone is a cool gadget to play with, especially when I can run my favourite programming language (no prize for guessing what it is!) on it! That was the logic which made me purchase a Nokia Series 60 smartphone, the N-Gage QD. This article describes a few experiments I did with the mobile - like setting up Bluetooth communication links, writing Python/C code and emulating serial ports.

Bluetooth on Linux

Bluetooth is a short distance wireless communication standard. It is commonly used to facilitate data transfer between PC's and cell phones/PDA's without the hassle of `wired' connections. The hardware which provides Bluetooth connectivity on the PC is a small device called a `USB-Bluetooth dongle' which you can plug onto a spare USB port of your machine. I approached the local electronics dealer asking him for such a device and got one which didn't even have the manufacturer's name printed on it. The driver CD which came with it of course contained only Windows software. Deciding to try my luck, I plugged the device on and booted my system running Fedora Core 3 - bluetooth service was started manually by executing:

sh /etc/init.d/bluetooth start

Here is the output I obtained when the command `hciconfig' ( which is similar to the `ifconfig' command used to configure TCP/IP network interfaces) was executed:
hci0: Type: USB
BD Address: 00:11:B1:07:A2:B5 ACL MTU: 192:8 SCO MTU: 64:8
RX bytes:378 acl:0 sco:0 events:16 errors:0
TX bytes:309 acl:0 sco:0 commands:16 errors:0

My no-name USB-Bluetooth dongle has been detected and configured properly! The number 00:11:B1:07:A2:B5 is the Bluetooth address of the device.

Detecting the mobile

The next step is to check whether Linux is able to sense the proximity of the mobile. If your phone has bluetooth disabled, enable it and run the following command (on the Linux machine):

hcitool scan

Here is the output obtained on my machine:
Scanning ...
00:0E:6D:9A:57:48 Dijkstra

The `BlueZ' protocol stack running on my GNU/Linux box has `discovered' the Nokia N-Gage sitting nearby and printed its Bluetooth address as well the name which was assigned to it, `Dijkstra'.

Pairing the mobile

For security reasons, some interactions with the mobile require that the device is `paired' with the one it is interacting with. First, store a number (4 or more digits) in the file /etc/bluetooth/pin (say 12345). Stop and restart the bluetooth service by doing:

sh /etc/init.d/bluetooth stop
sh /etc/init.d/bluetooth start

Now initiate a `pairing' action on the mobile (the phone manual will tell you how this is done). The software on the phone will detect the presence of the Bluetooth-enabled Linux machine and ask for a code - you should enter the very same number which you have stored in /etc/bluetooth/pin on the PC - the pairing process will succeed.

Transferring files

Files can be transferred to/from the Linux machine using a high level protocol called OBEX (standing for OBjectEXchange, originally designed for Infrared links). First, you have to find out whether the mobile supports OBEX based message transfer. Try running the following command on the Linux machine (the number is the bluetooth address of the phone):

sdptool browse 00:0E:6D:9A:57:48

You might get voluminous output - here is part of what I got:
Service Description: OBEX Object Push
Service RecHandle: 0x10005
Service Class ID List:
"OBEX Object Push" (0x1105)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 9
"OBEX" (0x0008)

OBEX is built on top a lower-level protocol called RFCOMM. The `Object Push' service uses RFCOMM `channel' 9. Let's try to upload a file to the phone; run the following command on the Linux machine:
obex_push 9 00:0e:6d:9a:57:48 a.txt

The phone will respond by asking you whether to accept the message coming over the bluetooth link. The same command, invoked without any option, can be used to receive files sent from the mobile over the bluetooth link (read the corresponding `man' page for more details).

Installing Python

Nokia has recently done a port of Python to the `Series 60' smartphones running the Symbian operating system. The Python interpreter as well as a few important modules are packaged into a single .sis file (somewhat like the Linux RPM file) which can be obtained from,,034-821,00.html. The file to be installed is named PythonForSeries60_pre_SDK20.SIS. The first step is to transfer this file to the mobile via obex_push. Trying to open the file on the mobile will result in the Nokia installer program running - it will ask you whether to install Python on the limited amount of memory which the phone has or to an additional MMC card (if one is present). Once the installation is over, you will see a not-so-cute Python logo on the main menu of the phone - Figure 1 is a screenshot I took of the main menu.

Figure 2 shows the interactive Python prompt at which you can try typing Python scripts!

Running the Python `Hello, World'

You can write Python scripts on the Linux machine and upload them to the mobile with `obex_push'. If you try to open these scripts (on the mobile), the `applications manager' will ask you whether to install the files as Python scripts or not. Once installed as scripts, you can execute them by following the instructions displayed on the screen when you open the `Python' application from the main menu.

Figure 3 shows the output obtained by installing and running the following script on the mobile:

import appuifw # The application UI framework = u'Cool Python'
appuifw.note(u'OK', 'info')

Socket programming

Application programs running on both the phone as well as the Linux machine interface with the Bluetooth protocol stack via the socket API. Listing 1 shows a simple client program running on the mobile which connects with a server running on the Linux machine and sends it a message; the server code is shown in Listing 2.

The Python client program running on the mobile opens a Bluetooth socket and connects to the PC whose device address is specified in the variable `ATHLON'. Once the connection is established, it simply sends a string `Hello, world'.

The server program running on the PC opens a Bluetooth stream socket, binds it to RFCOMM channel 4 and calls `accept' - the server is now blocked waiting for a connection request to arrive from the client. Once the request arrives, the server comes out of the accept, returning a `connected' socket calling `recv' on which will result in the server getting the string which the client had transmitted.

The `bacpy' function in the server program is defined as an inline function in one of the header files being included - so you need not link in any extra library to get the executable. But if you are using any of the other Bluetooth utility functions like `ba2str', you have to link /usr/lib/ to your code.

Using PyBlueZ

There is an interesting Python interface to the Bluetooth library in Linux called `PyBlueZ' available for download from It simplifies the process of writing bluetooth socket programs on the Linux machine. Listing 3 shows the Python implementation of the server program described in the previous section.

Emulating serial links

Programs like `minicom' are used to talk to devices connected over a serial link (say a modem). There is a neat software trick to present a `serial-port-like' view of a bluetooth link so that programs like `minicom' can manipulate the connection effortlessly. Let's try it out.

First, edit /etc/bluetooth/rfcomm.conf so that it looks like the following:

rfcomm0 {
bind no;
device 00:0e:6d:9a:57:48;
channel 1;
comment "Example Bluetooth device";

After stopping and restarting the bluetooth service, run the following command:
rfcomm bind /dev/rfcomm0

You should see a file called `rfcomm0' under /dev after executing the above command. Now, you can set up `minicom' by running:
minicom -m -s

The only thing to do is to set the name of the device to connect to as /dev/rfcomm0. Save the new configuration as the default configuration and invoke:
minicom -m

Minicom is now ready to talk to your phone! Type in `AT' and the program will respond with an `OK'. Say you wish to make your phone dial a number. Just type:
atdt 1234567;

There are many other AT commands you can experiment with; try googling for say `mobile phone AT commands' or something of that sort!

After you have finished with your virtual serial port manipulations, you should run:

rfcomm release /dev/rfcomm0

to `release' the serial-bluetooth link.

Python over a Bluetooth console

Once you get the serial port emulation working, there is another interesting hack to explore. The Nokia Python distribution comes with a program called `'. On one console of your Linux machine, run the command:

rfcomm listen /dev/rfcomm0

Now run `' on the phone. You will see that after a few seconds, `rfcomm' will respond with a `connected' message. Once you get this message, take another console and run:
minicom -m

What do you see on the screen? A Python interactive interpreter prompt! You can now type in Python code snippets and execute them on the phone on-the-fly! Isn't that cool?

Parting Thought

I was curious to know how Microsoft's Windows XP operating system, famous for its `ease of use', would compare with Linux when it comes to interacting with my NGage QD. I installed the Windows driver for my no-name usb-bluetooth dongle and tried to get the Nokia PC suite up and running on an XP machine - maybe it's because I am far more experienced in GNU/Linux than on MS operating systems, but I found the XP experience far less `friendly' than MS would care to admit. I believe that most of the `user friendliness' of the Microsoft operating system comes from hardware vendors and application developers tightly integrating their products with the platform rather than any inherent quality of the OS as such.


For a general introduction to Bluetooth technology, see An interesting paper on Bluetooth security is available at has plenty of information regarding Bluetooth and Linux; I found the document `Bluetooth Programming for Linux' ( very informative.

Lots of information about Python on series 60 mobiles is available at ObexFTP seems to be an interesting tool - you can get it from There are some documents floating on the net which describe how you can do an NFS mount of your phone's file system - try a google search for more info.

Source code/errata concerning this article will be available at

How to hack bluetooth mobile phones

Start the Bluetooth Hardware from your Laptop (ie. - FN + F5 for IBM laptop)

2. Start the service for Bluetooth on your Fedora Server (See Below:)

3. Load the Bluetooth Module (Required for Bluz)

4. Bind the Bluetooth Device to the Computer rfcomm0 port (make sure the port is being created if it’s missing)

5. Modify Parameter in the Program “” and run the program

6. should find the Mobile Devices (Phone, etc) which has Bluetooth enabled

7. Connect to the device Found (in a binding Manner) and start extracting information from device (phone must accept)

8. Reading and Sending SMS (The messages must still need to be converted to appropriate character)

9. Extract Last 5 dial, missed and received calls. (This require more program hacking to be successful)

10. Adding entries into the Phone book and reading the first 5 entries in the phone book (require more program hacking)

11. Making a call from the mobile (can be useful for spying on someone)

12. Program Terminated (THE END)

How to hack bluetooth mobile phones

Start the Bluetooth Hardware from your Laptop (ie. - FN + F5 for IBM laptop)

2. Start the service for Bluetooth on your Fedora Server (See Below:)

3. Load the Bluetooth Module (Required for Bluz)

4. Bind the Bluetooth Device to the Computer rfcomm0 port (make sure the port is being created if it’s missing)

5. Modify Parameter in the Program “” and run the program

6. should find the Mobile Devices (Phone, etc) which has Bluetooth enabled

7. Connect to the device Found (in a binding Manner) and start extracting information from device (phone must accept)

8. Reading and Sending SMS (The messages must still need to be converted to appropriate character)

9. Extract Last 5 dial, missed and received calls. (This require more program hacking to be successful)

10. Adding entries into the Phone book and reading the first 5 entries in the phone book (require more program hacking)

11. Making a call from the mobile (can be useful for spying on someone)

12. Program Terminated (THE END)


Article pulled from Security-Protocols

Mercury News Computing Editor

Police, prosecutors and most of the press call them
"hackers." Computer cognoscenti prefer the term "crackers."

Both sides are talking about the same people, typically
young men, whose fascination with computers leads them to gain
access to computers where they don't belong.

A few crackers make headlines, like Robert T. Morris Jr.,
son of a top computer security expert for the supersecret
National Security Agency, who let loose a "worm" program on a
national network of university, research and government computers
in 1988.

There are also notorious crackers like Kevin Mitnick, who
was under investigation at the age of 13 for illegally obtaining
free long-distance phone calls and was sentenced to prison in
1989 for computer break-ins.

Then there are legions of far more ordinary crackers who
simply use their knowledge of computers to "explore" intriguing
corporate or government computers or simply to go for the
electronic equivalent of a joy ride and impress their friends.

But they all share something: an air of mystery. How do they
do it?

At a recent conference on computer freedom and privacy,
computer expert Russell L. Brand gave a four-hour lecture on the
inner workings of computer cracking.

His basic message: Cracking is not as hard as it seems to an
outsider, and it often goes undetected by legitimate users of
"cracked" computers.

"Just because you don't see a problem is no reason to think
a problem hasn't occurred," Brand said. "Generally it's a month
to six weeks before (operators) notice anything happened and
usually because the cracker accidentally broke something."

Home computers aren't in danger from crackers because they
aren't accessible to outsiders--and because they aren't
interesting to crackers. Instead, they target mainframes and
minicomputers that support many users and are connected to
telephone lines and large networks.

Understanding how crackers work and what security weaknesses
they exploit can help system managers prevent many break-ins,
Brand said. And the biggest problem is carelessness.

"When I started looking at break-ins, I had the assumption
that technical problems were at fault," he said. "But the problem
is human beings."

The "Cracker": Most crackers are not bent on stealing either
money or secrets but will target a particular computer for entry
because of the bragging rights they will enjoy with fellow
crackers once they prove they broke in. Typically, the computer
belongs to a corporation or the government and is considered in
cracking circles to be hard to penetrate. Often, it is connected
to the nationwide NSFNet computer network.

The attack: Crackers can attack the target computer from
home, using a modem and a telephone line. Or they can visit a
publicly accessible terminal room, like one on a college campus,
using the school's computer to attack the target through a
network. At home, the cracker works undisturbed and unseen for
hours, but phone calls might be traced.

The resources: If the target computer is nearby, the cracker
may look through the owner's trash for valuable information, a
practice called "dumpster diving." Discarded printouts, manuals
or other paper may contain lists of accounts, some passwords, or
technical data more sophisticated crackers can exploit.

The target: The easiest way to enter the target is with an
account name and its password. Passwords are often the weakest
link in a computer's security system: Many are easy to guess, and
some accounts have no password at all. Sophisticated crackers use
their personal computers to quickly try thousands of potential
passwords for a match.

The cover: To make calls from home harder to trace, crackers
might use stolen telephone credit-card numbers to place a series
of calls through different long-distance carriers or corporate
switchboards before calling the target computer's modem.

The way in: Many crackers take advantage of "holes" in the
operating system, the software that controls the basic operations
of the machine. The holes are like secret doors that either let
crackers make their own "super" accounts or just bypass accounts
and passwords altogether. Five holes in the Unix operating system
account for the bulk of computer break-ins--yet many
installations have failed to patch them.

The network: Most large computers are connected to several
others through networks, a chief point of attack. Computers erect
barriers to people but often completely trust other computers, so
attacking a computer through another computer on the network can
be easier than attacking it with a personal computer and a modem.

Ill-used passwords let many pass

Passwords are the security linchpin for most computer
systems. But these supposedly secret keys to computer access are
easily obtained by a determined cracker.

The main reason: Users and system managers often are so
careless with passwords that they are as easy to find as a door
key left under the welcome mat.

Part of the problem is the proliferation of computers and
computerlike devices such as automated teller machines, all of
which require passwords or personal identification numbers. Many
people must now remember half a dozen or more such secret codes,
encouraging them to make each one short and simple.

Often, that means making their passwords the same as their
account name, which in turn is often the user's own first or last
name. Such identical combinations are called "Joe" accounts, and
according to computer expert Russell L. Brand, they are "the
single most common cause of password problems in the world."

These `secret' keys to computer access are easily obtained
by a determined cracker. The main reason: Users and system
managers often are so careless with passwords that they are as
easy to find as a key left under the welcome mat.

Knowing there are Joes, a cracker can simply try a few dozen
common English names with a reasonable chance that one will work.
Armed with an easily obtained company directory of employees, the
task can be even easier.

Joe accounts also crop up when the system manager creates an
account for a new employee, expecting that the user will
immediately change the given password from his or her name to
something else. But users often fail to make the change or aren't
told how. Sometimes, they never use the account at all, providing
not only easy access for the cracker but an account where the
owner won't notice any illicit activity.

Even if crackers can't find a "Joe" on the computer they
want to enter, there are several other common ways for them to
find a password that will work:

- Many systems have accounts with no passwords or have
accounts for occasional visitors to use where the ID and password
are both GUEST.

- Outdated operator's manuals retrieved from the trash often
list the account name and standard password provided by the
operating system for use by maintenance programmers. Although it
can and should be changed, the password seldom is.

- "Social engineering"--in effect, persuading someone,
usually by telephone, to divulge account names, passwords or
both--is a common ploy used by crackers.

- Crackers are sometimes able to obtain an encrypted list of
passwords for a target computer, discarded by the owners who
mistakenly believe the coded words aren't useful to crackers.
While it's true they are difficult to decode, it is easy for a
cracker to use a personal computer to take a potential password
and encode it. Because most passwords are ordinary English words,
crackers can simply run a personal computer program to encode the
contents of an electronic dictionary and identify any entries
that match passwords on the coded list.

- In another form of deception, crackers set up public
bulletin board systems whose real purpose is to snag passwords.
Because many people tend to use the same password for all their
computer accounts, the cracker can simply wait until someone who
has an account on the target computer also sets up an account on
the bulletin board. The cracker then reads the password and tries
it on the target system.

While individual users can't delete dormant accounts from
their computers or keep an eye on the trash, they can be
intelligent about what passwords they use. Brand suggests users
choose a short phrase that's easy for them to remember and then
use the first two letters of each word as the password. As added
protection, users who are able should mix uppercase and lowercase
letters in their passwords or use a punctuation mark in the
middle of the word.--Rory J. O'Connor

The rights of bits

Constitutional scholar Laurence H. Tribe, widely considered
the first choice for any Supreme Court vacancy that might arise
under a Democratic administration, proposed a fairly radical idea
recently: a constitutional amendment covering computers.

Tribe's proposal for a 27th Amendment would specifically
extend First and Fourth Amendment protections to the rapidly
growing and increasingly pervasive universe of computing. Those
rights would be "construed as fully applicable without regard to
the technological method or medium through which information
content is generated, stored, altered, transmitted or
controlled," in the words of the proposed amendment.

I am not a constitutional scholar, but I have to believe
that what's needed is not a change in the Constitution, but
instead a change in the thinking of judges in particular and the
public in general.

Tribe acknowledges that he doesn't take amendments lightly,
pointing to the ridiculous brouhaha over a flag-burning amendment
as an example of what not to do to the basic law of the land. But
like many people who are more deeply involved in the world of
computers, Tribe sees the issue of civil liberties in an
information society as a crucial one.

The question is not whether the civil liberties issue is
serious enough to be addressed by some fundamental legal change.
The question is really how to get people to see that
communicating with a computer is speech, and that to search a
computer and seize data is the same as searching a house and
seizing the contents of my filing cabinet.

People seem to have trouble making these connections when
computers are involved, even though they wouldn't have trouble
recognizing a private telephone conversation as protected speech.
Yet most telephone calls in this country are, at some time in
their transmission, nothing more than a stream of computer bits
traveling between sophisticated computers.

Admittedly, computers do make for some complications where
things like search and seizure are concerned.

Let's say the FBI gets a search warrant for a computer
bulletin board, looking for a specific set of messages about an
illegal drug business. Because a single hard disk drive on a
bulletin board system can contain thousands of messages from
different users, the normal method for police will be to take the
whole disk, and probably the computer as well, back to the lab to
look for the suspect messages.

Of course, that exposes other, supposedly confidential
messages to police scrutiny. It also interrupts the legitimate
operation of what is, in effect, an electronic printing press.

Certainly, in the case of a real printing press that used
paper, such police activity would never be allowed. But a
computer is involved here, which to some appears to make the
existing rules inapplicable.

But in a case like this, we don't need a new amendment, just
the proper application of the Bill of Rights.

As a more practical matter, the chances of amending the
Constitution are slight. It was the intent of the framers to make
the task difficult, to prevent just such trivial things as
flag-burning amendments from being tacked onto the document. Even
the far more substantial Equal Rights Amendment did not survive
the rocky road from proposal to adoption. I doubt Tribe's &nbs

Cracking Unix password files for beginners

I guess you're a newbie in pass-cracking like I was and you've probably started Johnthe Ripper full of enthusiasm, and got.... nothing. So the first thought you have is 'my god this must be hard, and I'm a newbie'. Forget it!!! You're always a newbie, and we all are... in pass cracking world, pardon, pass recovering world (or any world else) you always have something to learn. Sometimes, even if you are experienced in password cracking, you won't be able to crack the password or even get your own password. This is a pure technical manual and will give you only the recipe for cracking, but every password needs different approach...

OK, so a good way to get somewhere is to start getting somewhere...
What you're about to learn is to crack *nix(Unix/Linux/etc.) password files. It does not mean that you need to have some Unix distribution on your box, but it means you'll have to stop clicking your ass off all around the screen... 'What this fool is trying to say', you'll probably ask... This fool is trying to say that john is a DOS program (there is also Linux/Unix version, but I guess that most of the people that read this tutorial have win boxes). I will try to put this tutorial through the examples so it wouldn't look like a boring script with incredible amount of switches. After reading this text it wouldn't be a bad idea to look at the texts you get with John. I learnt it all from there, but that, of course, was the hard way, and you want the easy way, right? Right.

First, it wouldn't be a bad idea to get yourself John the Ripper, I guess... if you don't have it you can find it at:

1) (look at archives, password cracking)
2) (do some searching by yourself)

John can be found practically anywhere. For example: try going to and running a search for 'john the ripper'.

Second thing you'll need is.... a HUUUUGE amount of password dictionaries (I'll explain what these are in a minute). The best dictionary around is at and packetstorm (look at the archives) and is called theargonlistserver1 and is about 20Mb packed, and over 200Mb
unpacked... get it!!!! The people at theargon did a terrific job.

You should also get some smaller dictionary files (I'll explain why later).

2) Do we look like *nix?

So now you have john, loaded with that huuuuge pass dictionary, and you think that you can crack anything... If you plan to live for 100000 years, that wouldn't be a problem, but you only have some 80 years left in the best case scenario (unless, of course, scientists find a way to... oh, nevermind).

Now, the first thing is that you have to make sure your password file really looks like a Unix password file (were talking about the /etc/passwd file).

Let's see how Unix pass files look like

owner:Ejrt3EJUnh5Ms:510:102:Some free text:/home/subdir/owner:/bin/bash

The important part is the username and the encrypted password, which are the first and the second parts (each line is divided into seven parts by : symbols)


Owner is the username and 'that other thing' is the crypted password (encrypted in altered DES (Data Encryption Standard) encryption). For the other part you can put anything that looks like that but the structure must be same so the john could recognize it as unix pass. In fact the other part

:510:102:Some free text:/home/subdir/owner:/bin/bash

Is just some information about the user, his home directory, etc...

Sometimes you'll have passes that have only the first and second part, such as password files that you got from a webboard running matt's web board script.


You'll have to put the other part so that password would look like unix pass, and you can do a copy-paste from another pass, you can even use

:510:102:His name:/home/subdir/owner:/bin/bash

What you have now should look like:

owner:Ejrt3EJUnh5Ms:510:102:His name:/home/subdir/owner:/bin/bash

Hell, you can even put


It won't matter to john at all.

3) We're getting somewhere... nowhere

Now you're ready to crack. Type in

john -w:words.lst password.file

Where words.lst is password dictionary and password file where you have your password or passwords. If you use it on example i gave to you you'll probably get password because it's really weak pass. You'd be surprised to see that people usually use really weak passes like their names, pet names, or even their username (for example: username=zalabuk, password=zalabuk).

Hint: Don't be stupid! Use strong passes like

with as many characters you can remember. Hint is to use special characters and numbers those passes are much harder to crack (I'll explain why in a minute).
The other hint is to use passes as long as you can remember, 8 characters are sometimes not enough... it depends what box that someone who cracks has... on dual alpha is certainly not enough... in other words... more than 10 characters will do fine, even more wouldn't hurt (like 16...). By the way, older *nix have fixed pass length of 8 chars... that is old DES crypted pass that uses a 64-bit key... now there are 128-bit keys, and some perverts use even more, so there is more fun now :)

john -w:words.lst password.file

Wait wait wait! What am I doing here?
Alright, listen up carefully. The DES encryption that Unix uses CANNOT be reversed. Some encryptions can be reversed using a sometimes simple or sometimes incredibly complicated algorithm (in the 3rd century AD, Ceasar used to send encrypted letters which used a formula of "shift by three", which means that d stands for a, e stands for b etc'. At that time, such an algorithm was just fine. Today, it isn't).
So anyway, the altered DES encryption that Unix uses for it's password files cannot be reversed. Why? Because it's a key-based encryption. The encryption algorithm uses a bunch of letters (lowercase and uppercase), numbers and symbols within the algorithm. So, in other words, to run the decryption algorithm you will need this key, which you simply cannot just have, because the key is the password! You see, when a user picks a password, the system generates an encrypted password for him, called a hash (which is what you get when you somehow acquire a password file), which is created by running this altered DES algorithm using the user's password as a key. If you try to decrypt the password using standard reversable DES encryption, you get a null string.
So how do John and other password crackers do it? Easy. They try to recreate this process by taking passwords out of these dictionary files (or wordlists) and using them as keys for this altered DES algorithm process. Then, they compare the result to all the encrypted passwords within the password file you've given them. If the two strings match - there you have it! The password is yours!

If the first step doesn't work, the next step would be to do this:

john -w:words.lst -rules password.file

This switch turn on not only browsing through the dictionary, but it uses some modifications of the words that are word dictionary (like adding a number at the end of pass - fool -> fool1, etc' etc'). This one will take long with huge pass dictionary, but it may give better results... For a start you could do a try with a small pass dictionary, and if it doesn't works you can try it with a huge pass dictionary.

Sometimes people are not stupid when they choose passwords and basic rules won't do a job... aaargh. As you've seen it takes more and more time for your CPU to crack this thing out as we go further. Now you can leave your computer on and go to sleep....

If you want to get even more possible passwords out of your password file, try typing

john -i password.file

This -i stands for incremental cracking, not a really good word for it, but...
Okay, what the hell does it do? It uses the default incremental mode parameters, which are defined in john.ini. What does this mean? Do you remember -rules? Yes, well, of course you do, unless you're either incredibly senile or you've stopped reading after this part and only came back, like... a couple of years later. That is very much like rules, but much much more powerful than -rules, and it takes much, much more time.

4) So where are we now (dictionary vs. brute-force)?

You can see that in all cases you use so-called dictionary cracking... but hell, why not just run John on a mode where it tried all possible combinations of lowercase and uppercase letters, numbers and symbols? I mean, this would be much more efficient, right? ... WROOOOOOONGG!!!
This method is called 'brute-force' attack (basically, dictionary attack is also sort of brute-force attack, but most people use the word brute-force for this specific attack).
What are the differences? First and most important, with dictionary you go through the selected words that could be passwords and their modifications, and with brute force cracking you use ALL possible combinations. That means you have


comb - number of possible combinations
nrch - number of chars
let - number of letters used

In case you're dealing with john's default -i 95 character set and, presume, a 6 letter password you have possible 735091890625 combinations! OUCH!!
Sure, this is useful for passwords like 2405v7, but still... with the computational powers of today's modern PC, I'd just give up, unless I had access to some University's supercomputer, which I'd bet noone would ever give me (well, at least not for free, and certainly not to run a password cracker on it).
As you can see it can take a looooong time until you crack a single one pass, do a little math and try to calculate how many possible combinations there are for 10, 12 and 16 chars.
I don't think you'll like the answer :)
Of course, sometimes dictionary attacks are not enough, but john has very powerful 'thinking'. In 'incremental' mode john will do all possible combinations from 0 to 8 characters (by zero password length is considered a hashed empty string, this sometimes happens). So incremental mode is one sort of brute-force attack in some way...

If you want to fire all weapons at one then you use

john password.file

this will do first basic dictionary attack, then -rules, then -i

5) What if...

Ok, you have to turn off your box from time to time, don't you? If you're doing that haaard password that will take more than 20 hours of cracking you can set john with ctrl+c and then resume with

john -restore

If your box crashes or if there's a power failure, you won't be able to restore your cracking sessions (sometimes)... well that's just too bad. Hell, it happened
to me once :-(

John is modular, and that is the most powerful thing about john the ripper, and that is what makes john the most advanced password cracker. John is very, very modular. John uses modes that are described in john.ini (do you still remember that incremental cracking i was talking about? Modes for rules and incremental are described in john.ini).
If you're some inventive guy then you may change the parameters in john.ini.

Here is example how some default parameters for -i look like:

# Incremental modes
File = ~/all.chr
MinLen = 0
MaxLen = 8
CharCount = 95

Ok... what do we have here?

[Incremental:All] - this stands for the beginning of the definition for the -i:all switch
File - filename of file that has characters used in mode -i:all (whole character
MinLen - logically, minimum length of password that john -i:all would try
MaxLen - even more logical, maximum length of password that will john -i:all try
CharCount - number of chars used by john when you 'turn on' this switch

So, there are some more switches... heh
Yes there are and down there are all default modes pasted from john the ripper's documents:

John the Ripper's Command Line Options

You can list any number of password files on John's command line, and also
specify some of the following options (all of them are case sensitive, but
can be abbreviated; you can also use the GNU-style long options syntax):

  • single "single crack" mode Enables the "single crack" mode, using rules from [List.Rules:Single].
  • wordfile:FILE wordlist mode, read words from FILE,
  • stdin or from stdin These are used to enable the wordlist mode.
  • rules enable rules for wordlist mode Enables wordlist rules, that are read from [List.Rules:Wordlist].
  • incremental[:MODE] incremental mode [using section MODE] Enables the incremental mode, using the specified ~/john.ini definition (section [Incremental:MODE], or [Incremental:All] by default).
  • external:MODE external mode or word filter Enables an external mode, using external functions defined in ~/john.ini's [List.External:MODE] section.
  • stdout[:LENGTH] no cracking, write words to stdout When used with a cracking mode, except for "single crack", makes John print the words it generates to stdout instead of cracking. While applying
    wordlist rules, the significant password length is assumed to be LENGTH, or unlimited by default.
  • restore[:FILE] restore an interrupted session Continues an interrupted cracking session, reading point information from the specified file (~/restore by default).
  • session:FILE set session file name to FILE Allows you to specify another point information file's name to use for this cracking session. This is useful for running multiple instances of John in parallel, or just to be able to recover an older session later, not always continue the latest one.
  • status[:FILE] print status of a session [from FILE] Prints status of an interrupted or running session. To get an up to date status information of a detached running session, send that copy of John a SIGHUP before using this option.
  • makechars:FILE make a charset, overwriting FILE Generates a charset file, based on character frequencies from ~/john.pot, for use with the incremental mode. The entire ~/john.pot will be used for
    the charset file unless you specify some password files. You can also use an external filter() routine with this option.
  • show show cracked passwords Shows the cracked passwords in a convenient form. You should also specify the password files. You can use this option while another John is cracking, to see what it did so far.
  • test perform a benchmark Benchmarks all the enabled ciphertext format crackers, and tests them for
    correct operation at the same time.
  • users:[-]LOGIN|UID[,..] load this (these) user(s) only Allows you to filter a few accounts for cracking, etc. A dash before the list can be used to invert the check (that is, load all the users that aren't listed).
  • groups:[-]GID[,..] load this (these) group(s) only Tells John to load users of the specified group(s) only.
  • shells:[-]SHELL[,..] load this (these) shell(s) only This option is useful to load accounts with a valid shell only, or not to load accounts with a bad shell. You can omit the path before a shell name, so '-shells:csh' will match both '/bin/csh' and '/usr/bin/csh', while '-shells:/bin/csh' will only match '/bin/csh'.
  • salts:[-]COUNT set a passwords per salt limit This feature sometimes allows to achieve better performance. For example you can crack only some salts using '-salts:2' faster, and then crack the
    rest using '-salts:-2'. Total cracking time will be about the same, but you will get some passwords cracked earlier.
  • format:NAME force ciphertext format NAME
    Allows you to override the ciphertext format detection. Currently, valid
    format names are DES, BSDI, MD5, BF, AFS, LM. You can use this option when
    cracking or with '-test'. Note that John can't crack password files with
    different ciphertext formats at the same time.
  • savemem:LEVEL enable memory saving, at LEVEL 1..3
    You might need this option if you don't have enough memory, or don't want
    John to affect other processes too much. Level 1 tells John not to waste
    memory on login names, so you won't see them while cracking. Higher levels
    have a performance impact: you should probably avoid using them unless John
    doesn't work or gets into swap otherwise.

6) Tips

I) A good schedule to do your cracking job is

john -w:words.lst password.file

john -w:words.lst -rules password.file

john -w:words.lst password.file

john -i:digits password.file

john -i:all password.file

II) If you have a file that has only passes that look like

owner:*:510:102:His name:/home/subdir/owner:/bin/bash

you have a shadowed passwords file.
Go to the Byte-Me page at and try to find out more about
password files (I'll leave it up to you to do this. It's important that you'll
learn how to find things by yourself).

III) You have some little tools that you get with john, they are all
listed below (from john's docs)

Combines the passwd and shadow files (when you already have access to
both) for use with John. You might need this since if you only used your
shadow file, the GECOS information wouldn't be used by the "single crack"
mode, and also you wouldn't be able to use the '-shells' option. You'll
usually want to redirect the output of 'unshadow' to a file.

Gets password hashes out of the binary AFS database, and produces a file
usable by John (again, you should redirect the output yourself).

Removes duplicates from a wordlist (read from stdin), without changing
the order. You might want to use this with John's '-stdout' option, if
you got a lot of disk space to trade for the reduced cracking time.

A shell script to send mail to all the users who got weak passwords. You
should edit the message inside before using.

So, that was about it... hope you've got something from this text.
Further readings: try reading ALL the documentation you get with john in the docs
directory. Maybe it's a little bit chaotic, but.... man those are the docs :)

Ohh, wait, wait!!
Remember, not all password files can be cracked! Smart admins alter the
encryption that they are using, especially when it comes to root passwords.
But there are always other ways to get passwords. These are covered in other
BSRF tutorials. Collect them all (lol) at

Virus Source Code Database

Virus Source Code Database

Virus Source Code Database

Remote Backups for Linux and BSD

The Malicious Insider Threat

Snort Evasion Vulnerability in Frag3

Gartner Forecasts the Next Big Threats

Locating Exploited Users Data