strace <program> [args...]To get more details and options, 'man 1 strace'. This utility should be available on a standard Linux installation. Reportedly, Solaris and FreeBSD have a similar tool named truss.
One good target, however, is RadGameTools' Linux port of their Bink video player. The Bink file format has traditionally been very opaque and very little has been gained from merely examining the layout of different Bink files (though some information has been discovered and compiled in this document).
RGT has released Win32 versions of their standalone Bink video player. However, they go to great lengths to make it difficult to reverse engineer. The main program is self-decompressing to thwart static disassembly. When run, the main program then imports all of the external library functions it requires through a few special Win32 DLL calls, further frustrating static disassembly efforts. The RGT Linux port team clearly knows precious little about similar counter-RE techniques under Linux. Their Linux Bink player is not even strip'd which means that it retains a lot of debugging symbols. And, naturally, no self-decompressing code.
Let's apply strace against the BinkPlayer binary playing a file named 'original.bik':
strace BinkPlayer original.bik > output.txt 2>&1The command generates a lot of output to stderr which is why I redirect stderr to stdout, and stdout to a file. I search through the output for the Bink filename:
[...]
open("original.bik", O_RDONLY) = 8
read(8, "BIKil\220%\0\30\1\0\0\250}\0\0\30\1\0\0\0\2\0\0\200\1\0"..., 44) = 44
[...]
The open() call indicates that original.bik was opened and assigned to file
handle 8. Any subsequent calls to 'read(8, ...' will pull data out of the
Bink file until a 'close(8)' system call is encountered. The second parameter
of the read() call indicates the data that was returned in the memory
array. The third parameter reveals how much data was requested while the
function returns the amount of data actually returned. In this case, 44
bytes were requested and the data returned began with 'BIK'. This is the
Bink file signature. According to the format information that has already been
determined, a Bink file begins with a 44-byte header. Further, if bytes
40-43 of the header contain 0x1 (little-endian), there are 12 more bytes for
audio parameters. Sure enough, BinkPlayer is acting on this information soon
afterwards:
read(8, "\0\34\2\0", 4) = 4 read(8, "D\254\0\340", 4) = 4 read(8, "\0\0\0\0", 4) = 4Next, BinkPlayer reads what is apparently the frame offset table, followed by a number of bytes whose meaning is unclear. After this, the player keeps reading 16-kilobyte chunks from the file until the end. Admittedly, this is about as far as this experiment will go as I have already figured out how the player reads data from a Bink file. After reading the header information, the player must read 16384 bytes at a time and organize them in memory later. It is also possible, based on further RE experiments on the actual program, that there is a RadGameTools abstraction layer that has its own layer of file caching.