4 ms·
High end malware development.
by panxyh 3y ago
High end malware development.
- nvy 3y agoCould you elaborate, or provide a link as a jumping off point for someone who wants to learn more about this topic?
- lost_tourist 3y agoIt's the difference between being a script kiddie and an actual hacker/cracker. Any web search will turn up thousands of links on hardware hacking at all levels.
- nvy 3y agoThat's not really what I'm asking, though. Parent claimed "high-level malware development" happens in ASM, but as far as I know a good chunk of sophisticated malware (stuxnet, wannacry, etc.) are written in plain ol' C or C++, so I categorically disagree that the differentiator between "script kiddie" and "leet haxor" is in whether or not someone writes assembly. But I'm interested in reading about malware written in assembly and was hoping for a diving board into that particular pool.
- freedomben 3y ago> as far as I know a good chunk of sophisticated malware (stuxnet, wannacry, etc.) are written in plain ol' C or C++, so I categorically disagree that the differentiator between "script kiddie" and "leet haxor" is in whether or not someone writes assembly. Indeed. It's also useful to differentiate between malware and exploits (although the former often includes the latter). Exploits it's common to use assembly when finding and developing the exploit, but unless you're severely byte constrained you're just gonna use tools to generate your shellcode instead of hacking it out by hand. Even then there are tons of pre-written shell code snippets you can reuse from places like metasploit. The number of jobs where you're paid to write an exploit are small unless you can get on an elite team in a government agency (or contractor). Malware on the other hand is mostly just written in higher level languages like C
- timacles 3y agoCheck out the legendary Poc||GTFO articles: https://pocorgtfo.hacke.rs/ https://pocorgtfo.hacke.rs/ they are a treasure trove for this sort of information. High level hacking requires assembly because you're trying to reverse engineer opaque APIs that aren't meant to be interfaced with. What other way is there to do that other than trying to examine what things are being moved to which memory addresses