DosTips.com

TLDR I wouldnt use AB2EC because theres some weird registry/file access and it's also immediately detected as ransomware by Windows Defender, at least on my box. And the author was weird when I contacted him. Enjoy reading



So, I was getting a bit pissed off at the false positives with one of the more famous "Advanced Bat To Exe Converter" compilers (It's actually paid, 80$ license I believe). I wanted to know why it was being detected and exactly what it was doing, so after doing some research I found a couple suspicious things in the program.


The Main Executable



(First virustotal link, https://www.virustotal.com/gui/file/1b9 ... %20Jujubox)

First lets take a look at the main executable (A infinite hello world program). AB2EC is simply self extracting your batch files into AppData\Local\Temp\ytmp. It also is placing (if your using extended commands) another temporary file with the case of temp(random-numbers).exe,
that file is about 70KB. We'll take a look at that later and call it the "Other temporary file".

As for the main program, its accessing the following folders in the sandbox on runtime:

C:\Users\<USER>\Downloads
C:\Program Files (x86)\Common Files\Oracle\Java\javapath\
C:\Users\admin (Secondary administrator user)

So, already its accessing JavaPath (for some reason) and my downloads folder. A bit odd but, I'll roll with it.

As for the main files imports, it doesn't really import much so I didn't investigate further into that.



That "Other Temporary File"

(Second virustotal link, https://www.virustotal.com/gui/file/c69 ... /detection)

Heading over to the second temporary file here, it's been scanned before with similar hashes, so it was detected with some other executables, but I ignored that as its possible malicious programs actually could have used AB2EC.
Looking at the behavior of the file we see the executable accesses a lot of dll files in system32, normal stuff I guess for a EXE in c++.

What's more suspicious is the fact that its accessing some cool registry keys I've never seen in other compilers like:

``` Registry\Machine\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\996E.exe ``` < --- Wat?
``` \Registry\MACHINE\System\CurrentControlSet\Control\SafeBoot\Option ```
``` \REGISTRY\MACHINE\Software\Policies\Microsoft\Windows NT\Rpc ``` < --- Remote procedure calling
``` REGISTRY\MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\996E.exe\RpcThreadPoolThrottle ``` < -- Another RPC
``` \REGISTRY\USER\S-1-5-21-1482476501-1645522239-1417001333-500\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers``` < -- Software restriction policies, possibly from the process caller itself.

So, I had the feeling that some of the other registry keys that I deemed suspicious could have been used for digital signing and security so i didn't decide to include them, but I don't like the fact that my primary batch compiler, which has some proxy executable that (according to the author, which I'll talk about later) deals with advanced commands management, is importing a network-detail agnostic procedure calling system, with zero functionality that needs it, and is dealing with safe boot.

Furthermore, I couldn't find any "Processes Created" but this executable ends a process located in ``` C:\Documents and Settings\(USER)\Local Settings\Temp\EB93A6\996E.exe ```, **another** executable that I was unable to locate, so i couldn't provide a scan of that.

As for DLL imports, it doesn't import anything that bad, only imm32.dll and comctl32.dll (These two deal with input and one of them has the functionality I believe is for the compilers "graphics" feature). However, it does import that really nice looking "rpcrt4.dll" file that deals with remote procedure calling, which makes me a bit unsettled that this is being imported on runtime as I don't expect my program to be doing anything on my LAN.

That's all I could find about this weird file created.


Process Monitor

So, if I couldn't find any other files or events on VirusTotal I decided to use Process Monitor. I didn't find anything suspicious per se. So there wasn't much to find here other than the above mentioned events.



Actually contacting the author of the program

Due
to the potential legal issues I could get by sharing the emails (And i'd rather not get accused of doxxing) I'll be giving emails to anyone privately on request. But, I contacted the author asking about these odd security things happening.


I had listed the above events that were *very* suspicious to him, and I also told him about a soon-to-be-debunked string that was found in that "Other temporary file" called "RCHELICOPTERFTW", but that was the only explanation he gave for anything. His reply to my email was, in no verbatim:

"My compiler is my lives work and purchased by government agencies, popular corporations and universities often. It is perfectly clean and always has been.
I have over 6 thousand hours invested in developing my compiler since before 2002."

As such I was a bit piqued by his lack of an explanation for any of the other claims (Downloads folder, weird registry access, odd imports, etc), so I sent him another email re-iterating what I said, and he only replied stating that the "Only registry keys" that are created are on installation of the IDE for context menus. He may be right, but the fact that these keys are so unique to his processes as compared to two other compilers I tried (B2EV/B2EM) gives me some doubt that "Just" installation keys were added.


I then told him to take a look (and embedded a image of the virustotal listing with the registry calls) at the keys himself, and he said, in no verbatim:

"It may look like a simple thing to to but there is a lot of magic going on and this is the only way to make it work on all versions and configurations of Windows.

Check out "OLLYDBG" on youtube. This is the program hackers use to hack ALL expensive "encrypted" or protect AAA games, business software and Windows itself by making anything in memory completely PLAIN TEXT. This is how all software is hacked the day it is released.
"

First of all, I already have OLLYDBG installed and that was a bit of a weird thing to say, as it didn't relate to anything I was talking about. I also found it funny how he said there's a lot of "magic going gon" to make this program work on all versions of windows. I can agree in some part, but judging by how the registry keys were being accessed it just seemed like he switched to compatibility mode smh.

I emailed him again explaining how my main concern was the folder access and the invasive registry keys, and he proceeded to reply, in no verbatim:

"
there are many things that must happen to run 32bit EXE that can detect 64 bit Windows and run 64bit commands. The EXE are running on all Windows languages, versions and configurations flawlessly and can be digitally signed in the most secure way possible. I have nothing but happy customers.
"

First off, the actual program already runs in compatibility mode so there isn't necessarily "many things" to enable compatibility mode (If that, as I'm fairly sure x64 machines can run x86-32 code fine enough, up to Windows though), and "Running on all windows languages" was a bit of a odd phrasing. It seems like he didn't think I knew much about computers (Even though I told him I already had OLLYDBG and provided my own Process Monitor images.

So, I told him and reassured him that I wasn't just throwing accusations out, and I just wanted to ensure the security of my box (And, my community which uses this software VERY often), and that I was concerned at the background activity and just wanted some implementation-like explanation (in summary that's all) about why these registry keys were being placed/why RPC was being used at all. And he responded with an accusation towards VirusTotal:

"VirusTotal is not interested in a way to quickly report false positives to all of their AV companies listed. No other industry has 70 competitors and you will find articles from pandasecurity showing how some AV companies blindly add false positives from the site without doing any work.

All of these companies exist only because VirusTotal exists who automatically forward the files to all companies upon any detection. VirusTotal is not trying to find what is actually a false detection and have been asked to make it as easy for developers to report the false positives. This would cut in to the AV profits and VirusTotal profits."

Now, some of what he's saying is documented and true but, the fact that I've given him cross verified information and the fact that he's blindly throwing out "VirusTotal is lying to consumers" after I give him an honest request for why its showing this, it makes me a bit suspicious of how he's treating my questions. Very defensive as if he is hiding something.

Now at this point I got a bit annoyed at how he was dragging this on for about a two hour fast-email spree, so I just told him, in verbatim, "I've cross verified the file access under my own process explorer, and I would only like just an explanation as to why these are being accessed for my own security and my team". And, he responded with, in no verbatim:

"Sorry I do not understand your concerns. There is no hidden malicious code or anything to be worried about. Software is complicated. You should check out Unity or any other development tool with a fine tooth comb. "

Yes, as a fellow developer and computer architecture hobbyist, software is complicated. And, I already use Unity. Pretty rude to respond to a customer who's been respectful but also is not giving into misnomered information or excuses without actually addressing the security issue I had.

Then it delved into more bantering back and forth until i just decided to stop replying. He made a quote about how I was basically lucky the dude responded to me (As if he was busy, because this is a niche product) and that other developers wouldn't even care and went on a micro-rant about that.







To conclude this, I may be 95% wrong with my stuff, if I am please contact me here and I'll gladly understand. I just know what I know, and what I know so far has led me to believe there's more going on in the background of the executables compiled with this. I also don't want to directly call him out for anything, but I did want to share that the dude was also suspicious in how he handled a potential customer of his 80$ BATCH compiler software with a security concern that is totally logical.

Also, his front-page site claims that the executables are compiled into native exe code (Just saying, its not, its just your standard batch container).

If this is taken as a callout/harassment I'll gladly remove on my own behalf from staff but, please, comment what you think about this.

Thanks ~ Zeek.