Free fakes software for linux

aria2 is a software for downloading files.
The transfer can be paused, resumed, queued, and saved. It has a friendly GTK-based GUI and useful log consoles.
It supports URL list importing, CRC checking, HTTP proxy servers, HTTP recursive downloads with various useful options, and cut-and-pasting. It can also handle annoying CGI fake download pages.
Main features:
- Command-line interface
- HTTP/HTTPS GET support
- HTTP Proxy support
- HTTP BASIC authentication support
- HTTP Proxy authentication support(using GET or CONNECT)
- FTP downloading support
- FTP via HTTP proxy(using GET or CONNECT)
- Segmented downloading
- Cookie support(currently aria2 ignores "expires")
- It can run as a daemon process.
- Very low resource usage
Enhancements:
- This release adds SHA256 support and fixes lots of bugs.
- The cygwin/mingw patch was also merged.

QPBPManager is a PBP File manager for Linux. The software is intended to use as a user friendly GUI to the known tedious pack and unpack processes of the PSP PBP files, directory generation and further copy into the PSP, in order to execute those binary files in PSPs with firmware 1.50.
QPSPManager automates this process to make it a simple task to the end user, who will only have to select a PBP file and the PSP directory, leaving all other tasks to the program. It also provides some other cool features such as selecting custom PNG, PMF and AT3 files to use as an icon or background in the PSP menu.
QPBPManager also allows the user to backup the savegames to the computer and copy those savegames later to the PSP.
Main features:
- Unpacks PBP files and selects automatically the icon and background files from the source file.
- Extracts the program name included in the PBP file and sets it as default output directory.
- Extracts the ELF of the PBP file and packs a fake PBP file without the ELF for showing in the menu of the PSP.
- Allows to select custom icon and background files to use in the menu.
- Allows to select custom video and music files to use in the menu.
- Allows to select the output directory on the PSP and the actual PSP directory, which is saved as an option for further usages, so you only have to configure it once (as long as the PSP directory does not change).
- Provides support for backup the savegames on the PSP to the computer and viceversa.
Although QPSPManager was mainly designed only to transfer PBP files into the PSP so they can be executed through the memory stick menu, Im thinking about new features in future versions non related to PBP file management. Some of those features:
- Conversion and transfering of any kind of video file. It will allow to convert all kind of video files into the PSP format and transfer the files to the PSP to allow viewing them on the console.
- Conversion and transfering of any kind of audio file. It will allow to convert all kind of audio files into the PSP format (mp3) and transfer the files to the PSP to allow hearing them on the console.
Enhancements:
- Added ISO/CISO compression/decompression and transfer support.
- Fixed bug where you couldnt rename a directory in the PSP.
- Changed renaming policy for kxploit.
- Copy file routine changed.
- Support for different linux distributions where mount options change the filenames of the mounted PSP to uppercase.

Linux::Smaps is a Perl interface to /proc/PID/smaps.

SYNOPSIS

use Linux::Smaps;
my $map=Linux::Smaps->new($pid);
my @maps=$map->maps;
my $private_dirty=$map->private_dirty;
...

The /proc/PID/smaps files in modern linuxes provides very detailed information about a processes memory consumption. It particularly includes a way to estimate the effect of copy-on-write. This module implements a Perl interface.

CONSTRUCTOR, OBJECT INITIALIZATION, etc.

Linux::Smaps->new($pid)

creates and initializes a Linux::Smaps object. Returns the object or undef if a PID was given and update has failed.
$self->pid($pid) or $self->pid=$pid

get/set the PID.

$self->update

reinitializes the object; rereads /proc/PID/smaps. Returns the object on success or undef otherwize.

$self->lasterror

update() and new() return undef on failure. lasterror() returns a more verbose reason. Also $! can be checked.

INFORMATION RETRIEVAL

$self->vmas

returns a list of Linux::Smaps::VMA objects each describing a vm area, see below.

