LiLi, Linux Live USB Creator

Filed Under (Uncategorized) by Brian Keith on 09-01-2011

I use this all the time and so far it’s the best program out there for making bootble usb keys with live version of Linux on it. One really cool feature is virtualization. LiLi can install a portable version of VirtualBox on the key. You can then load up Linux onto you Windows desktop.

Below is more information from LiLi’s website.

Linux Live USB Creator(LiLi) is a free and open-source software for Windows for creating portable, bootable and virtualized USB stick running Linux.

LiLi is designed to be used by both beginners and geeks.

If you are a beginner, LiLi will let you try Linux for the first time, keeping Windows clean of any modifications.

And if you are a geek, LiLi will allow you to test almost any Linux distributions directly from Windows, or just install them from a USB flash drive instead of CDs.


  • Supports hundreds of Linux distributions
  • No reboot needed
  • Totally free and open-source
  • Persistence on selected Linux
  • SmartClean and SmartDownload
  • Available in a lot of languages
  • Really easy to use
  • Automatic integrity check
  • And much more …


Understanding APC

Filed Under (Uncategorized) by Brian Keith on 08-01-2011

Understanding APC

by Vito Chin | October 7, 2010

APC is a performance-enhancing extension. It should not be confused with a magic pill, although having it around does provide a positive impact on performance! If configured incorrectly, APC can cause unexpected behaviour, however when implemented optimally APC can be a useful weapon in your arsenal. In this post we will examine APC’s capabilities and it’s application both as an opcode cache and in its less common usage as a data cache.

How APC differs from Memcached

APC is not a replacement for memcached. They are designed for different roles. memcached is a generic, distributed caching daemon. APC on the other hand is PHP-specific and limited in size. As such, you’ll want to only use APC for local caching of articles and objects that are relatively small. This begs the question: why not just use memcached universally?

The answer to this question, and indeed the question of whether to use memcache or APC, depends entirely on your circumstance. If you have a small application under a lot of load, then APC is a good choice. APC is a PECL extension, so it is very easy to add into your PHP ecosystem if you have control over your platform. Memcache on the other hand has a dependency on the memcache libraries and an external daemon running. The additional dependencies can imply additional maintenance costs in terms of administering the system, so APC, which does not have these dependencies, can be a better choice.

As generic caches, we can store many types of item in either APC or memcached. These include opcodes (which we will examine in more depth later in this article), strings, or other result representation from database queries or HTTP calls to feeds and services external to your application. We can also store objects that are expensive to create within our application, ready to use again later. The key is that all these objects can or will be in the same state for a certain period of time.

A key metric is the projected sum of the size of all objects; this is a determining factor between chosing APC or memcached since this dictates the size of the cache required. Memcached is more relevant than APC when a large cache is required because the maximum allocated memory is only limited by the architecture in which it runs. As it is language-independent, memcached can be helpful when used creatively within applications constructed in multiple languages. The distributed nature of memcached also enable resource sharing and makes it flexible enough to fit within a scalable environment.

We should view APC and memcached as tools that have different applications, although some part of their functionalities do intersect. That said, APC and memcached can be used together if the application architecture would benefit from this approach. They can be part of a layer of caches, covering anything from database results to pages or snippets of pages for the view layer. This article examines the use of APC for opcode and data caching, if you want to know more about using memcached, read our other posts about getting started with Memcached and regarding the new memcached extension.

How important is APC?

How important APC is for your setup depends on whether speed is important, and that depends on where you use PHP. Certain scripts may not be time critical, but user-facing applications usually are. Another aspect to consider is whether there is a need to minimise resource utilisation. Usually, the full potential of APC can be seen best in environment where usage/traffic volume is high, i.e. there is a small code base being executed very frequently.

As you will know, PHP is an interpreted language. This means that a PHP script has to be read, parsed and compiled before it is executed. (There is a very interesting resource on slideshare regarding this, from Joseph Scott – Anatomy of a PHP Request). The process of serving a PHP script ends up looking something like this:

