Computer Hackers Will Blow Your Family to Smithereens

This is deep nostalgia for me. A bootloader and a toy ... kernel ... were the outset things I e'er wrote after leaving Apple II BASIC behind. The local library had no books on anything other than BASIC and assembler. I didn't know what a higher-level language was - never even heard of C or Pascal or anything - I just knew that I didn't seem to be able to practise a lot of stuff in Basic. After a few hours at the library, I thought that assembler was the only option. And that'due south how I spent that entire summer. Going over books on assembler that for some reason were in the library of a tiny Mississippi town. Ralf Chocolate-brown's Interrupt List fabricated me giddy once I understood exactly what it meant. I all the same call up that day. Information technology was in some TSR program that I could view while in EDIT. Adjacent yr, I found out virtually Pascal, pirated a copy of TP(three? 5?) from my friend's dad and didn't affect assembler over again until college. Only I found the knowledge of how x86 worked useful for many years, fifty-fifty into my kickoff real-world job. God, I'm old.

Corking to run into someone is doing this in 2017. I was writing my own bootloader in 2003 with together with a little command interpreter in pure assembler. It taught mena lot nigh computers, it changed my thinking nigh what software really is. I retrieve for instructional purposes, getting dorsum to this basic level is a great affair.

> QEMU is great because you don't have to worry about accidentally destroying your hardware with badly written OS lawmaking Is that actually possible?

Yes. Not as easily as twenty years agone, merely still fairly easily. In fact, even well-written code can crusade hardware-bugs to burn out your hardware. Modern Bone'southward have a ton of hacks to work around limitations of sure hardware. Example A: Intel'due south Cantlet C2000 family. [0] In that location'southward quite a few things there, SATA voltages being too high etc., just if we're looking for ultimate destruction then we tin't go passed AVR54 from the errata. > The SoC LPC_CLKOUT0 and/or LPC_CLKOUT1 signals (Depression Pin Count bus clock outputs) may stop functioning. If you lose the LPC clock... The arrangement won't boot anymore. The whole story isn't in the link, but apparently the crusade for this, is that the clock tin can suddenly stop performance if you check it "besides often", ordinarily failing after 18 months of use. Cisco has the aforementioned problem with some of their routers, from the aforementioned hardware. It'due south a hardware issues, but with a quick BIOS fix, Cisco and Intel have worked around it, and their devices keep working without a recall... But your own lawmaking hasn't, and will eventually brick your device. Oh, and notice the engagement on Intel's link. April, 2017. [0] https://www-ssl.intel.com/content/dam/www/public/united states of america/en/docum...

Not quite right. The documented interface that was used for firmware control on BIOS systems generated errors if you poked information technology on UEFI systems, and the kernel logged those errors into UEFI variables. If the UEFI variable storage filled upwards, the machine stopped booting. It was possible to trigger the failure by filling the variable store, even nether Windows. The workaround was to reserve some variable storage space at all times, but this was made difficult due to the fashion some UEFI implementations practise garbage drove - deleting variables wouldn't free the space. The workaround is to try to create a veritable that's larger than the reported free space in society to trigger garbage collection, but not all implementations will do garbage collection at runtime. So the kernel volition check how much free space there is during early boot and attempt to create an oversized variable in order to trigger gc before it transitions to runtime mode. Terminal time I checked, Windows did nothing to cease you killing your organisation. Computers are bad. (source: I debugged this and wrote most of the remediation lawmaking)

I love this comment, in part because it'south totally exterior my surface area of cognition simply I can nevertheless picture the battles and expressionless ends yous must have worked through to make it stable. Did you kill a lot of hardware figuring information technology out? What was the purpose of poking that acquired the underlying issue?

I but killed one laptop in the end, the residue of the testing was done with VMs and a system that had a hardware EFI variable reset button. The issue that was triggering it on Samsungs was the driver that supported backlight control - information technology worked by writing a value to an address which triggered some arrangement management mode lawmaking in the firmware, just that code just worked properly in BIOS way. In EFI mode it generated machine cheque exceptions, which in turn caused the kernel to dump the backtrace to EFI variables.

> a system that had a hardware EFI variable reset button Ooh, that sounds useful for hardware hackers. What was this?

The only times I've heard of destroying hardware with software have been: 1) stopping the ray in a CRT monitor through special purpose registers and using it to burn through the phosphorous. 2) Early floppy drives where yous could position the head to an impossible position causing the servo to burn down. Haven't heard of annihilation like what he is describing the last 20 years. Peradventure yous can overheat some stuff - simply near likley information technology'll shut down earlier anything bad happends. At that place are all the same some worrying notes on OSDEV nigh causing potential damage when probing for memory, perhaps the author read this and got worries. It isn't detailed or probable, imho.