$self->size
$self->rss
$self->shared_clean
$self->shared_dirty
$self->private_clean
$self->private_dirty

these methods compute the sums of the appropriate values of all vmas.

$self->stack
$self->heap
$self->vdso

these are shortcuts to the appropiate Linux::Smaps::VMA objects.

$self->all
$self->named
$self->unnamed

In array context these functions return a list of Linux::Smaps::VMA objects representing named or unnamed maps or simply all vmas. Thus, in array context all() is equivalent to vmas().

In scalar context these functions create a fake Linux::Smaps::VMA object containing the summaries of the size, rss, shared_clean, shared_dirty, private_clean and private_dirty fields.

$self->names

returns a list of vma names, i.e. the files that are mapped.

NRPG Ratiomaster is a small standalone application which fakes upload and download stats of a torrent to almost all bittorrent trackers.

This means that it does NOT rely on your bittorrent client (uTorrent, Azureus, etc.) and it will NOT download/upload the files on a torrent - it only can fake download/upload.

The application has hardcoded emulations for the most commonly used BitTorrent clients: uTorrent, BitComet, Azureus, ABC, BitLord, BTuga, BitTornado, Burst, BitTyrant, BitSpirit.

genromfs project can create romfs images.
romfs is a space-efficient, small, read-only filesystem originally for Linux and used by some Linux based projects. It is a block-based filesystem, that means it makes use of block (or sector) accessible storage driver (like disks, CDs, ROM drives). It is part of stock Linux kernels since about version 2.1.21 (about January, 1997). All current (2.4--2.6) kernel sources contain support for romfs, but depending on the distributor, it might not have been compiled in.
A working Linux system requires the kernel, and at least some programs running, which obviously needs a filesystem too. Most Linux disk filesystems are designed to be high performance, supporting all POSIX features, sometimes elaborate recovery on crashes (journaling), and that usually makes them quite heavy-weight, and thus often inappropriate in some special purposes.
romfs makes two shortcuts: first, its read-only, you cant simply use your disk if its a romfs disk, you must build its image beforehand. Second, it stores only the absolute minimum required from a filing system. No modification dates, no unix permissions.
Enhancements:
- Compilation fixes were made for the Cygwin platform, and there is less dependence on the ntohl() implementation.
- A segfault is now avoided with nonexistent directories.
- The acceptable names for "fake" device names were made to include the "-", "_", and "+" characters.

B::CC is Perl compilers optimized C translation backend.

SYNOPSIS

perl -MO=CC[,OPTIONS] foo.pl

This compiler backend takes Perl source and generates C source code corresponding to the flow of your program. In other words, this backend is somewhat a "real" compiler in the sense that many people think about compilers. Note however that, currently, it is a very poor compiler in that although it generates (mostly, or at least sometimes) correct code, it performs relatively few optimisations. This will change as the compiler develops. The result is that running an executable compiled with this backend may start up more quickly than running the original Perl program (a feature shared by the C compiler backend--see B::C) and may also execute slightly faster. This is by no means a good optimising compiler--yet.

OPTIONS

If there are any non-option arguments, they are taken to be names of objects to be saved (probably doesnt work properly yet). Without extra arguments, it saves the main program.

-ofilename

Output to filename instead of STDOUT

-v

Verbose compilation (currently gives a few compilation statistics).

--

Force end of options

-uPackname

Force apparently unused subs from package Packname to be compiled. This allows programs to use eval "foo()" even when sub foo is never seen to be used at compile time. The down side is that any subs which really are never used also have code generated. This option is necessary, for example, if you have a signal handler foo which you initialise with $SIG{BAR} = "foo". A better fix, though, is just to change it to $SIG{BAR} = &foo. You can have multiple -u options. The compiler tries to figure out which packages may possibly have subs in which need compiling but the current version doesnt do it very well. In particular, it is confused by nested packages (i.e. of the form A::B) where package A does not contain any subs.

-mModulename

