flat assembler
Message board for the users of flat assembler.
Index
> Windows > My simple compiler generates an EXE identified as trojan |
Author |
|
revolution 21 Jan 2021, 14:45
Disable Windows 10 Defender. It is clearly not accurate so don't use it.
|
|||
21 Jan 2021, 14:45 |
|
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.
|
|||||||||||||||||||
21 Jan 2021, 15:54 |
|
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.
|
|||
21 Jan 2021, 16:03 |
|
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* |
|||
21 Jan 2021, 17:28 |
|
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. 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. |
|||
21 Jan 2021, 19:14 |
|
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. |
|||
21 Jan 2021, 21:56 |
|
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. 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.
|
||||||||||
22 Jan 2021, 03:34 |
|
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. |
|||
22 Jan 2021, 06:47 |
|
FlierMate 23 Jan 2021, 13:10
sinsi wrote: Two things I thought of 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.
|
||||||||||
23 Jan 2021, 13:10 |
|
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.
|
|||
23 Jan 2021, 13:23 |
|
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 |
|||
23 Jan 2021, 15:33 |
|
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. |
|||
24 Jan 2021, 11:50 |
|
FlierMate 24 Jan 2021, 11:52
DimonSoft wrote:
|
|||
24 Jan 2021, 11:52 |
|
FlierMate 05 Mar 2021, 12:57
----------
|
|||
05 Mar 2021, 12:57 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.