I mean, this message is at the same time revolting, and sad.
The main actual problem with your review is that you give it credits by citing you cybersecurity experience, but you actually provide no actual real proof that the app is a virus but just speculation based on a rather pretty low level analysis.
Also yes on the contrary of many of the comments you saw before, I actually justify myself with actual facts its why answers are long.
I'm not here to say you are bad in cybersecurity and probably a lack of experience in programmation/development in general, but your point of view is highly biased by your experience of cybersecurity analysis and to be honest I kind of understand why because I can relate, (I'm relating to what you say because when I was young I was really interested in cybersecurity and IT in general (maybe too much), and yes I know how RATS, keylogger etc works, its always the same, they either are using a nested chaining system of execution to hide the real exe behind hundreds of nested application code where they call raw binary exe from memory or they are sometimes renaming themselves at high frequency and are capable of changing directory with a pair of process by reversing the roles between which program is the master and the other the slave, most of the time you actualy need to put breakpoints in IDA to see when this reverse operation is made).
For me you may also know that the critical point in determining if an app is a virus or not is its behavior mainly (api calls, system calls, driver usage, IO usage), and not some technology/security used for the app itself even if they still are indicators for investigation.
1. Yes like I said before, you can use the dll, the exe is in fact just a bootstrap for the app. I'm not sure why you're talking about the installer, what I actually sent to virustotal is the dll itself containing the entire code of the application and not the installer which is stupid yes to analyse. (
https://www.virustotal.com/gui/file/b57b95eae48cd1e16dc71b51b8f0ec21adaf830396db9695733ba90ab666beb4?nocache=1)
2. Regarding this d.exe, this is at the same time a mistake and also not a mistake, the fact that its still running in the background after the app running itself is a programmation mistake, the process d.exe is not a child of the main process, and therefore doesn't die on the application end, the concept of processes and who owns the child process in comparison to linux after main program end is a little different.
This d.exe is actually yes a packaged python app made into a single program, the reason is python dependencies, installation and python appliction deployment is extremely instable due to the nature of python itself.
d.exe is actually the process that generates the Mythic mob syntax code using AI, its actually embedding the cpu version of pytorch to allow character generation.
Why isn't it inside the application code ? because first its using a different programming language, and also because Microsoft dvelopment technologies and AI are really not good friends at all, from bad performance to unsupported hardware and tremendous amount of bugs, yes onnx exist, but its not a linear implementation and its not supported correctly on hardware especially amd systems.
Python is definetly the best technology for AI.
And no its not stupid to protect an application from being sandboxed since the same technique for decompilating and create cracks of software is used.
For me your conclusion is the result of an unfinished/incomplete analysis combined maybe with some lack of knowledge about application development itself, but I can be wrong. However its a bit normal if your main experience is cybersecurity only.
