To implement:

• Add a list indicating which columns are enabled and which are disabled to the project config.
• Update this list when a column is enabled or disabled.
• When the timeline is rendered, use this list to set the columns enabled and disabled. This should be set inside of the menu bar's widget instead of directly in the timeline. There is a dictionary of BooleanVar there that controls column state. It may not be possible to do this directly in the timeline __init__.

Verify that the state is preserved if the project is saved, closed, and opened again when...

• the program is closed
• the project is closed by reopening the project.
• the project is closed by opening another project.
• the project is closed by creating a new project.

Verify that the state is preserved if the timeline is re-rendered by...

• importing a log file
• applying a filter

Other:

• Implement tests. Ideally, the above verification stages would be covered, in addition to any unit tests you deem necessary.

Allow the user to configure colors by event id. Create a default color configuration and save user edits on a per-project basis.

Some log files appear to have characters that don't play nice with xmltodict. Find a way to clean logs of these characters and remove them.

We should set up a unit testing framework. Pytest might be a good one.

Create a draft by 10/6. Final document due by 10/11.

The user doesn't need to see a hash of the source file. That data is meaningless to them. Instead, display the alias of the source file.

I'm not sure how much of this is necessary, but the current code in util.data copies the latest version of the config in the package into the application directory if it doesn't already exist there.

#47 requires the user to delete that copy if they want to grab the latest version of the config.

It may be useful to add a UI for project-independent settings where the user can 'reset to default,' which would overwrite the application copy with the version in the package. Other configuration can be done here as well, such as editing the default colors for any project.

This may be overkill. I'll leave it up to whoever grabs this ticket to decide what direction to take it in.

Create a UI for kicking off the log import process

We need to review the list of logs added/changed in Windows 10 and determine if any changes should be made to the logs we are collecting.

Create the UI for querying the log database.

Filters will be output as (column, operator, value).
Column selectors will be provided as a list of columns to pull.

When you haven't saved and close the project, it asks you if you want to save before closing. If you say yes, an error occurs. Included stack trace picture for reference.

Reference the DVPR for more details.

Implement the following and record the results in the DVPR. If the test cannot yet be implemented, please document why and file a follow-up issue and link it. If the results of the test indicate that changes must be made, please file a follow-up issue and link it. This is due by 2/14.

Parsing library throws an error

• Add a unit test which passes invalid data to the parser and tests that errors are handled

Important record information is not collected during import process

• Verify key record information is not blank

Timeline is exportable to an Excel-compatible format

• Export timeline to tab-delimited file and open in Excel

Log times are displayed in a user-specified timezone

• Attempt to specify the timezone

Might want to look into using a right click menu on the timeline.

Add a UI for specifying the name of the project to create. Check to see if that project already exists. Maybe allow the user to specify a different directory to save the project in.

• Create a dummy project config file that contains a filter specifying which logs to collect.
• Write project.get_project_config to get the project config in an easy to use format.
• Write project.filter_logs to filter a list of logs based on the filter specified.
• Write project.is_duplicate which will return true or false based off of whether the project already contains that log or not. As of the time of writing, this function does not yet have a prototype, but it should go inside of winlogtimeline.util.project.Project.

Generate the program architecture via a block diagram or data flow diagram.

We need to discuss which features are required for a minimum viable product, and which features are a stretch goal (to be implemented after we have a fully working prototype). After we have this list created, we should discuss with the client in order to ensure that we have a complete list and that our priorities align.

Basic Features (WIP)

• Ability to parse events from the event log and display them in a timeline
• Ability to color code events
• Ability to sort events by type, date, etc
• Ability to dedupe events
• Ability to verify event log integrity
• Ability to recover deleted events
• Ability to combine events from multiple machines

Suggestions

• It may be useful to store events in an intermediate project file (local DB maybe?) along with metadata

Currently, the record parsing is all hard coded. Redesigning it to be more data-driven would allow for the user to easily make changes to the records being scraped from the logs.

Come up with a json-based data structure that describes how to parse a record. This issue can be considered once the redesign has been reviewed and approved by all members of the team.

• Propose a design
• Gather feedback
• Move to implementation

Create a way for the user to export the logs in an easy-to-read format. CSV is probably the easiest (ensures Excel compatibility).

• Implement a parser for the grammar described in #67.
• Compare the time it takes to parse a log with both the grammar and the hard-coded parsing.
• If the difference is too great, implement the grammar as a backup only method for parsing records.
• Document the grammar
• Add a way for users to add events from within the UI. User-configured events should be saved in the program-wide config.

