Lower Runtime detections
#1
hello to everyone, this is my first post.

i would like to ask you tips on how to lower the detections on Runtime of the raw bin (unencrypted).
i'm coding a Windows/C++ tool and at the moment i have applied some stuff like:
- encrypting most strings (xored)
- some junk functions at boot (randomized for each sample, like "sample 1" runs functions a+c and "sample 2" runs functions b+d, so samples are a bit different from each other)

thank you in advance
Reply
#2
none of the things you listed affect runtime detection lol

the presence of strings is scanned at, well, scantime.
xor-ing them reduces the scantime detection
if anything, decryption during runtime would be something the AV is watching for, not to mention static decryption of a string in memory means that the string will then exist in memory as plaintext.

junk functions might seem like something that affects runtime, but when it's not doing anything at runtime, then the AV doesnt care. not to mention, static analysis is how you get a list of functions, not running it and debugging it.

just strip the symbol table and like 70% of these two things are already covered. the string encryption thing is hard to really get around for runtime stuff, but you can probably be really hacky with some cool typecasting and whatnot.

if you're familiar with reverse engineering/assembly, then try some crackme's. as you try harder ones, you can get an idea of how they are hiding plaintext strings in the binary without actually storing the string itself anywhere.



as for actually improving runtime detection ratios, it's a lot more complicated. you might have noticed that more advanced packers/crypters/whatever you may call them are using some sort of virtualization now, and that's for good reason. makes static analysis nearly impossible and makes runtime debugging exponentially harder too.

you're gonna need to work harder to achieve what you want.
there are some tools out there to help you find the actual signature that's being detected but a fair bit of it might also just be grunt-work and trying to change stuff manually.

creativity is your best bet. find a weird way to do something, or find a harder way to do something. for instance, smokeloader doesn't compile with winapi headers, instead it finds PEB and scans through LDR to find offsets of winapi DLLs loaded in memory, then uses hardcoded offsets of winapi functions it needs to call them directly, all in raw assembly. not a particularly new concept by any means, but will reduce the total size of the binary while making it harder for a novice reverse engineer to figure out whats going on.
Reply
#3
thanks for your input and lengthy reply.

"none of the things you listed affect runtime detection lol"
true, obfuscated strings are for static, i meant it regarding anti-detection in general.

"junk functions might seem like something that affects runtime, but when it's not doing anything at runtime, then the AV doesnt care. not to mention"
so if i mix junk function between the real code you think it's not useful?

"you can probably be really hacky with some cool typecasting and whatnot."
could you expand on this?

"if you're familiar with reverse engineering/assembly, then try some crackme's."
i have been checking out some tools like pestudio, but not very good at reversing. i guess i need to check what the "other guys" (analysts) are doing.

"there are some tools out there to help you find the actual signature that's being detected"
any tool to recommend?

"smokeloader doesn't compile with winapi headers, instead it finds PEB and scans through LDR to find offsets of winapi DLLs loaded in memory, then uses hardcoded offsets of winapi functions it needs to call them directly"
this is Winapi/IAT hashing or another concept? in that case is more for scantime correct?

the bin im working on is getting 0/26 on scantime (on antiscanme at least), so my main concern is lowering the runtime. it seems as you said it needs a lot of experimenting and hard work.

also do you think antis (anti analysis/vms checks) should be a red flag?

regards
Reply
#4
(09-28-2021, 04:16 PM)cryogenic Wrote: so if i mix junk function between the real code you think it's not useful?
exactlySmile
junk code isnt going to trigger a heuristic detection.
your "real code" will.
adding junk code really only makes it harder for the poor analyst over at paloaltonetworks tasked with taking your binary apart, and not the AV that is looking for the bad code.


Quote:"you can probably be really hacky with some cool typecasting and whatnot."

could you expand on this?

get creative
the below probably wont compile because ill be missing too many *'s, not to mention endianness will affect the result
Code:
void *x  = (void*)0x68656c6c;
void *y  = (void*)0x6f20776f;
void *z  = (void*)0x726c6421;

char result[13];
sprintf(result, "%x%x%x\0", &x, &y, &z); //ideally you would eliminate the middleman somehow as to not explicitly store the string anywhere, maybe feed character by character to where it needs to be used)


Quote:"if you're familiar with reverse engineering/assembly, then try some crackme's."

i have been checking out some tools like pestudio, but not very good at reversing. i guess i need to check what the "other guys" (analysts) are doing.

ill stress the "if youre familiar with RE" part.
you already mentioned that you're doing fine for scantime. strings affect scantime. therefore, you do not need to work so hard here.


Quote:"there are some tools out there to help you find the actual signature that's being detected"

any tool to recommend?

only the one i listed, despite it being 4 years old.
it's fairly simple by design though, a solid starting framework if you feel like updating it.


Quote:"smokeloader doesn't compile with winapi headers, instead it finds PEB and scans through LDR to find offsets of winapi DLLs loaded in memory, then uses hardcoded offsets of winapi functions it needs to call them directly"

this is Winapi/IAT hashing or another concept? in that case is more for scantime correct?

exactly thatSmile
yeah it mainly affects scantime, but i'm just giving you an example to get creative with how you accomplish the task in front of you. the easiest way isn't going to be the most evasive way.


Quote:also do you think antis (anti analysis/vms checks) should be a red flag?

