IPED: the Brazilian Federal Police forensic indexer you build from source

What IPED is for, and who it is actually built for

IPED stands for Digital Evidence Processor and Indexer, translated from Portuguese. The README states it was originally developed by digital forensic experts from the Brazilian Federal Police starting in 2012, and that although it was always open source, the code was only officially published in 2019. That origin explains the shape of the tool. It is not a consumer recovery utility. It is a batch processor for evidence seized at crime scenes by law enforcement or examined in a corporate investigation by private examiners, and the stated goals from day one were efficient data processing and stability.

The intended user is an examiner who has a disk image or a set of container files and needs them indexed, categorized, searched and reported on, often unattended. The README lists command line data processing for batch case creation first among the key characteristics, ahead of the analysis interface. The GUI exists, but it is the analysis side of a pipeline whose input is a case directory and whose output is an index plus reports. If your workflow is one laptop examined by hand over an afternoon, most of what IPED does is overhead you will not use.

How IPED processes evidence: Sleuthkit for decoding, out-of-process parsing

The architecture is visible in the repository layout. The top level splits into iped-api, iped-app, iped-carvers, iped-engine, iped-geo, iped-parsers, iped-utils and iped-viewers. That separation matters: the engine drives the pipeline, parsers decode individual formats, carvers recover files from raw streams, and the viewers and geo modules back the analysis interface.

IPED uses the Sleuthkit Library only to decode disk images and file systems, per the README. That is a deliberate boundary. Image formats therefore track Sleuthkit's own support: RAW/DD, E01, ISO9660, AFF, VHD and VMDK. On top of that, the README lists additional support for EX01, VHDX, UDF(ISO), AD1 from AccessData and UFDR from Cellebrite. Once a file system is decoded, the engine recursively expands containers across dozens of formats, handles embedded forensic and virtual disks including split or single segment DD, E01, EX01, VHD, VHDX and VMDK with differential VMDKs, and indexes both content and metadata, including unknown files and unallocated space.

One design choice deserves attention: the README describes stable processing with out-of-process file system decoding and file parsing. Running decoders in separate processes is what lets a malformed or hostile file take down a worker instead of the case. It is also the reason the tool can be resumed. The --continue and --restart options exist for stopped or aborted processing, which implies the pipeline keeps enough state to pick up mid-run. The README gives the throughput claim as up to 400GB/h on modern hardware and a multicase capacity of 135 million items as of 12/12/2019. Treat those as the project's own figures from that date, not as a specification you can count on for your hardware.

Building IPED from source on Windows or Linux

There is no installer in the README. The build path is explicit: git, Maven, and Java JDK 11 plus JavaFX, with Liberica OpenJDK 11 Full JDK given as an example. Set JAVA_HOME to your Java 11 installation folder, then clone and build.

git clone https://github.com/sepinf-inc/IPED.git
cd IPED
mvn clean install

The README states this generates a snapshot version of IPED in the target/release folder. Before you run it on real evidence, read the next line of the README carefully: the default master branch is the development one and is unstable, and if you want a stable version you should check out one of the release tags after the clone step. The recent releases listed for the repository are 4.3.1 from 2026-03-29, 4.3.0 from 2025-12-31 and 4.2.2 from 2025-04-24, so a release tag is available to check out.

On Linux the README adds a second requirement: you must also build The Sleuthkit and additional dependencies, and it points to the Linux section of the wiki for that. That is the step most likely to consume an afternoon, and it is not covered in the README itself.

For a first real use, the README directs new users to the Beginner's Start Guide on the wiki rather than reproducing invocation syntax in the README. So the honest sequence is: build or check out a tag, read the Beginner's Start Guide for the exact command line for your case, and only then point IPED at an image. Do not invent flags for it. The options the README does name are --continue and --restart for resuming or restarting stopped or aborted processing.

Processing profiles decide what IPED looks for

IPED ships processing profiles rather than a single default behaviour: forensic, pedo (csam), triage, fastmode (preview) and blind, the last described as for automatic data extraction. This is a real design decision, not a preset menu. The profile changes what the pipeline spends time on and what it surfaces, which means two examiners running the same image under different profiles can legitimately reach different results. For a triage pass you want fastmode; for a full examination you want the forensic profile. If you hand a case to a colleague, the profile is part of the case's meaning, and the README does not describe a mechanism for recording it inside the case itself.

