flat assembler
Message board for the users of flat assembler.

Index > Windows > My simple compiler generates an EXE identified as trojan

Author
Thread Post new topic Reply to topic
FlierMate



Joined: 21 Jan 2021
Posts: 219
FlierMate 21 Jan 2021, 14:28
Long story short.

It all started with the following template:
(Recent changes include addition of GetStdHandle -10 and ReadConsoleA)
Code:
format PE console
entry start

include 'include\win32a.inc'

section '.data' data readable writable
    msg     db 'Hello World!',13,10,0
    len = $-msg
    dummy   dd ?

section '.code' readable writable executable

 start:

push STD_OUTPUT_HANDLE
call [GetStdHandle]         ;STD_OUTPUT_HANDLE (DWORD)-11

push 0         ;LPVOID  lpReserved
push dummy         ;LPDWORD lpNumberOfCharsWritten
push len         ;DWORD   nNumberOfCharsToWrite
push msg         ;VOID    *lpBuffer;
push eax         ;HANDLE  hConsoleOutput
call [WriteConsole]

push 0
call [ExitProcess]

section '.idata' data import readable writable

library kernel32,'KERNEL32.DLL'
include 'include\api\kernel32.inc'    


FASM produced a portable executable with size of 2048 bytes.

My simple compiler was based on that PE by keeping most DOS header, PE header, COFF header, section table and Import Table Section intact.

What this compiler does is creating Data Section and Code Section from scratch.

It supports two commands:
Quote:
ReadLine
WriteLine


So based on the input of source file, my simple compiler would generate identical code (produced by FASM) multiple times programmatically.

The following is source code in my "Satay" programming language:
Code:
ReadLine
WriteLine What this for?
ReadLine
WriteLine Yeah, you got it right
WriteLine What about now?
ReadLine
WriteLine Quitting...    


Now the problem is, the source code above if compiled using my SATAY.exe will produce an EXE identified as trojan by Windows 10 Defender.
(Although not every EXE generated by SATAY.exe will be reported as malware)

I have lost the Pascal source code of SATAY compiler, and I have deleted the complete Assembly source code (similar to first code snippet above, but with additional lines to support ReadLine command).

This SATAY compiler is producing a PE based on binary output of FASM. That's why I seek your help and advice.


Description: Test.txt.EXE was reported as malware.
Filesize: 89.66 KB
Viewed: 11965 Time(s)

Screenshot 2021-01-21 220923.gif


Description: Windows 10 denies access to my Test.txt.EXE
Filesize: 34.05 KB
Viewed: 11965 Time(s)

Screenshot 2021-01-21 220834.gif




Last edited by FlierMate on 13 Apr 2021, 16:28; edited 1 time in total
Post 21 Jan 2021, 14:28
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20339
Location: In your JS exploiting you and your system
revolution 21 Jan 2021, 14:45
Disable Windows 10 Defender. It is clearly not accurate so don't use it.
Post 21 Jan 2021, 14:45
View user's profile Send private message Visit poster's website Reply with quote
FlierMate



Joined: 21 Jan 2021
Posts: 219
FlierMate 21 Jan 2021, 15:54
revolution wrote:
Disable Windows 10 Defender. It is clearly not accurate so don't use it.


Thanks. You're right. I can replicate the issue with the following Assembly code and two additional steps.

Long code (if compiled will produce almost identical PE as Test.txt.EXE)
Code:
format PE console
entry start

include 'win32a.inc'

section '.data' data readable writable
    key1     dd ?
    buffer1  dd ?
    msg1     db 'What this for?',13,10,0
    len1 = $-msg1
    dummy1   dd ?
    key2     dd ?
    buffer2  dd ?
    msg2     db 'Yeah, you got it right',13,10,0
    len2 = $-msg2
    dummy2   dd ?
    msg3     db 'What about now?',13,10,0
    len3 = $-msg3
    dummy3   dd ?
    key3     dd ?
    buffer3  dd ?
    msg4     db 'Quitting...',13,10,0
    len4 = $-msg4
    dummy4   dd ?



section '.code' readable writable executable

 start:

push STD_INPUT_HANDLE
call [GetStdHandle]         ;STD_INPUT_HANDLE (DWORD)-10

push 0
push key1
push 1
push buffer1
push eax
call [ReadConsole]

push STD_OUTPUT_HANDLE
call [GetStdHandle]         ;STD_OUTPUT_HANDLE (DWORD)-11

push 0         ;LPVOID  lpReserved
push dummy1         ;LPDWORD lpNumberOfCharsWritten
push len1        ;DWORD   nNumberOfCharsToWrite
push msg1         ;VOID    *lpBuffer;
push eax         ;HANDLE  hConsoleOutput
call [WriteConsole]

push STD_INPUT_HANDLE
call [GetStdHandle]         ;STD_INPUT_HANDLE (DWORD)-10

push 0
push key2
push 1
push buffer2
push eax
call [ReadConsole]

push STD_OUTPUT_HANDLE
call [GetStdHandle]         ;STD_OUTPUT_HANDLE (DWORD)-11

