4 ms·

Very nice post. However I thought it would be about writing programs that could be executed from OS, but OS would be completely unaware that such a program is r

Very nice post. However I thought it would be about writing programs that could be executed from OS, but OS would be completely unaware that such a program is running. Not sure if that is even possible. I know it’s possible to not use libc or similar, but os is aware of such a program.

cirosantilli 8y ago
It is not possible from userland, except for extremely serious zero days, due to hardware protections which OSes use, see: https://stackoverflow.com/questions/18717016/what-are-ring-0-and-ring-3-in-the-context-of-operating-systems/44483439#44483439 https://stackoverflow.com/questions/18717016/what-are-ring-0...
viraptor 8y ago
Kind of. Check out IBM's isostack. It takes CPU cores which are not used by the main os (you explicitly disable them) and essentially runs a parallel operating system which only handles the network cards / network stack. The main os cooperates with it, but otherwise it's not really aware of it.
pjc50 8y ago
A bit of thought about what it means to "run" gives you the answer here: in order for the code to run, it has to be scheduled at some point. That means it has to be in the operating system's task list somewhere. Having said that, there are places you can put running code that get scheduled but don't appear in an obvious way: inside other processes, as device drivers, as code on peripherals (GPU etc), or on the notorious management engine. Variations of these methods are used by viruses and exploits: the core of any exploit is getting code to run inside some other program that did not originally contain it. The final place is to put it "outside" the operating system as a hypervisor, then run the "normal" operating system as a seamless virtual machine inside the hypervisor.
0xcde4c3db 8y ago
I remember hearing that the PlayStation emulator bleem! did something like this for threading/timing purposes, essentially running its own microkernel and hooking interrupts to bypass the Windows scheduler. However, this supposedly worked by basically exploiting a bug in the way Windows 9x set up task switching and memory protection, and so didn't work on any NT-based Windows (or Wine, for that matter). Also, it obviously didn't try to hide the main program that managed the window and other I/O operations. Malware often has something akin to this as a goal, but as far as I know it usually works by hiding itself from the user rather than the kernel.
davrosthedalek 8y ago
In some way, this is what TSR (terminate stay resident) programs did under DOS. They were started by the OS, exited, but some of the code was still around as part of IRQ handlers and such. DOS didn't really know about that.
- finchisko 8y ago
  Yes, I had exactly this on my mind. DOS era.

cirosantilli 8y ago

It is not possible from userland, except for extremely serious zero days, due to hardware protections which OSes use, see: https://stackoverflow.com/questions/18717016/what-are-ring-0-and-ring-3-in-the-context-of-operating-systems/44483439#44483439 https://stackoverflow.com/questions/18717016/what-are-ring-0...

viraptor 8y ago

Kind of. Check out IBM's isostack. It takes CPU cores which are not used by the main os (you explicitly disable them) and essentially runs a parallel operating system which only handles the network cards / network stack. The main os cooperates with it, but otherwise it's not really aware of it.

pjc50 8y ago

A bit of thought about what it means to "run" gives you the answer here: in order for the code to run, it has to be scheduled at some point. That means it has to be in the operating system's task list somewhere. Having said that, there are places you can put running code that get scheduled but don't appear in an obvious way: inside other processes, as device drivers, as code on peripherals (GPU etc), or on the notorious management engine. Variations of these methods are used by viruses and exploits: the core of any exploit is getting code to run inside some other program that did not originally contain it. The final place is to put it "outside" the operating system as a hypervisor, then run the "normal" operating system as a seamless virtual machine inside the hypervisor.

0xcde4c3db 8y ago

I remember hearing that the PlayStation emulator bleem! did something like this for threading/timing purposes, essentially running its own microkernel and hooking interrupts to bypass the Windows scheduler. However, this supposedly worked by basically exploiting a bug in the way Windows 9x set up task switching and memory protection, and so didn't work on any NT-based Windows (or Wine, for that matter). Also, it obviously didn't try to hide the main program that managed the window and other I/O operations. Malware often has something akin to this as a goal, but as far as I know it usually works by hiding itself from the user rather than the kernel.

davrosthedalek 8y ago

In some way, this is what TSR (terminate stay resident) programs did under DOS. They were started by the OS, exited, but some of the code was still around as part of IRQ handlers and such. DOS didn't really know about that.

finchisko 8y ago
Yes, I had exactly this on my mind. DOS era.