Installation on ArchLinux

[noraj]

On arxsys there is instruction to install dff from sources but all dependencies are given for Debian.

Can you give a ArchLinux install guide or only depencies will be enought.

Thanks

[blshkv]

and this is how you should realise NOT to provide dff-build.sh. The software should have a proper CMakeLists.txt (which this project has already). Let distro maintainers do it right.

P.S. I'm creating an ebuild for Pentoo Linux right now, and it will look very similar with ArchLinux packages

[jarylc]

Hey @noraj1337, do take a look at the PKGBUILD I just published on the AUR.
https://aur.archlinux.org/packages/dff-git/

Let me know if you encounter any problems building it.
There may likely be missing dependencies, but yeah, just inform me.

[blshkv]

Gentoo/Pentoo ebuild is here as well:
https://github.com/pentoo/pentoo-overlay/tree/master/app-forensics/dff

[blshkv]

As you can see, both build packages are UGLY. As I said, DFF developers should review all patches, sed changes, etc and fix DFF properly.

[jarylc]

@blshkv I have to agree, some of their codes aren't very up to date. One example is the latest ICU not being detected in their old yet customized FindICU.cmake. Other problems include python3 and python2 conflicts.

My headache for the past 4 days is almost over...

I placed a pull request to the repo and tested building on both Debian & ArchLinux.

[blshkv]

@jarylc 4 days?!.. wow ... out of curiosity, I've looked at your PKGBUILD .. It looks like arch linux does not provide any utilities and that's why you have to do everything manually using bash commands.

It took me an hour probably. Yes, the same problem with ICU, so I just commented out 2 depreciated lines . No problem with python because it is handled by a distro eclases. Well, except linux_launcher.sh which is python (not a shell) script apprentely. SICK!

One of the hardest problem was broken code in dff-api/search/CMakeLists.txt file . It does not install __init__.py file if TRE library not found. That breaks the tool (does not start) and it took me awhile to figure it out ..

[noraj]

@jarylc : I commented your AUR package: https://aur.archlinux.org/packages/dff-git/#comment-578098

Install successfully from an up-to-date system.

But some (non-blocking) python import error when launching dff-gui:

libpng warning: iCCP: known incorrect sRGB profile
ImportError: No module named pyregfi

  File "/usr/bin/dff/api/loader/loader.py", line 239, in __load
    module = imp.load_module(modname, file, pathname, description)

 File "/usr/lib/python2.7/site-packages/dff/modules/databases/winreg/winreg.py", line 25, in <module>
    from hive import RHive

  File "/usr/lib/python2.7/site-packages/dff/modules/databases/winreg/hive.py", line 15, in <module>
    import pyregfi

[blshkv]

You are missing reglookup (and may be others). See my ebuild.

P.S. I'm working with reglookup upstream on Scons improvements, see pentoo/pentoo-overlay#145

[jarylc]

@noraj1337 @blshkv

Also Reglookup on the AUR currently only installs for Python 3, we need to copy the site-packages over to Python 2 libraries for support.

I have no control over that package as it's maintained by someone else. I could make python2-reglookup, but that would be redundant. I'll wait for the maintainer's reply or action to my comment.

@blshkv I'm not sure if what you are pushing to Scons repo would fix this as I've not read it yet. Will take a look later.

@noraj1337 Look at my reply and pinned comment on the AUR on how to fix this.

[blshkv]

Ha! I didn't realise that this old (2011) tool supports python3 as well. Thanks, fixed!

[noraj]

I see dff is included in blackarch now : https://blackarch.org/forensic.html

But both dff from blackarch and from git doesn't work now. There is a segmentation fault.

$ dff-gui
libpng warning: iCCP: known incorrect sRGB profile
[1]    8710 segmentation fault (core dumped)  dff-gui

$ dff-cli
1
loading modules in /usr/lib/python2.7/site-packages/dff/modules
[OK]	loading LOCAL v1.0.0
[OK]	loading DEVICES v1.0.0
[OK]	loading extract v1.0.0
[OK]	loading decompressor using old style module check
[OK]	loading skindetection v1.0.0
[OK]	loading compound v1.0.0
[OK]	loading lnk v1.0.0
[OK]	loading metaexif v1.0.0
[1]    8744 segmentation fault (core dumped)  dff-cli

And I have some python errors when asking help:

$ dff-gui -h
usage: DFF [-h] [-v] [-g] [-l [{cn,de,en,es,fr,it,nl}]] [-b [BATCH]]
           [-c [CONFIGURATION]] [-d] [--verbosity [VERBOSITY]]
           [--disable-exception-handler | --silent-report]

