Giter VIP home page Giter VIP logo

fishy's Introduction

fishy

fishy is a toolkit for filesystem based data hiding techniques, implemented in Python. It collects various common exploitation methods, that make use of existing datastructures on the filesystem layer, for hiding data from conventional file access methods. This toolkit is intended to introduce people to the concept of established anti-forensic methods associated with data hiding.

This document will provide some basic information about fishy. For a more in-depth documentation, you can visit the github wiki or use the documentation within the repository.

Code Authors and Project

fishy is a project initiated by the da/sec research group and several bachelor students of the Hochschule Darmstadt (h_da), University of Applied Sciences.

Student members: Jan Türr, Adrian Kailus, Christian Hecht, Matthias Greune, Deniz Celik, Tim Christen, Dustin Kern, Yannick Mau and Patrick Naili.

da/sec members: Thomas Göbel, Sebastian Gärtner and Lorenz Liebler.

References

  • [1] Adrian V. Kailus, Christian Hecht, Thomas Göbel und Lorenz Liebler, „fishy – Ein Framework zur Umsetzung von Verstecktechniken in Dateisystemen“, in D-A-CH Security, Gelsenkirchen (Germany), September 2018.
  • [2] Thomas Göbel and Harald Baier, „fishy – A Framework for Implementing Filesystem-based Data Hiding Techniques“, in Proceedings of the 10th EAI International Conference on Digital Forensics & Cyber Crime (ICDF2C), New Orleans (United States), September 2018.
  • [3] Thomas Göbel, Jan Türr and Harald Baier, „Revisiting Data Hiding Techniques for Apple File System“, in Proceedings of the 12th International Workshop on Digital Forensics (WSDF) to be held in conjunction with the 14th International Conference on Availability, Reliability and Security (ARES), Canterbury (UK), August 2019.

Attribution

Any publications using the code must cite and reference the conference paper [1] and [2].

Requirements

  • Build:
    • Python version 3.5 or higher
    • argparse - command line argument parsing
    • construct - parsing FAT filesystems
      • Note: Please install a version earlier than 2.9 (2.8.22 is recommended)
    • pytsk3 - parsing NTFS filesystems
    • simple-crypt - encryption of metadata using AES-CTR
  • Testing
    • pytest - unit test framework
    • mount and dd - unix tools. needed for test image generation
  • Documentation
    • sphinx - generates the documentation
    • sphinx-argparse - cli parameter documentation
    • graphviz - unix tool. generates graphs, used in the documentation

Installation

# To run unit tests before installing
$ sudo python setup.py test
# Install the program
$ sudo python setup.py install
# Create documentation
$ pip install sphinx sphinx-argparse
$ python setup.py doc

To generate the documentation as pdf:

$ cd doc
$ make latexpdf

You may have to install some extra latex dependencies:

$ sudo apt-get install latexmk
$ sudo apt-get install texlive-formats-extra

Usage and Hiding Techniques

Techniques we found

  • FAT:

    • File Slack [✓]
    • Bad Cluster Allocation [✓]
    • Allocate More Clusters for a file [✓]
  • NTFS:

    • File Slack [✓]
    • MFT Slack [✓]
    • Allocate More Clusters for File [✓]
    • Bad Cluster Allocation [✓]
    • Add data attribute to directories
    • Alternate Data Streams
  • Ext4:

    • Superblock Slack [✓]
    • reserved GDT blocks [✓]
    • File Slack [✓]
    • inode:
      • osd2 [✓]
      • obso_faddr [✓]
  • APFS:

    • Superblock Slack [✓]
    • Write-Gen-Counter [✓]
    • Inode Padding [✓]
    • Timestamp Hiding [✓]
    • Extended Field Padding [✓]

CLI

The cli interface groups all hiding techniques (and others) into subcommands. Currently available subcommands are:

FATtools

To get information about a FAT filesystem you can use the fattools subcommand:

