Just a nice little example demonstrating how a fake unpacking stub can be used to fool static analysis unpackers and A/V scanners. In this case an Armadillo stub is used to mask a UPX packed file.

http://illusivesecurity.pytalhost.com/viewtopic.php?t=140

Kayaker

Reading that thread reminded me of something I've been thinking about for a while:

Many antivirus programs seem to have big problems with analyzing/unpacking files packed by ACProtect. Why is this? ACProtect isn't normally known as a "high profile" protection in the reversing/cracking circles I frequent, and in the beginning it also just seemed to be a cheap byte-rip of Asprotect?!

If anyone knows anything about what seemingly makes ACProtect so hard, and why noone in the reversing world seems to speak openly about it as being one of the "hardest packers", you are very welcome to share what you know here!

@delta

"Many antivirus programs seem to have big problems with analyzing/unpacking files packed by ACProtect."

Actually, there is apparently NO antivirus program that can unpack files packed by ANY sophisticated commercial protector. This applies to ACProtect, Armadillo, ASProtect, Obsidium, Themida etc. If an antivirus detects malware protected with the help of a commercial protector it uses a signature created for the packed file or a signature taken from the resource section. Also generic unpacking engines fail to unpack commercial protectors.

Are you sure? I know some AV programs mention that they regularly update their internal unpackers. Avast is the one that comes to mind. hxxp://www.avast.com/eng/av4_revision_history.html
I think kaspersky also includes internal protection decompressors. though according to this article seems they are easily fooled. Interesting read.

ACProtect is not heard of often simply because it is not popular. ASprotect (note the 1 letter difference), Armadillo, etc. are much more commonly encountered, so there isn't much study of uncommon packers.

@gabriel

Kaspersky has a MUCH better unpacking engine than Avast. But even Kaspersky fails to unpack complex commercial protectors. What (some) AV scanners can do is UPX, ASPack, PECompact, Yoda, Netwalker, Morphine, telock, crunch, FSG etc. But NOT the "heavy stuff".

I know that some AV people claim that they have developed an Armadillo unpacker (similar to dillodie). But it remains to be seen whether it works good and fast enough so that it can be included into an unpacking engine.

Hi, I'm wondering why don't they trace till oep in armadillo, it can be done for all armadillo versions very simple(std, debug blocker, copy memII) and perform scan on unpacked process in memory while it is at oep, and of course, this is very fast unpacking, 2-4seconds Maybe AV companies should start reading reversing tutorials