push 0         ;LPVOID  lpReserved
push dummy2         ;LPDWORD lpNumberOfCharsWritten
push len2        ;DWORD   nNumberOfCharsToWrite
push msg2         ;VOID    *lpBuffer;
push eax         ;HANDLE  hConsoleOutput
call [WriteConsole]

push STD_OUTPUT_HANDLE
call [GetStdHandle]         ;STD_OUTPUT_HANDLE (DWORD)-11

push 0         ;LPVOID  lpReserved
push dummy3         ;LPDWORD lpNumberOfCharsWritten
push len3        ;DWORD   nNumberOfCharsToWrite
push msg3         ;VOID    *lpBuffer;
push eax         ;HANDLE  hConsoleOutput
call [WriteConsole]

push STD_INPUT_HANDLE
call [GetStdHandle]         ;STD_INPUT_HANDLE (DWORD)-10

push 0
push key3
push 1
push buffer3
push eax
call [ReadConsole]

push STD_OUTPUT_HANDLE
call [GetStdHandle]         ;STD_OUTPUT_HANDLE (DWORD)-11

push 0         ;LPVOID  lpReserved
push dummy4         ;LPDWORD lpNumberOfCharsWritten
push len4        ;DWORD   nNumberOfCharsToWrite
push msg4         ;VOID    *lpBuffer;
push eax         ;HANDLE  hConsoleOutput
call [WriteConsole]

push 0
call [ExitProcess]

section '.idata' data import readable writable

library kernel32,'KERNEL32.DLL'
include 'api\kernel32.inc'    


Compile the code above using FASM, and perform two additional steps:
1. Change the message in DOS Stub to "Please run this program under Win32 environment" (ended with dollar sign terminator string).

(Note: The default message is "This program cannot be run in DOS mode.")

2. Replace the checksum to 0x6D5F.

Voila, Windows 10 Defender found a new malware.


Description: Replace the checksum to 0x6D5F
Filesize: 29.27 KB
Viewed: 11941 Time(s)

Screenshot 2021-01-21 234650.gif


Description: Customize the message in DOS stub.
Filesize: 41.3 KB
Viewed: 11941 Time(s)

Screenshot 2021-01-21 233816.gif


Post 21 Jan 2021, 15:54
View user's profile Send private message Reply with quote
FlierMate



Joined: 21 Jan 2021
Posts: 219
FlierMate 21 Jan 2021, 16:03
Suddenly I have become malware analyst. The Assembly code above does nothing malicious but don't know why Windows Defender team identified it as trojan.
Post 21 Jan 2021, 16:03
View user's profile Send private message Reply with quote
Calanor



Joined: 19 Jul 2015
Posts: 45
Location: Sweden
Calanor 21 Jan 2021, 17:28
I consider it a side-effect of bloatware becoming the norm. Any compact code (e.g. written in assembler) runs the risk of being labeled as a "virus" by most (all?) anti-virus software. I called F-Secure some years ago and asked if they really think that making such assumptions is OK and they claimed that they'd never received any complaints about it. Absolute nonsense, if you ask me, though I guess most just accept the fact that anti-virus software act like this and don't bother to contact the companies behind them.

When I wrote a patcher/loader for a commercial product, I actually had to bloat the file with nonsense due to complaints from customers. I simply repeated a few instructions at the end of the code block, over and over again, increasing its size by 50K or something along those lines. All of a sudden, the loader wasn't considered a threat by the anti-virus software *heavy sigh*
Post 21 Jan 2021, 17:28
View user's profile Send private message Reply with quote
FlierMate



Joined: 21 Jan 2021
Posts: 219
FlierMate 21 Jan 2021, 19:14
Calanor wrote:
I consider it a side-effect of bloatware becoming the norm. Any compact code (e.g. written in assembler) runs the risk of being labeled as a "virus" by most (all?) anti-virus software. I called F-Secure some years ago and asked if they really think that making such assumptions is OK and they claimed that they'd never received any complaints about it. Absolute nonsense, if you ask me, though I guess most just accept the fact that anti-virus software act like this and don't bother to contact the companies behind them.

When I wrote a patcher/loader for a commercial product, I actually had to bloat the file with nonsense due to complaints from customers. I simply repeated a few instructions at the end of the code block, over and over again, increasing its size by 50K or something along those lines. All of a sudden, the loader wasn't considered a threat by the anti-virus software *heavy sigh*


Good reply. Before reading your post, I thought I want to submit feedback to Microsoft security team, but after reading your post, I have changed my mind.

It is intriguing to hear you actually needed to make the loader larger to prevent it to be scrutinized by anti-virus software.
It does look like compact size of an executable is not always a good sign.

Thank you for sharing your valuable experience.
Post 21 Jan 2021, 19:14
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20339
Location: In your JS exploiting you and your system
revolution 21 Jan 2021, 21:56
There are more than 50 AV programs around. It is impossible to please all of them all of the time. You can't predict which one your users have unless you own all of the system your code runs on.

So IMO don't even bother trying. The AVs should not be dictating how to write our code. They should be a tool for detecting bad code. But instead it seems the AV companies expect us to bend ourselves into contortions as they demand.