# Get some meta information about the FAT filesystem
$ fishy -d testfs-fat32.dd fattools -i
FAT Type:                                  FAT32
Sector Size:                               512
Sectors per Cluster:                       8
Sectors per FAT:                           3904
FAT Count:                                 2
Dataregion Start Byte:                     4014080
Free Data Clusters (FS Info):              499075
Recently Allocated Data Cluster (FS Info): 8
Root Directory Cluster:                    2
FAT Mirrored:                              False
Active FAT:                                0
Sector of Bootsector Copy:                 6

# List entries of the file allocation table
$ fishy -d testfs-fat12.dd fattools -f
0 last_cluster
1 last_cluster
2 free_cluster
3 last_cluster
4 5
5 6
6 7
7 last_cluster
[...]

# List files in a directory (use cluster_id from second column to list subdirectories)
$ fishy -d testfs-fat12.dd fattools -l 0
f     3        4        another
f     0        0        areallylongfilenamethatiwanttoreadcorrectly.txt
f     4        8001     long_file.txt
d     8        0        onedirectory
f     10       5        testfile.txt

Metadata

Metadata files will be created while writing information into the filesystem. They are required to restore those information or to wipe them from filesystem. To display information, that are stored in those metadata files, you can use the metadata subcommand.

# Show metadata information from a metadata file
$ fishy metadata -m metadata.json
Version: 2
Module Identifier: fat-file-slack
Stored Files:
  File_ID: 0
  Filename: 0
  Associated File Metadata:
    {'clusters': [[3, 512, 11]]}

File Slack

The fileslack subcommand provides functionality to read, write and clean the file slack of files in a filesystem.

Available for these filesystem types:

  • FAT
  • NTFS
  • EXT4
# write into slack space
$ echo "TOP SECRET" | fishy -d testfs-fat12.dd fileslack -t myfile.txt -m metadata.json -w

# read from slack space
$ fishy -d testfs-fat12.dd fileslack -m metadata.json -r
TOP SECRET

# wipe slack space
$ fishy -d testfs-fat12.dd fileslack -m metadata.json -c

# show info about slack space of a file
$ fishy -d testfs-fat12.dd fileslack -m metadata.json -t myfile.txt -i
File: myfile.txt
  Occupied in last cluster: 4
  Ram Slack: 508
  File Slack: 1536

MFT Slack

The mftslack subcommand provides functionality to read, write and clean the slack of mft entries in a filesystem.

Available for these filesystem types:

  • NTFS
# write into slack space
$ echo "TOP SECRET" | fishy -d testfs-ntfs.dd mftslack -m metadata.json -w

# read from slack space
$ fishy -d testfs-ntfs.dd mftslack -m metadata.json -r
TOP SECRET

# wipe slack space
$ fishy -d testfs-ntfs.dd mftslack -m metadata.json -c

Additional Cluster Allocation

The addcluster subcommand provides methods to read, write and clean additional clusters for a file where data can be hidden.

Available for these filesystem types:

  • FAT
  • NTFS
# Allocate additional clusters for a file and hide data in it
$ echo "TOP SECRET" | fishy -d testfs-fat12.dd addcluster -t myfile.txt -m metadata.json -w

# read hidden data from additionally allocated clusters
$ fishy -d testfs-fat12.dd addcluster -m metadata.json -r
TOP SECRET

# clean up additionally allocated clusters
$ fishy -d testfs-fat12.dd addcluster -m metadata.json -c

Bad Cluster Allocation

The badcluster subcommand provides methods to read, write and clean bad clusters, where data can be hidden.

Available for these filesystem types:

  • FAT
  • NTFS
# Allocate bad clusters and hide data in it
$ echo "TOP SECRET" | fishy -d testfs-fat12.dd badcluster -m metadata.json -w

# read hidden data from bad clusters
$ fishy -d testfs-fat12.dd badcluster -m metadata.json -r
TOP SECRET

# clean up bad clusters
$ fishy -d testfs-fat12.dd badcluster -m metadata.json -c

Reserved GDT Blocks

The reserved_gdt_blocks subcommand provides methods to read, write and clean the space reserved for the expansion of the GDT.

Available for these filesystem types:

  • EXT4