Instead of generating source for a runnable executable, generate source for an XSUB module. The boot_Modulename function (which DynaLoader can look for) does the appropriate initialisation and runs the main part of the Perl source that is being compiled.

-D

Debug options (concatenated or separate flags like perl -D).

-Dr

Writes debugging output to STDERR just as its about to write to the programs runtime (otherwise writes debugging info as comments in its C output).

-DO

Outputs each OP as its compiled

-Ds

Outputs the contents of the shadow stack at each OP

-Dp

Outputs the contents of the shadow pad of lexicals as its loaded for each sub or the main program.

-Dq

Outputs the name of each fake PP function in the queue as its about to process it.

-Dl

Output the filename and line number of each original line of Perl code as its processed (pp_nextstate).

-Dt

Outputs timing information of compilation stages.

-f

Force optimisations on or off one at a time.

-ffreetmps-each-bblock

Delays FREETMPS from the end of each statement to the end of the each basic block.

-ffreetmps-each-loop

Delays FREETMPS from the end of each statement to the end of the group of basic blocks forming a loop. At most one of the freetmps-each-* options can be used.

-fomit-taint

Omits generating code for handling perls tainting mechanism.

-On

Optimisation level (n = 0, 1, 2, ...). -O means -O1. Currently, -O1 sets -ffreetmps-each-bblock and -O2 sets -ffreetmps-each-loop.

jdresolve is a software that resolves IP addresses to hostnames. Any file format is supported, including those where the line does not begin with the IP address. One of the strongest features of the program is the support for recursion, which can drastically reduce the number of unresolved hosts by faking a hostname based on the network that the IP belongs to.

DNS queries are sent in parallel, which means that you can decrease run time by increasing the number of simultaneous sockets used (given a fast enough machine and available bandwidth). By using the database support, performance can be increased even further, by using cached data from previous runs.

HOW IT USED TO WORK

jdresolve used the algorithms describe below up to version 0.2.

The initial version of jdresolve tried to only speed up the name resolution by implementing numerous concurrent requests. I The first problem was: how to resolve the maximum possible number of IPs concurrently without reading the whole log file into memory (they can get quite _huge_)? I figured Id need a 2 pass approach, collecting all distinct host IPs that needing resolving in the first step, then resolving them efficiently inside a loop, and finally just replacing the resolved IPs on the second pass through the log file.

This way we can garantee that the resolve queue will always be full with no need to weight that against how many lines of buffered log entries we would need to cache. The number of distinct IP addresses tend to be quite lower than the number of lines in the log file, and the IP part takes about only 1/20th of the log line, so we cant be using too much memory just by putting a few hundred or thousand small strings into a hash.

After looking thru CPAN, I came across the excellent Net::DNS module and was more than happy to note that it already provide a subroutine and examples for background queries. Just add IO::Select to that and you have a full non-blocking aproach to multiple concurrent queries. You can even specify the timeouts to make the name resolving even more efficient.

Having this much done, I was quite happy to have the fastest log resolving routine I have come accross. By setting the numbers of concurrent sockets and timeouts you could fine tune the beast to resolve names _very_ rapidly. But still there where about 25% of the IPs left unresolved...

"This is not much help", I thought. I need to know _at least_ from what country these people are accessing from. After a few not very scientifical aproaches, I realized that by recurring thru the DNS classes (C, B and finally A) and checking for the host listed in the SOA record I could be pretty sure this was a father domain to the IP. The implementation goes like this: find out all distinct IP addresses, then determine which C, B and A classes contain these addresses. Make up a list from these queries and send them thru a resolver in chuncks of 32 (configurable via the command line). If a socket times out, leave that request unresolved.

After running a big log file against the recursive aproach, I determined it didnt take much longer to resolve it at all. Full class domains tend to have decently configured DNS servers, and you get a lot of repeated classes when resolving your logs. The best was still to come: 0 unresolved IPs :) And since that I havent found an IP that cant be determined at least to its A class.

HOW IT WORKS NOW