Plus if it is so easy to make changes to avoid detection then genuine malware writers can just do that also, so the AV doesn't do its job anyway.
Post 21 Jan 2021, 21:56
View user's profile Send private message Visit poster's website Reply with quote
FlierMate



Joined: 21 Jan 2021
Posts: 219
FlierMate 22 Jan 2021, 03:34
revolution wrote:
There are more than 50 AV programs around. It is impossible to please all of them all of the time. You can't predict which one your users have unless you own all of the system your code runs on.

So IMO don't even bother trying. The AVs should not be dictating how to write our code. They should be a tool for detecting bad code. But instead it seems the AV companies expect us to bend ourselves into contortions as they demand.

Plus if it is so easy to make changes to avoid detection then genuine malware writers can just do that also, so the AV doesn't do its job anyway.


This is my first time encountered this, so I was quite panicked because it downgrades the reputation of my experimental , though , a very simple compiler (SATAY.exe). I like it when you said "the AVs should not be dictating how to write our code" and "it is so easy to make changes to avoid detection...".

Nonetheless, I have submitted a report to Microsoft and that they now removed the incorrect detection. There are 12 other AV engines also gave false positive when I uploaded it VirusTotal.com but I could not care anymore .

Thank you to @revolution and @Calanor for your valuable inputs.


Description: Microsoft removed the incorrect detection after I submit reports
Filesize: 27.28 KB
Viewed: 11876 Time(s)

Screenshot 2021-01-22 112538.gif


Post 22 Jan 2021, 03:34
View user's profile Send private message Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 789
Location: Adelaide
sinsi 22 Jan 2021, 06:47
Two things I thought of

The filename was the classic "hidden extension" problem - in a standard install, the filename would have
been "test.txt", a harmless text file but it's hiding the fact that it's an exe.

In today's world of multi-megabyte exes a 2K exe is suspect.


Well done, I guess, to MS.
Post 22 Jan 2021, 06:47
View user's profile Send private message Reply with quote
FlierMate



Joined: 21 Jan 2021
Posts: 219
FlierMate 23 Jan 2021, 13:10
sinsi wrote:
Two things I thought of

The filename was the classic "hidden extension" problem - in a standard install, the filename would have
been "test.txt", a harmless text file but it's hiding the fact that it's an exe.

In today's world of multi-megabyte exes a 2K exe is suspect.


Well done, I guess, to MS.


I enjoyed reading this comment. Yes, maybe issue with hidden extension, compact executable size, and also checksum (is fixed at 0x6D5F).

The Test.txt.EXE is fine since then, but I encounter another incorrect detection if I use SATAY.exe to compile:

Code:
WRITELINE Hello World!    


I mean it is crazy. @revolution was right, I don't bother to contact those security intelligence this time.


Description: Same incorrect detection again
Filesize: 5.32 KB
Viewed: 11784 Time(s)

Screenshot 2021-01-23 210519.gif


Post 23 Jan 2021, 13:10
View user's profile Send private message Reply with quote
Calanor



Joined: 19 Jul 2015
Posts: 45
Location: Sweden
Calanor 23 Jan 2021, 13:23
Well, it's not like MS has updated the detection algorithms because of your report. They've just basically whitelisted that particular EXE, so I'd expect that even small variations in the code would trigger the AV software again. The problem is the assumptions AV software are making. Some activities have a greater chance to upset the AV software though - saving or modifying files, for instance. Or worse yet, if the code is downloading something off the internet.
Post 23 Jan 2021, 13:23
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 1228
Location: Belarus
DimonSoft 23 Jan 2021, 15:33
Calanor wrote:
Some activities have a greater chance to upset the AV software though - saving or modifying files, for instance. Or worse yet, if the code is downloading something off the internet.

For example, downloading another antivirus Smile
Post 23 Jan 2021, 15:33
View user's profile Send private message Visit poster's website Reply with quote
FlierMate



Joined: 21 Jan 2021
Posts: 219
FlierMate 24 Jan 2021, 11:50
Calanor wrote:
Well, it's not like MS has updated the detection algorithms because of your report. They've just basically whitelisted that particular EXE, so I'd expect that even small variations in the code would trigger the AV software again. The problem is the assumptions AV software are making. Some activities have a greater chance to upset the AV software though - saving or modifying files, for instance. Or worse yet, if the code is downloading something off the internet.


True. I don't bother this time, although it is quite a fact that a few demoscene ASM coders had entered virus writing circle. So I think I can't put the blame entirely on AV software maker.
Post 24 Jan 2021, 11:50
View user's profile Send private message Reply with quote
FlierMate



Joined: 21 Jan 2021
Posts: 219
FlierMate 24 Jan 2021, 11:52
DimonSoft wrote:
Calanor wrote:
Some activities have a greater chance to upset the AV software though - saving or modifying files, for instance. Or worse yet, if the code is downloading something off the internet.

For example, downloading another antivirus Smile


Very Happy
Post 24 Jan 2021, 11:52
View user's profile Send private message Reply with quote
FlierMate



Joined: 21 Jan 2021
Posts: 219
FlierMate 05 Mar 2021, 12:57
----------
Post 05 Mar 2021, 12:57
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.