Digital Forensics Framework

optional arguments:
  -h, --help            show this help message and exit
  -v, --version         show program's version number and exit
  -g, --graphical       start the graphical interface
  -l [{cn,de,en,es,fr,it,nl}], --language [{cn,de,en,es,fr,it,nl}]
                        set the default language for user interface
  -b [BATCH], --batch [BATCH]
                        execute batch file containing either python code or
                        dff commands (line starting with ! ) or both
  -c [CONFIGURATION], --config [CONFIGURATION]
                        use the provided file as configuration
  -d, --debug           redirect outputs (aka print) to console
  --verbosity [VERBOSITY]
                        change debug verbosity. If debug is not enabled there
                        is no effect.
  --disable-exception-handler
                        disable exception handler (useful while live
                        debugging)
  --silent-report       do not start the graphical report sender after crash
                        and directly send the report (useful when running
                        tests and wanting backtrace in case of crash)
Traceback (most recent call last):
  File "/usr/bin/dff-gui", line 36, in <module>
    arguments = parseArguments()
  File "/usr/bin/dff/ui/ui.py", line 101, in parseArguments
    arguments = parser.parse_args()
  File "/usr/lib/python2.7/argparse.py", line 1701, in parse_args
    args, argv = self.parse_known_args(args, namespace)
  File "/usr/lib/python2.7/argparse.py", line 1733, in parse_known_args
    namespace, args = self._parse_known_args(args, namespace)
  File "/usr/lib/python2.7/argparse.py", line 1939, in _parse_known_args
    start_index = consume_optional(start_index)
  File "/usr/lib/python2.7/argparse.py", line 1879, in consume_optional
    take_action(action, args, option_string)
  File "/usr/lib/python2.7/argparse.py", line 1807, in take_action
    action(self, namespace, argument_values, option_string)
  File "/usr/lib/python2.7/argparse.py", line 997, in __call__
    parser.exit()
  File "/usr/lib/python2.7/argparse.py", line 2362, in exit
    _sys.exit(status)
SystemExit: 0

No python error with dff-cli -h.

update: this is DFF 1.4.0 - dff-183.d40d46b-1

[jarylc]

@noraj1337 oh DFF got updated to 1.4.0? Seems like I need to recreate the patch files again if changes were made.

edit: oh, I don't think it was a DFF update that caused it because it wasn't updated... Probably a new update to either python 2, qt4, swig or any other build tool that caused it... I'll check it out when I have the time.

EDIT: I found some problems regarding the latest version of python2-pyqt4. Reference http://stackoverflow.com/questions/37604532/python-2-7-11-importerror-cannot-import-name-qtwebkit-kali-linux-debian-8#37616466

I'll need to find time to perform the hard fix.

[udgover]

Hi guys!

Sorry for this long delay but we had lots of "business" stuff to manage and as you may have seen we are currently closing ArxSys. However, that does not mean it's the end of the development of DFF. We will soon release everything on github and there will be huge changes which may resolve your issues. We are going to work on this merge during the following days.

[noraj]

@udgover Good news for DFF and sorry for ArxSys.

[Baricanac]

Hi guys!

Sorry for this long delay but we had lots of "business" stuff to manage and as you may have seen we are currently closing ArxSys. However, that does not mean it's the end of the development of DFF. We will soon release everything on github and there will be huge changes which may resolve your issues. We are going to work on this merge during the following days.

Have there been any new developments on the current situation since this post? I have tried compiling DFF 1.3.6 from source on Debian 9.5 (Stretch), but so far I have been unable to compile it in any way.
In regards to all the suggested methods on the Installation page, which for me so far all have been unsuccessful due to the following matters:

The repo 'http://repo.digital-forensic.org/debian' used for a normal installation on Debian Jessie/Stretch, doesn't exist anymore , so there is no way that this is going to work anymore, meaning that option has become outdated. I have found another guide to install an older version of DFF using the Kali Linux repo, but that does not change the fact that I'm still not willing to give up on DFF 1.3.6.

When I tried to compile DFF 1.3.6 from source I ended up with some problems with the actual compilation itself, unrelated to the dependencies or prerequisites needed for the compilation.

So I'm going to ask this question as a plea for help, if anyone out there is still reading this. Has anyone actually been able to compile DFF 1.3.6 on Debian Jessie and/or Stretch? I'm not willing to take a no on this matter since I'm sure there might be a simple solution for this problem. One I'm unable to find at the moment. I hope someone is able and willing to work with me on this here?

Thanks in advance!

[blshkv]

No. dff is dead. The quality of code is bad and should not be used for forensic investigations