# write int reserved GDT Blocks
$ echo "TOP SECRET" | fishy -d testfs-ext4.dd reserved_gdt_blocks -m metadata.json -w

# read hidden data from reserved GDT Blocks
$ fishy -d testfs-ext4.dd reserved_gdt_blocks -m metadata.json -r
TOP SECRET

# clean up reserved GDT Blocks
$ fishy -d testfs-ext4.dd reserved_gdt_blocks -m metadata.json -c

Superblock Slack

The superblock_slack subcommand provides methods to read, write and clean the slack of superblocks in an ext4 filesystem or the superblock and object map structures in an APFS filesystem

Available for these filesystem types:

  • EXT4
  • APFS
# write int Superblock Slack
$ echo "TOP SECRET" | fishy -d testfs-ext4.dd superblock_slack -m metadata.json -w

# read hidden data from Superblock Slack
$ fishy -d testfs-ext4.dd superblock_slack -m metadata.json -r
TOP SECRET

# clean up Superblock Slack
$ fishy -d testfs-ext4.dd superblock_slack -m metadata.json -c

OSD2

The osd2 subcommand provides methods to read, write and clean the unused last two bytes of the inode field osd2

Available for these filesystem types:

  • EXT4
# write int osd2 inode field
$ echo "TOP SECRET" | fishy -d testfs-ext4.dd osd2 -m metadata.json -w

# read hidden data from osd2 inode field
$ fishy -d testfs-ext4.dd osd2 -m metadata.json -r
TOP SECRET

# clean up osd2 inode field
$ fishy -d testfs-ext4.dd osd2 -m metadata.json -c	

obso_faddr

The obso_faddr subcommand provides methods to read, write and clean the unused inode field obso_faddr

Available for these filesystem types:

  • EXT4
# write int obso_faddr inode field
$ echo "TOP SECRET" | fishy -d testfs-ext4.dd obso_faddr -m metadata.json -w

# read hidden data from obso_faddr inode field
$ fishy -d testfs-ext4.dd obso_faddr -m metadata.json -r
TOP SECRET

# clean up obso_faddr inode field
$ fishy -d testfs-ext4.dd obso_faddr -m metadata.json -c	

Write-Gen-Counter

The write_gen subcommand provides methods to read, write and clean the Write-Gen-Counter field found in APFS inodes

Available for these filesystem types:

  • APFS
# write into inode write_gen_counter fields
$ echo "TOP SECRET" | fishy -d testfs-apfs.dd write_gen -m metadata.json -w
# read hidden data from inode write_gen_counter fields
$ fishy -d testfs-apfs.dd write_gen -m metadata.json -r
TOP SECRET
# clean up write_gen_counter fields
$ fishy -d testfs-apfs.dd write_gen -m metadata.json -c

Inode Padding

The inode_padding subcommand provides methods to read, write and clean the inode padding fields found in APFS inodes

Available for these filesystem types:

  • APFS
# write into inode padding fields
$ echo "TOP SECRET" | fishy -d testfs-apfs.dd inode_padding -m metadata.json -w
# read hidden data from inode padding fields
$ fishy -d testfs-apfs.dd inode_padding -m metadata.json -r
TOP SECRET
# clean up inode padding field
$ fishy -d testfs-apfs.dd inode_padding -m metadata.json -c

Timestamp Hiding

The timestamp_hiding subcommand provides methods to read, write and clean the nanosecond parts of timestamps located in APFS inodes

Available for these filesystem types:

  • APFS
# write into inode nanosecond timestamps
$ echo "TOP SECRET" | fishy -d testfs-apfs.dd timestamp_hiding -m metadata.json -w
# read hidden data from inode nanosecond timestamps
$ fishy -d testfs-apfs.dd timestamp_hiding -m metadata.json -r
TOP SECRET
# clean up inode nanosecond timestamps
$ fishy -d testfs-apfs.dd timestamp_hiding -m metadata.json -c

Extended Field Padding

The xfield_paddingsubcommand provides methods to read, write and clean the dynamically created extended field padding areas in APFS inodes

