Jörg Stucke
Jörg Stucke
It seems to be still limited by unpacking: There is an additional progress bar displaying the unpacking progress (in yellow) and there seems to be no firmware with more analysis...
I agree that it would be nice to have this in FACT. Since there doesn't seem to be a "multiprocessing-safe" priority queue implementation in python, there seems to be no...
Hi, the message "Could not connect to clamd" usually means that the clamav-daemon service is not running. `clamdscan` uses the clamav daemon service (which should be running in the background)...
I don't like the idea to remove `complete_shutdown`. It is there for a reason: There are some cases where an exception in a process can lead to the backend (or...
Hi, I think this is a great idea. I already thought about whether e-mail notification would be a useful addition but this would probably be even better. Your contribution will...
Since FACT is designed to be a multi-user system, making the feature configurable during upload would make the most sense in my opinion.
The function `result_collector()` in `src/scheduler/Analysis.py` is used for collecting the results of the analysis plugins. In `_remove_from_current_analyses()` in line 473 the check, whether the firmware analysis is complete takes place....
The `Firmware` object and any unpacked `FileObject` undergo the analysis process individually. This made the check, if the analysis is complete a bit complicated. But you could simply add the...
I was thinking about this feature and I noticed another problem: the analysis scheduler (where the completed analysis is noticed) and the frontend (from where the signal is sent) may...
Everything should be MIT/Apache/BSD license or compatible, so even commercial use should not be an issue. FACT is not intended to be hosted publicly anyway (that could be problematic for...