Bit off topic, but in some sense, I really miss old DOS/Windows virus scene.
A lot of people was writing viruses just for fun, and they were inventing very clever technics, such as polymorphic/metamorphic code or advanced anti debugging/disassembling tricks (which nowdays you can find in Denuvo :D ). Nowdays most of the malware are just money grabbers without any art in them, as a proof of my words - till now nobody were able to beat Z0mbie's "Zmist" from 2002
Hiding malware in Windows: The basics of code injection
11–20 of 24 posts
Re: Hiding malware in Windows: The basics of code injection
#12This might be the wrong venue but with the popularity of randomware and more complex malware attacks, I'm saddened that one of Microsoft's premiere safety technologies, AppLocker, is license restricted. AppLocker is system-wide whitelisting for those unaware. You can restrict which executables can execute based on a number of criteria of your choosing. At work I have access to AppLocker thanks to our Enterprise editi…
Do you mean "whitelisting" or is a term I've never heard of?
Re: Hiding malware in Windows: The basics of code injection
#13Bit off topic, but in some sense, I really miss old DOS/Windows virus scene. A lot of people was writing viruses just for fun, and they were inventing very clever technics, such as polymorphic/metamorphic code or advanced anti debugging/disassembling tricks (which nowdays you can find in Denuvo :D ). Nowdays most of the malware are just money grabbers without any art in them, as a proof of my words - till now nobody…
Re: Hiding malware in Windows: The basics of code injection
#14This might be the wrong venue but with the popularity of randomware and more complex malware attacks, I'm saddened that one of Microsoft's premiere safety technologies, AppLocker, is license restricted. AppLocker is system-wide whitelisting for those unaware. You can restrict which executables can execute based on a number of criteria of your choosing. At work I have access to AppLocker thanks to our Enterprise editi…
Do you mean "whitelisting" or is a term I've never heard of?
Thanks, typo fixed.
Re: Hiding malware in Windows: The basics of code injection
#15Does anyone got any ideas (or know any posts) on how machine learning can be used to detect these types of attacks?
Re: Hiding malware in Windows: The basics of code injection
#16Earlier quoted context omitted.
Only if one is writing to a process running under a different user ID. Non-privileged users can write to the memory of their own processes. Linux used to be similar (and I think some distributions still are), but is now slightly more restrictive, in that processes running as non-root user accounts can only debug child processes they've launched, as opposed to other processes running under the same user account. It ca…
> Mac OS is the only mainstream OS I know of that disallows debugging by non-root user accounts entirely. This isn't true; Xcode works just fine on non-root accounts. You will need to get permission to debug anything from an admin user, or add yourself to the developers group. And if you want to debug a system binary you'll need to disable SIP.
> Xcode works just fine on non-root accounts
Are you sure that attaching to a process (for debugging/memory-modification) in general does on modern versions of Mac OS?
"In order to guarantee support for debugging on the Mac, you need to log in on the Developer Tools Access dialog box using the administrator or root user password" [1]
"DTrace requires admin privileges" [2]
[1] http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Acquiring_...
[2] http://dtrace.org/blogs/brendan/2011/10/10/top-10-dtrace-scr...
Re: Hiding malware in Windows: The basics of code injection
#17Hiding Male-ware in windows?
Like, for example, a update functionality, that randomly flips the switch to "metered connection off" for tethered WiFi and uses up my bandwidth for a month?
Would that be considered malware?
Correct title would be- upload parasite-packages into a already installed malware system.
Re: Hiding malware in Windows: The basics of code injection
#18Bit off topic, but in some sense, I really miss old DOS/Windows virus scene. A lot of people was writing viruses just for fun, and they were inventing very clever technics, such as polymorphic/metamorphic code or advanced anti debugging/disassembling tricks (which nowdays you can find in Denuvo :D ). Nowdays most of the malware are just money grabbers without any art in them, as a proof of my words - till now nobody…
Reading that reminds me of "The Whale":
> The Whale virus is a computer virus discovered on July 1, 1990. The file size, at 9,216 bytes, was for its time the largest virus ever discovered. It is known for using several advanced "stealth" methods.
From:
https://en.wikipedia.org/wiki/Whale_(computer_virus)
At the time, as the wikipedia page says, I was amazed at the size of the thing! I got a couple of my own (academic) creations included in various lists, and at the time I was completely amused that they often had such gems as "Origins: Romania".
I was never terribly invested in the scene, but I did read a lot of the zines, 40hex, and similar, and because I was interested in low-level coding I would often decompile virus-samples and experiment with similar techniques, especially when the polymorphic engines started to appear.
Re: Hiding malware in Windows: The basics of code injection
#19Earlier quoted context omitted.
This is probably enough so that the majority of users would not be able to find it. I probably wouldn't, unless the process ended up using excessive resources and I sampled it.
They were referencing the misspelled title of the post.
Ah. It seems like the title has been changed, so I didn't catch that.
Re: Hiding malware in Windows: The basics of code injection
#20Earlier quoted context omitted.
> Mac OS is the only mainstream OS I know of that disallows debugging by non-root user accounts entirely. This isn't true; Xcode works just fine on non-root accounts. You will need to get permission to debug anything from an admin user, or add yourself to the developers group. And if you want to debug a system binary you'll need to disable SIP.
> Xcode works just fine on non-root accounts Are you sure that attaching to a process (for debugging/memory-modification) in general does on modern versions of Mac OS? "In order to guarantee support for debugging on the Mac, you need to log in on the Developer Tools Access dialog box using the administrator or root user password" [1] "DTrace requires admin privileges" [2] [1] http://docwiki.embarcadero.com/RADStudio/…
That's consistent with I'm saying. You do not need to be root to attach to a process on macOS; you merely need to be part of the _developer group. I believe admins are added to this group by default, but you can do it manually if you wish. If you don't, you'll need to type the password of an admin user before you can debug anything.