Available for these filesystem types:

  • APFS
# write into inode extended field padding
$ echo "TOP SECRET" | fishy -d testfs-apfs.dd xfield_padding -m metadata.json -w
# read hidden data from inode extended field padding
$ fishy -d testfs-apfs.dd xfield_padding -m metadata.json -r
TOP SECRET
# clean up inode extended field padding
$ fishy -d testfs-apfs.dd xfield_padding -m metadata.json -c

Encryption and Checksumming

Currently, fishy does not provide on the fly encryption and does not apply any data integrity methods to the hidden data. Thus its left to the user, to add those extra functionality before hiding the data. The following listing gives two examples, on how to use pipes to easily get these features.

To encrypt data with a password, one can use gnupg:

$ echo "TOP SECRET" | gpg2 --symmetric - | fishy -d testfs-fat12.dd badcluster -m metadata.json -w

To detect corruption of the hidden data, there exist many possibilities and tools. The following code listing gives an easy example on how to use zip for this purpose.

$ echo "TOP SECRET" | gzip | fishy -d testfs-fat12.dd badcluster -m metadata.json -w

Development

  • Unittests can be executed by running pytest. Please make sure the create_testfs.sh script runs as expected.
  • To make sure tests will run against the current state of your project and not only against some old installed version, consider installing via pip install -e . or python setup.py develop instead of python setup.py install
  • Doctests can by executed with python3 -m unittest tests/test_doctest.py.
  • To add modules to doctest, extend the load_tests funtion under tests/test_doctest.py.

Creating test filesystem images

With create_testfs.sh you can create prepared filesystem images. These already include files, which get copied from utils/fs-files/. To create a set of test images, simply run

$ ./create_testfs.sh

The script has a bunch of options, which will be useful when writing unit tests. See comments in the script for further information.

If you would like to use existing test images while running unit tests, create a file called .create_testfs.conf under utils. Here you can define the variable copyfrom to provide a directory, where your existing test images are located. For instance:

copyfrom="/my/image/folder"

To build all images that might be necessary for unittests, run

$ ./create_testfs.sh -t all

How to implement a hiding technique

Here some general rules an hints, how one can integrate a hiding technique into the existing project structure:

  1. Under fishy create a wrapper module for each hiding technique, which handles the filesystem specific hiding technique calls + does main-metadata handling. The cli module would only know about this wrapper module, not your filesystem specific hiding technique module.
  2. Hiding techniques are located in either fat, ntfs or ext4 submodule.
  3. Create a Metadata class in your hiding technique implementation. This class holds hiding technique dependent metadata, to be able to restore hidden data after write operations. Only use primitive data types in this class, so they can be serialized via the __dict__ attribute. Let the write method return an instance of this class, which then will be written to the metadata file.
  4. Every hiding technique should implement at least a write, read and a clear method.
  5. Ony operate on streams in your hiding technique implementation. E.g. don't pass a file to the write implementation, which then would be opened, read and its content hidden. Instead let the wrapper script handle opening things. This shall ensure that the hiding technique gets more reusable and also simpler, as non technique specific things don't be handled there.

A simple example would be the fishy.fat.cluster_allocator.py

Metadata handling

To be able to restore hidden data, most hiding techniques will need some additional information. These information will be stored in a metadata file. The fishy.metadata class provides functions to read and write metadata files and automatically de-/encrypting the metadata if a password is provided. The purpose of this class is to ensure, that all metadata files have a similar datastructure. Though the program can detect at an early point, that for example a user uses the wrong hiding technique to restore hidden data. This metadata class we can call the 'main-metadata' class

When implementing a hiding technique, this technique must implement its own, hiding technique specific, metadata class. So the hiding technique itself defines which data will be stored. The write method then returns this technique specific metadata class which then gets serialized and stored in the main-metadata.

fishy's People

Contributors

celikd avatar d-kern avatar eeveeseyes avatar importantchoice avatar kn000x avatar mauamy avatar mc68 avatar panail avatar rkgk04 avatar thetout avatar timbuntu avatar tom-g1 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Forkers

