Hi Dan,
This is a long and probably rambling post, with the definite potential for errors. I've now had a chance to check my utilities that were flagged by SiriusLLM as malware. I'm going to skip a lot of the smaller details as I think they will just complicate matters without adding anything of merit to the discussion.
I'll start with my pushover alert sending client that I've mentioned previously. I've reached the stage where I've decided to drop UPX. Not because of Sirius as such, but more because after repeated attempts, I've still not been able to get this program whitelisted on a couple of AV solutions and the concern and frustration of what they are misidentifying my app as. I do still think there would be merit in the increased accuracy for Sirius by using signature identification and pre-processing on the client side to ensure that AI gets to more accurately analyse the target when it comes to UPX compressed executables. I honestly have no idea how prevalent such executables are these days though, especially with the increased instances of mis-identification we see from many anti-malware solutions now. I can be a bit of a dinosaur with an early 2000's mindset at times.
The good news is SiriusLLM no longer sees Pushover as a threat. The only issue I see is it is detected as a .NET application.
indicates that it is a .NET application
This app is written entirely in Rust, as are the majority of my modern apps. My older apps tend to be written in C and Sirius seems to detect those without issue. Rust identification currently seems to be very hit and miss. I don't think this is a massive deal, but the model can clearly be improved in some cases when it comes to identifying the underlying compiler.
fwblock.exe: -
Selected result: Not Safe with 92% confidence from Model 1.
Malware Type: Firewall Bypass Tool
strongly suggests its real purpose is to open firewall holes for malicious payloads
It seems like the code optimization does make this code understandably more difficult to interpret than it should be, but by checking one of the pointers when building the rule prior to the function call, all code within the app creating the firewall rules can be proven to be hard-coded to "block". How the AI models came to the conclusion that this is a firewall bypass tool is not clear. I assume it is taught to be paranoid by default? Generally this shouldn't be a problem, but either code complexity from compiler optimizations or AI under analysis has lead Sirius to come to the conclusion that this app opens up holes in the firewall for malicious payloads with absolutely zero discernible evidence.
.text:00000001400038BC lea rax, [rbp+1520h]
.text:00000001400038C3 movups xmmword ptr [rax+10h], xmm1
.text:00000001400038C7 movups xmmword ptr [rax], xmm0
.text:00000001400038CA mov [rbp+14B0h], r12
.text:00000001400038D1 mov [rbp+14B8h], rbx
.text:00000001400038D8 lea rax, off_14004D5D8 ;Pointer to Block mode
flush.exe: -
"Rust is a modern language, so this might be a Rust-compiled program". Identification worked successfully here, which is great.
"Anti-debugging imports like `IsDebuggerPresent` are uncommon in benign utilities." I'd agree, but my code has no debugger checking so this had me scratching my head. Looking at the compiled executable though, SiriusLLM is actually completely correct on this one: -
.text:0000000140044313 mov [rsp+5C0h+var_570], 40000015h
.text:000000014004431B mov [rsp+5C0h+var_56C], 1
.text:0000000140044323 call cs:IsDebuggerPresent
.text:0000000140044329 mov ebx, eax
.text:000000014004432B xor ecx, ecx
I can only assume this is from one of the 3rd party imported crates. This app uses Clap, standard rust libraries and standard Microsoft Windows crates. From my investigation so far, there appears to be a bit more to this though, which I've detailed below.
Malware Type: Malware
Malware Name: DriveManip.BenignMask
Final verdict: Malicious with 92% confidence.
The Rust-based code and overlay entropy patterns align with the use of modern languages for obfuscation and evasion, which is uncommon in traditional legitimate disk tools.
I assume the entropy is caused by compiler optimizations? There is zero obfuscation either in my code or the compiled target. I'm not sure why the AI believes there is any form of evasion. Using a modern language probably shouldn't be a trigger simply because it isn't C, but without a more detailed understanding of the AI model, it is hard to know exactly the trigger here outside of the level of entropy.
volumes.exe: -
"APIs: IsDebuggerPresent suggests anti-analysis behavior". Yep, probably true here too.
The threading synchronization primitives (CreateMutexA, WaitForSingleObjectEx) and exception handling framework suggest multi-threaded operation with sophisticated error handling.
The most revealing strings expose this as a Rust-compiled application with full panic handling and debugging infrastructure. Key concerning strings include:
- Rust-specific error handling ("panic in a function that cannot unwind", "thread panicked while processing panic")
- Threading primitives ("too many active read locks on RwLock")
- Debugging symbols and PDB references
- Color coding references that suggest more than simple text output
- Advanced file system feature detection that goes beyond basic volume information
These strings collectively describe a sophisticated application framework, not a simple volume utility.
Erm, thanks I think?
Malware type: Dropper
Malware name: RustDropper.FakeUtility
Final verdict: Malicious with 92% confidence.
Maybe I have over complicated things, but correct error handling of Rust panic situations, multi-threading and text color coding seems a bit of stretch to define this as a fake utility.
crc32.exe: -
The imports include several security evasion functions like IsDebuggerPresent, IsProcessorFeaturePresent
I'd argue IsDebuggerPresent is the exact opposite of security evasion and I'm not sure why "IsProcessorFeaturePresent" should even be an issue? I suppose neither points are particularly important though.
What is more important: -
Malware type: Dropper
Malware name: Dropper.StegoLoader
Final verdict: Malicious with 90% confidence.
How is this being determined to be a dropper or (I assume) use stenography? What is being seen in the code to trigger this? It has no code related to network connectivity of any kind, which makes it kind of impossible to function as a dropper and the underlying code is fairly clean and simple, so I'm not sure why Sirius is identifying it as "Dropper.StegoLoader".
This one is interesting (to me at least) because this is nearly 30 year old C code (although it has only recently been recompiled and signed recently for public release). The thing is there are no 3rd party libraries in this app and everything outside of my own code is a call to standard Microsoft libraries. This points to "IsDebuggerPresent" being included by a standard Microsoft library. I need to do a bit more digging, but I will get to the bottom of where this is coming from. I'm only surprised that this hasn't been flagged more often. Maybe this is just due to the sort of system utilities I am writing though.
I intend to investigate this further to determine exactly where the debugger check is coming from in the final compiled code. Maybe once there is a clear reason why this exists in some code (due to libraries etc), it might possibly make it easier to distinguish between naturally occurring library code and the function being actively called.
I'm very happy about your recently reported retest results where none of the above were found to be malware. I am still very curious about what has caused most of these triggers though, as the AI is somewhat opaque around how it came to a number of these conclusions.
Again, just to reiterate, this honestly is not criticism of SiriusLLM. I think it is a fantastic product with amazing potential. I just want to provide some (hopefully) constructive criticism that with luck helps lead to product improvements going forward.
Regards,
Chad - Emerita Codeworks
help.nextdns.io
).