Tangent, just a expert story: Early in my career, in the CRT era, I was working late at a client's office. Ane of the executives stopped by to chat; he was telling me that his house burned down the past weekend (!) due to a wiring fault in an SUV in the attached garage that somehow ignited something ... any acquired it, holy shit. His family all got out ok - in the centre of the nighttime - just everything they owned was lost. As nosotros were walking through the darkened office on our way out - the last two to leave - he said, 'do you smell something burning?' Poor guy; he must smell it everywhere. For all I know there was withal smoke residuum in his sinuses. Anyway, I take to humor him - I'm tired and actually want to get dwelling house, merely there'due south no question of trying to talk sense to someone in his state. So I make a bear witness of looking effectually the part with him - and sure enough, there was a CRT monitor, plugged in, off (or maybe comatose), and literally smoking. I never saw anything similar information technology earlier or since, in over 20 years in Information technology. But he must yet smells smoke everywhere he goes.

> The merely times I've heard of destroying hardware with software accept been I was trying to find some data to back up my story, but I tin can't find annihilation that does. Then I'll draw what I experienced, and maybe someone will have an thought. Around 1999, my begetter gave me the first calculator that was "mine" (previous ones having been "family computers"). I was inexperienced and fifteen years former, with access to filesharing platforms, and learned the difficult way about *.jpg.exe files. The hard bulldoze started making rhythmic sounds equally presently as the Os was booted. A couple days subsequently, the Os wouldn't kick. A reinstall worked for a curt time (simply the drive still did its odd sound). We had some bootable deejay scanning utilities from the drive vendor. They identified the drive as having 100% bad sectors. I've e'er causeless that a virus was crashing or misaligning the read heads somehow. That was reinforced when the second drive that I got met the same fate. Although, I gauge it'southward more likely that they were two drives from the same shipment that met early deaths due to manufacturing defects.

I have never heard of annihilation like the following, simply hither is a reasonable still very much theoretical explanation for what you described: This virus loaded itself somehow at early on bootup (perchance fifty-fifty launched via an contradistinct bootloader) and and so sequentially accessed every single sector on the disk and deliberately marked information technology as bad at either the FAT32 or ATA (hardware) level. The bustlework involved with really issuing tons of such ATA commands could explain the thrashing. Ref/inspiration for this theory: ^F for "--make-bad-sector" in https://linux.die.internet/homo/eight/hdparm (Just to exist redundantly, obsessively clear, this parameter is several orders of magnitude more than dangerous than "rm -rf --no-preserve-root", every bit hdparm volition use ATA/SCSI commands that will be preserved by the hardware beyond infinite reboots until exactly the right --repair-sector control is issued.) And FWIW, I do run across a lot of holes in this (very simplistic) estimation, and would be genuinely stunned if this is what actually happened.

Given the year, that sounds suspiciously like the IBM 75gxp Deathstar fiasco. Information technology probably wasn't your mistake at all.

1999, maybe 2000, with six.4GB and viii.4GB drives (I suspect they were WDs, based on disk utility floppies I've got around from that era). It looks like the affected Deskstars were 15-75GB, and probably at to the lowest degree a yr afterward, correct?

On the Commodore PET you could write a curt BASIC program to rapidly alter the management of the tape drive motor, it would fry the transformer that ran it.

I had a coworker who used to be a C64 enthusiast. One day, a very long time agone, he discovered a C64 program on Usenet called "drive music". He downloaded information technology and ran information technology... and his floppy bulldoze started playing music. After playing with it for a while, he heard that using it likewise much could throw your drive heads out of alignment, so he got rid of information technology.

For me, alignment problems on the 1541 were fairly common (at that place was a lot of head thrashing when trying to read "protected" disks), which concluded up with the 1541 cover being easily removable for me, and always a screwdriver nearby to recalibrate.

I've always been told that there is chance of irreversible hardware damage. I haven't whatever thought where this claim comes from, and I've never been offered an caption. It'southward one of the things that has ever made me wonder, and why I've never tested any of my own code on existent hardware. I'd exist curious to encounter this claim expanded, or debased.

Yes. Back in the early on days of GNU/Linux, getting 10 to run could kill your monitor. Some other instance, many hard bulldoze controllers used to blindly move their heads to whatever position they were told, even if it was an incorrect position. In the old days you lot too had to apply something similar PC Tools to park the heads before moving the reckoner.

I'd say yes. Specially if y'all mess with ACPI and, say, plow off the fans...

Experience with an incorrectly heatsunk laptop GPU has demonstrated to me that the BIOS will yank power to the system if information technology hits 100°C. Yep. Well, in all honesty I'1000 non sure if it was Linux, the BIOS, or some depression-level thermal monitoring circuitry, but yeah, I one infinitesimal I was messing effectually with WebGL and the next infinitesimal I got dislocated about whether I'd forgotten the ability cable. (Then I realized I hadn't heard any beeping (this was a ThinkPad and I didn't take the beeper muted) and realized it had overheated.)

