31–40 of 100 posts
Anti-virus bypasses and even exploits are extremely common. My current line of thinking is that the best way to take control of your computer is to use virtualization to run many separate OS images for different sets of uses.
So what's this line all about: ((void(*)())exec)(); Type cast a void pointer to a void pointer, execute the result, then execute the result of that? Or ... Can anyone explain what's going on here?
This is a common way of executing shellcode in a PoC. Exec (before the cast) points to memory containing the shellcode data. To actually start executing the shellcode, you just need to somehow cause the program counter to point to the address of the shellcode. An easy way to change the program counter is by calling a function ... which is what this line does. Read this as "cast exec to a pointer to a function that ta…
void *exec = VirtualAlloc(0, sizeof c, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
Would be a red flag. I don't know how many programs use that on the Windows side of things but I have almost never seen programs call this function that weren't "crypters."
I am honestly impressed how simple this program is (it's the most elegant crypter I've probably ever seen) but I am still wondering whether heuristics could be made to detect this (without also falsely detecting thousands of other programs?) What do you think OP? Not really my field but curious all the same.
I once wrote a kernel extension that intercepted any and all file open()'s on OS X. If the application in question was opening a file that it was not whitelisted to do so, it would bring up a modal dialog box asking whether or not this application should be allowed to open this file. It was basically a firewall on the kernel level. It worked splendidly, however, I was never able to gain any traction in marketing it.…
――――――
I wouldn't be surprised if this was a common practice; we considered our product's detection capabilities to be proprietary.
Is this an oversight of the AV software companies? Did no one come up with this before? Could it be that if people did come up with this before that a lot of Windows computers have viruses without them knowing? Is their virus detection scheme fundamentally flawed? Should I be shocked? Shouldn't I be? I'm currently shocked but I don't know if it's justified, not an expert in the field.
> Is this an oversight of the AV software companies? No, this is a principle limitation of any AV software that is based on blacklisting. > Did no one come up with this before? Of course other people came up with similar ideas before. > Should I be shocked? If and only if you had trust in your AV software before.
So after the program is actually compiled into binary code do the resulting instructions become so simple (and so fundamental to the operation of programs) that any attempt to write a heuristics rule to stop this technique would break thousands of programs or are heuristics just so inherently shitty that this technique works? Because I would still think that this line here: void *exec = VirtualAlloc(0, sizeof c, MEM_…
So after the program is actually compiled into binary code do the resulting instructions become so simple (and so fundamental to the operation of programs) that any attempt to write a heuristics rule to stop this technique would break thousands of programs or are heuristics just so inherently shitty that this technique works? Because I would still think that this line here: void *exec = VirtualAlloc(0, sizeof c, MEM_…
What's more, every program that uses Boost on Windows calls VirtualAlloc, in several places.
I once wrote a kernel extension that intercepted any and all file open()'s on OS X. If the application in question was opening a file that it was not whitelisted to do so, it would bring up a modal dialog box asking whether or not this application should be allowed to open this file. It was basically a firewall on the kernel level. It worked splendidly, however, I was never able to gain any traction in marketing it.…
Hands Off!¹ has done this for a while now (been around since 2011 if I remember correctly). ―――――― ¹ — http://www.oneperiodic.com/products/handsoff/
However, if a technical user is using the product, it makes security 100% solid. You can literally intentionally download and run any virus, with full confidence that you can easily stop it from doing anything you dont want it to. Since a dialog box is created before it can read or write to any file, there is literally nothing it can do without your permission.
It's also useful for monitoring what an installer or app is doing to your filesystem, exactly what files it is touching as it goes along, and also how to thoroughly uninstall it if you want to.
I have been meaning to make a cut down version just for the filesystem monitoring and as an uninstaller that works 100%. You can even make an uninstaller that not only uninstalls all files that were created alongside the file you choose, but also any files that were created by any of those files (by logging the paths of the open()'s with O_CREATE by any of those files)