If in the past months you had to choose between squinting your eyes with ultra small icons and way to small menus or blurry text when using one of your favourite IDEs than the end is near! Eclipse finally updated to support high resolution displays (like 3200 x 1800 px) and when you update to version 4.6 you can finally use it like on a normal “old fashioned” display with sharp text and normal icons. 🙂
Prior to 4.6 the following website gave a better solution than increasing the editor font size to like 30 which still left the menu too small but ran Eclipse in a rather blurry mode [https://jaxenter.com/netbeans/hidpi-with-eclipse-and-netbeans] by using a manifest file next to the EXE.
The problem was discussed in this bugtracker: https://bugs.eclipse.org/bugs/show_bug.cgi?id=421383
TSK Autopsy Artifacts
The below tries to summarise the various sources (see bottom of the post) on how Autopsy 3 artifacts & attributes work and should be used.
TSK Autopsy Artifact relationship
- a file can have none to many artifacts
- use more than 1 artifact if the attributes don’t have a relationship to each other
- artifacts can represent the actual content of a container such as a PST or Log file where each artifact should be an email or log entry
- a artifact can have 1 to many attributes
- attributes should be related to each other
- standard and custom types of artifacts/attributes are referenced by their ID which is maintained by the Blackboard system
other “best practises”
- don’t use attribute contexts –> create custom attributes instead
- use TSK_GEN_INFO as a catch all if you don’t create a custom artifact and no others fit
- try not to use custom artifacts/attributes if possible
Which Artifact shows up where?
The below is a work in progress
Initial observations show you could add any kind of “attribute” to each artifact, the type of the artifact will determine the behaviour/use inside of Autopsy. Please note that it seems you can use the attribute TSK_TAG_NAME in other artifacts than TSK_TAG_FILE but this does not create tags and just confuses the reporting module making it believe there are tagged items when there are none.
probably a favourite of mine, custom table, items in the treeview, result tab view and thumbnails per tag work; the wiki states that separators work to build a tag hierarchy (sub tags?) but I have tried many separation characters (-/\|,:;) and scanned the source code using tags and cannot find support of this pre 3.1 API (maybe in the future):
plain fields in the result tab, no items in the tree view, no special table view:
plain fields in the result tab, items in the tree view, special table view, no sub item in tree view for TSK_SET_NAME though 🙁 :
plain fields in the result tab, items in the tree view, special table view (shows data source –> image but not the file path like with other artifacts):
Some time ago I was thinking of continuing the development of SmutDetect: maybe adding a GUI and implementing other ideas and insights I gathered since first publishing it. Luckily I noticed that autopsy got a refresh from the web-browser base to a Java environment (my language of choice – brilliant). Sadly the way this was done means I would need to change from Eclipse to NetBeans to facilitate the NetBeans module development. *Not amazing at all*
Not wanting to re-invent the wheel and interested in the challenge I decided to go down the route of making an autopsy module.
After a few weeks of reading up on the matter, getting used to NetBeans and some recoding the first working version of SmutDetect4Autopsy is up and running:
First successful port of SmutDetect as an autopsy ingest module (some thumbnails pix-elated for web-use)
As you can see above, I am using the
TSK_TAG_FILE Blackboard artifact type to sort the images into the different skin tone percentage bands (intervals of 10). For whatever reason the File Tags do not get sorted alphabetically but rather what I assume is creation time. This allows the Thumbnail overview of table view to each group while the detailed results are stored in the tag’s comments. This is fine for the report modules existing already but seems a bit limiting for more advanced views and reports. To port some of the more advanced features I need to do some more reading and find an alternative.
Old SmutDetect HTML Report as comparison
Due to the really early alpha status this module is not available for download yet but if you are interest please just email me 🙂
Some resources I have found useful so far:
- Source Code of the EXIF Parser and Scalpel Module