User Controls
On converting ASM to Bytearray Shellcode and it's applications in malware.
-
2016-03-21 at 1:45 PM UTC
Even if the executable code produces errors, it can still be executable. Just think of PIDs. You can have a situation where some of the PIDs produced by the executable file can be broken, while others can still function normally. In some cases, you'd actually want errors, because the scanner is looking for code which produces no errors, backwards as that sounds.
And this is where your lack of programming knowledge really shines through. When we say errors in the context of code we can mean either of three things.- Syntax errors
- Semantic errors
- Logical errors
When errors are detected we distinguish between run time errors and compile time errors. Your program will run fine when you have a run time error(Dynamic semantic/logical error that the compiler does not detect) but will not do what you expect it to do. In this case your "executable code" has an error in it but it will still run. This has nothing to do with PIDs and you never want errors. Perhaps i should have been more specific and say compile time errors or syntax errors but that's besides the point.For example, if you take an old rootkit (which virus scanners already easily detect), and then run it through UPX, and then run it through ASPack, then run it through UPX again, that breaks SOME of the sub processes on the executable program, while leaving other sub processes fully functional, because certain sections of the program's code get all garbled from using the different packing methods back and forth. The virus scanner then passes right over it, even though a good majority of the code is still known viral code. The scanner doesn't want to produce a possible false positive, so it allows it. Meanwhile, the main process and some of the sub processes may still work… ie: opening port, calling home, replicating, etc. So yeah, even if the executable code is producing errors, it can still be executable.
That's really not how it works. -
2016-03-21 at 4:01 PM UTC
There are constructor kits out there which allow you to embed an executable file of your choice into a standard .html document using HEX, VB and shellcode. When the .html is loaded in the browser, the executable file is built "on-the-fly" into the target machine's temp folder and launched from that location. That is not outside the scope of this conversation.
You've been living under this delusional and clearly purposeful ignorance of the browser security model literally for years. Like yeah, maybe back in the 90s when IE was the only browser with a real commercial market share and more bugs than you should share a stick at but nothing you've ever fumbled to describe has been meaningful in the context of browsers made this decade. -
2016-03-21 at 6:43 PM UTC
That's really not how it works.
Be that as it may, I can covert any detectable trojan or virus into a completely FUD trojan or virus, simply by mixing encryption/packing methods. I've already done it many times and tested the result on major scanners with the latest definitions. Not detected by any, and most of the main functions still work. -
2016-03-21 at 6:44 PM UTC
You've been living under this delusional and clearly purposeful ignorance of the browser security model literally for years. Like yeah, maybe back in the 90s when IE was the only browser with a real commercial market share and more bugs than you should share a stick at but nothing you've ever fumbled to describe has been meaningful in the context of browsers made this decade.
Old tricks can be made brand new again, with a little thinking outside the box. You of all people should know this.
-
2016-03-21 at 7:09 PM UTC
Be that as it may, I can covert any detectable trojan or virus into a completely FUD trojan or virus, simply by mixing encryption/packing methods. I've already done it many times and tested the result on major scanners with the latest definitions. Not detected by any, and most of the main functions still work.
Sure, no contest here. This is what packers and crypters are for broadly speaking. -
2016-03-21 at 7:19 PM UTC
Sure, no contest here. This is what packers and crypters are for broadly speaking.
Cryptors and packers are added to the scanner definitions and detected as suspicious as fast as they come out. It's not the packer or cryptor that makes the old trojan FUD again, it's the way you use the cryptors/packers. The scanners are not designed to detect packed files which have been packed using a variety of different packers in a certain order.
-
2016-03-21 at 7:53 PM UTC
Cryptors and packers are added to the scanner definitions and detected as suspicious as fast as they come out. It's not the packer or cryptor that makes the old trojan FUD again, it's the way you use the cryptors/packers. The scanners are not designed to detect packed files which have been packed using a variety of different packers in a certain order.
Incorrect, crypters and packers might get flagged as PUP's. But the definitions are updated on the basis of the new signature that results from encoding X malware with Y crypter. Other than that, heuristics are employed to detect malicious code. Heuristics are defeated by the encryption/packing itself and signatures are defeated when the encoding/packing is done polymorphically.
I actually encoded the shellcode in the OP with polymorphic XOR additive feedback, as such there's not an AV solution in the world that can prevent it from executing which is why metasploit has appropriately named this encoding scheme "Shikata ga nai" which is Japanese for; it can't be helped. -
2016-03-22 at 1:48 AM UTCAV scanners are only programmed to detect threats within standalone packing, but are not able to detect threats within certain combinations of packers. That is a fact, Chester. They won't say as much as "boo", even when heuristic scanning is specified.
-
2016-03-22 at 2:34 AM UTC
AV scanners are only programmed to detect threats within standalone packing, but are not able to detect threats within certain combinations of packers. That is a fact, Chester. They won't say as much as "boo", even when heuristic scanning is specified.
When i said incorrect it was in reference to this.
[greentext]>It's not the packer or cryptor that makes the old trojan FUD again, it's the way you use the cryptors/packers[/greentext]
It doesn't matter how you use it. What makes it undetectable is the operation of the crypter itself. I'm not saying it's impossible to use multiple crypters/packers/whatever, it's just redundant.
What's more if your packer just compresses the executable it doesn't matter if you use ten of them because heuristics analyzes the behavior of the program. Now if your packer also encodes the executable, you'll take care of heuristics and if your encoding is polymorphic signature analysis becomes impossible as well.
This is a good example of what a proper crypter does, trust me you don't need more than this.
http://seclist.us/pecloak-py-beta-a-...sion-tool.html
Also, FUD is a skid term and who the hell is Chester. -
2016-03-22 at 3:40 AM UTC
It doesn't matter how you use it. What makes it undetectable is the operation of the crypter itself. I'm not saying it's impossible to use multiple crypters/packers/whatever, it's just redundant.
What's more if your packer just compresses the executable it doesn't matter if you use ten of them because heuristics analyzes the behavior of the program. ..
Not true. It DOES matter. When you encrypt something which is already encrypted, strange artifacts begin to appear in the result. You have only begun to scratch the surface of the evil dark side, oh, Obe Wan Kanobee... or should I say, Chester the Molester. -
2016-03-22 at 4:10 AM UTC
Not true. It DOES matter. When you encrypt something which is already encrypted, strange artifacts begin to appear in the result. You have only begun to scratch the surface of the evil dark side, oh, Obe Wan Kanobee… or should I say, Chester the Molester.
1. no. the encryption/encoding algorithm would have to be lossy to affect the data within it's container, and for that very reason - ie. we don't want our data warped whenever we encrypt/decrypt it - we do not use such algorithms on strictly structured data.
2. no. if for some reason we DID use encryption algorithms that lost or modified data within the container, it would break the internal file format and no longer function correctly as an executable.
don't believe me? go get veracrypt (fork of truecrypt), get a png image, encrypt a copy of it with 20 different encryption algorithms, one after the other. decrypt each one. compare the PNG in the cryto containers to the original file.
I was going to write a bit about packers and crypters and how they're still relevant (to an extent), but it's really not worth the effort. just quickly Sophie (I fuckin hate typing that) - packers don't just compress the application, they obfuscate program flow as well, making it more difficult for heuristics testing to work out what the code is actually doing. -
2016-03-22 at 5:20 AM UTCYou don't know shit spectral, but let's forget about that for a second in order to point out some inconsistencies in your posts.
AV scanners are only programmed to detect threats within standalone packing, but are not able to detect threats within certain combinations of packers That is a fact, Chester. They won't say as much as "boo", even when heuristic scanning is specified.
It's funny because here you are implying it's a good thing to use multiple packers.Not true. It DOES matter. When you encrypt something which is already encrypted, strange artifacts begin to appear in the result. You have only begun to scratch the surface of the evil dark side, oh, Obe Wan Kanobee… or should I say, Chester the Molester.
And here you're implying the exact opposite. Make up your fucking mind. -
2016-03-22 at 5:24 AM UTC
I was going to write a bit about packers and crypters and how they're still relevant (to an extent), but it's really not worth the effort. just quickly Sophie (I fuckin hate typing that) - packers don't just compress the application, they obfuscate program flow as well, making it more difficult for heuristics testing to work out what the code is actually doing.
Just call me soph then or sophist or psycho, but alright (n_n"), thanks for the insight. Still doesn't make spectral right though. -
2016-03-22 at 11:12 AM UTC
2. no. if for some reason we DID use encryption algorithms that lost or modified data within the container, it would break the internal file format and no longer function correctly as an executable…..
That's just not true, aldra. Even if you break the internal file format, that doesn't automatically mean it will no longer function. Like I said before, some parts of the code will be broken, but some parts will still function. I've already fully tested this concept.
-
2016-03-22 at 2:30 PM UTC
That's just not true, aldra. Even if you break the internal file format, that doesn't automatically mean it will no longer function. Like I said before, some parts of the code will be broken, but some parts will still function. I've already fully tested this concept.
It's ok to admit you're wrong Spectral, the sooner you admit it, the sooner you'll learn. -
2016-03-22 at 8:57 PM UTC
It's ok to admit you're wrong Spectral, the sooner you admit it, the sooner you'll learn.
You know what shellcode is, but I don't think you understand the process of what it actually does.
-
2016-03-23 at 1:48 PM UTC
You know what shellcode is, but I don't think you understand the process of what it actually does.
How can i not know? Aldra did a good job explaining it here.
http://niggasin.space/forum/technophiliacs-technophiles/82417-on-converting-asm-to-bytearray-shellcode-and-it-s-applications-in-malware?p=82460#post82460
I even mentioned in my reply later that i appreciate the insight because i don't usually focus on low level memory and processing stuff. The difference between you and me is however. You have no idea of low level stuff but also not of high level stuff. Worst case scenario that makes me 50% more knowledeable than you regardless.
-
2016-03-23 at 6:32 PM UTC
The difference between you and me is however. You have no idea of low level stuff but also not of high level stuff. Worst case scenario that makes me 50% more knowledeable than you regardless.
The fact is, kid, you really have no idea what I know or don't know, because all you know is what I want you to know.
-
2016-03-23 at 7:29 PM UTC
The fact is, kid, you really have no idea what I know or don't know, because all you know is what I want you to know.
Yeah, yeah whatever asshole. Go ahead pretend you're l33t. With that attitude we can all safely say you'll never amount to much in the InfoSec field. -
2016-03-23 at 9:29 PM UTCI remember when I was 14 and thought spictroll was cool and knowledgeable, boy was I naive
