Archive for August, 2008

PHP vs Perl (final)

In the first post I discussed the sick amount of functions in PHP compared to Perl, in the second one the reason why writing Perl applications goes faster and now in this third and final post, I'll discuss external connections.

Connecting to an other server is useful for a number of reasons, think about content scraping or posting messages to a website or forum. Both PHP and Perl have great support for this, but this time I think PHP wins the prize for being the most useful. This is a very strange thing to say because exploits etc are mainly written in Perl.

When you're connecting to a website in Perl, you can use LWP::Useragent, in PHP it's easier and you can just use file_get_contents("http://www.randombase.com"). These are only suitable for HTTP servers so not that useful.

As soon as you're trying something more advanced (IRC bot?) you need more powerful tools.  In PHP, the way to go is fsockopen(), this is an awesome function that is very easy to work with, it can work with virtually any protocol and gives you endless possibilities. The same goes for Perl's IO::Socket. This extension is maybe more powerful than PHP's, but for some reason I think it's unnecessary complex, there is too much information to be defined before you can actually use it.

So, my final judgement of this PHP vs Perl series would be Perl if you're writing something intended for personal usage or when you need to write a quick hack. I also think Perl is just candy for people who are good with advanced structures, because good and efficient Perl code is almost unreadable in the end. PHP is easier to pick up because of the enormous documentation (Perl's documentation is shattered on the web), and still the unbeaten king for developing websites.

Streaming things (example)

Took a while but here is my example for the post streaming things:

http://iron.randombase.com/monitor.php

This application shows the serverload, both graphically and in numbers. This example uses a random number generator instead of showing the actual serverload, so don't worry, our server isn't that unstable. I can give you the source code on request, just send me an e-mail!

Streaming things

Now I'm truly slacking off. It's been nine full days since my last blog post, but same reason as always, nothing interesting is happening and one project is sucking up all my time.

I was working on a dumb game but realised it was dirt so I quit working on it, mainly because of the forced lag you get through AJAX and PHP. Little did I know at the time I wrote it because apparently there are ways to keep the connection open, even in PHP and AJAX, instead of resending the headers each time. This would reduce lag greatly, and get normal latency. I'm only going to discuss/explain one of two methods I read about because I didn't quite get the other one.

The method is, very simply put: you keep your PHP script running and use Javascript to dynamically update the things on the page. Using usleep() to define the amount of lag you want, and of course deciding what amount of server load you're willing to give to your script. I'm not giving any example, it's late already and it's not hard.

Using Javascript's function getElementById() you can easily manipulate things on the homepage, and use flush() to get the output constantly sent to the browser.

flush() already

A function that has been on my ignore-list for quite some time, but not anymore. PHP's function flush() makes sure the output you have generated gets sent to the browser. Now, why is this useful? To make it obvious your script is still running to the end-user for example.

Imagine you have one of those lame "value my site" scripts, that connects to the Google PageRank server, Alexa, Yahoo Backlinks and what not. 99% of all scripts simply connect to the servers in one turn, making the script look frozen for atleast a couple of seconds. Statistics show all users leave if your script is running more than 9.81 seconds (OK, I made that up).

To fix the frozen state, add a flush() line between every connection, example:

<?php

connectToGoogle();

flush();

connectToAlexa();

?>

The moment the script is finished with connectToGoogle(), it will show the output it has already and continue to Alexa. Not clear enough? Here is my little example:

http://iron.randombase.com/flush.php

Distributed hash cracking through Javascript

Mad ideas always score, and this one is almost finished! The basic idea of this project is to use the CPU of our visitors for cracking passwords, encrypted in md5 or SHA1 or something like that.

The code I have so far is quite simple, it works like this:

Step 1: generate a MySQL table filled with the so called "ranges" or "blocks", a block is a part of the amount of hashes you want to generate for cracking your hash. For example, the blocksize I'm currently using is 50. So if I want to generate a million hashes, I'd create 20,000 blocks.

Step 2: create a server file for the AJAX function in the Javascript cracker. The server file is written in PHP and returns a random, uncompleted range from the database.

Step 3: the moment a user visits a page, the AJAX function retrieves a random block from the server and starts cracking it (small blocksize so the cracking only takes a few miliseconds). If the block is finished, it tells the server. If the hash is cracked, it also tells the server. The server checks this (no invalid input by evil users, kthxbye) and if this is correct, removes all remaining blocks.

The main issue here is that you need a huge website to get really good speeds. RandomBase receives around 3 hits / second, which would mean only 150 hashes / second.