16 replies to this topic

[ComeBack]

Please Login or Register to see this Hidden Content

With that stub  and  with an encrypted Bozok v143 file  i have 3 detections

Please Login or Register to see this Hidden Content

.

 

[x58]

Finally some quality in the assembly forums. Great share.

[fool'sfool]

This is cool... okay I'm getting maybe a quarter of this but I like it... can you tell me about the 50ms check... is this an effort at a reliable but subtle anti VM mechanism? As in, if the code is being emulated by VM it'll run slow, and just die rather than run the stub? I don't know how stupid this might be, but what if you also included a serial MAC chain to aquire the correct key for decryption? What if you generated a couple thousand random keys, then MAC them all in paralell for three minutes or whatever time is enough to make AV sweat, then say that number of MAC's is the key number. You then integrate that produced key from the MAC chain as the encryption/decryption key as used by the stub. In that case, you have a decryption process that can't be sped up (it's serial, not paralell) or skipped (you need to MAC for three minutes to get the right key and decrypt, cutting the loop will produce garbage). As it is, I feel like a smart AV could pick out the key and skip the killswitch...

 

That said I've only given this a cursory glance... could be this shit does soemthing entirely differently...

 

One thing I've often considered is the idea of using time to derive values... do some loop that takes time, say likely less than 10s, and that equals 0, then something equals more than 10s, equals 1, and that way you produce a binary representation of decryption striing in a really obscure way that also requires time.

 

EDIT: Uh by a couple thousand MAC keys I mean you could produce as many as you want, while any analyst program has to serially work on one, so you have work time advantage.

[ComeBack]

Hi fool'sfool,
the rdtsc timestand isn´t milliseconds that are cpu clock cycles in real (you can plz edit it)
I used the rdtsc instruction, because it does stop the microsoft av and it wasn´t an attempt as anti vm here (just a sideeffect). On a real computer the difference of 2 rdtsc instructions are less 50 clock cycles and with a VM or a debugger the value must be higher. And when i have a lot of stuff in the background...watching movie or so it does not always executing my file, that are my experiences, so that EBFe isn´t real good in each case ,because it can´t exit or cleaning the process in my sample.

And i heard vx people like to use rdtsc for random values and codeflow obtions, so that the emulalor must calculating each stuff, and of course that needs time so av emulators are vulnerability in this point.

 

 

What do you mean with MAC chain, i only know the MAC network address?

 

 