The possibility is small, simply with voltages and frequencies nether software control, yes. AFAIK even ordinary "not-overclocker" hardware has this adequacy, despite not being exposed in the BIOS settings, for power direction purposes. This is particularly problematic with certain laptops --- I remember hearing nigh some that would overheat when booted into BIOS or fifty-fifty an alternative OS for an extended period of time, since they depended entirely on a driver to plough on and control the CPU fan...

Yes in the 80s PC monitors had CGA and MONOCHROME style, and if yous switched fast between them in DOS (y'all could practise mode mono, and style co80 in a loop) and information technology fried my GPU :)

Apparently hackers can turn your dwelling computer into a bomb ...& blow your family unit to smithereens!

Last line in this commodity mentions a Function 2, which will encompass getting into Protected Mode. Which implies that x86 boxen are yet to this day are POSTing in 16-fleck real style What I'm wondering, is whether this is because of the pattern of the firmware, hardware or both. Back when protected mode was the new hotness, it made sense for the CPU to power on in real mode, for backwards compatibilty. Only back-compat w/ DOS is less of a business concern today than it was twenty years ago. Is it all the same required for back-compat with older versions of Windows, since UEFI wasn't commonplace in the WinXP or Win7 days? Does UEFI have to lift the CPU from existent-manner to protected way, or does information technology leave that to the OS? Some other thing I wonder nearly, is if it's possible to have the CPU come online directly in protected mode or long fashion afterwards POWER_OK has settled and the motherboard releases the reset line. I recall reading various datasheets for tiny specialized controller fries (fan controller, et. al.), wherein by leaving various pins floating, or asserting them loftier or depression with pull-up/down resistors, one ready the power-on value of the annals(s) which controlled start-upwardly behavior. It'd be cool if you lot could practice that with a modern mobo/CPU. But fifty-fifty if it were, I suspect it would be a modern reserved for those brave enough to have a soldering atomic number 26 their motherboard. I uncertainty such is a common plenty demand that mobo manufacturers are exposing that through jumpers or firmware config.

UEFI boot handles the real->protected (and ->long) transitions, and then it's no longer necessary for the OS to handle it. EFI executables run in protected manner, with a retentivity mapping prepare by the runtime. > Another affair I wonder about, is if information technology's possible to accept the CPU come online directly in protected way or long mode after POWER_OK has settled and the motherboard releases the reset line. No. The BIOS needs to perform some touchy, hardware-specific initialization -- like detecting and calibrating RAM -- before releasing control to user code. It's not something you'd desire the OS to be responsible for.

>> Another thing I wonder about, is if information technology's possible to have the CPU come online directly in protected manner or long mode subsequently POWER_OK has settled and the motherboard releases the reset line. > No. The BIOS needs to perform some touchy, hardware-specific initialization -- like detecting and calibrating RAM -- before releasing command to user code. It'southward non something you lot'd want the Bone to be responsible for. I remember you misunderstood me. I didn't mention, and wasn't even thinking about the Bone yet. Every bit y'all said, UEFI handles the real->protected->long transitions. While the Os isn't loaded yet, and hardware initialization is being done, the CPU is still executing. What I'chiliad talking about is setting the CPU'southward default power-on state, how it is before it begins executing even the kicking firmware to initalize hardware and set to hand over execution to the Os. Past my understanding, when the power comes on, the motherboard waits for the PSU to assert POWER_OK. Once the PSU has done so, and POWER_OK has settled, so the mobo releases the CPU'due south RESET line, allowing the CPU to begin executing. At this point, the CPU is in real mode. What I am wondering is if the hardware can exist configured so that once the motherboard releases RESET, the CPU is already in long fashion, and begins executing the boot firmware. Is there something about the nature of pre-OS hardware initializtion that requires the CPU to be in existent-fashion to practise this? If CPUs could be coming online straight in long-manner, then perhaps the UEFI firmware could be simplified, since it doesn't need to handle the existent->protected->long transitions anymore.

> No. The BIOS needs to perform some touchy, hardware-specific initialization -- like detecting and calibrating RAM -- earlier releasing control to user code. It'southward not something you'd want the OS to be responsible for. I don't feel like the person you're responding to suggested that the OS should exist responsible for information technology; he/she simply wondered if information technology is possible to have the CPU not have to bound through 16-bit real way and 32-bit protected way merely to go to 64-bit. I see no central reason why it should be impossible for the BIOS to exercise its initialization piece of work in 64-bit mode. There's the issue of paging and the page-tabular array maybe, but it seems piffling enough to propose that the CPU could initialize with a very basic 1:1 mapping betwixt virtual memory and RAM. That said, I don't know if such a affair would ever actually happen, since I imagine that it would advise re-writing a lot of code.

meh. since the retentiveness controllers are part of the CPU proper this is a pita, but not clearly super magic that only contractors of motherboard manufacturers should touch on either. I worked someplace where nosotros ran AMD fries with no bios. someone who had meliorate uses for his time had to probe the ram modules and configure the controller. it wasn't the terminate of the world. same with pci tree discovery (waste of time, not the stop of the world) interacting with EFI is a little more sane than the old bioses, and less proprietary - simply i dont recollect at that place as clear a line every bit you imply

It's a great write-upwards (follow the next parts if you've but seen the 1st one) I wonder how this changes by booting from UEFI (and not using whatsoever 'emulation mode')

