Manalyze Open Source Contribution
As of 22/07 (Happy pi day), I am proud to say I am now an open-source contributor. It's not exactly a huge contribution, but I hope I'll be able to do more in the future as well.
At £JOB, I was asked to make a system for scanning built artifacts for any issues, to help prove to clients that our software is safe. After some searching, I found the Manalyse program
. It seemed interesting, but the prebuilt binaries link seemed to be dead, so I tried to get it to build on my work machine. Unfortunately, I had some issues with it, as it kept crashing when trying to run YARA scans, and some arguments didn't seem to be working properly.
I reached out to the author, Ivan, via email, explaining how I was having problems getting the program to build properly, and that the prebuilt binaries link appeared to be dead, and he quickly set up the released page on the github, allowing me to properly test the program. This version worked much better, with the command line arguments working properly, no crashes, but it was generating warnings related to the YARA rules. I have struggled with C++ in the past, so I take all the responsibility for my own builds not succeeding, as I was likely doing something wrong on my end.
However, the YARA rule errors did annoy me a bit, as they prevented the rule files from compiling properly, and meant that all scans using the ClamAV rules failed to run. I decided that, since the rules generator was written in python, rather than C++, I could take a crack at fixing it up and contributing back to the program. There were some existing github issues about this program, so I knew that it was something that other people were struggling with too.
YARA rules are a system for matching sequences of suspicious bytes in a program, that could indicate the program is malicious, or has been infected by another program. For example, the rule could contain searches for filepaths that are known to be accessed by infomation stealers, that any legitimate program would never need to access. They could have rules that search for the machine code that encrypts data in an unusual way, or they could have a regex that looks for bitcoin addresses. These can be used by a YARA scanning program to search files, or be embedded into another program that can do it.
ClamAV has its own signature system that works in a similar way to YARA rules, but can also include more features in some cases. For example, it can also embed regex into the conditions with a trigger based on other rules, which YARA doesn't directly support. In most of these cases, the Manalyse parser will simply say that the rule is malformed and continue past it, but when I ran it, there were 4 specific rules that were attempted to be parsed, but emitted invalid YARA rules. These situations were the ones I wanted to fix.
After reading the Github guide to contributing to projects to make sure I was doing it correctly, I forked off the project and made my own branch for the fixes. I first fixed some low hanging fruit where python was complaining about the strings used for regexes. They were simply maked as normal strings, "like this", but python warned that this would be deprecated and they needed to be marked as raw strings, r"like this". This allows backslash characters to be used without them being interpreted as escape characters (like how newlines are written as "\n"), among other things. Then I turned to fixing the actual issues in the code.
I made PCRE substrings simply fail processing. They could be rewritten to be parsed correctly, but I think that would have required some changes to the architecture of the parser, which I wasn't willing to do as a first time contributor.
The other three errors were caused by what I can only assume to be malformed ClamAV rules, as they did not seem to match with the documentation I could find. For example, one rule had a condition starting with 0:0, when conditions should start with a single number. If I changed it to be 0 instead, the rest of the rule made complete sense, so I added a check that rewrote any condition starting with stuff:things to just start with things instead.
In cases where I could not confidently rewrite a rule into a working YARA rule, I simply returned the same "malformed rule" errors that were already being returned, to match with the existing behaviour. However, it would be nice to add some more output in those cases to specify why exactly the rule was malformed, and potentially work on rewriting parts of the parser to be able to accept those rules, where a conversion is possible (eg in the PCRE substring cases I mentioned earlier). That is something I would like to potentially do in the future, as another contribution.
One final thing I added was a -q/--quiet flag to the parser, just to make it not output all the messages about malformed rules. While they might be useful debugging information in some cases, it made it extremely hard to find the actual errors I was looking for when working on the parser, and it's not really necessary for the end user.
I made the final pull request, and it was quickly merged in by Ivan, which was really good to see. My interactions with him and the project have been very positive, and I would be happy to work on the python part of his code in the future (though not the C++ part. I hate C++).
Back to Main Page
Copyright © 2026 Amy Shaw