|
Depends how you do it - there are MBR viruses (and I think I've heard of GPT viruses as well) which can survive a reformat of the system partition. It's also possible to infect the BIOS / UEFI, though that's a lot harder, so they are pretty rare: BIOS Virus - Microsoft Community[^]
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
To answer the question in the subject line:
Yes, any product having an update-able bios can retain a malware.
Which is most hard drives, motherboards and graphic cards.
|
|
|
|
|
if the hard drive will not boot/reboot, then formatting will not work, and there are viruses that will break your machine's ability to boot/reboot.
Other than that I would have to Google for answers, just as I am sure you did already.
|
|
|
|
|
Yes, this is possible. The flash bios on any hardware that has a flash bios can be infected, i.e. a graphics card, the motherboard, etc. I saw this first hand back in the mid 90's when flash bios started to become a thing. The company had ordered 24k modems for all of the lab workstations to upload lab results to an offsite reporting service. Due to the nature of the flash bios on the modems, one got infected from a user running a DOS application downloaded from a BBS. It took us, seems like, forever to discover that the hardware itself was compromised and had to be removed from the workstation.
"When you are dead, you won't even know that you are dead. It's a pain only felt by others; same thing when you are stupid."
Ignorant - An individual without knowledge, but is willing to learn.
Stupid - An individual without knowledge and is incapable of learning.
Idiot - An individual without knowledge and allows social media to do the thinking for them.
modified 19-Nov-21 21:01pm.
|
|
|
|
|
OK, it looks like there is a type of virus that infects the Master Boot Record. So wouldn't that be wiped if I do a re-partition on the drive?
|
|
|
|
|
Not necessarily; it depends on what the repartitioning software actually updates.
If it read the current MBR, updates only the partition size(s), and then writes it back, the virus code will still be there. If it rewrites the entire MBR, it will probably kill the virus.
The best way to handle MBR viruses is to:
- Backup your data from the partition(s) (not an image backup!)
- Zero the disk using DBAN or any other convenient disk zapper that works on the ENTIRE disk (not on disk partitions)
- Repartition the disk and reinstall all software (this will also be a good chance to get rid of any cruft that has accumulated over time - just don't reinstall it).
- Perform a full anti-virus sweep (using your newly-reinstalled anti-virus software) on the disk. If all is OK, make an image backup of the disk.
- Lastly, restore your data.
There may be quicker methods, but none are more certain.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
As others pointed out already, the MBR is in the startup chain, selecting the needed (and more obviously named) bootsector on a partition of the disk. In the early nineties at least, we called this the partitionsector. In that time, people did not seem to be generally aware of this. Once I was home with a flue, I got a call from work for assistance from just such an impossibly recurring virus. I had to feel my way with debug calling int 13h but succeeded tracing the problem to the MBR and overwriting the sector with the normally formatted partition sector. Forgot all about my flue in the proces.
|
|
|
|
|
Let me try a (speculative) answer along different lines:
1. If it's a QuickFormat, then virus data can still exist in sectors that are marked as clean of files. Of course, this virus is not active. I am just pointing out that a virus could use this to store its payload or stolen data for later use, if it was able to reactivate itself somehow.
2. Another vector would be a false format. If you format a disk (not the OS boot disk) from a computer that has malware, it could run a fake format that leaves things apparently blank, but in reality the disk is booby-trapped for the virus to reactivate itself. It would be quite tricky to pull this off, survive an OS reinstallation etc.
|
|
|
|
|
I always do a deep format, that way I can determine the health of the hard drive.
|
|
|
|
|
I saw a proof-of-concept that a laptop battery firmware could be weaponized.
Outside of a dog, a book is a man's best friend; inside of a dog, it's too dark to read. -- Groucho Marx
|
|
|
|
|
This has been discussed as to WHY you SHOULD ONLY USE a charging USB Cable!
The USB can be flashed from a public charging stand infected. And it is basically impossible to detect, because the virus LIES about being installed (imagine my shock!), and it adds itself on all future updates.
Only possible if a Data Cable is used!
|
|
|
|
|
I remember the rootkit scandal with Sony many (15?) years ago. It was something that hid itself from the operating system, but I guess that could be removed by a complete format of the hard drive.
As other have pointed, if your BIOS can be updated by software (my Dell computer every now and then updates its BIOS), you could definitely put a virus in there.
It would be an interesting task for a weekend 
|
|
|
|
|
I knew a company whose security product was designed to survive exactly that, by storing info in the interpartition gaps. BIOS mods (by the BIOS mfr) brought that info back out again.
|
|
|
|
|
I remember back in my early career (DOS, pre-Windows 3.1) where we had to do manufacturer specific low-level formats to remove certain infections. Getting the utilities from the manufacturers was like pulling teeth. I spent 3 days strait at one client's office rebuilding ALL of their computers, then another full day scanning all of their floppies. Virus coders have become even craftier since then. Now days, you can infect so many different parts of a computer to survive formatting. Just about every component has its own flash-able memory that can be infected.
Money makes the world go round ... but documentation moves the money.
|
|
|
|
|
Yes. 
The firmware of hard drives can be updated and infected by a persistent virus.
The same applies to USB thumb drives.
Of cause there is very deep knowledge required to accomplish this.
Destroying your hard drive is the only way to stop the super-advanced Equation malware | PCWorld
If the firmware of your ethernet network adapter or WLAN adapter gets infected your machine is lost.
An attacker can send you secrect data packets over the network and gain direct access to your RAM.
Your machine could also disconnected temporary or permanently from the internet ('internet kill switch').
|
|
|
|
|
Have a look at this article - the Intel management engine (IME) is basically a very small computer running inside your PC that has pretty much unrestricted access to every part of your PC and is completely unmonitored by your human facing operating system. The IME is so low-level that it's said to operate at 'Ring -3', i.e. it has more privileged access than your main operating system in kernel mode. And it has its own space for firmware, which could hold malware that would survive a disk being reformatted (or even taking out the old disk and putting in a new one).
And of course, vulnerabilities exist inside the IME - it's running software, so it's pretty much guaranteed it has bugs, and bugs lead to vulnerabilities - and those have been demonstrated several times... The 'Ring -3 rootkit' is particularly scary - something that can monitor everything your PC does, lives outside of your ability to see it, and is very difficult to remove...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
|
APL (a write-only language)
Lisp (lotsa incredibly superfluous parentheses)
Python (significant white space  )
I actually enjoyed programming in Assembly (25-35 years ago)
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
I stated out doing Assembler on the Apple II in 84 an I really liked it at the time. Then I taught myself C and after that didn't do much Assembler. Do some now on Embedded stuff, but not a lot.
I'm not sure how many cookies it makes to be happy, but so far it's not 27.
JaxCoder.com
|
|
|
|
|
Mike, you too? I started in 1986, on a shiny new (but ill fated) Apple ][gs
Applesoft BASIC straight to asm and bytecode as I had discovered the mini assembler *after* Call -151 
Did you end up with any Beagle Brothers books? Just curious.
Real programmers use butterflies
|
|
|
|
|
We were running ProDOS on our machines. The boss came in one day with a 5Mb HDD and we were awed. He would take me and my coworkers code into his office load it onto the HDD and compile and link it. The HDD sounded like a jet plane taking off when it spun up.
No never even heard of Beagle Bros. We were a tiny shop writing give away software that went with new modem boards.
I'm not sure how many cookies it makes to be happy, but so far it's not 27.
JaxCoder.com
|
|
|
|
|
Assembly languages vary. I worked with one where you e.g. loaded float register 4 from memory location xyzzy by "F4 := xyzzy" and the multiplied it by 4.5 with an "F4 * 4.5" instruction. A conditional jump was written like e.g. "IF = GO Label" (if the flag bits were not set other ways, you would have to precede the IF by a "COMP x, y". Call this syntactic sugar - it definitely is! - but it makes the code a lot easier to read than the treaditional assembler acronym letter soup.
This was definitely a CISC machine: E.g. it had a loop instruction "W LOOPI i, imax, TopLoop" for incrementing i, comparing it to imax, and until imax was reached, jump to TopLoop- a for-loop control in a single instruction. There were call instructions transferring a list of arguments onto the stack, moving the stack pointer and checking for stack overflow. There were heap allocate/free instructions (and the call instruction might allocate stack frames from the heap, for coroutine use). A comprehensive set of string instructions, e.g. for translating a string to another (single-byte) encoding / case / ... - strings were addressed through descriptors giving the location and length. Math functions such as square root, X**Y, log and trig functions were single instructions.
The distance in abstraction level between K&R C and this assembler/instruction set was so moderate that at the time, I didn't really see any advantage of C other than that it could also be compiled for more primitive instruction sets. In fact, we used to refer to C as "Machine independent assembler"  I preferred the machine dependent one... (But for the most part, we were programming in higher level languages than C).
|
|
|
|
|
I started assembly language programming in the late 70's but in the last 20 years in my career as an Embedded Systems Engineer (now retired), I saw no need to use assembly language in any of the products I worked on. C/C++ compiler tech for anything from an 8051 to a TI DSP generate excellent code that's relatively hard to improve upon.
|
|
|
|
|
Very true, I seldom use assembler, mostly c++.
I'm not sure how many cookies it makes to be happy, but so far it's not 27.
JaxCoder.com
|
|
|
|
|
That's pretty much my list too, with the addition of Forth. It's another write-only language.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
