INPUT_MODULE - A small one-line description of the module.
Small description of the module, what it's purpose is, how it does stuff, etc.... links to relevant information, such as links that describe the structure, or it's evidentiary values, blog posts discussing how to interpret the results, etc....
new
This is the constructor for the subroutine.
If this input module uses all of the default values and does not need to define any new value, it is best to skip implementing it altogether (just remove it), since we are inheriting this subroutine from the SUPER class
There are some variables that can be set here that affect the flow of information for the module.
An examples of such variables are: $self->{'multi_line'} = defines how the get_time method is called and what it should return. The default value is 1, which makes the tool read the file line-by-line, so the method get_time is called for each line of the file that is being parsed (and it returns a single object). Otherwise it is read as a single call to get_time, which then returns a hash or collection of timestamp objects.
Another variable that can be set, $self->{'type'}, which should be set as file, unless we are dealing with a directory.
Since we might be dealing with files that are not readily accessible, such as files within an image file (might come in the future), we need to define a tag if we really need to have access to the file (for instance in the case of a SQLIite database that might have to be copied so it can be read). This is controlled in the variable $self->{'file_access'}, which defaults to 0, or not allow access to the file.
init
The init call resets all variables that are global and might mess up with recursive scans.
This subroutine is called after the file has been verified, and before it is parsed.
If there is no need for this subroutine to do anything, it is best to skip implementing it altogether (just remove it), since we are inheriting this subroutine from the SUPER class.
The method can be used to create any global variables, or to initialize them.
get_version
A simple subroutine that returns the version number of the input module. There shouldn't be any need to change this routine, it serves its purpose just the way it is defined right now. (so it shouldn't be changed)
get_description
A simple subroutine that returns a string containing a description of the funcionality of the input module. This string is used when a list of all available input modules is printed out.
end
Sometimes there might be some resources that need to be closed, for instance some temporary files created by the module that need to be deleted, or database connections closed or any other possible operations that need to be performed to successfully close the file before it is possible to start parsing the next one.
This method is used for that, so if there is a need to close some connections, do it here.
It is not necessary to close the file handle though, that is done in the main engine, not unless the module has created its own using the file name that got passed to it, then it might be necessary to close it here.
get_time
UPDATE_ME
This is the main "juice" of the input module. It parses the input file and produces a timestamp object that get's returned (or if we said that self->{'multi_line'} = 0 it will return a single hash reference that contains multiple timestamp objects within it.
This subroutine needs to be implemented at all times and this comments need to be updated to reflect the logic of the routine, what it does and how it does it... are there any risks, might there be loss of data, possibly provide some tips on analysis, etc...
get_help
A simple subroutine that returns a string containing the help message for this particular input module. This message gets printed when the user calls for a help on a particular module.
This text therefore needs to be defined and changed for each input module so that it accurately describes the module in question.
It might contain information about the path names that the file might be found that this module parses, or URLs for additional information regarding the structure or forensic value of it.
verify
This subroutine is very important. Its purpose is to check the file or directory that is passed to the tool and verify its structure. If the structure is correct, then this module is suited to parse said file or directory.
This is most important when a recursive scan is performed, since then we are comparing all files/dir against the module, making it vital for it to be both accurate and optimized. Slow verification subroutine means the tool will take considerably longer time to complete, too vague confirmation could also lead to the module trying to parse files that it is not capable of parsing.
success -> INT, either 0 or 1 (meaning not the correct structure, or the correct one) msg -> A short description why the verification failed (if the value of success is zero that is).