The above algorithm works extremely well except for the case of very large logs (>100Mb). The hashes containing IPs and their parent A/B/C classes gets pretty huge doesnt fit in memory any more.

So as of v0.3, we have a new 1 pass approach. We have a line cache that holds 10000 lines (configurable with -l, dont set it much lower). Using my test base it looks like each 10000 lines take about 4Mb of RAM during processing (thats the log lines themselves plus the hashes and arrays used for caching/processing). Each IP and class to be resolved has a count value, which is increased every time a line with that number is read, and decreased after we print out a resolved line with that reference value.

Think of it as a "moving window" method, and that we do our own garbage collection. The process pauses if the first line in our line cache is still unresolved, we dont have any more sockets, or were waiting for socket data. We cant control the last two items, but to minimize the pauses do to yet unresolved lines, increase the -l value if you notice pauses during resolving. There should be enough lines cached so that even if we have timeouts on sockets we are still waiting for other socket data to come in, not just for 1 single socket to time out.

Using this method the memory usage during executing is almost constant. So you can determine how much RAM you wish to use for resolving names and set your -l value and forget about it. Theres really no performance loss when compared to the resolved.log

If you simply run the script as you would with the Apache logresolve program, you get the same results, only much faster. But if you want really take advantage of jdresolve, you should at least turn on the -r option for recursive resolves. As of version 0.2, the -m option takes a mask as an argument. The valid substitutions are %i for the IP address and %c for the resolved class. So an IP like 1.2.3.4 with a mask of "%i.%c" (the default) would become something like "1.2.3.4.some.domain". A mask of "somewhere.in.%c" would turn it into "somewhere.in.some.domain".

The -h switch shows you basic help information. The -v switch will display version information. Use -d 1 or -d 2 (more verbose) to debug the resolving process and get extra statistics. If you dont care for the default statistics, use -n to disable them.

After some runs you may want to change your timeout value. The -t option accepts a new value in seconds. For even better performance, use the -s switch with a value greater then 32, but remember that many operating systems have a hard coded default for open files of 256 or 1024. Check your systems limit with "ulimit -a".

New in v0.3 is the -l switch, which specified how many lines we will cache for resolving. The default is 10000, but can be vastly incremented without using too much RAM, as explained in "HOW IT WORKS".

After you used jdresolve on the log file, you can check which ips where left unresolved by using the --unresolved option on the file that was generated.

WHAT DOES RHOST DO?

rhost is a quick script to take advantage of the new STDIN functionality of jdresolve. Many times you use the host command to resolve a single IP (like host 200.246.224.10). As with standard log resolvers, host doesnt do recursion. So rhost just calls jdresolve with the apropriate parameters to resolve that single IP number. The syntax is rhost .

DATABASE SUPPORT

As of version 0.5, jdresolve provides simple database support thru db (dbm, gdbm, sdbm, etc) files. You can use the --database switch to specify the db file and that will allow for fallback in case some DNS servers are down and also performance improvements since you can lower your timeout value without sacrificing resolved percentage.

To use the database support, just supply a database name (i.e. hosts.db) using the --database option. If it does not yet exist, a new database with that name will be created. All resolved hosts and classes during a jdresolve run will be cached to the database.

After you have some data in a db, you can use --dumpdb to look at it. With --mergedb to add new information to it (the format of the input file is the same as the one from a dump using --dumpdb, e.g. an ip/class followed by the hostname/classname, separated by white space)

Ex: echo "0.0.0.0 testip" | jdresolve --database hosts.db --mergedb -

...adds and IP entry to the db

Ex: echo "0.0.0 classname" | jdresolve --database hosts.db --mergedb -

...adds a class entry to the db

Note: Since when recursing the resolved hostnames are stored to the database (even when resolved by recursion), you _may_ not want to use the same database for normal and recursed runs. That is because a cached host from a resolved run will show up as a "real" IP if you dont recurse and use the --dbfirst or --dbonly options, or just use the database and the lookup times out. Nothing too serious, but this detail may be important to some people.