And this malware is largely based on open source code (Linux) that was originally developed on open, documented hardware, where the firmware boot loader did nothing more than load the first 512 bytes of your hard disk to address 0x7c00 and transfer complete control to it.

Yes, there were viruses that exploited this openness, but imagine if Linus Torvalds would have needed a cryptographic certificate from IBM or Microsoft to be allowed to run his own code! This is basically the situation we have today, and if you don't see how dystopian this is, I don't know what more to say.

I will never understand why such an overwhelming majority of people seem to just accept this. When frigging barcodes where introduced, there were widespread conspiracy theories about it being the Mark of the Beast -- ridiculous of course, but look at now where in some places you literally can't buy or sell without carrying around a device that is hostile to your interests. And soon it will be mandated by the state for everyone.

Google must be destroyed.

    2100 push ax            ;--- EmitByte: write one byte to code output ---
    2101 mov di, [code_ptr] ;DI → current position in output buffer
    2104 stosb              ;Write AL to output, advance DI
    2105 mov [code_ptr], di ;Update code pointer
    2108 pop ax             ;Restore AX
    2109 ret                ;Every compiled instruction flows through this 6-instruction emitter
    2110 mov al, 0E8h       ;--- EmitCall: generate CALL instruction ---
    2112 call EmitByte      ;Emit opcode byte E8h (near CALL)
    2115 sub bx, [code_ptr] ;Calculate relative offset
    2118 sub bx, 2          ;Adjust for instruction length
    211A xchg ax, bx        ;AX = relative offset
    211B call EmitWord      ;Emit 16-bit relative displacement
    211E ret                ;Generated: E8 lo hi — a complete CALL instruction

EmitByte here is unnecessarily pushing/popping AX, which isn't modified by the few instructions in between at all. No competent assembly language programmer would do this. So maybe against all expectations, Turbo Pascal is just really badly coded? No, it's of course a hallucination: those instructions don't appear in the binary at all!

That the hex addresses are wrong can already be seen in the instruction "mov di,[code_ptr]" here being apparently only three bytes long. In reality it would take four! And it's easy to confirm that this code isn't present at the addresses shown.

So maybe it's somewhere else? x86 disassembly can be complicated because the opcodes are variable length, and particularly in old programs like this the code and data are often not cleanly separated. Claude apparently ran it through NDISASM, which doesn't even attempt to handle that task.

But searching for e.g. the hex opcode B0 E8 ('mov al,0xe8') is enough to confirm that this code snippet isn't to be found anywhere.

There is a lot more suspicious code, including some that couldn't possibly work (like the "ret 1" in the system call dispatcher, which would misalign the stack).

Conclusion: it's slop

The designers of RISC-V included the bare minimum needed to compile C, everything else was deemed irrelevant.

Galaxy brained protip: instead of a trap, use return instructions as padding, that way it will just work correctly!

Some compilers insert trap instructions when aligning the start of functions, mainly because the empty space has to be filled with something, and it's better to use a trapping instruction if for some reason this unreachable code is ever jumped to. But if you have to do it manually, it doesn't really help, since it's easier to forget than the return.

https://man7.org/linux/man-pages/man2/modify_ldt.2.html

Set seg_32bit=0 and you can create 16-bit code and data segments. Still works on 64 bit. What's missing is V86 mode, which emulates the real mode segmentation model.

Nothing more privileged than ring 0 is required for that.

"v86" is what allowed real mode to be virtualized under a 32-bit OS. This is no longer available in 64-bit mode, but the CPU still includes it (as well as newer virtualization features which could be used to do the same thing).

Using a non-standard mechanism of loading CS (LOADALL or RSM), it's possible to have a writable CS in protected mode too, at least on these older processors.

There's actually a slight difference in the access rights byte that gets loaded into the hidden part of a segment register (aka "descriptor cache") between real and protected mode. I first noticed this on the 80286, and it looks to be the same on the 386:

- In protected mode, the byte always matches that from the GDT/LDT entry: bit 4 (code/data segment vs. system) must be set, the segment load instruction won't allow otherwise, bit 0 (accessed) is set automatically (and written back to memory).

- In real and V86 mode, both of these bits are clear. So in V86 mode the value is 0xE2 instead of the "correct" 0xF3 for a ring 3 data segment, and similarly in real mode it's 0x82 (ring 0).

The hardware seems to simply ignore these bits, but they still exist in the register, unlike other "useless" bits. For example, LDT only has bit 7 (present), and GDT/IDT/TSS have no access rights byte at all - they're always assumed to be present, and the access rights byte reads as 0xFF. At least on the 286 that was the case, I've read that on the Pentium you can even mark GDT as not-present, and then get a triple fault on any access to it.

Keeping these bits, and having them different between modes might have been an intentional choice, making it possible to determine (by ICE monitor software) in what mode a segment got loaded. Maybe even the two other possible combinations (where bit4 != bit0) have some use to mark a "special" segment type that is never set by hardware?

>Unless you can manually set CHS in BIOS to match, which a USB adapter won't let you do anything you want like BIOS. A Pi could substitute for that but it was never really a good idea, mainly useful to set a non-default CHS on one drive to match the default CHS on an established drive when both are plugged into the same motherboard.

USB hard drives act as SCSI block devices, they don't have a CHS geometry and sectors are addressed by a single number (LBA=Linear Block Address).

Again: the purpose of this device is to connect an OLD HARD DISK to a MODERN COMPUTER. Not the other way around! If you plug it in and try to boot from with a BIOS / UEFI CSM that supports this, it will make up a CHS geometry based on the total number of sectors, instead of using the (real or translated) one that the drive actually uses and reports in its "IDENTIFY DEVICE" response. Because it's connected over USB and behaves like any other USB mass storage device.

That may well lead to problems when booting DOS from a drive that was formatted in some other machine, because the MBR will not use the same geometry. But that's not what this is for.

>If I was being very skeptical, I would say it's possible the coder didn't even know that USB adapters exist.

From the second paragraph in the readme: «« While cheap, modern adapters usually only work with newer "LBA" type drives, ATAboy works all the way back to the earliest CHS only, PIO Mode 0, ATA disks. »»

But maybe some of these cheap adapters do in fact work with CHS, or that specific 40 MB drive with LBA?

Or do you have some "smoking gun" evidence?

I think the setup screen is a really nice touch and not something an AI would come up with.

[1] https://github.com/redruM0381/ATAboy/commit/4e55223acd1c8cdc...

[2] or someone else? it keeps using the phrase "your friend"

Didn't see it mentioned in the article though, maybe I missed it. If not, I think that this detail would be a good thing to include, both since it's a common mistake that others with less experience might make, and to get ahead of nitpicky comments like mine :)

e.g.

    0x8000_0000 < 0x0000_0001 for signed numbers
    0x8000_0000 - 0x0000_0001 = 0x7fff_ffff, high bit clear