ekojs

fishy's Issues

APFS Superblock Slack Read bug

When reading larger amounts of hidden data, the technique reads parts of the filesystem structure instead of the hidden data (e.g. seems to happen when reading a volume superblock for the first time).

FAT,NTFS: construct incompatibility

The construct library changed some things in their recent 2.9.X release so that our code is currently incompatible with their current version.

Maybe someone has the time to fix those incompatibilities. Meanwhile I will fix our requirements to construct in its pre 2.9 version.

Licensing

We still need to decide under which license this project will be published...

Has anyone preferences?

Info-Switch Bug

Some Info-Switches that incorporate both non-metadata and metadata variants throw exceptions after printing the information when no metadata is used.

E.g. ext4 Superblock Slack throws a "not implemented" exception.

APFS: Timestamp Hiding Improvement

As of right now, Timestamp Hiding in APFS hides data in 4 bytes of the nanosecond part of the timestamps. This potentially also affects the seconds of the timestamp.

To fix: Either write to only 3 bytes of the timestamp or determine the exact amount of bits (likely 30) and use them.

APFS: Parse non-perfect images

Parse APFS images that aren't perfectly prepared as the Wiki entry explains. Possible solution: find first NXSB instance and count the used blocks.

FAT:FileSlack: Traverse directories for info output

The fileslack subcommand traverses the directory structure and uses all found files, if a directory is given as the destination. The info switch does not respect this, but treats a directory as a file, which results in unusable and false output.

Document responsibilities

Don't know which form/which place are the best to document the responsibilities, but we must start somehow, so here some notes about what I remember. Please feel free to add stuff you or others have done.

  • Framework:
    • Architecture: me
    • Metadata encryption: @D-Kern
  • FAT:
    • FAT filesystem parser: me
    • Hiding Technique FileSlack : me
    • Hiding Technique Bad Cluster: me
    • Hiding Technique Additional Cluster Allocation: me
  • NTFS:
  • EXT4:
  • Documentation:
    • Introduction Stuff: me
    • FAT Filesystem explanation: me
    • Module Overview: me

FileSlack: possible overwrites in directory autoexpand feature

If a user supplies a directory plus a file in this directory as destinations for fileslack exploitation, the autoexpansion of directories could lead to multiple writes into the slack space of the same file. For instance:

$ fishy -d testfs_fat12.dd fileslack -w -m "meta.json" -d adir/afile.txt -d adir longfile.txt

would first write into adir/afile.txt, then expand adir to adir/afile.txt and then write again into the slack space of adir/afile.txt.

This is an issue in FAT fileslack implementation, but I'm not sure if the NTFS implementation is affected.

Metadata: Fix reading metadata

Reading metadata files via the cli tool failes since the introduction of the metadata encryption feature.

Without encryption of the metadata file:

$ echo nonsense | fishy -d testfs-fat12.dd fileslack -d onedirectory -m /tmp/foo -w
$ fishy metadata -m /tmp/foo                                                       
Traceback (most recent call last):
  File "/usr/bin/fishy", line 11, in <module>
    load_entry_point('fishy', 'console_scripts', 'fishy')()
  File "/home/matti/Seafile/Dokumente/Studium/5.Semester/PSE_-_Projekt_Systementwicklung/fishy/fishy/cli.py", line 204, in main
    do_metadata(args)
  File "/home/matti/Seafile/Dokumente/Studium/5.Semester/PSE_-_Projekt_Systementwicklung/fishy/fishy/cli.py", line 24, in do_metadata
    meta.read(args.metadata)
  File "/home/matti/Seafile/Dokumente/Studium/5.Semester/PSE_-_Projekt_Systementwicklung/fishy/fishy/metadata.py", line 211, in read
    self.metadata = json.loads(instream.read().decode("utf8"))
AttributeError: 'str' object has no attribute 'decode'

With encryption of the metadata file:

$ echo nonsense | fishy -d testfs-fat12.dd -p lol fileslack -d onedirectory -m /tmp/foo -w
$ fishy metadata -m /tmp/foo                                                              
Traceback (most recent call last):
  File "/usr/bin/fishy", line 11, in <module>
    load_entry_point('fishy', 'console_scripts', 'fishy')()
  File "/home/matti/Seafile/Dokumente/Studium/5.Semester/PSE_-_Projekt_Systementwicklung/fishy/fishy/cli.py", line 204, in main
    do_metadata(args)
  File "/home/matti/Seafile/Dokumente/Studium/5.Semester/PSE_-_Projekt_Systementwicklung/fishy/fishy/cli.py", line 24, in do_metadata
    meta.read(args.metadata)
  File "/home/matti/Seafile/Dokumente/Studium/5.Semester/PSE_-_Projekt_Systementwicklung/fishy/fishy/metadata.py", line 211, in read
    self.metadata = json.loads(instream.read().decode("utf8"))
  File "/usr/lib/python3.6/codecs.py", line 321, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa6 in position 9: invalid start byte

As the unit tests for reading and writing metadata pass, there might some inconsistencies between the tests and the usage via the cli.

NTFS:FileSlack: Make info switch consistent to FAT:FileSlack

The current info method of the ntfs.fileslack module lacks some information, that the user would need to thoughfully handle fileslack. My suggestion would be to unify the output to match the output of the fat.fileslack module.

For instance:

$ fishy -d testfs-fat12.dd fileslack -d another -m /tmp/foo -i
File: another
  Occupied in last cluster: 4
  Ram Slack: 508
  File Slack: 1536

NTFS FileSlack: cant write into slackspace of file 'another'

I tried to write something to file slack of an NTFS filesystem, but got this:

$ echo "Simple test" | fishy -d utils/testfs-ntfs.dd fileslack -w -d another -m /tmp/meta.json                 
filesize:12
Traceback (most recent call last):
  File "/usr/bin/fishy", line 11, in <module>
    load_entry_point('fishy==0.1', 'console_scripts', 'fishy')()
  File "/usr/lib/python3.6/site-packages/fishy-0.1-py3.6.egg/fishy/cli.py", line 127, in main
    do_fileslack(args, device)
  File "/usr/lib/python3.6/site-packages/fishy-0.1-py3.6.egg/fishy/cli.py", line 46, in do_fileslack
    slacker.write(sys.stdin.buffer, args.destination)
  File "/usr/lib/python3.6/site-packages/fishy-0.1-py3.6.egg/fishy/file_slack.py", line 75, in write
    slack_metadata = self.fs.write(instream, filepaths)
  File "/usr/lib/python3.6/site-packages/fishy-0.1-py3.6.egg/fishy/ntfs/ntfsSlackSpace.py", line 23, in write
    m = self.slackTool.write(instream, filepaths)
  File "/usr/lib/python3.6/site-packages/fishy-0.1-py3.6.egg/fishy/ntfs/ntfsSlack.py", line 121, in write
    raise Exception("Not enough slack space")
Exception: Not enough slack space

Don't know if it matters, but the actual filesize is 4 Bytes on my system...

$ ls -l utils/fs-files/another 
-rwxr-xr-x 1 xxxxx users 4 Oct 26 20:48 utils/fs-files/another

I used the ntfs-image created by running ./create_testfs.sh

Writing to other files, like 'long_file.txt', work fine.

Failing tests for FAT and NTFS

Some of us discovered a few problems while running the unittests. Under Debian and arch linux all FAT tests pass, but the NTFS test of MFT File Records failes with:

____________________________________________________________________ TestGetRecordOfFile.test_get_record_of_file ____________________________________________________________________

self = <test_ntfs.TestGetRecordOfFile object at 0x7f78e89e5fd0>, testfs_ntfs_stable1 = ['/tmp/tmpjej3b9pj/testfs-ntfs-stable1.dd']

    def test_get_record_of_file(self, testfs_ntfs_stable1):
        """
            Tests if the correct record is returned for
            the supplied name
            """
        with open(testfs_ntfs_stable1[0], 'rb') as fs:
            ntfs = NTFS(fs)
            assert ntfs.get_record_of_file('$MFT') == 0
            assert ntfs.get_record_of_file('$MFTMirr') == 1
            assert ntfs.get_record_of_file('$BadClus') == 8
            assert ntfs.get_record_of_file('another') == 64