[fool'sfool]

MAC in that context is Media Access Control address, but this is a different sense, this is a Message Authentication Code. Basically its one half of cryptography, one of two solutions to cryptography's two key problems. The first is to ensure a message is hidden from any observer, that security is assured. I encrypt my password, send it to you via Mr Alexander , and you decrypt it. Mr Alexander can't read it. However, he can still mess with us, either moderately badly or really catastrophically, by changing the underlying message. In a moderate scenario my password is changed en route and I can't log in, a kind of DOS attack. Maybe more critically it gets reset and the stupid reset pass is in cleartext email, going via Mr Alexander, and he gets into my account. Cryptography needs to provide not just security but also integrity. So I add a Message Authentication code with my encrypted message, which is something you're probably familiar with: a hash like md5 or sha, AES etc. Before decryption (order is important, if you do it after encryption, this scheme can be super vulnerable and if one thing is wrong, attackers can unencrypt the whole message, this actually happened) you hash my encrypted message into the hash fuction, and compare the result. If Mr Alexander has changed the encrypted message by one single bit, the result will be different, and the message rejected before being decrypted. You and I now know there's a problem, network problems or data manipulation, and we can re-route or re-negotiate, whatever needs to be done. This is a simplification of course, the MAC and hash functions are more than just hashes, they have keys, they have random values, date and time stamps etc... if it were just a sha256sum or something then Mr Alexander could pretty easily figure things out and interfere in a way that matches changed code to MAC result. But it's complicated, let's leave that there.

 

The MAC chain idea comes from the idea that messages are longer than hash lengths (say 64 bits per block, 128, 256, whatever). So, to generate the MAC value, most modes of hashing will feed the results of the first hash into the next. Thus both you and I can 'chew up' the whole message and arrive at a very specific and practically un-fakeable signature for the encrytped message, or file, or whatever. This is very useful, even beyond straight cryptography. You must be familiar with software version checking with hashes, and its idenical, same shit, different usage, except you need no key there.

 

So, what's the point? Well, remember we were talking about checking if VM's are in operation using processing speed. Okay with a 50 cycle difference you have a margin of error. You don't want that. Worse, what if I'm a smart fucker, a white hat with a little black hat at heart, and I code my AV to spot these traps. I'll also get it to spot the non-vm path and just flip the jump from jb to ja, or just a couple nops, since you branch on the jump. Then I'm in your code and your trousers are down. Fuck, classic cracker trick right in some AV code right? So let's flip it on its head, channel the inner white hat for some good guy tricks to turn up the heat. A white hat protecting his data with a code better not be using a cmp/jmp branch to weed out bad passwords, right, cause he'll fall victim to the same branch manipulation. The ultimate solution for real data protection, perversely, is to get a password from input, decrypt data and see if it makes any sense. No branching, just do it and see, so with an incorrect key you get nonsense. Decrypt, check for nonsense and branch accordingly to a nice death. If the AV still flips the branch it runs into... some crazy invalid instructions probably, sissegv or other horrible program death. Nasty, but hey, if every program with sissegv bugs got flagged as 'generic malware that fucks with AV" then nothing would pass IMO.

 

So... what? Let's kill two birds with one stone: AV has a limited runtime right? I really am no expert, I just know interesting shit like this MAC chain idea, so please tell me if AV will run shit forever before it's okay with files. My brain just says turing completeness means they can't try every possiblle combo, that's just the np vs p problem. A chess board has 8*8 possible squares and 16 unique pieces * 2 players (shut up, the pawns are unique by position, they just are). No computer can predict every possible position. Push your program beyond that limit and I guess somethiing funky will happen, right? So we need some arbitrarily long runtime, which we also use as a lame VM check assuming it will do some good but can be bypassed, but also make sure the full delaying tactic MUST take place, at least one time.

 

Just as MACs can chain one block of a message into another, you could also chain a hash function back into itself. That takes time. Generate a random key1 and run it through a hash. Do it again, again, again, do it for five minutes and see how many times you've done it. For as long as you want the AV to be delayed. Take the final hash, key2, and encrypt your stub, program data or whatever with it, then store just the initial key1 (maybe hide it and derive it back via crazy methods), plus the number of iterations. When your program runs, it MUST take the full 5 or whatever minute hashing path to produce the correct key2, which then is used to decrypt the payload. Add in a last small wall of defence of a VM timing check, which will be more likely to be accurate given a larger execution sample, and we're a lot more of an annoying bastard to run under a VM.

 

Better, let's say AV implements a "stupid huge hash chain check", great. So we just hash maybe 50 times, add our (admittedly pathetic) timing check, and we're within message size range. Let's mov and xor some shit, let's... I dunno, check if files are present, let's make arrays and stack frames then take them down. Let's retrieve our 50 hashed hash and decrypt a payload and jump to it... that payload will hash it another 50 times, do some byteshifts maybe, maybe... hmm, okay movsx for kicks... move along and then retrieve the now 100 hashed hash and decrypt payload number 3. Maybe that branches, branch 1 hashes a further 50 times and then pushes stuff, incremements some registers, whatever. Branch two is more intreresting, see it does increments first, then pushes, pops, who cares. It also hashes a further 50 times. Both then decrypt with the same 150 hashed hash payload 3. And so on. Maybe we, during the original encryption, make each hashing stage a random number. Make that unique per version. Call me crazy, but we're getting branching, execution of instructions, AND vm checks, through the actual encryption/decryption. Plus we're wasting the AV's time, and turning this into a chess game that can only end in a draw. We don't even need to use high level or external functions: AES encryption opcodes are built right into IA-32+ processors. We can do this, or something very like it just using ASM mnemonics and no external libraries.

 

I'll admit to being a bit of a novice when it comes to malware, having a conscience is a bit of a drawback in this kind of interesting area, but the theory is cool. I kind of think I'm proposing an interesting idea here.

[ComeBack]

@fool'sfool I believes you want to do some kind of cryptography with bruteforcing (if I have understood you) but that needs, more code and the hh scanner result from my tested file will also not be less! If you want to hide your data for security reasons, then do so. For myself, i don´t need to protect my cfg data inside the bozok file. I have only thought, someone of the shellcode coder will show me his concept (with less code maybee). And to answer your question, I only know that the av engines on market are an agreement for being fast with good results and less false positives.

[fool'sfool]

Well it's not cryptography for the sake of permanently hiding data, its cryptography for hiding code so it can'e be scanned, and can only be run after a delay of some kind. For the code to run properly, a key decoding process has to take place, which 1) must take whatever time you specify, and 2) must take place for the proper code to be run or checked. This will mean the AV cannot skip your delaying tactic or test your code: you force it to run your file for x amount of time before it can do any kind of scanning. Perhaps what will be long enough for it to decide your file is innocuous, especially if you split the decryption process into chunks and run legit looking code in those. Maybe its a bit of an obscure idea, but its al about a guaranteed time lock.

