If you read this article, you'll understand just how easy it is to compromise so many computers. What I have seen infecting my own systems works on computers built in 2004 as well as new machines, so its exploiting the design and implementation of various international standards. The way it works, is the bios loads the malware irrespective of the boot drive order specified in the bios, and then it seems to rewrite th…
The "findings" you are describing are characteristic of security-conscious users suffering from paranoid schizophrenia. This is not an isolated incident. The "badBIOS" incident reported by Dragos Ruiu a few years ago ([1]) had many of the same characteristics as what you are reporting: • Vague symptoms, affecting all computers (and, often, even non-computer devices) owned by the individual • Inability to isolate the…
Writing a Tiny x86 Bootloader
41–50 of 55 posts
Re: Writing a Tiny x86 Bootloader
#42It's been forever since I've thought about the segmented memory model. Can someone explain this math to me: The OP states: "Since our code resides at 0x7C00, the data segment may begin at 0x7C0" 0x7C00 in decimal is 31744 and 0x7C0 in is decimal 1984 and a segment is 16 bits. I understand that the CPU is hardwired to do a JMP to 0x7C00. But how did they arrive at choosing 0x7C0 for the data segment?
So typically the first thing you do on entry to the boot sector is to do a far jump to change code segments. But you don't have to; if you're immediately switching to 32-bit mode it may not be worth it.
Here's my boot sector --- everyone's written one. Mine's intended to load and run raw tiny mode executables on floppy.
https://github.com/davidgiven/ack/blob/default/plat/pc86/boo...
Re: Writing a Tiny x86 Bootloader
#43It's been forever since I've thought about the segmented memory model. Can someone explain this math to me: The OP states: "Since our code resides at 0x7C00, the data segment may begin at 0x7C0" 0x7C00 in decimal is 31744 and 0x7C0 in is decimal 1984 and a segment is 16 bits. I understand that the CPU is hardwired to do a JMP to 0x7C00. But how did they arrive at choosing 0x7C0 for the data segment?
0000:7c00 (segment 0, offset 0x7c00) and 07c0:0000 (segment 0x7c0, offset 0) are at the same physical address of 0x00007c00, so the processor will see the same bytes each way. The latter's more useful in 16-bit mode, though, as it allows you to use offsets 0x0000 to 0xffff to access the 64kB of data starting at physical address 0x00007c00. So typically the first thing you do on entry to the boot sector is to do a far…
"Since our code resides at 0x7C00, the data segment may begin at 0x7C0"
If those are both the same address how can the code segment and the data segment occupy the same address?
Thanks.
Re: Writing a Tiny x86 Bootloader
#44Earlier quoted context omitted.
0000:7c00 (segment 0, offset 0x7c00) and 07c0:0000 (segment 0x7c0, offset 0) are at the same physical address of 0x00007c00, so the processor will see the same bytes each way. The latter's more useful in 16-bit mode, though, as it allows you to use offsets 0x0000 to 0xffff to access the 64kB of data starting at physical address 0x00007c00. So typically the first thing you do on entry to the boot sector is to do a far…
Thanks for the clarification and your link. Maybe I am reading this wrong then? "Since our code resides at 0x7C00, the data segment may begin at 0x7C0" If those are both the same address how can the code segment and the data segment occupy the same address? Thanks.
It's also possible to configure the system so that your code lives in one segment, and your data and stack live in another. That way, you get 64kB for code and another 64kB for data.
We have to put the stack in the same segment as the data because C requires the stack to be addressable; if you're not working in C, you can put the stack in a third segment and get a bit more space.
Of course, if you're willing to use pointers which contain the segment as well as the offset, so 32 bits wide, you can use multiple segments, but that raises all sort of complexity that's not really worth thinking about these days.
Re: Writing a Tiny x86 Bootloader
#45Earlier quoted context omitted.
Except I have isolated the code and can reproduce it on demand, and have the photo's & video's as evidence so nice try. However having just read this https://www.facebook.com/dragosr/posts/10151655183445588 I can see he has explained much of what I was witnessing on some systems as well. Cant rule out a modern day version of one of these https://en.wikipedia.org/wiki/Phoebus_cartel considering the Windows MSR partiti…
With all due respect, everything you said sounds like some kind of conspiracy theory. If you have isolated this case, write a blog post of how to reproduce it, post said photos & videos, so people might at least take their time to read it. I'm sure with all the experts here on HN somebody would provide an explanation. There are hell lots of processes happening at modern system boot time, if it does something you don'…
Have a mother board which supports PS2 mouse & keyboard connections, but use a USB mouse. One thing I have observed in Ubuntu 16.10 live CD when it strikes, is when the screen starts dimming (power saving) and then goes blank, the USB system seems to stop. So if you move your USB mouse to bring the display back up it doesnt work, but moving the PS2 mouse does bring the screen back up from power save so the malware doesnt appear to work "so far" on ps2 devices. If you happen to be printing to a USB Printer in my case a HP LaserJet 1200, the printer system (CUPS) will say the printer is paused and the only thing you can do to get it printing again is to reboot which means having to boot from a live cd and download said webpage again. Sometimes you have to do this for each page the website goes over. This is whats called resource burn.
Get a USB CD/DVD device, although its slower, when the firmware of this is changed(infected) it starts emitting a different noise like its jumping around alot more to read stuff. As I have a silver ubuntu 16.10 disc, these cant be burnt again so are a little safer as nothing can be added to these discs, but I suspect burnable CD/DVD's despite choosing the option to make them burn proof ie cant be added to, can be. Looking at the disc under a microscope or jewelers loupe might confirm this.
The hex editor in the Parted Magic disc I have here (its about 3-4years old at least) wont show infected files eg a webpage printed to a pdf in its entirety, but looking at the raw partition searching for a matching part of the string data and then doing a side by side comparison using the hex editor opened twice will show the data goes beyond the sector it stops at having loaded an infected file.
Now I'm not a security expert, my background is database programming but I have been programming computers since an early age and have noted the changes in operating systems.
So staying within the laws of physics, and considering wifi has been built into CPU's (Intels VPro/AMT for example) but possibly deactivated by microcode is cheaper CPU's, is all the above just a side show? Or does this code only become activated when some CPU microcode is switched on for example, making it impossible for other's with CPU's not affected to find this?
Another clue you might have an infected system, is when using dd to zero a device, the device either never completes throwing the usual "out of space" error or it throws an Input/Output error suggesting the block device has a reliability issue.
The make and model of CD/DVD drives and so far some Western Digital hard drives, seem to be rewritten when the system is infected. In theory, just because a manufacturer doesnt provide a firmware upgrade, doesnt mean you cant upgrade the firmware. Just look at the package FlashRom which I discovered a few days ago, or hddguru.com for some of the firmware tricks that can be carried out on different devices.
Another clue, is Iptables doesnt seem to work properly, when setting rules (I always go for log and drop) for everything, not just filter, but nat, mangle, raw and bear in mind here in the UK IP TV stations provided by the ISP's are delivered over IPv6, even if you set iptables for IPv4, how many set iptables for IPv6? If you poke around with your ISP supplied router, download the config file you'll find IPv6 settings plus some also provide wifi access points which are unecrypted and accessible open to anyone who wants to fly a little drone and drop a PiZero into your properties gutter hacking your wifi.
I can post some photo's to my imgur account if they stay up there, if not post an email address to here and I'll send some photo's of the bios screen from an old pc which shows the drive's make and model being changed, taken on an old digital camera's so it cant be hacked unlike so many of todays wifi enabled device's and I'll post a couple of PDF's which seems to cause Input OutPut errors. In the PDF case, yes I will need to start looking at the PDF reader's code that ship's on Ubuntu 16.10 to see what it does but its not something I have done before.
Here's a screen shot of a UEFI bios which shows that the bios can load and unload drivers http://imgur.com/gallery/npR9ZIw
The bottom line with all of this stuff is who do you trust? When you phone a call centre how do you know you are talking to a call centre and not the spooks? You cant prove it, and this is what all of this seems to be about. In law you need evidence, which is interesting because the Snoopers Charter now in law here in the UK specifically section 56.4 allows all spook activity from 1985 onwards to be considered legal. And you cant talk about their methods.
If you know about the phone system FreeSwitch you'll know you can run your own phone company with it, whilst setting up call intercepts so irrespective of what number an extension dials, it always go through to the same extension. A similar example is when visiting a company, sometimes in reception there might be a single phone which you pick up and it automatically rings another extension. If you added a VOIP number to and set FS to record all calls, as the VOIP is shunted to FS, FS detects it needs to play back the ringing tone's to the caller which it does, now as its also setup to record conversations, the caller can leave a message and there is never a billing record to suggest the call connected. What a great way for spooks to communicate within a country, unless of course all phone's are actually recorded and for arguments sake what the Govts tell us is just a lie to stop up from getting upset about being spied on all the time ala the Panaopticon?
Practically anything can be done with digital technology and with the resources and ingenuity of nation states, you can pull off a Brexit or Trump election if you so wanted!
Take digital TV, how many channels to keep you entertained? Bread & Circus springs to mind, and divide and conquer also springs to mind, which starts with everyone being educated into what ever takes your fancy, whilst few actually have an overview of whats really going on in life. Maybe life is more like the Matrix than it appears to be?
PS. On the point of a microcode switch being in play, I have observed Raspberry Pi SD cards which load on one Rpi but take the same SD card out and place it in another Rpi, and the same SD card wont boot, so microcode/Rpi firmware is quite likely a factor, and the same probably applies to Intel/AMD CPU's which is why I wonder if its a modern day pheobus cartel forcing people to go out and buy new hardware. HP PSU's in network printers and laptops also seem to have a tendency of blowing up as well.
Re: Writing a Tiny x86 Bootloader
#46Earlier quoted context omitted.
Thanks for the clarification and your link. Maybe I am reading this wrong then? "Since our code resides at 0x7C00, the data segment may begin at 0x7C0" If those are both the same address how can the code segment and the data segment occupy the same address? Thanks.
Yup, they can. That way your code and data share the same address range, so you need to make sure that the offsets within the address range don't overlap. It's also possible to configure the system so that your code lives in one segment, and your data and stack live in another. That way, you get 64kB for code and another 64kB for data. We have to put the stack in the same segment as the data because C requires the st…
You mention:
"We have to put the stack in the same segment as the data because C requires the stack to be addressable"
Are symbols only "reachable" if they are within the base and limit of same memory segment then? If this was the case I would think that the code and stack must be in the same segment? Why is the data segment?
Cheers.
Re: Writing a Tiny x86 Bootloader
#47Earlier quoted context omitted.
The "findings" you are describing are characteristic of security-conscious users suffering from paranoid schizophrenia. This is not an isolated incident. The "badBIOS" incident reported by Dragos Ruiu a few years ago ([1]) had many of the same characteristics as what you are reporting: • Vague symptoms, affecting all computers (and, often, even non-computer devices) owned by the individual • Inability to isolate the…
If you're going to respond empathetically to someone who you think needs help, it's important to distinguish that from a personal attack. This comment doesn't do that—indeed it almost seems like you're invoking "psychiatric help" as ammunition in an argument, which would be bannable offence here.
But I certainly see what you mean; I was probably too quick to use that stock phrase. My intent here wasn't to argue, because I know that's impossible; it was more to identify the pathology to others. Would my comment have been fine without the last line? (I'm assuming that you were the one to flag it.)
*: and I mean that in the psychiatric sense, not as an insult
Re: Writing a Tiny x86 Bootloader
#48Earlier quoted context omitted.
> the rest is just reading up some documentation about what you are going to load That documentation is usually.... lacking > You can't fit a filesystem parser into 1 sector and have anything other sensible in there You don't use a single sector. You use a 2 stage bootloader that uses a reserved FAT sector. In FAT12 (at least) you can specifiy how many reserved secotrs on formatting. A reserved sector comes directly…
You sound pretty well versed in this area, would you be interested in writing something up? Don't take this as a dig, I know the value of free time and how much that free time is lacking for most of us, I just thought I'd toss it out there.
Re: Writing a Tiny x86 Bootloader
#49Earlier quoted context omitted.
If you're going to respond empathetically to someone who you think needs help, it's important to distinguish that from a personal attack. This comment doesn't do that—indeed it almost seems like you're invoking "psychiatric help" as ammunition in an argument, which would be bannable offence here.
It's almost a moot point. Given the underlying pathology, any attempt at all to discredit this type of delusion* will necessarily be seen as a part of the conspiracy, and hence as an attack. No amount of empathy will help. But I certainly see what you mean; I was probably too quick to use that stock phrase. My intent here wasn't to argue, because I know that's impossible; it was more to identify the pathology to othe…
There's probably a way of making this point that's fine, but it would require pre-emptively distinguishing your comment from the obvious misinterpretations. Which is tedious, but such is the way communication on a large forum needs to work, or else people just react and attack.
Re: Writing a Tiny x86 Bootloader
#50It's sad that most of these "bootloader" guides don't take you into actualy boot-loading something. No searching a file system. No loading another binary. No setting up 32 mode. Nothing, just printing text. That's what most of these are on.
"0x2098" "lgdt"
Please chime in with other links to great bootloader tutorials!