posted on Aug, 18 2013 @ 07:55 PM
reply to post by ipsedixit
I haven't seen this done in particular, but it's just a set of files on a hard drive. If you know enough about how anything is constructed and have
access to the CPU outside of the operating system itself, you can do pretty much anything you desire. On the programming side, you would probably
want to write in assembly and use an assembler that does not enforce the operating system memory space and monitoring paradigm. An assembler like
this may be hard to find these days, but they are certain to be out there somewhere.
Then, when you are given the CPU (usually requested by an interrupt when I used to write stuff like this), your little program can do literally
anything you know how to do, understand the structure and protocols of, and know where the dedicated or shared memory is in terms of absolute
addresses (relative addresses might work, in some cases). Once you are outside of the operating system, the entire computer and all connected
hardware is yours and nothing but your own ignorance gets in your way. FYI: if you do something "bad" you can really screw things up too.
I used to write a lot of my own drivers for keyboard, video, mouse, and hard drives to enable dynamic debugging of software that was running that I
didn't want to disturb because the run times were very, very long (days in some cases). I'd go scan register contents, shared video memory, hard
disk buffers, keyboard buffers, printer buffers, etc. Generally peeking to see what was going on (monitoring) but occasionally poking new contents to
see how the program reacted. It's basically trivial to do, with the right knowledge and a little experimentation.
So, yeah -- it should be possible. If I were doing something like that, I think I would try looking for a spot on the hard drive to leave a file
outside of the file system (essentially lie to the allocation table). Then, when your little program begins running, if you want to expose it to the
operating system, you could just correct the allocation table. I'm not sure why you would want to expose a hidden user account though, except
perhaps to do something you don't quite understand yet or that takes too long to write in assembly?