First of all, http://ubuntuforums.org/showthread.php?t=786095 is a great tutorial for installing FFMPEG. In my case, it was actually installed on Debian through SSH.

Also, http://www.kilobitspersecond.com/2007/05/24/ffmpeg-quality-comparison/ does a very good job of looking into the different qscale options.

For a video, I chose my friend Ron’s video named “potter” which is about 5 minutes long, 720p, and around 450MB in size before any sort of compression. Note that this takes a while to convert if you don’t have a very fast server.

The code:

ffmpeg -i /path/potter.mp4 -qscale {QSCALE} -ar {ARATE} -ac 2 -acodec {ACODEC} -vcodec {VCODEC} -ab {ABITRATE} -f flv -s 1280x720 /path/potter_{ARATE}_{ABITRATE}_720p.flv

After a few tests with different video codecs, I chose libx264. After messing with a different video from Ron, I was very happy with the results.
Before conversion: http://localhostr.com/files/F6c63r0/capture.png (29.3 MB)
After conversion: http://localhostr.com/files/RufUdEt/capture.png (6.7 MB)

The converted file’s size was only 23% of the original file’s size with an audio rate of 22050 Hz, video codec libx264, and the audio codec libfaac.

More Tests (audio)

I tried 22050 and 44100 as the audio rates and 196k and 256k as the audio bit rates and LAME MP3 and AAC as the audio codecs.
The results were quite similar to each other.

gamevue:/path# du potter*
121596  potter_22050_196k_720p.flv
124824  potter_22050_196k_LAME_720p.flv
121596  potter_22050_256k_720p.flv
124824  potter_22050_256k_LAME_720p.flv
124528  potter_44100_196k_720p.flv
126016  potter_44100_196k_LAME_720p.flv
124528  potter_44100_256k_720p.flv
128408  potter_44100_256k_LAME_720p.flv

The quality difference in audio was not very much going from LAME to AAC, but it did shave off almost 4MB on the higher quality audio file.
Audio Codec chosen: AAC (libfaac)
Video Codec chosen: x264 (libx264)
Audio Rate chosen: 44100
Audio Bit Rate chosen: 256k

Zero Remorse's new template

Zero Remorse, a professional Australian gaming team,  has asked for a complete reconstruction of their website. I’m developing the PHP and MySQL server-side and the XHTML, CSS, JS, jQuery, and AJAX client-side. This includes incorporation into a PHPBB forums system, a recent, upcoming, and current matches feature, and much more.

Well, this is posted a few months after the actual completion and launch of EoReality‘s new template. This template was designed by sYnergy Forge (check them out, my favorite game/clan template designer I’ve ever seen) and coded in XHTML/PHP/CSS and some jQuery/Javascript/AJAX.

About EoReality:

By providing the highest quality performance servers in the industry, EoReality has gained the trust of top teams, organizations, and players. EoReality runs its highly optimized servers on premium networks to ensure the lowest possible pings, best trace routes and accurate hit registration. What are you waiting for? Stop playing and start gaming. End of Reality.

EoReality now provides hosting for my server(s), which allows upload speeds of up to 1gbps (as if that high is even needed) because it runs on Google Fiber’s new super-fast network.

Note: EoReality will be replacing the template I developed with a new one in the near future, so sorry if mine isn’t there any more.

]]> http://zanehooper.com/blog/eorealitys-new-website.html/feed 0 http://zanehooper.com/blog/php-security-part-2-protecting-vulnerable-files.html http://zanehooper.com/blog/php-security-part-2-protecting-vulnerable-files.html#comments Mon, 12 Jul 2010 03:01:29 +0000 Zane Hooper http://zanehooper.com/?p=25 While developing, a lot of files are files you don’t want users to see – whether they are admin, config, or page files – should be well secured.

Admin Files

You’re administrative home page (if you have an administration panel) should require the user to be of a certain level (state, whatever you want to call it) or in a certain user group. This value SHOULD NOT be stored in a cookie. Cookies can be modified too easily, and a nosy hacker would be able to be in your admin panel in seconds.

If you have properly secured your admin panel so that a regular user cannot access it, the next step is to secure the files (assuming you’re using a paged interface, which I will explain here).

A paged interface is one in which there is a home page that includes files in a pages folder of some sort. There are multiple insecurities that I will cover with this:

1. Users accessing the directory of the pages
2. Users accessing other directories through this system

1. Users accessing the directory of the pages

This can happen through multiple ways. One thing you must do is make sure that the file exists using if( file_exists( $file_name ) ), otherwise a user could enter an incorrect value and PHP will try to include a page that doesn’t exist. This step covers up your tracks for hiding the directory.

Next, you want to protect the files of the directory. My favorite way to do this is through a .htaccess file (for apache users). In the pages directory, add a .htaccess file with the contents:

This protects the path and sends the user to the specified path. This could be a home page, a 404 error, page, or whatever you want. I do know that some people don’t like this method, or don’t have Apache, so the other way would be to use define( ‘SITE’, true ); in your index page and then add at the beginning of everyone of your pages, add if( !defined(‘SITE’) ) die( ‘Hey! You\’re not supposed to be here!’ );

These methods protect your pages directory from direct access but still allow use of PHP’s include(  ), include_once(  ), require(  ), and require_once(  ) functions.

2. Users accessing other directories through this system

This is a pretty simple hack that I found once while testing out the security of my files. I thought “Well, if I can access anything in the pages directory, what’s to keep me from accessing other directories?”

This hack is quite simple actually, and allows the hacker to figure out entire directories of a website and generate plenty of errors. As I said in Part 1, to be good at security you need to learn to hack first. So here’s how the hack works:

[Some Website]/index.php?page=ucp

Seems pretty simple right? That’s how links work. The PHP script then performs include( ‘pages/ucp.php’ ), but what if we change UCP?

[Some Website]/index.php?page=../index

Hmm… PHP interprets this as include( ‘pages/../index.php’ ), which includes the index page again. Now we start getting errors. Actually, now it includes the index page over and over until the page breaks. Now the user can do some snooping around, with things like:

[Some Website]/index.php?page=../admin/delete_user&id=1

Using things like this the user can access admin/delete_user.php?id=1 and wreak havoc on the website. The simplest protection ever can fix this:

$page = str_replace( ‘../’, ”, $page );

And you’re done!

Up Next: PHP Security: Part 3 – XSS Worms/Hacks