This process is not ideal in a deployment where speed and resource minimalisation is a requirement, because the code is repeatedly parsed and compiled. APC is an excellent tool under such circumstances as it caches compiled code for execution so that there is no need for code to be parsed and compiled every time it needs to be executed. APC is not the only solution available for this purpose, there are others ( see the wikipedia page on PHP accelerators), however APC is mature and widely-used. For those facing optimisation challenges similar to those of Facebook’s, there is always HipHop PHP.

What does APC actually cache?

A PHP script is converted into opcodes in the parsing and compilation process. APC caches these opcodes, making opcodes available to be executed without going through the parsing and compilation process.

There is a PECL extension, VLD (Vulcan Logic Dumper/Disassembler), which allows you to check out the opcodes generated from the compilation and execution of a PHP script. For instance if you consider the following code example:

				"Test variable";

Will show the following opcodes:

Finding entry points

Branch analysis from position: 0

Return found

filename:       vldtest.php

function name:  (null)

number of ops:  2

compiled vars:  !0 = $testvar

line     # *  op                           fetch          ext  return  operands 


				>   ASSIGN                                                   !0, 'Test+variable'

				> RETURN                                                   1


branch: #  0; line:     2-    3; sop:     0; eop:     1 

path #1: 0,

Limitations of Caching with APC

APC caches in memory, so inherently the size of the available cache is not massive. The default size of the cache is 30 MB. This can be changed with the apc.shm_size configuration directive. For APC instances that are configured to use the System V-style kernel shared memory, the maximum size of shared memory is dependent on the shmmax kernel parameter. For Debian machines, this is usually 33MB. You can check this by doing:

$ cat

However, since v3.0.11, APC uses mmap by default and with that you can a specify a cache size that is unconstrained by the limit in the OS’s shmmax parameter. The cache size specified can go beyond the size of the physical RAM but that will result in swapping (which means that part of the memory utilised is actually taken from the hard disk) which is undesirable for those without a solid state drive. In any case, the apc_sma_info() function shows memory allocation information pertinent to your APC instance.

Another consideration of using AP is that it only caches to the host machine where the PHP instance is executed. As a result we cannot share an APC cache among multiple load-balanced PHP servers serving the same application in parallel. Each PHP instance on a server has to maintain and utilise their own cache.

Storing Data, Rather Than Opcodes, With APC

APC also caches user data via the apc_add/apc_store functions, essentially this means we can place the values of a variable into APC, not too unlike caches such as memcached. Although this can be very useful, especially in systems without another convenient caching mechanism, do be wary of the memory limitations of APC and remember that user data stored within cache could be vying for space with cached opcodes from files. Let’s take a look at how the value of a particular variable is stored:

				"This is a value to be stored in cache. ";


The first parameter to the apc_store() method is the key. Here, the md5() function maybe useful to create unique keys from any string that could be used to identify the value. To retrieve stored values:

echo apc_fetch("sampleKey1");

A conventional method with user caches is to first check if an item exist in the cache first before getting it from source and storing it in the cache if it is not available in cache:

				= apc_fetch('key'))





Benefits of User Data Caching

Although user data caching is often perceived as a secondary purpose of having APC, it is nevertheless a very useful feature for a certain type of data. APC is faster than a cache residing in another server that needs to be reached via a socket connection. The overall size of the cache however is relatively small. Because of these characteristics, data that can fully reap APC’s benefits should be relatively small, used often within a short time, and take a long time to generate. One example of such a data is the accessible resources of a particular role in an ACL component. If this list is stored in a database, effort to retrieve this list typically looks like the following:

function getResourceList()


				mysql_connect("localhost", USERNAME, PASSWORD);



				"Unable to connect to database server";





				"Unable to connect to database";




				mysql_query("SELECT resource_id FROM acl WHERE role_id = 1 ORDER BY resource_id ASC");





				"Unable to retrieve resource list";










				= getResourceList();

With Xdebug profiling, we are able to determine the execution time of the above code, which is about 5 ms. The breakdown of this operation looks like this:

Since it is likely that we are going to need this resource list very often, we can cache it in APC to give us improved execution speed, caching the data and eliminating the overhead of fetching it each time. We would use some caching code along the lines of:

				= apc_fetch('resource_list'))

				= getResourceList();





