What I mean is when you have a disk that suddenly cannot be mounted on win10 OR on Linux Mint could it have been corrupted somehow from the BIOS ( via the OS writing to the BIOS somehow) ?

Like by malicious attack for instance?

And the answer to the question may reveal ways to rescue the data off that disk.

Here's the story:

disk: system disk, on Win10. Suddenly machine will not boot. Will not pass that initial BIOS screen from the mobo which invites you to press F11, F2, etc. for Bios and whatever.

AND: none of those 'presses' will work.

BUT: Ctrl-Alt-Del WILL work and the system can reboot and reboot but it always hangs right there.

Now: when pulled out ( a SATA disk, it is ) and stuck in a Linux Mint machine with only a sys disk on SATA 1 and put on SATA 3 it does exactly the same thing: makes the OS hang on the BIOS screen.

i.e. it seems to be screwing the BIOS somehow before it ever gets to the OS. Is my unskilled, untutored, inexpert reading of it.

Hence the question: could something have been written to the disk that really causes the BIOS to freeze when it reads it? What is the interaction? Mainly a handshake protocol I'd imagine. Where in that procedure is there a 'sticking point' where an answer will prevent further processing of the algorithm, the code AND avoid error handlers?

Right now that disk is hanging off a Mint machine and is not seen by Files or Disks but is seen by lsblk and smartctl reported back that it was okay (but with one bad sector).

It was gotten there only by 'hot swapping'. As I said, booting with it causes a hang. So I booted without it and then 'hot swapped' or 'hot added ' it.

When I restart the machine I have to do all that again. It doesn't stay 'added'. The machine will hang. I have to pull it, reboot, hot add.

I need to read the data off that disk somehow.

All this is in pursuit of that goal.

Any input will be appreciated.

Are we talking about a real BIOS here or a UEFI? If it's a BIOS, I don't know of any mechanism that could write to it from the OS. But if it's a UEFI, all bets are off. Recently something called Black Lotus emerged; it writes stuff to the EFI system partition on your drive, older versions of Windows software that are vulnerable and should have been blacklisted. Trouble is, Microsoft can't blacklist them because they are in wide use and a lot of angry customers would suddenly find their machines unbootable. So much for the improved security that UEFI is supposed to make possible!

When BIOS (UEFI, whatever) boots from a disk it loads some code from it - bootloader, and passes control to it. If bootloader is corrupted the computer will freeze, and it doesn't involve BIOS modification or other dark arts. You have to reinstall the bootloader, maybe recreate partition table. No idea how to do it in windows without destroying everything.

If a drive is reporting a bad sector I assume it has others waiting in the wings - SMART is great until it isn't, because end of the day what you're hoping is on the failing device with errors to be able to self-monitor its errors while it fails and tell you about itself failing while it fails...sorta circular there

As far as the bootloader becoming corrupted or damaged, yes this is possible - especially if the drive has bad sectors/blocks, or has other issues (e.g. its taking too long to get ready or provide data to the system). As far as the host OS writing back to the firmware, UEFI has a lot of interactivity with the OS, but BIOS does as well (the host OS can write back and impact things like the system clock and various other things at a hardware level if appropriate drivers exist). The bootloaders (both for linux and Windows) will interact with MBR in BIOS or UEFI in order to function, but in normal course of operation this behaves as long as the configuration is sane. With a dual-boot things are a bit more exotic and so (ime) more likely to have configuration issues, but if things were working on Monday and then suddenly aren't on Tuesday, and you're now seeing bad sectors on the system disk, I'd look at the hard drive before looking at the software, unless you also ran updates that touched grub (or in Windows - the specific services that init Windows are bootmgr and winload but I don't think Windows Update provides granular information of each update as to which service its touching, but if you've run updates and the list isn't too great you can work it it backwards from the KB #s associated with each update) which may have set something improperly vs how your system needs to work. All of that said, I don't personally trust drives that are throwing bad sectors, so if it was me, I'd be getting the backups out and looking for a new drive.

The very first piece of PC-DOS debugging I ever did was to hand dis-assemble the Michaelangelo virus from one of our office PCs some time last millennium. Never having seen x86 assembler before that time.

Have had a very bad opinion of "security safeguards" in the PC market ever since ...

If it was mine I'd either write generic MBR code to the boot sector on that disk, or wipe the MBR sector's first 446 bytes, then try booting with the disk already connected, to hopefully be able to determine what if anything else can or needs to be done to resurrect partition(s) or recover data.

As hazel pointed out, BlackLotus is out there. There'a another one too, MoonBounce, and some other thing writing to the blank EFI partition.

I get the feeling you're still using that disk? I very much don't like the idea of it landing as sda. Insert it under one circumstance - to copy off potentially useful data if you teetotally failed to back it up. I wouldn't trust any M$ install there. That's not useful data anyhow, and probably infected.