interesting thing to add to your os

[unknown user]

my friend and i thought of a way to do something quite interesting. we call it "real-time hacking", and it's basically disassembling code from a running program and modifying it, and then running it from the relative breakpoint in a sort of "sandbox". when you are satisfied that it works ok, you can save the loaded program as a file, and you can have sandboxes inside sandboxes, like multiple vmware oses running inside each other.
what do you think?

[Tim]

Sounds like a debugger.

[Solar]

I don't see this as an OS feature, but rather a feature of an development environment.

[Pype.Clicker]

agree with tim ... there's nothing amazing in the approach, and i've been testing weird ASM code that way with tdebug for ages.
I'm not sure to get the advantage of "sandbox within sandboxes" ...

Moreover, you should keep in mind that the kind of approach you suggest will hardly work with high-level language.
I'd also like to add that needing to patch code while it is running usually proves the code has been written too fast. You'll fail to keep your invariant conditions and from hack to hack, you'll finally notice that your code doesn't do what it should at all ...

That's roughly why i dropped ASM programming (after about 5 years of practice) for my OS. Higher-level languages like C give you a better overview of what's happening, so that changing the code is clearer and introduces less bugs.

[Solar]

Moreover, you should keep in mind that the kind of approach you suggest will hardly work with high-level language...

...unless you have the source at hand and your binary has been compiled for debugging, in which case we're back in the development environment.

MS VisualC++ allows to make changes to the source and recompile without (usually) interrupting your debug session.

But with code compiled for release - i.e., with all the symbols taken out - you'll be in the land of uncommented ASM... :-\

[Pype.Clicker]

even if you have sources by your side and symbols info, etc.

and you see that

Code: Select all

   C++;

doens't do what you want to but that you instead need

Code: Select all

   C--;

it means that you'll have to re-compile the function (watch out for the optimized code), replace code, make sure it didn't change size, or move the whole stuff, etc.

nah, definitely, it doesn't sound practical.

Even in pure ASM, let's say you have

Code: Select all

inc al

and want to replace it with

Code: Select all

add al,2

which is one byte longer, you'll have to move the whole function code. What will occur to jumps offsets ?

[Tim]

Having said that, Microsoft has Edit and Continue working very well in Visual C++. They compile functions with gaps in between, generate special debug info, and apply the compiler's output to the running program image.

[bkilgore]

As long as the project you're working on isn't too large (i.e. 20MB debug executables) and the code you're editing isn't too close to the line that is about to execute, I've found the Edit and Continue option to be very helpful. Microsoft handles it very well and only rarely is there a problem where I need to restart the debug session.

[unknown user]

the thing about it is that it changes all the jmps and everything automatically. that's why i said "relative breakpoint". and it's os software because it's built into the kernel for kernel development. the point of the sandboxes is so that you can test newly compiled kernels without rebooting or switching your old kernel out completely, and so that if something goes wrong you can kill that sandbox and default back into your previous environment.

[mystran]

To sandbox a kernel one is likely to need an emulator, and having an emulator in a kernel... why not

Anyway, I'd first get the kernel to host the rest of the development environment...
Also you can get all the benefits of such a sandbox with things like VMWare, and for testing on actual hardware, such a sandbox is of limited use.

As for modifying running binaries, I might be interested in changing a value in the heap once in a while, but I'd rather restart the debugging session after each modification to binary.