Printable View
Is there ANY way using C, C++, and/or assembly that lets you directly access memory of a computer? Like the actual basic hard drive in bytes or something. I'm interested in OSs and the very ground-level stuff, like memory and stuff, so yeah.. I'm all about manipulating the lowest-level stuff.
As a side note, I'm very interested in security. Does anybody have any very simple firewall code? (not so much antivirus.. although that is interesting). Firewall or any GameGuard/XTrap type stuff?
Thanks
Physical memory? No.
Virtual memory? Yes.
Just use a pointer to a specific address, but it won't work unless you've allocated that page you're trying to read/write to.
Oh I was hoping for physical memory. Thanks anyway
No, you can't access Physical Memory because that would severely bork the OS.
Thankfully virtual memory is implemented in today's processors, so even if you bypass the OS, you can't do it.
o_O "bork"?
I guess that'll work too. I just kinda thought creating files by scrolling through and editing HEX would be kinda cool
Yes, you can have direct access to the physical memory, just not with a user space application. It's a pretty advanced topic though, and the implementation is heavily dependent on what OS you are using.
It would be a major security risk. That is why this kind of code produces segfault -
as for accessing harddrive in bytes, in Linux, assuming you have root priviledge, you can just open /dev/hda (or the name of your harddrive) in binary mode. I am not sure how one would do that in Windows.Code:int a[10];
a[100000] = 3;
Actually, on a second thought, it is possible on Linux too, to access physical memory. Just open /dev/mem in binary. Again, you will need root priviledge to do that. Not sure about Windows though.
I just tried "sudo head /dev/mem" on my Linux box and it workedQuote:
you can have direct access to the physical memory, just not with a user space application
In Windows, you must at least be in kernel mode.Quote:
Originally Posted by bithub
The thing about physical memory is that the OS works on virtual memory - giving X amount to each application and then mapping that into physical memory or the page file. All applications are sharing this. You can't just go in and write stuff all over the place - you'll crash the other applications, and perhaps even the OS itself!
Not all operating systems use virtual memory.Quote:
The thing about physical memory is that the OS works on virtual memory
From the guy's posts, it appears he is more interested in writing to hard drive memory, not RAM.Quote:
You can't just go in and write stuff all over the place - you'll crash the other applications, and perhaps even the OS itself!
That would be a rather poor operating system, if I may say so.Quote:
Originally Posted by bithub
It's possible to directly manipulate the bytes of the HDD, but you'll need hours just to look up and recalculate all the values that you have to change in order to create a real file without screwing everything up. (And during these hours, the OS will probably do some routine job, change a small thing and invalidate all your calculations.) Hard disks have an organization, you know.Quote:
I just kinda thought creating files by scrolling through and editing HEX would be kinda cool
True, very true. I just thought it'd be interesting.
There's nothing interesting about endless amounts of hex digits, believe me.
Any OS running off ROM would not have any virtual memory (since there is nothing to page the physical memory to). It has absolutely nothing to do with being a "poor operating system".Quote:
That would be a rather poor operating system, if I may say so.
Yeah there is!! I love hex editing, and converting hex to assembler and stuff. I love doing math and stuff with hex, it's fun!Quote:
Originally Posted by CornedBee
I'm a nerd, I know =P
If you really want to access memory and look at it because you think it would be 'cool' then create your own array, fill it with data, stream to std out, and enjoy. If that's not 'cool' enough for you then you probably are interested more in something we do not condone on this board. Well behaved programs don't go poking around in memory they do not own nor do they attempt to access the hard drive at a low level. Exceptions to the rule would be low level utils like defrag or Diskkeeper or some other utils. I highly doubt this is one of those exceptions.
You can access memory but only that which belongs to you and that which you have allocated. There is nothing exciting about ton of hexadecimal digits.
I'm not going to argue with you cause you can ban me. But if I were interested at the moment in lobbinb stuff like this onto other computers, I wouldn't be on this forum. It'd just be intersting to make a different interface into the hard drive, but not a really high-level one.
I'm a nerd. You're just a masochist.
A hard drive is a huge thing to look at. Load data files like PNGs or MP3s into a hex editor and compare their headers and general structure to the format descriptions, if that's your thing.
How is asking for direct access to the hard drive akin to a malicious program? To do so in Windows he would need to be in kernel space, and to do so in Linux he would need root access. This does not at all sound like a "hacker" sort of question.Quote:
Originally Posted by Bubba
I believe that as long as the drive isn't mounted, you can actually open a hard-disk for read/write as a raw device. Of course this excludes the boot-device, as that is definitely being mounted as part of the boot process. But if you have a disk that isn't being used by the OS, then you can [assuming you have sufficient [e.g. administrator] rights on the machine] open the drive itself for read/write, and use ReadFile and WriteFile to access the raw data on the drive.
Now why anyone would want to do that on a modern OS with a modern filesystem is a different story.
Of course, if you write your own driver, you can also access the hard-disk directly there - just bear in mind that if you mix this with OS accesses, God [or Satan, more likely, perhaps] only knows what you'll end up with, but it is unlikely to be anything good.
--
Mats
Perhaps because there is no full-blown driver for that particular filesystem available, and you want to read some files anyway. There are various tools to read files from Linux FSs under Windows (e.g. rfsgui for ReiserFS).Quote:
Originally Posted by matsp
Or because you want to write a userspace format utility.
Or because you want to draw a bit-by-bit backup.
Or ... you get the idea.
Sure, but it gets quite complex quite quickly.Quote:
Originally Posted by CornedBee
--
Mats
There's more OS's than desktop OSQuote:
Originally Posted by Elysia
I would recommend to pick up a book about driver writing for the OS you want to work on
I'll admit, I didn't think of operating systems for embedded and things.Quote:
Originally Posted by KIBO
First, I think people are gettign virtual memory confused with paging. Virtual memory is specifically when the OS uses mass storage to create the appearance of more memory than the system has physical RAM. Hence 'virtual' memory. It does this by marking unused pages as not-present in the global descriptor table or one of the local tables. The decriptor table entry is what maps the apparent memory location to a physical memory location, or to an external device. When the processor accesses a memory location the paging unit looks up the location in the descriptor tables, and if it is marked as present uses the value in the tables to access physical memory, if it is marked as not-present, then it causes a page fault, which the OS must handle. Usually this is done by paging a not recently used page to the pagefile, and paging the needed address block into physical ram, although there are other schemes.
They have a Union.Quote:
Originally Posted by CornedBee
Descriptor tables (in x86) are what describes memory segments, and although those HAVE a "present" bit that needs to be set for the segment to be accessible, it's not involved in "swapping to disk" [hasn't been that way since OS/2 1.x]. Most 32-bit OS's use only two segments, shared between EVERY process in the system [1]Quote:
Originally Posted by abachler
Paging and virtual memory are essentially, in a modern system, done by the page-table, where pages of 4KB at a time can be made present or not present. [2]
But paging is also used in conjunction with protection, such that each process has it's own page-table, so that only that process can access the pages that particular process owns.
Once paging is enabled, addresses within the processor [at least on x86] are considered "virtual", meaning that the page is accessed through the page-table. The virtual to physical translation can be linear or non-linear, where a linear translation is "direct", 1:1 between the virtual and the physical address. The non-linear, any virtual address can point to "any" physical location.
[1] Technicaly, there is a duplicate set of segment descriptors for when the OS is in the kernel, and perhaps also some other "administrative", for example a TSS segment to handle Double-Fault/Stack-Fault [in kernel mode] conditions.
[2] Some processors and OS's support "Large pages", where pages are for example 2MB instead of 4KB, which reduces the size of the page-table for example when having large shared sections of OS memory that is common between all processes, and thus don't need the small 4KB granularity.
--
Mats
Ah, that's what "Union FS" is all about :)Quote:
Originally Posted by indigo0086
--
Mats
It's not per se but there is a reason this type of access is a bit more involved than just using the filesystem. Unless someone is writing a low-level util or something there is never a reason to gain direct access to the hard drive.Quote:
How is asking for direct access to the hard drive akin to a malicious program?
Here is a snippet from the original post:
...directly access memory of a computer...Quote:
Is there ANY way using C, C++, and/or assembly that lets you directly access memory of a computer? Like the actual basic hard drive in bytes or something. ....
Yeah they are called variables and arrays. Why would you want to access any memory except that which you own or have allocated in a thread or DLL?
Like the actual basic hard drive in bytes or something. ....
First the memory bytes have nothing to do with the hard drive bytes (with the exception of virtual memory). You normally access the hard drive bytes via a filesystem that has folders and files. Low-level access is possible but rarely needed.
So the simple answer is we access memory every day in every program we write. If you are accessing files then you are accessing hard drive bytes.
Hence my suspicion.
Bubba, from what you quoted it's pretty clear to me that he is talking about hard drive memory - not RAM.
A hard drive is memory. Just because the data doesn't go away when you pull power doesn't make it something different.Quote:
First the memory bytes have nothing to do with the hard drive bytes (with the exception of virtual memory)
I agree, but it's still fun to mess around with. One of my first Linux projects was writing my own filesystem. It was tough to do, and simple by modern filesystem standards, but it was fun and I learned a lot. I see no reason to discourage people from taking on this type of exercise if they want to learn about how block devices work.Quote:
You normally access the hard drive bytes via a filesystem that has folders and files. Low-level access is possible but rarely needed.
I don't know if you should go as far as to call the hard drive a memory? DRAM, our typical memory, and hard drives are entirely different technology.Quote:
Originally Posted by bithub
even DRAM's are different though. Its still memory. storage in teh HDD is just non-volatile, as apposed to system memory which is volatile. Its still RAM, and hence memory. How it is accessed and the nature of the underlying technology is different, but so what.
I'd say that hdds are not RAM, because they require seeks and time for the platter to spin around.
Not all non-volatile data is stored on platter hard drives. What about flash memory for instance?Quote:
Originally Posted by robwhit
Flash is another different technology. Hard Drives I don't consider memory. Although flash is memory.
flash is non-volatile, maybe, but that doesn't make it a hard disk drive.Quote:
Originally Posted by bithub