When running this from the CLI, do remember to set apc.enable_cli=1 in your APC runtime configuration. Notice that we serialize() the $resourceList before caching it and unserialize() it after retrieving it from APC. $resourceList is a serializable() array and thus can be cached. The $result itself in getResourceList is a resource that is not cacheable. Retrieving the list from APC for the first time takes 6 ms, so our breakdown on the first iteration looks like this:

This is slightly longer than when it is not cached but only happens initially when $resourceList is not available in the cache. As long as subsequent requests are made within the TTL of the cached data, retrieval of the list takes 0.112 second, as we can see from this third breakdown:

By caching the resource list and retrieving it whenever its needed, we save that amount of time per request. In this example, using APC is about 50x faster and certainly helps when request volume is large and frequent. getResourceList() is not too lengthy to begin with, imagine the time that can be saved on heavier functions. The speed in which we see here is specific to APC. Other data caches will have different times since their implementation is different and there are other factors may be involved, such as the network latency that we touched on earlier. We will not delve too deeply into the performance differences of the various data cache solutions here, but consideration given to the difference between data caches helps in identifying the best cache for your situation.

File Cache

A file cache is also known as the “system” cache. By default, APC caches compiled files whenever they are executed. Pre-compilation before execution can be triggered with the apc_compile_file() function if so desired. To obtain a list of compiled files, call the apc_cache_info() function. To turn off this system caching, set apc.cache_by_default to 0. Using these functions, we can “warm up” a cache, filling the cache with the opcodes of our scripts.

Time To Live

Cached opcodes and user values has a default TTL (Time To Live) of 0, which means that nothing will be removed until the entire cache becomes full, in which case the whole cache is expunged. To avoid such an expunge, you can set a TTL on your opcode caches with the apc.ttl configuration directive and customise TTLs to specific keys based on the need of the application and specific data being stored. The TTL for cached user values can be supplied as the third parameter to the apc_store or apc_add function. For the user cache, an item place with a specific TTL will be expunged even if the space used by the item is not needed.

Deleting from cache

To delete a compiled file stored within the opcode cache, we call apc_delete_file(), passing in the filename to be deleted from cache. For user cache, the apc_delete() function can be used, passing in the key of the item that we wish to remove. However, such deletion may be costly as it might involve re-structure of internal hash tables. It is more ideal to work on a basis of auto-expiry of cache items, or to clear the user cache via a call to apc_clear_cache(“user”) if you need to do so.


apc.stat is an important configuration directive, especially if you’re looking at optimising APC for a production environment. This configuration is turned on by default and causes APC to check a requested file to see if there are any modifications and serve from cache only if there are none. Turning this check off will speed things up and is typically done in a live or stage environment where deployments are usually followed by a restart of the webserver, clearing the cache and forcing the loading of the newly modified files. After the webserver restart, APC will no longer check for file modifications, this is useful since scripts should not normally be modified directly on these environments. On a development environment however, it is more common to set apc.stat to be turned off as scripts will be changing during development.

Monitoring the cache

Distributed along with the APC source is an apc.php script which provides a browser-based front-end that shows useful information about the current state of your APC instance. Here’s an example of the interface:

The information shown is quite intuitive and is a great place to start looking to improve configuration to optimise performance. One value of importance to cache performance is the Cache full count, which can be seen under File Cache Information when in the View Host Stats tab. This indicates the number of times the cache became full, upon which it is expunged if apc.ttl is set to 0. If apc.ttl is larger than 0, APC removes items in the cache that are older than the allowed apc.ttl to make way for newer items. The expugning process has a negative impact on performance and thus the number of times this occurs should be reduced if possible. This can be done by either increasing memory allocation or reducing cached scripts via the apc.filters configuration directive. Lastly, remember to place apc.php in location that is not publicly accessible.


APC is a performance-enhancing tool that is a key part of the stack for most live environments where PHP-based web-applications are deployed. The system cache will definitely complement other performance-enhancing endeavours while the user cache can be used if a fast and small object cache is desired. Whatever your situation, it is beneficial to invest some time into understanding how APC behaves with your application and configure APC accordingly, in order to get the best advantage from this tool or any other.