> I wonder how this changes by booting from UEFI (and not using any 'emulation mode') It's pretty damn like shooting fish in a barrel: ane. You don't write a bootloader since UEFI is that bootloader. 2. You write a portable executable which gets executed past the UEFI bootloader. This executable runs straight in long-style without any nonsense. three. You take to link against some different C-libraries, not the standard ones, but that's about information technology. Here's an example: http://x86asm.net/articles/uefi-programming-first-steps/

Aye, I really want to write a hobbyist OS atop UEFI & amd64, but … the learning curve is daunting. BIOS is too unproblematic, just UEFI is hyper-complex. There's probably a reason most hobbyist OSes seem to be using BIOS …

> Yeah, I really want to write a hobbyist Os atop UEFI & amd64, but … the learning curve is daunting. BIOS is besides elementary, but UEFI is hyper-circuitous. That doesn't really seem very representative of reality. UEFI basically takes care of all the terrible legacy stuff for you, and so yous don't have to. You can just focus on the Bone, built on a modern architecture. See my other annotate regarding BIOS vs UEFI: https://news.ycombinator.com/item?id=15517300 If you also try to compare UEFI vs BIOS on a deeper technical level, UEFI also seems to come out in a favourable way: https://www.happyassassin.net/2014/01/25/uefi-kick-how-does-... The only "complex" part about it, is that you already know and take come to terms with all those terrible & complex things which booting a OS from legacy BIOS-mode entails, but UEFI while simplifying a million things is still different and something you lot haven't learned nonetheless.

> That doesn't really seem very representative of reality … Yous can just focus on the OS, built on a modernistic compages. Just that means complexity. E.thousand. BIOS only loads the beginning 512 bytes from a volume into retentivity; UEFI requires FAT filesystems, with paths &c. BIOS routines can hands be chosen from assembly; I don't know if UEFI routines can, or if the EFI Development Toolkit is required (I could find out, of course — but that's role of the learning bend). I take no dubiety that once I learn it all I'll prefer UEFI. Just, as I said, the learning bend is daunting.

UEFI itself might exist catchy but, actually, nothing stops you lot from burning those 512 bytes on a flash bulldoze and booting from it on Legacy mode.

Nobody knows how to do this anymore. Near half the projects I got when I freelanced were projects that were finished but "just needed" a boot loader.

I've just finished studying the bootloader and JOS Kernel and it's dainty to see that people are really working around this in 2017 :)

I guess Open up Firmware is the canonical answer. This of course compiles for x86. Just it's massive and sprawling and non actually designed for "tin be hands grasped while leaving mental room to actually learn something" only rather for broad-spectrum back up. -- You of course already know about ColorForth (confident approximate), which of class fits the bill here. Not quite "build an OS" and more "finished thing", but certainly hits the marker of "rapidly bring upwards new hardware functionality". -- I simply institute 4os (commodity: https://news.ycombinator.com/particular?id=12709802) -- I plant http://forthos.org/drive.html a petty while ago simply completely failed to get it going in QEMU (the CD image boots Grub, just promptly hangs on loading). I oasis't yet tested information technology with any other emulator, and oasis't fed information technology to any actual hardware withal either. HN article: https://news.ycombinator.com/item?id=2973134 -- There'south also gfxboot, SuSE'south arroyo to bootloader management. This is a scary pile of assembly linguistic communication (https://github.com/openSUSE/gfxboot/hulk/main/bincode.asm - warning: 16k lines, large webpage) that parses an as scary script grammar (run across .bc files in https://github.com/openSUSE/gfxboot/blob/master/themes/openS...) that is heavily inspired past Forth (the stack/RPN grammar is right there) just as well reminds me of Tcl too (it uses a { } block syntax). AFAIK this ships on the install media, and I besides vaguely recall building it from scratch existence very easy (I used SYSLINUX to bootstrap it). -- This isn't quite an OS-dev matter, but I remember it's fun: http://phrack.org/problems/53/ix.html

waltersupood1951.blogspot.com

Source: https://news.ycombinator.com/item?id=15514179

Share this post