[ComeBack]

Thats sounds interesting fool'sfool, I remember SolarBot uses also a kind of delayed code start method and yesterday I found a crypter called rcrypt 1.3 and I did read a new paper about some user interaction like mouseclick down or so. So I will put it in my to do list maybe, if Im finish with my other stuff. And what kind of "looking code" can be legit ?

[Hess]

OMG fool'sfool , You did elaborate on this ! As for legit code , some dummy code which does nothing , or something that is beginner like. Like "hello world" or garbage collector , etc.

[fool'sfool]

Hmm... basically what Hess says is what I'm thinking, but even something just like an elaborate nop... a nop is actually just an xchg eax, eax if you look at the machine code (0x90 range is all xchg eax, r32, so 0x91 is xchg eax, ecx). You can extend that idea, and do operations that result in no data state changes... e.g.: xchg circles which dance data between registers, ending in the original, or similar logical loops, inc eax, inc eax, sub eax, 2, for example. XOR with 0 is another, shift 0, AND with -1, OR with 0, all are similar. You can do junk with currently useless registers and memory, move data, load addresses, anything... later you use them again, but can a recognition engine really pick whether this complicated jumble is genuinely useful code? Maybe they check for printing, check for file accesses, writing to memory buffers, so you check for files that aren't there, make a file then delete it, get data from a random file, make an array and fill it... maybe write to a file... I've never done any of this, but I'd be willing to bet it has some interesting results.

[Hess]

fool'sfool , that is what it is , some basic programming concept , so AV wont raise flag , mine idea was like executing and looping various beginner codes , so , after some time AV will think that it's beginners program and not something that might be suspicious.

[ComeBack]

Junkcode is something to hide real code instructions with useless code, that does nothing.
And the conclusion is maybe, junkcode is good to avoid static analyses but that could also be detected by an AV emulator. And for this reason, it should mixed with "looking legit code" -
if I have properly understood it.

[Hess]

Yes , You did.

[ComeBack]

Plz be not bad Hess, but then you are a kind of Junkcode for me, coz a lot of your messages are hidden for me, i mean it isn´t clear.

[Hess]

Well , sorry for being too short , meaning , that You're partially correct , instead of junk code , there is a lot of beginners code which is legit and due to huge amount of it , and its repeating , AV wont even suspect on it and it will hurry up to do other work , since newbie codes are not so much interesting , especially if they do nothing , they are just school samples of programming.

[ComeBack]

And do you know which AV proactives can be bypassed with a "legit code" loop that needs 15-60sec Hess ?

[Hess]

Well , with such code , every AV , example can be an app which generates garbage and also has garbage collector and cleaner , which is something very basic in programming , and looping can be overlooked as beginners programming mistake. Thus , AV will drop its look from it and will continue to check other things , since no one wants to waste time on codes made by "beginners". It wont for sure act like JIT and tell You: "Dude , You made mistake , it shouldn't loop !"