Cracking WEP with Aircrack-ng in Backtrack 4

Filed Under (Uncategorized) by Brian Keith on 06-01-2011

Cracking WEP with Aircrack-ng in Backtrack 4

Alfa AWUS036H Wireless Adapter

This tutorial demonstrates the insecurity posed by implementing WEP Encryption on a wireless network. The tutorial uses the Aircrack suite of utilities (airmon-ng,airodump-ngaireplay-ng and aircrack-ng), in Backtrack 4.


To learn more about WEP Encryption click here.



Choosing a wireless card for Backtrack

Selecting the right wireless card to use with Backtrack can be a little daunting, as there are certain cards with may have reduced functionality, while other cards may not work at all. This is mainly due to driver issues with regards to what functions the card is able to perform. Not every card’s drivers will allow it to be put into “Monitor Mode“, or enable it to inject packets.

The Remote Exploit website however, has a fantastic Hardware Compatibility List (HCL), which users have built up through time, stating which cards function correctly, often highlighting any additional driver upgrades which may be neccessary, for the cards to function in the desired manner.

The wireless card used for this particular tutorial is an: Alfa AWUS036H. It is a fantastic high-powered card (1000 mW !!!), and features an SMA connector to facilitate the connection of an external aerial. It also features an Realtek 8187L chipset, which is well supported and gives very good results during vulnerability tests.

You can read a review of the Alfa AWUS036H Wireless Adapter here.

The best advice I can give people starting out, is to do your research before you purchase a card. There are some cards out there that may require driver updates (or modifications in some cases), and this take quite a bit of effort in Linux for a newbie. If you get a decent card from the beginning, you will be off to a flying start !


What you will need:

  1. Aireplay listens for any ARP Requests being sent between the Associated Client and the Access Point.
  2. When an ARP Request is obtained, it is sent back to the Access Point in a continuous cycle.
  3. The Access Point responds by sending the reply back to the Wireless Card, and in the process transmits Initialisation Vectors alongside the transmitted packets.
  4. Aireplay continues to collect ARP Requests, which it continues to send in a loop to the Access Point.

The result of this, is that a significant amount of network traffic is generated, and subsequently vastly increases the quantity of IV’s collected by airodump.

It should be noted, that this is very much an “Active Attack”, in that it can be potentially monitored. It does however, rapidly speed up the IV collection process.

To begin the ARP Replay Attack on the access point, the following command is entered:

aireplay-ng -3 -b [BSSID of access point] -h [MAC Address of wireless card] mon0

example: aireplay-ng -3 -b 00:0E:A6:7A:0F:E8 -h 02:7D:B4:C2:C0:F9 mon0

At this point, your attention should be drawn to the airodump window, and take note of the#/s (Packets per Second). There may be a slight delay, as aireplay is waiting to receive an ARP Request Packet, but once it has obtained this, you will start to notice the Packets per Second column in airodump start to increase rapidly. Typically, this will rise to between 50 – 300 Packets per Second, depending on the Wireless Card used.


Step 7 – Cracking the WEP Encryption Key

Once sufficient packets have been captured, we can begin our attempt at cracking the WEP key. Ideally, we need to have captured around 50,000 IV’s to be in with a good chance of cracking the key.

To crack the key, we use the aircrack program. Aircrack has a number of really good features and customisation options, so that both Korek’s and PTW attacks may be performed. A feature I particularly like, is in the situation of there being insufficient IV’s to find the key. Aircrack will simply wait until another 5000 IV’s have been appended to the dump file, before re-attempting the attack.

We begin cracking the WEP key, by start aircrack as follows:

aircrack-ng -b [BSSID of access point] [filename of dump file](.ivs)

example: aircrack-ng -b 00:0E:A6:7A:0F:E8 dumpfile.ivs

Aircrack will now begin attempting to crack the WEP key, from the IV’s contained within the dump file. When the key is successfully obtained, the following message will be displayed:

Starting PTW attack with 867904 ivs.
                     KEY FOUND! [ 00:11:22:33:44 ] (ASCII: ..”3D )
        Decrypted correctly: 100%