Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Uni

International Doom Latest Version Virus Threat?

Recommended Posts

Hey guys, sorry for starting a new thread about this but I downloaded the latest Inter-Doom version and I got 2 notifications from my Anti-Virus that the files have been infected with 2 types of trojan horses : Trigger!rfn and Wacatac.H!ml. 

 

Is it possible that the download links are this dangerous or is this just a false positive? I google searched the later one and it seems harmful to the system.

Share this post


Link to post

Thanks, I scanned it and it said that the file might be infected so I'm gonna need to take some steps. I've never had issues with that source port before.

Share this post


Link to post

It is most certainly a false positive. This has popped up on other source ports as well from time to time.  

Share this post


Link to post

Sadly, yes, there is a false positive on newly introduced console wrapper "inter-doom.com". This file is needed to provide console text output under certain conditions (aside from -devparm command line parameter is doing mostly same thing) and can be safely deleted if not needed.

 

Project's co-author Leonid Murin tried to fix it in one of recent commit, but apparently it is happening again. Wrapper's code is here, and I honestly have no idea what can we do next to shut up such false positives.

Share this post


Link to post

@Julia Nechaevskaya Thanks for the reply. I figured it was something like that. I was just trying to be sure, especially after recent events.

 

I'm pretty much depended on this port since I can't use any other one, it's simply that awesome.

Share this post


Link to post

It is false positive. It comes from "inter-doom.com" file. If you don't use CLI, you can delete it.
 

Q: Why does "inter-doom.com" exists?
A: Because of Windows's stupid application types. App can either be Console or GUI. Only Console app can properly attach to parent terminal (cmd, PowerShell, etc.), but always creates new console window if there is no parent one. The first approach was to make Inter Doom a console app and close the console window when it is not needed, but @Julia Nechaevskaya didn't like the blinking window, so we decided to go with the console wrapper.

The ".com" extension have priority over the ".exe" if no extension specified in the command line, like "inter-doom --help". The code of this wrapper originates from the Woof! source port and it's distributions also have false positives.

At the beginning it had only 3/72 false positives and I managed to fix them for x64 builds by removing some function calls that read input stream code page and console mode. Now then it is 32/64 false positives, I think that we need to come up with more sophisticated launcher on Windows.

Share this post


Link to post

@Dasperal Thank you so much for the clarifaction, I figured it was something to do with Windows, just had to be sure. 

 

Also thank you guys for making and maintaing this port, it's my absolute favorite. 

Share this post


Link to post
On 10/17/2022 at 12:52 PM, Dasperal said:

I think that we need to come up with more sophisticated launcher on Windows.

One idea would be to spawn a console app as a separate process and capture its standard IO handles to interact with from the port.

Share this post


Link to post

GZDoom does this from the main process:


        StdOut = GetStdHandle(STD_OUTPUT_HANDLE);
        if (StdOut != NULL)
        {
            // It seems that running from a shell always creates a std output
            // for us, even if it doesn't go anywhere. (Running from Explorer
            // does not.) If we can get file information for this handle, it's
            // a file or pipe, so use it. Otherwise, pretend it wasn't there
            // and find a console to use instead.
            BY_HANDLE_FILE_INFORMATION info;
            if (!GetFileInformationByHandle(StdOut, &info))
            {
                StdOut = NULL;
            }
        }
        if (StdOut == nullptr)
        {
            if (AttachConsole(ATTACH_PARENT_PROCESS))
            {
                StdOut = GetStdHandle(STD_OUTPUT_HANDLE);
                DWORD foo; WriteFile(StdOut, "\n", 1, &foo, NULL);
                AttachedStdOut = true;
            }
            if (StdOut == nullptr && AllocConsole())
            {
                StdOut = GetStdHandle(STD_OUTPUT_HANDLE);
            }

    }

 

Have you tried that?

Share this post


Link to post

@Graf Zahl Yes, I tried. The main problem with this approach is that it returns control to the parent terminal (cmd, PowerShell, etc.) immediately after the process is started. This creates a situation when two applications control one console window simultaneously. This also means that when the process exits, you won't see the expected line with the current directory path and cursor, as it was already printed long before. Things become match more broken if you use Far Manager:

.

@Quasar This has the same cons as described above, but also as it spawns an additional process, it will trigger a lot of antivirus false positives.

For now, I decided to make .exe and .com link a DLL with the main code, this cleared almost all false positives, but I can't guarantee that they won't come up again. And it's a very annoying work to try to bypass the stupid heuristic AI of antivirus. I don't want to do it ever again.
If your antivirus still detects viruses in Inter-Doom distributions, report it to your antivirus maintainers as false positive.

In my opinion the best solution to CLI problem is the initial one: Make only .exe, make it SUBSYSTEM:CONSOLE, immediately close automatically created console window if not needed. The only con is blinking of the icon of console window in the task bar (and blinking of the console window itself) that @Julia Nechaevskaya doesn't like. If you think that the blinking is ok, you can attempt to convince @Julia Nechaevskaya.

Share this post


Link to post
1 hour ago, Dasperal said:

@Graf Zahl Yes, I tried. The main problem with this approach is that it returns control to the parent terminal (cmd, PowerShell, etc.) immediately after the process is started. This creates a situation when two applications control one console window simultaneously. This also means that when the process exits, you won't see the expected line with the current directory path and cursor, as it was already printed long before.

 

Oops, you are right. The console support has always been sufficient for what I use it for but I guess when actually starting stuff from a terminal app things may become a bit tricky. It's really too bad that Windows knows no middle ground between a GUI app and a console app that automatically can attach to a console if available but does not depend on it.

 

 

1 hour ago, Dasperal said:

 

Things become match more broken if you use Far Manager:

.

 

Ouch! I've never seen a Windows application (ab)using the console like that.

Truth be told, I wonder anyway how that will fare as the Windows console system sees some more serious reworks. Surely they promise to keep the old stuff working but I'd expect some breakage with such extreme use cases as time goes on.

 

 

2 hours ago, Dasperal said:

In my opinion the best solution to CLI problem is the initial one: Make only .exe, make it SUBSYSTEM:CONSOLE, immediately close automatically created console window if not needed. The only con is blinking of the icon of console window in the task bar (and blinking of the console window itself) that @Julia Nechaevskaya doesn't like. If you think that the blinking is ok, you can attempt to convince @Julia Nechaevskaya.

 

Here's the actual problem with this: To many Windows users this appears unprofessional and stuff quickly gets dismissed as "yet another piece of poorly ported Linux software".

 

 

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×