surprisingly, no.
there's tons of software out there that doesn't like being run in a VM, or rather it will try to tell the user not to run it in a VM.
granted, be a bit more silent with your anti-VM checks. checking rdtsc is going to be a lot more quiet than scanning the entire registry for vmware strings.
Reply
#5
(09-28-2021, 01:53 AM)poppopret Wrote: none of the things you listed affect runtime detection lol

the presence of strings is scanned at, well, scantime.
xor-ing them reduces the scantime detection
if anything, decryption during runtime would be something the AV is watching for, not to mention static decryption of a string in memory means that the string will then exist in memory as plaintext.

junk functions might seem like something that affects runtime, but when it's not doing anything at runtime, then the AV doesnt care. not to mention, static analysis is how you get a list of functions, not running it and debugging it.

just strip the symbol table and like 70% of these two things are already covered. the string encryption thing is hard to really get around for runtime stuff, but you can probably be really hacky with some cool typecasting and whatnot.

if you're familiar with reverse engineering/assembly, then try some crackme's. as you try harder ones, you can get an idea of how they are hiding plaintext strings in the binary without actually storing the string itself anywhere.



as for actually improving runtime detection ratios, it's a lot more complicated. you might have noticed that more advanced packers/crypters/whatever you may call them are using some sort of virtualization now, and that's for good reason. makes static analysis nearly impossible and makes runtime debugging exponentially harder too.

you're gonna need to work harder to achieve what you want.
there are some tools out there to help you find the actual signature that's being detected but a fair bit of it might also just be grunt-work and trying to change stuff manually.

creativity is your best bet. find a weird way to do something, or find a harder way to do something. for instance, smokeloader doesn't compile with winapi headers, instead it finds PEB and scans through LDR to find offsets of winapi DLLs loaded in memory, then uses hardcoded offsets of winapi functions it needs to call them directly, all in raw assembly. not a particularly new concept by any means, but will reduce the total size of the binary while making it harder for a novice reverse engineer to figure out whats going on.

(09-28-2021, 05:16 PM)poppopret Wrote:
(09-28-2021, 04:16 PM)cryogenic Wrote: so if i mix junk function between the real code you think it's not useful?
exactlySmile
junk code isnt going to trigger a heuristic detection.
your "real code" will.
adding junk code really only makes it harder for the poor analyst over at paloaltonetworks tasked with taking your binary apart, and not the AV that is looking for the bad code.


Quote:"you can probably be really hacky with some cool typecasting and whatnot."

could you expand on this?

get creative
the below probably wont compile because ill be missing too many *'s, not to mention endianness will affect the result
Code:
void *x  = (void*)0x68656c6c;
void *y  = (void*)0x6f20776f;
void *z  = (void*)0x726c6421;

char result[13];
sprintf(result, "%x%x%x\0", &x, &y, &z); //ideally you would eliminate the middleman somehow as to not explicitly store the string anywhere, maybe feed character by character to where it needs to be used)


Quote:"if you're familiar with reverse engineering/assembly, then try some crackme's."

i have been checking out some tools like pestudio, but not very good at reversing. i guess i need to check what the "other guys" (analysts) are doing.

ill stress the "if youre familiar with RE" part.
you already mentioned that you're doing fine for scantime. strings affect scantime. therefore, you do not need to work so hard here.


Quote:"there are some tools out there to help you find the actual signature that's being detected"

any tool to recommend?

only the one i listed, despite it being 4 years old.
it's fairly simple by design though, a solid starting framework if you feel like updating it.


Quote:"smokeloader doesn't compile with winapi headers, instead it finds PEB and scans through LDR to find offsets of winapi DLLs loaded in memory, then uses hardcoded offsets of winapi functions it needs to call them directly"

this is Winapi/IAT hashing or another concept? in that case is more for scantime correct?

exactly thatSmile
yeah it mainly affects scantime, but i'm just giving you an example to get creative with how you accomplish the task in front of you. the easiest way isn't going to be the most evasive way.


Quote:also do you think antis (anti analysis/vms checks) should be a red flag?

surprisingly, no.
there's tons of software out there that doesn't like being run in a VM, or rather it will try to tell the user not to run it in a VM.
granted, be a bit more silent with your anti-VM checks. checking rdtsc is going to be a lot more quiet than scanning the entire registry for vmware strings.


"junk code isnt going to trigger a heuristic detection.
your "real code" will. adding junk code really only makes it harder for the poor analyst over
at paloaltonetworks tasked with taking your binary apart, and not the AV that is looking for the bad code."
ah i thought it might help for rt. i still can't wrap my head around the way AVs flag a Winapi
call as good or bad, if it's the same one for all programs. maybe having the binary signed/unsigned is one of the primary deciding factors?

"only the one i listed, despite it being 4 years old."
sorry, missed the link due to the color.

"there's tons of software out there that doesn't like being run in a
VM, or rather it will try to tell the user not to run it in a VM"
good info, anyway i will check with antis on/off to see if something changes with the detections.

thank you
Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  B: antidysrhythmic electromechanical complicated lower nail-fold. udijouded 0 8 3 hours ago
Last Post: udijouded
  How to persist malware in Windows without tripping runtime AV? God Himself 2 13,681 04-21-2021, 10:25 PM
Last Post: Vector