Remember back in the daze of the CoCo (Radio Shack color computer)? No software needed, the display was easily mapped to any area in memory. Seems there is absolutely NOTHING to do this now. What i need is a program to read ANY arbitrary part of drive (Spinrte does this on an incremental basis) and do a one-to-one pixel display (byte value determines color - back to the CoCo). Program has means of user-control scrolling thru HD memory.
Dur, he said byte-per-byte... no compression, no encoding, raw.
Presumably also a 256-color indexed display mode, but even if it's quite large (e.g., VESA mode 011Ch: 1600x1200, 8bpp), that's only [just shy of]
2MB displayed on screen. Supposing you need at least a tenth of a second to decide whether any of those pixels are forming some pattern you're looking for (nonzero or otherwise), you'll flip through your entire 50GB HDD in about only 2 minutes. ;-)
Besides being tedious and ineffective, manual review of such a volume misses alternative circumstances: the HD's onboard controller can be compromised (the CIA is known to use this, and civilian hackers have demonstrated it before), hiding or leaking whatever it likes. If you're paranoid about wiping drives, there's only one true solution: thermite.
OK, how much video data is stored, uncompressed, on a hard drive? Given that there could be pretty much any known graphics device connected to the computer, I'd expect that there is damned little.
It could be done faster than that. There's doubtfully anything there.
Best tool for byte-snoop is HxD (i.e. best free tool). There are disk editors, but it's probably 17 years since I used one.
Blazing fast on a RAMdisk.
Meh, on a regular snoozer drive.
It's better than some other hex editors I've used, when searching for a pattern.
*******
You can open a single file and examine it. That's the normal usage for the program. But it will also open a drive for examination.
formatting link
It's not like one of the great (ancient) disk editors, where as you stepped over structures, it told you what you were looking at. Like "this is the FAT" or "this is the $UPPERCASE file". All that this editor gives is raw hex, so you'd better know your way around.
If the partition is NTFS, then nfi.exe can give LBA addresses, which must be added to the partition start offset, to figure out what stuff is. So you can, after a fashion, step into a file, get the hex address, do the reverse math, map to NFI output, and figure out which file it is.
But anyway, this is a freebie, and it's better than staring at the ceiling, wondering what's going on :-)
Remember that computers like you to be Administrator, when doing block-level access to disks. If you get "Error 5", that's "You're not the Administrator". That's the only gotcha that comes to mind.
Just be careful not to edit something by accident.
Even under 2k there's this program that's pretty nice and seems to be sort of in the same vein:
I'm really having a hard time thinking of what useful information somehow mapping all the gajillions of bytes in a mega-gigabyte hard drive could possibly provide.
To scan a terabyte at 2MB/frame, 10 frames per second, would take four and a half months without a break. After that, you wouldn't need your data anyhow, because you'd never have a sane thought again. Then again, perhaps Robert has already experienced that? :)
In many cases the video memory is on a different bus to the main memory. libSDL can give access to byte-per pixel display mechanisms, but you can't map the boot rom in and display it, you have to use the CPU or DMA to do that..
--
This email has not been checked by half-arsed antivirus software
That is because modern kit uses graphics accelerators.
There is a way to set or read individual pixels but it isn't often used.
Why on earth do you want to do this? Disk contents today are almost invariably compressed to some extent and will have high entropy. JPG and MPEG streams only the headers are distinguishable from noise.
Only the simplest of flat text files or prehistoric BMP files will have any discernable structure to the naked eye.
Who said anything about JPEG? I do not care about images, compression,etc ad nausea. JUST a simple byte read.
First, is the program to READ a selected part of the HD, and put the bytes in RAM. With that part available,i think i can do all of the rest. If the number of bytes read is controlled correctly (VERY easy), and one will have the layout of a BMP (not necessary) to use for some indeterminable crazy reason. The program reads from this byte array and sets an appropiate pixel on the screen, NO conversion needed. One-to=one mapping,i think that is called.
All i am trying to do is determine WHY dd diskwipe is a LIAR and get an idea what is left behind, as XP considers the drive to be formatted, labelled and have accessible data.
I know virtually nothing about Linux; would have to see which flavor to get,learn pain to set it up, etc. Then how to use this "frame buffer" to read the HD and figure how to get its data for display,etc etc. Much simper to forget the lies.
Looked at that and about a dozen others. Firstly they all ASSUME a formatted HD with some kind of directory. Now,*IF* dd diskwipe did it job correctly, there would be no formatting for starters. Since i have proven that dd diskwipe fails, it would be nice to see WHAT happened, and one cannot depend on a coherent file/directory layout. Hence none of those programs are useful.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.