The feature list around the profiles is where the scale of the tool shows. Hash support covers md5, sha-1, sha-256, sha-512 and edonkey, with PhotoDNA available for law enforcement by contacting the address given in the README. Hash sets can be loaded in NIST NSRL, NIST CAID, ProjectVIC, Interpol ICSE or standard CSV form, and fast hash deduplication runs on top. Carving is described as taking under 10% of processing time and scanning much more than unallocated space, with support for over 40 file formats and extensibility by scripting. Optical character recognition is powered by tesseract 5. Language detection covers over 70 languages. Named entity recognition requires Stanford CoreNLP models to be downloaded separately, which is a dependency the README flags rather than bundles.

Where IPED is the wrong tool, and what the README does not promise

The most concrete limitation is the one the project states about itself: master is the development branch and is unstable. Anyone who clones and builds without checking out a release tag is running development code against evidence. For an examiner whose output may end up in a report or a courtroom, that is a procedural problem, not just a technical one.

The second limitation is platform. The README says multiplatform support, tested on Windows and Linux systems. macOS is not in that sentence, and the related searches around Mac and iOS forensics tools are not answered by anything in the README. If your evidence is an iPhone backup or a Mac disk image, nothing here tells you the workflow is covered. The format list is about images and containers, and the parsers listed for messaging are Emule, Shareaza, Ares, WhatsApp, Skype, Telegram, Bittorrent and ActivitiesCache. Mobile acquisition is simply not the subject.

Third, some of the headline features are conditional. Named entity recognition needs models you download yourself. Nudity detection via the Yahoo open-nsfw deep learning model needs keras and tensorflow. Audio transcription has local and remote implementations, with the remote ones using Azure and Google Cloud services. Each of those is an extra dependency or an external account, and the README does not describe offline fallbacks for the cloud paths.

Finally, the performance and capacity numbers are dated. The 400GB/h and 135 million item figures are attributed in the README to 12/12/2019. They say what the project achieved then, not what you will get. Nothing in the README documents rollback of a processing run, and no rollback option is listed among the command line options it names.

How IPED differs from Autopsy and other Sleuthkit front ends

The natural comparison is Autopsy, the other well known open source forensic platform built on Sleuthkit. Both decode the same family of images through Sleuthkit, so the difference is not format support at the bottom of the stack. It is the top.

Autopsy is a GUI-first investigation environment: you open a case, add a data source, and work through modules in a desktop application. IPED inverts that. Its first listed characteristic is command line data processing for batch case creation, and its output is an index you search, with a web API for searching remote cases and retrieving file metadata, raw content, decoded text and thumbnails. That makes IPED a better fit when you have many images to process and limited examiner hours, or when you want processing to run on one machine and analysis to happen elsewhere. The README also states portable cases without installation can be run from removable drives, which is a different deployment model from a workstation install.

The cost of that inversion is operational. IPED expects you to build it, manage Java 11 and JavaFX, and on Linux build Sleuthkit and additional dependencies yourself. The README does not offer a packaged download. If your team has no one who can maintain a Maven build, the effort lands on the examiner, and that is where Autopsy's packaged installer wins.

Licence, maintenance and the cost of upgrading

The repository's licence is reported as NOASSERTION, and there is a LICENSE.txt at the top level alongside a licenses folder and a ThirdParty.txt. That combination means the project carries its own licence text plus third party notices, and no automated classifier has matched it to a standard identifier. Read LICENSE.txt and ThirdParty.txt directly before you redistribute a build or ship a portable case to another organisation. Nothing here is legal advice, and the fact that the code was published in 2019 does not by itself tell you the terms.

Maintenance looks current from the outside: the repository is not archived, the last push was on 2026-09-21, and there were three releases in the period covered by the release list, 4.2.2, 4.3.0 and 4.3.1. That is a healthy release cadence, and it is the only maintenance signal available here.

The upgrade cost is the part to plan for. Because IPED is built rather than installed, an upgrade is a rebuild: check out the new tag, run mvn clean install, and expect a new target/release. On Linux, a Sleuthkit or dependency change on the host can affect the build independently of IPED's own version, so a machine that built fine last quarter may not build today. Cases are portable and can run from removable drives, but the README does not state that a case processed by one IPED version can be opened by another. Verify that against your own cases before you standardise a version across a lab.

Editorial conclusion

Adopt IPED if you run batch processing over disk images and containers and you are willing to build it yourself with Maven and JDK 11, or to install it from a release tag rather than the unstable master branch. Do not adopt it as a point-and-click acquisition tool for a phone in the field: it decodes images and file systems through Sleuthkit and parses apps, but acquisition is not what the README describes. Before committing, verify that your image format is in the supported list, confirm what the LICENSE.txt in the repository root actually grants, and read the Linux wiki section, because the Sleuthkit and additional dependencies must be built there separately.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. sepinf-inc/IPED on GitHub