Typically, malware is harder to run on linux due the system asking for a sudo password for anything that requires administrator privlages. There are also plenty of other factors that i dont feel like getting into
Not to also mention most malicous applications are designed for windows, not linux.
Its mainly the market share thing really. Using good default policies on windows or Linux would kill a lot of malware but typical Linux users still just copy paste shit into the command line and add random repositories etc anyways. And a program running with my privileges in my home directory would be 99% as bad as it running as root since my machines are really just me using them.
your main concern would be files. If you run something as your usual suspect user, that software can do pretty much whatever it feels like with files under those permissions, unless sandboxed.
Not quite malware, but if someone wanted to troll you a goof rm -rf isn’t hard.
This is a good idea and a good practice in my opinion.
Some malicious code detects when it’s being sandboxed and hides itself until it’s running somewhere it can do damage though.
Once malware is VM aware it can also get outside a VM. Furthermore, malware can be written to seat itself comfortably in your PC and lay low for hours, days, weeks before becoming active. Installing in a VM and waiting for shit to hit the fan is not always reliable.
Getting out of a VM reliably is not usually trivial, and VM escapes are usually designed to target specific configurations rather than an arbitrary deployment. A VM with a minimum amount of shared resources is usually a reasonable security boundary unless you think the malware you’re analyzing has hypervisor-specific 0 days.
A crack changes program code and is executed. There is no easy way to check if it is safe.
Unless you inspect the source code or binary code (directly or through reverse-engineering) you can not verify it.
What’s left without that is attempts at gaining confidence through analysis trust of third parties - the providers, distributors, creators - who have to be confirmed beyond a matching text label too.
The alternative to or extension of being confidently safe or accepting the risk is to sandbox the execution. Run the crack in a restricted environment with limited access in case it does things you do not want to. Optionally monitoring what it does. Which has to be put into relation of what the program does without the crack.
Back when I used cracks often the cracks were small keygens and sometimes a patched main exe/dll, so I could just generate the key in a vm/sandboxed environment and inspect the patched binary, usually they did nothing weird.
Huge repacks are often very sketchy though…
Nowadays there are many great FOSS alternatives so I tend to use them more.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !piracy@lemmy.dbzer0.com
⚓ Dedicated to the discussion of digital piracy, including ethical problems and legal advancements.
I never used Linux before, is virus still a problem for cracked software on Linux?
Typically, malware is harder to run on linux due the system asking for a sudo password for anything that requires administrator privlages. There are also plenty of other factors that i dont feel like getting into
Not to also mention most malicous applications are designed for windows, not linux.
Its mainly the market share thing really. Using good default policies on windows or Linux would kill a lot of malware but typical Linux users still just copy paste shit into the command line and add random repositories etc anyways. And a program running with my privileges in my home directory would be 99% as bad as it running as root since my machines are really just me using them.
your main concern would be files. If you run something as your usual suspect user, that software can do pretty much whatever it feels like with files under those permissions, unless sandboxed.
Not quite malware, but if someone wanted to troll you a goof rm -rf isn’t hard.
Test strips. PSA: Everyone should test their drugs and carry narcan.
I was gonna say “have someone else smoke it first”
If the installer is small enough (<650MB I believe), you can upload it to virustotal.com to have it be scanned by ~65 antivirus programs
If it’s suss use a vm before your main OS.
And start with no network for the VM
This is a good idea and a good practice in my opinion. Some malicious code detects when it’s being sandboxed and hides itself until it’s running somewhere it can do damage though.
Once malware is VM aware it can also get outside a VM. Furthermore, malware can be written to seat itself comfortably in your PC and lay low for hours, days, weeks before becoming active. Installing in a VM and waiting for shit to hit the fan is not always reliable.
Getting out of a VM reliably is not usually trivial, and VM escapes are usually designed to target specific configurations rather than an arbitrary deployment. A VM with a minimum amount of shared resources is usually a reasonable security boundary unless you think the malware you’re analyzing has hypervisor-specific 0 days.
Isn’t DaVinci resolve free?
@ccdfa yeah but h264/mp4 exports are paid only from what I heard
export it as some QuickTime/mov/whatever and recode it with handbrake.
A crack changes program code and is executed. There is no easy way to check if it is safe.
Unless you inspect the source code or binary code (directly or through reverse-engineering) you can not verify it.
What’s left without that is attempts at gaining confidence through analysis trust of third parties - the providers, distributors, creators - who have to be confirmed beyond a matching text label too.
The alternative to or extension of being confidently safe or accepting the risk is to sandbox the execution. Run the crack in a restricted environment with limited access in case it does things you do not want to. Optionally monitoring what it does. Which has to be put into relation of what the program does without the crack.
Back when I used cracks often the cracks were small keygens and sometimes a patched main exe/dll, so I could just generate the key in a vm/sandboxed environment and inspect the patched binary, usually they did nothing weird. Huge repacks are often very sketchy though… Nowadays there are many great FOSS alternatives so I tend to use them more.
first visual inspection: is there any rash or poop or anything nasty in there? then sniff.