I think the biggest problem is that it actually needs to run, deroko. Of course, placing a break on (mmh... don't remember now... i.e. createthread, 2xcall edi or ebx etc.) might be very quick, but what if the viral code is 'between' the break marks?
You cannot afford infecting a system while running an AV scan -face would be lost...

So, better make divide-et-impera signatures. Surely less safer for the user, but much safer for the company.

Still, I think they are mad. WHY the hell they don't simply ask user's permission and create a very limited user for unpacking purposes (NTFS perimitting)? That way, malware should have a bad journey as it could be quickly unpacked&accessed using debug privileges, while nullifying its negative effects (and such user, anyway, could be removed/fixed/altered at will by the AV).

Well, hope to see one with such basic technique very soon. It's not SO difficult...

I'm not talking about createthread method, I mean use nonintrusive tracer to reach oep in armadillo debug blocker or copy mem II.

Yep, still it has to run, but only armadillo code is running, not packed application

I am missing the point, deroko. A non-intrusive tracer requires you to inject within application space, so you effectively need to run -not emulate- the application. Which leads to the above mentioned problem, regardless the method.

The problem is not gross unpacking, in my opinion, but a safe environment (a sort of sandbox) where it can be done without risks. I don't think AVs would risk to launch an application while scanning -it would be a hot, true security problem for them. What would happen if a comes virus (as it would) that take advantage of the 'full run' to infect& stop the AV?

It might be done, however, within a secured environment. At that point, the unpacking style gets important. And, if we discover that the 'secure' user is bugged, AVs has no guilt, as it would be a m$ failure, and users of the AV are not the first to be worried about it...

edit----
maybe adding a behaviour blocker to the tracer? But it would probably a be more complex and less reliable solution.
Being you a V, what do you think about? I mean, if you knew an AV really executes code in (i.e.) admin space.

oki lets go like this:

1. AV is scanning hdd and finds armadillo packed app
a. run till oep and check for signatures
b. virus detected/not detected

2. AV finds file that is not packed
a. scan it as usualy using signatures, "heuristic"
b. virus detected/not detected

I don't see anything dangerous here, malware is not running, only thing that is running is armadillo layer If AV is scared to run it till oep, then run it untill executable isn't decrypted, for example, for execryptor only execute tls callback and bingo whole exe is decrypted, check signatures and voila - packed code is not executed and still you get decrypted executable.

Maximus is trying to describe the following situation:
A malware author uses Armadillo to protect their a program. They then insert malicious code into the unpacking stub such that the AV engine will still detect it as Armadillo yet this inserted malicious code will run before the OEP is reached. This is bad.

This could be prevented by maintaining checksums of the unpacking stubs. Armadillo loses none of its security by publishing SHA-1s of the stub, and the interval between changes to these stubs is far greater than the interval between AV sig updates. It would of course require considerable cooperation between protector-coders and av-companies, which in itself is probably a fairly insurmountable hurdle.

@disavowed : yep I completely understand what he is trying to say, but how many of such modifications have you seen? if they could modify their malware to not be detected then they wouldn't use armadillo or other protector to hide their HL malware.

I don't think it works.
Packers might give possibility to execute code before OEP with internal registration APIs, or protection ones.
Also, what if certain dynamic data is kept within stub boundaries?
I don't think Armadillo (or others) wishes to tell where it keeps its 'dynamic' data.
An easier solution for V is to just disable crcs and add a jump in a frequently changed area -that's all.
For example, take arma stub: add a jump and you are done. AV launched the malware in admin space.
Load my driver, please...

edit---
this is the problem that would raise if code were executed. Right now, code isn't executed so the problem is theoretical. It's the problem that happen now when you open a malware in the debugger, and you run the decompression stage without noticing that little weird polyjump out of it...
you get infected.

you really think that some skilled vx writer will use armadillo to protect his own code? nah

HL malware writers are the ones who are/will use armadillo,aspr,svkp, etc. to hide their easily detected code.

That's for sure
I started as a VC many many years ago, when DAV ruled
...before windows 95 wrenched my HD 2 times I think, one fatal.
DOS was an interesting period, as size optimization was also one of the goal.

I never examined today's viruses (maybe I'd look to your code 'n see how V are coded today, or 29A work) - but I think they now contains complex poly features to eavesdrop AV (like aspr, which seems to have used a v-derivated one).

Your idea isn't wrong or such, simply I say that using a 'natural' sandbox in case the malware writer is smarter than the average is needed, as NO AV can risk to infect a system while scanning -would be a quick way to kick itself out of the market, you convey...

Excuse my ignorance.

Why is it necessary for the AV machine to unpack the program first to find the viral signature? Is it not possible to define and detect a static signature of a PACKED file?

As far as I know packers are not polymorphic . . .

Variants, families... you can place a zillion of copies of the same viruses, else.

God bless chroot()

@naides: repacking with other options will make malware imune to signature scan also I saw effort from some people to pack hxdef so only way to find hxdef in such case is unpacking

@Maximus

Let's assume that a limited account was really safe and did not allow file infections etc. Why would malware run under under such limited conditions? There is already anti-emu code, anti-VM code etc.

@deroko

Unpacking with the help of breakpoints ("breakpointing" is not an entirely new idea. The last guy who tried it is the same guy who now claims the developement of an Armadillo unpacker. The breakpointing experiment did not work out too well. A competitor came along and developed an exploit turning the scanner (using breakpoints) into a virus centrifuge ;-)

What happened? The breakpointing was not safely implemented: the unpacking engine used createprocess + suspend and then executed the malware sample until the breakpoint. Unfortunately, the unpacking engine also loaded any static DLLs. If such a DLL's main routine contained a virus the virus was executed. In other words, a very cautious user who would never execute unknown executables could be infected simply by scanning such executables with a virus scanner ... ;-)

well I guess that guy just wanted to make fast solution without thinking about all possibilities I was thinking about this issue a 6-7months ago when I was asking myself "but what if AV implements this and that".

anti-vm, anti-emu is fine but what if code executes itself on real cpu, I can't fool real cpu I was personally afraid of that, but as I see they aren't going to implement such thingie so malware is safe

anyway here is my idea for armadillo(I use 4 and 5 to dump it):
1. detect type of protection (std,dbg, cmII)
2. of course, hook LdrLoadDll to catch all loaded dlls and scan them(but aren't dlls also scaned aswell?)
3. if std -> PAGE_GUARD on code section and wait (arma isn't chaning protection on code section), hook also VirtualProtect and be sure that guard is there
4. if dbg -> inject nonintrusive tracer in second process and perform same steps as for std but with nonintrusive tracer (LdrLoadDll hooked aswell), and patch WaitForDebugEvent to catch exception and pass them with dbg_cont, dbg_excpt_not_handled depending on exceptions
5. if cmII -> little more work but yet very simple:
a) hook WaitforDebugEvent/ContinueDebugEvent and wait for page_guard when it occurs bingo there is oep -> redirect execution to nonintrusive tracer that will dump memory, now nonintrusive tracer will redirect execution to next page_guarded page and hook in 1st process will again redirect execution to tracer which will dump that page and it goes till whole process isn't decrypted. of course, dll scaning is performed in 2nd process via hooks for LdrLoadDll...

nonintrusive tracer can be .dll (yuck) or offset independent code (yumy)

Implementing this tech for arma/aspr/svkp is ok imho, but for other files they should only use signatures and heuristisc (they have to imporve heuristic a lot).

It's not being done now because there is no benefit since no AV engines that I know of unpack binaries by executing them on the real CPU. If AV engines started to do this though, I'm sure we would start seeing such modifications to exploit this malicious-code-execution vulnerability.

Does anyone remember the nested ZIP flaw in a couple of the commercial AV engines a few years back? I don't recall if that flaw resulted in an overflow followed by code execution; if it did then that's a practical implementation of exactly what we're talking about. At the least it effectively DOS'd a lot of scanning engines.

I don't remember the details but it it was something along the lines of deep recursion causing a stack overflow.

Oh, you must mean the ZIP vuln in Sophos -- http://www.securiteam.com/unixfocus/5VP0L00GAU.html ("http://www.securiteam.com/unixfocus/5VP0L00GAU.html")
Or was it the ZIP vuln in F-Prot -- http://www.securityfocus.com/bid/15293 ("http://www.securityfocus.com/bid/15293")
Or perhaps it's the Symatec ZIP vuln -- http://www.securityfocus.com/bid/14757 ("http://www.securityfocus.com/bid/14757")
Or did you mean the ClamAV ZIP vuln -- http://www.securityfocus.com/bid/12408 ("http://www.securityfocus.com/bid/12408")
Unless it's ZIP vuln in F-Secure -- http://www.securityfocus.com/bid/11732 ("http://www.securityfocus.com/bid/11732")
But you might have meant the ZIP vuln found in Trend, Symantec, Norman, Ikarus, Frisk, ClamAV, and AVG -- http://www.securityfocus.com/bid/12793 ("http://www.securityfocus.com/bid/12793")

My half assed answers, thinking out loud here, not very constructed.

Fake stubs are not really new.. you can also abuse the fact that signatures have wild chars (??) to redirect the code flow, yet matching the signatures.



It does not take a skilled guy to copy/paste a few bytes from my old asm stub in Armadillo, and redirect code flow to the other packer Entry Point.

I think the benefit of using Arma (or other commercial protectors), is that even if it could be emulated by AV engines (not a lot of engines can do it from what i have seen), it takes too much times anyway.
Each packed file has a different encoded representation, so if you pack the same file, every time it is different. (to some extent anyway).

I suppose they just want to make it harder to detect, not because it is actually hard, but because a tons of legitimate applications use those commercial protectors, and thus, false positives are possible..

When i was working for Armadillo, we have had a lot of problems with this, false positives from AV vendors detecting ANY armadilled application as a virus.

Obviously, a skilled guy would not bother using a commercial protector, as it bloat the file, and has been studied by everyone and his brother.

If would be a lot more effective to write your own stuff to protect your files against detection (pre signature) and analyse..

But then, when you make your own custom stuff, it is not a problem for AV people to detect it. (i am not talking about infectors here).

Now regarding the live unpacking, you won't find AV running applications on the real cpu, because it could (and would) be abused. The idea of limited user is interesting, but they would still not take the risk.

It reminds me some very old stuff, back in DOS days, some scanner were emulating applications, and there were viruses that would take advantage of that, to actually infect the whole computer.. and the computer was clean before the scan

An example:
http://www.chez.com/unkm/DATAS/TUTORS/NUKE/Rstut010.txt

Naides:

They need to unpack the application first, because making signatures on packed files is not reliable, and prone to false positives. Also a lot of packers will make the packed data different every time the application is packed..
And, why making a signature for every packed variants (ie a lot of sigs), when you can make only one (or few) that would detect it, once the file has been unpacked, no matter what packer has been used (i am talking about packers, and not protectors here. as they were proved to thwart most AV anyway).

My 2 cents.

PS:

Deroko: nice unpacking work by the way, i like what you do. I started looking at this HyperUnpackMe2, i have the whole VM almost commented, but i am lacking free time those days..

Disavowed: heya

Tnx HyperUnpackMe2 is really good unpacking challange

Yes, it looks like it is

I am thinking of injecting a VM logger, to get a pcode disassembly of the whole loader, as it is boring to follow it manually.

Is that the way you choose ? I noticed that some instructions were removed at protection time, replaced by int 3 nops.. once the app runs, those are overwritten with some code that eventually do a jmp eax or something like this.

I did not look at it yet (my little kid takes all my free time), but i suspect they did some ASM 2 bytecode stuff.. maybe not there, but at the entry point?

It seems they do stolen bytes , and they may have turned asm code into VMpcode.. i don't know, just hypothesis.

I think they patch calls with those int 3 (eventually calling API functions probably).. i saw they also play with mov edi, blabla call edi...

I need to work a bit on it when i have some free time.. in a few days if all goes well..

Anyway, good work again i enjoyed your defeating R0 approach as well.

I first unpacked it, then I started commenting and playing with VM
My way was to somehow find oep, then I forced progy to store all stolen procedures in some range which I may append to dump w/o a problem and finaly import fixing by looging where are dlls reallocated and then : api - reallocated_dll_base + real_dll_base and I got all apis like that (well except some forwards to ntdll)

It would be a serious OS flaw, and AV could blame m$ for free. And if you consider that many companies uses limited account, the AV won't be the only one to be exploited - the exploit trick would be used more directly.
Adding a behaviour analyser at r0 would also make a very tough heuristic nearly for free, and help preventing bad effects. Remember, no-one but the virus is running in the limited context, so the behaviour can strictly analyse it having no user work in it.

Not very difficult to implement, honestly, and 100% safe as the bug would lie in Windows, not the AV... I'm surprised that none of the AV that tries to climb the market made it.

hehe i did not try to unpack it yet, i just wanted to analyse the whole VM

me too, I don't wanna submit solution at crackmes.de untill I analyze whole VM

No, this is not correct. It is poor security practice to have differently privilege-leveled programs running on the same interactive desktop and Microsoft strongly recommends against this. See http://www.microsoft.com/technet/archive/security/news/htshat.mspx?mfr=true ("http://www.microsoft.com/technet/archive/security/news/htshat.mspx?mfr=true") and http://www.microsoft.com/technet/security/bulletin/ms02-071.mspx ("http://www.microsoft.com/technet/security/bulletin/ms02-071.mspx")

uhm... I was remembering something about services and desktop, so I reopened the win32 help file.


Should we make the AV emu-user to run in the interactive desktop? It needs not to interact with the user. And Impersonating can be behaviour blocked very easily.
So, I think blaming m$ is correct eheh

Yes, that assumes that your service isn't malicious


No, this is the exact problem outlined above.


If that really makes you feel better, then fine.