>           assert ntfs.get_record_of_file('onedirectory/nested_directory') == 69
E           AssertionError: assert 71 == 69
E            +  where 71 = <bound method NTFS.get_record_of_file of <fishy.ntfs.ntfs_filesystem.ntfs.NTFS object at 0x7f78e89e5748>>('onedirectory/nested_directory')
E            +    where <bound method NTFS.get_record_of_file of <fishy.ntfs.ntfs_filesystem.ntfs.NTFS object at 0x7f78e89e5748>> = <fishy.ntfs.ntfs_filesystem.ntfs.NTFS object at 0x7f78e89e5748>.get_record_of_file

tests/test_ntfs.py:69: AssertionError

Under ubuntu there are issues with the FAT tests but NTFS tests pass.

I was not able to reproduce the FAT test failures under the latest ubuntu version.

APFS Timestamp Hiding Utilities

Several improvements can/have to be made to the APFS Timestamp technique:

  1. The choice of which timestamps should be written to needs to be simplified and accessible from the console (right now, the code would have to be changed).

  2. Instead of writing to 4 bytes, the technique should only write to 30 bits.

Documentation: Extend and add multiple sections

We need to add some sections to the documentation:

  • Why we wrote this tool, why should our program be used, analysis of existing tools...

  • Use case of our tool

    • Maybe just describing a brief scenario where one could use this tool
    • Mention that no encryption is applied to the hidden data, so the user is responsible for that.
  • Document create_testfs.sh including testfs filestructure (the reason/test case for each file/directory)

  • Limitations of our program (e.g. linux only)

  • Evaluation of our program and hiding techniques

    • Gained Capacity for each hiding technique
    • Detection Rate with fsck and forensic analysis tools
    • stability of the hiding technique
  • Extended usage, e.g. use pipes to add checksumming and encryption

  • Metadata: explicitly mention that it is serialized as json

  • Filesystem data structures for ntfs and ext4

  • Hiding Technique documentation (nearly all)

  • List all implemented hiding techiques in README.md AND doc/source/01_getting_started.rst

  • Api Reference for nearly all important modules

  • Development: move notes from readme to documentation and extend it

  • Future work (-> turn following bullet points into continuous text!)

    • Use a more secure clearing technique for hiding techniques -c option
    • Add possibility to hide multiple files
    • Implement a fuse filesystem, which uses multiple hiding techniques to store data
    • Maybe add encryption feature
    • Hide Metadata files itself
    • more reliable filesystem autodetection (FAT and NTFS detection only check for an ASCII string in bootsector)
  • Extend "abstract"

  • include documentation structure (01_overview.rst)

  • Turn most bullet points into text

  • Make sphinx size included images to a format that fits on page for the pdf version.

  • For all:

    • Please check all written stuff for consistency. Many eyes see more than just one two.
    • Add your name to the author variable in fishy/doc/source/conf.py (if you want), so that it will appear on the documentation.
    • Check if all of your work is mentioned in responsibilities (doc/source/07.2_responsibilities.rst)

Refine cli interface

The are some inconsistencies in the cli interface.

  • The metadata subcommand does not require a device (-d), but all other commands do.
  • The info option of fileslack subcommand should not require a metadata file

Also it might be nicer to move the -d option behind the subcommand.

The argparse configuration should require all options which are actually required and should not require options, which are not required...

Edit:

  • Maybe we should seperate informational functionality (fattools, metadata) from hiding techniques via additional subgroups
  • Read/write/clear/info options of a hiding technique should only be used once at a time. We could propably implement this via add_mutually_exclusive_group
  • for fileslack subcommand, the -d option must be required, when writing to fileslack

Some other things are wrong or need extension in the help output:

  • as the mftslack options were copied from fileslack, this keyword occures in the help output, but is wrong there.
  • subcommand help output should be more descriptive

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.