The status bar increases vertically by a few pixels when the status bar pops up. This issue is considered done once that no longer occurs.

As it stands, the timeline view loads extremely slowly with the number of events that we are gathering. Find a way to fix this.

Pull the deleted event logs into the database.

• Determine how we should represent logs internally.
• Write logs.parse_record to convert a libevtx record into that representation.
• Write logs.sort_logs to sort a list of logs by a particular value (date, event id, etc).

Make a loading bar to give the user feedback on how far in the import process the program is. Two main parts: parsing events from the event log and rendering the event section.

The client asked that we review the events added in Windows 10 to determine if the list of events we are collecting needs to be modified.

Create a pop-up wizard for creating a new project.

This is useful for when we import multiple different EVTX files (i.e. one Security and one System file) from the same computer.

Perform a layout of the basic UI design for our first Sprint.

This appears to be a bug in the version of tk/tcl supplied with macOS.

Resolution

• Implement a mechanism to detect the user operating system on startup.
• Implement a check before disabling certain GUI elements (buttons with images, menu bars) that are dependent on the operating system
• Write a wrapper function to attach to the callback functions used by these GUI elements. This wrapper should display some feedback to the user about why the action they attempted to perform was unsuccessful. This could be a pop-up dialog or a message in the status bar.

Related issues

• #29
• #55 comment by @ShaneKent

Please.

We are currently only getting a portion of the data from the event logs, find out how to get the rest of the data.

• Add an option to the settings which allows the user to specify a timezone.
• Display timezone options as UTC offsets.
• Display region indicators along with the UTC offset.
• Apply the timezone offset to the database query
• Change the UI to reflect the current timezone
• Make the timezone persistent (save it in the project config)

Reference the DVPR for more details.

Implement the following and record the results in the DVPR. If the test cannot yet be implemented, please document why and file a follow-up issue and link it. If the results of the test indicate that changes must be made, please file a follow-up issue and link it. This is due by 2/14.

Query fails to return the correct data

• Execute a valid query on a known set of data and examine the returned data. If this can be made into a unit test that would be ideal

Alias used was previously used

• Add a unit test which does the following: Import a log with an alias. Import another log with the same alias. (Alternate methods of testing this are acceptable)

Unwanted records are filtered out

• Add a unit test which attempts to parse both wanted and unwanted records, and verifies that only the desired records are returned

• Write collect.collect_records to collect events from an event log file. Do not include filtering.
• Write collect.collect_deleted_records to carve deleted events from an event log file.
• Write collect.get_machine_name to parse the machine name from an event log file.
• Write collect.get_log_file_hash to get verification info from an event log file.

Map existing functionality to the menu and add shortcuts.

Currently, I can think of a few functions that should be added.

• Import - Ctrl+I
• Exit - Ctrl + Q

I would like this issue to be a location for us to track all menu functionality that should be added.

• Modify the timeline tags to use a combination of event source and event ID
• Modify the parser to identify records by both event source and event ID
• Modify any tests which handled parsing using only event ID

Have users test the program and gather feedback

Download, install, and run the provided Python library for viewing events.

Labels have a darker background than the rest of the window, which looks kind of odd. No clue why this is. Investigate and fix.

• Determine an appropriate format for storing the logs in a project.
• Write project.load, project.save, and project.close.
• Write project.write_log_data to add a log to the project. This function should call project.is_duplicate to ensure that duplicate logs are not being added to the file.
• Write project.get_all_logs to return a list of logs contained in the project.

See discussion on #63

Sphinx?

An alternative is to manually set up a GitHub wiki and update that. I feel that might be unreliable, and propose that we only use that for functional documentation rather than code documentation.

Reference the DVPR for more details.

Implement the following and record the results in the DVPR. If the test cannot yet be implemented, please document why and file a follow-up issue and link it. If the results of the test indicate that changes must be made, please file a follow-up issue and link it. This is due by 2/14.

Query fails and provides user feedback

• Enter a query containing SQLite control characters. If this can be made into a unit test, that would be ideal.

Duplicate records are filtered out

• Add a unit test which attempts to parse two of the same log and verifies that only one is returned.

Implement a rough GUI prototype containing major UI elements. The elements do not need to be functional for this prototype.

Parts to be implemented include:

• Menu bar (non-functional, placeholder items)
• Toolbar (non-functional, placeholder icons)
• Timeline (non-interactive, dummy data)
• Query box (non-functional)

Changing the destination directory for the export tool doesn't affect where the .csv file is actually exported. It always gets exported to the project directory.