Allow input to be programmatically passed to an interactive program without needing explicit support

[sly rover]

Note: The title of this feature suggestion might be slightly misleading as I was not able to phrase it properly due to title length limitations. Please read this message fully to understand what this feature suggestion is about.

Feature suggestion

Allow input to be programmatically (i.e. via GreyScript code) passed to a program without needing the program's developer to add explicit support for it (i.e. via custom objects).

Reason for suggesting this feature

Currently, most tools in Grey Hack are interactive (meaning that they use the user_input function instead of launch parameters to receive user input), it would be nice if there was a way for the user_input function to return not just input manually entered in by the player via the terminal, but also input passed via GreyScript code (if any). This would allow for more flexibility in automation.

For example, in real life, a command-line program usually expects input via stdin, this allows input to be programmatically (i.e. via code) passed to the program by writing to its stdin buffer. In this case, input can be passed to that program programmatically without waiting for its developer to explicitly add support for programmatically passing input to it.

What the end result of implementing this feature might look like

// A simple script (written in GreyScript) that automates the process of passing input to an interactive program (called 'interactive-cli' in this case) that receives input via the `user_input` function instead of launch parameters.

launch(
  "/usr/bin/interactive-cli",
  "",
  // A 3rd parameter could be added to the `launch` function that allows input that will be passed to the `user_input` function to be specified.
  "command-1\ncommand-2 arg-1\ncommand-3"
)

For further reference

Link to the starting comment of a discussion regarding this feature suggestion: #coding message

[sly rover]

On 2nd thought, I'm thinking that it might be better if each in-game process's input and output buffers could be exposed via the GreyScript API?

[half pebble]

i think this is a limitation of the underlieing scripting language... but i am iffy on that

[marble karma]

I get what you mean but if someone that was developing a tool with that function wanted this they could easily make it. Just check if the params table has indexes and if it has try to interpret them as a command for your tool. But well adding them more commands it wouldn't really work.... But like I don't really see the point of this.

[sly rover]

this feature suggestion is more so concerned with increasing flexibility of automation (via GreyScript) such that one would not need to rely on the original program's developer explicitly adding support for passing user input via code (instead of manually through the terminal) to their program

[marble karma]

Yeah sure I get that but like if you want automation then just write your own program....

[sly rover]

but tbf implementing this feature alone might not have as much intended impact since it still does not address other limitations, which is why i mentioned that alternatively each in-game process's input and output buffers could be exposed via the GreyScript API

[sly rover]

it saves time to call another program with the relevant input, let it do its thing, and optionally receive the relevant output from it instead of re-implementing the program again, sort of like how sometimes its better to just use an existing library instead of reinventing the wheel

unlike a library, a program can't just be imported into your script (unless you have access to its source code), so allowing players to do this would expand automation capabilities

plus the player wouldn't be tied to a single tool's (i.e. Viper's, Omni's) macro system (assuming that the tool even provides a macro system in the first place)

[humble niche]

exposing input/output buffers will require mutex locking in the interpreter since other processes can read/write to these buffers, this is extremely complicated to manage in a language like miniscript, if it was added on't expect something like this anytime soon

or at all

You can easily crash the interpreter

[sly rover]

i see, in that case, an alternative method of implementing this feature could be considered but would require a solid understanding of the game's relevant internals in order for me to provide a feasible implementation suggestion

where does the user_input function get its return value from under the hood? just asking in case anyone has looked through this part of the game's code before

[sly rover]

maybe an alternative approach would be to allow a GreyScript program to intercept calls to the print and user_input functions by passing callback functions (one that gets executed when print is called and another that gets executed when user_input gets called) as optional parameters to the launch function?

[humble niche]

once sec

[humble niche]

pPrint = @print
print = function(value)
    pPrint("x " + value)
end function

you can override intrinsic functions

close to function hooking

but you still have the memory space issue

[sly rover]

i'm aware of that, but what i'm suggesting is sort of similar to function hooking but for a launched program

so like hooking the print and user_input functions of a program launched using the launch function

[sly rover]

for reference: #coding message

[sly rover]

if a custom object (the one returned from the get_custom_object function) can be accessed from both the launcher process and the launched process, why can't a callback function be accessed?

[humble niche]

I know exactly what your trying to do, I doubt support for actual trampolining functions in a running process will be added

it's undefined behavior

However, making a launch script a child process, would allow sharing of memory

so both scripts share the same memory space

[sly rover]

the thing is that when you launch a process using the launch function, it runs synchronously (blocking the execution of the script that launched the process), so why would there be a multi-threading related issue here

[humble niche]

no the input/output buffers you suggest, have to be exposed

otherwise just use get_custom_object

[sly rover]

that's what i'm referring to, allowing a parent process to hook into the print and user_input functions used by its child process

[humble niche]

but your wanting to alter not just the state but the actual code of a running process

atm, from what I can tell every launched script has it's own process and memory

[sly rover]

i'm no longer referring to the input/output buffers i previously suggested, as implied by my previous message (which i'm replying to)

[sly rover]

yes but that would mean that the developer of the launched program would have to explicitly add support for passing input to the program via code instead of manually through the terminal, the purpose of this feature suggestion in the first place is to eliminate this dependency

[humble niche]

Would simply allowing scripts to return values, eg like functions solve your problem?

would like get_terminal_text be enough?

[sly rover]

launched programs can already return values in the form of strings, but this is not relevant to solving the problem that this feature suggestion aims to solve

[humble niche]

tldr, can you explain the problem again sorry

[sly rover]

the problem is that launch is a synchronous function that blocks until the entire program has finished executing, but the program might make multiple calls to the print function in which case the terminal output text will differ at different points of that program's execution

[humble niche]

You want async output to another program?

[sly rover]

i just want the parent process to be able to execute some custom logic when the child process (i.e. the program it launched using the launch function) calls the print and/or user_input functions

[humble niche]

You want to inject custom logic into a process/script you don't own, correct?

[sly rover]

i don't think so, because if a parent process launches a program (the child process) using the launch function, doesn't the parent process own the child process?

[humble niche]

can you give me an example of a use case

kinda having a hard time following why you would need this kind of complex logic

[sharp torrent]

So, because it's synchronous execution, you'd need the child process to have custom behavior on print/user_input, cause the main processes is blocked at those points. That "custom" behavior would need to be strictly defined by the game though. Allowing the launching script to just inject its own function into the launched script would have some pretty nasty security implications.

[humble niche]

You just reexplained everything we talked about, I wanted an actual use case

[sharp torrent]

Arcane hasn't been super clear if thet want custom functionality in the print, or just a way to later interact with it, without printing, so I was just explaining the security limitation of using a fully custom print implementation.

As for use case, I use it for handing off batch scan/deciphers to subprocesses so I can carry on with my business while they decipher, and just populate the main script as they finish. But that does hinge more on the usefulness of the multithreadding bit than the IPC

[humble niche]

Ya, this can be done via "shared memory" through files

create two files mem1.txt and mem1.lck

if mem1.lck is present then some script is using the resource

simulates a lock

so spin lock wait until it's not present

A string is also simply an array/list of bytes, so you can write ByteBuffers

in miniscript

so if players see mem1.txt it's just bytes

for ICP across systems, you can create services that allocates values on the global get_custom_object map

that's how alteast I do async process comm

[sharp torrent]

Yep. Everything talked about so far is very possible to implement already. The only issue comes from them wanting to do it with binaries they didn't write. Lol

[humble niche]

Ya, adding function hooking on scripts you don't own is going to be death for new players

[sly rover]

if the print/user_input function is only hooked during the call to the launch function, how would this be a security issue/liability?

if the player runs the program that's hooking the calls to those functions, then yes it could be a security issue (originating from user error rather than an issue with this feature), but at that point, whether the program hooks those functions would be the least of their concerns since the program could already do anything malicious without hooking those functions (since the player allowed the program to run on their in-game computer)

to be clear, what i'm suggesting currently is to provide a way (via the GreyScript API) for the parent process to be able to execute some code when the child process (i.e. the program it launched using the launch function) calls the print and/or user_input functions, the modified print and user_input functions should be restored to their original versions (i.e. whatever they were set to before the call to the launch function) after the call to the launch function ends

[sharp torrent]

If you can replace the child's print function with your own custom logic, it becomes a security problem, cause that's executed in the called scripts runtime, so you can just walk the whole global map and do naughty things to anything you might find (ie: coin objects, stored infrastructure shells)
If you're just replacing print with a pseudo stdout type deal, that's less of an issue.

[humble niche]

I still don't really understand what you would use this for

[sly rover]

as for the 1st point, unless the user runs the program thats injecting the custom logic into the child's print function, it shouldn't be a security issue since the changes made to the child process cease to exist once the child process exits (i.e. after the launch function finishes executing)

[sharp torrent]

prints state reverting after execution wouldn't matter, really. The damage is done during execution. You could insert a whole other tool into print, if you wanted.
Image I make a program for crypto gamblng that I distribute to others to play. Now, I'm going to store the coin object in memory to avoid the coin popup every time I wanna do an operation with it. Now bad actors can take my game, launch it with a program that writes custom coin stealing logic into print, and easily hijack the coin.

[sly rover]

i see, could this issue be avoided by running the parent process's callback function (that gets called when either print or user_input is called in the child process) in the parent process's runtime/context rather than that of the child process? i'm presuming that if the callback function is run in the parent process's runtime/context, it will not be able to access the child process's memory

[sharp torrent]

In theory, but that would presumably involve unblocking the parent process, which i would imagine would have other consequences

(tbc, I'm not trying to nay-say or anything, just explaining the technicalities)

[sly rover]

i see

[sly rover]

i get that and thanks for doing so

[sudden fog]

I want to chime in here. A very big issue I would have with being able to inject code into a script that was not specifically coded to allow it is it would make running a bank impossible (as Tanshy pointed out).

if you can just inject whatever code you want in 1337coins app, then everyone who banks there is hosed.

but if the change is only allowing user input to be passed, fine.

[sly rover]

although i forgot to mention this initially, the injected code was supposed to run in the parent process’s context instead of the child process’s context so that the parent process would not be able to access the child process’s memory via the injected code, however, implementing this might not really be feasible so that’s why i’m trying to figure out an alternative way to achieve the intended goal of this feature suggestion

[humble niche]

if you would give me a use case, an example of what you would use this feature for, I could help you figure out a workaround

[neat pike]

input = user_input(">")
while (input != "exit")
code
end while

[nova crag]

He wants to be able to send arbitrary user input to a launched binary that he didn't create, which doesnt support commandline params

[sly rover]

as nyx mentioned, a simple example use case (in relation to the overall goals of this feature suggestion) would be to programmatically send arbitrary input to a launched program that doesn’t support launch parameters and only receives input via the ‘user_input’ function (ideally without altering the code of the launched program)

[sudden fog]

So I was messing around with a way to remote control a 5hell session using a shared file. Works great until, dun dun dun, user input is required. So yeah, now I see a definite use for something like what you suggest.

Then I was thinking, "how can we make it safe." And I couldn't think of something that couldn't also be open to a hack.

And then I thought, let it be open to attack! There was already some wiff of a mention about process injection. Maybe get a shell on a system and inject into the Terminal.exe. The inject causing input to be immediately sent to that Terminal.exe (essentially injecting into bash. So if the target is on a user_input prompt when the attack is run, the attack enters the user_input. Would work wether the target is in bash or another script since bash would be a script by the time this were to be possibly implemented.

So like, instead of adding a way to alter how scripts that are already written operate, we change Terminal.exe to be able to be hacked and have input injected into it. A feature that would be both a utility feature, as well as an attack vector, just like rshells.

could make an entire object API around running processes. hackable like overflow attacks with different possible return values.

one could be a vuln that allows you to snoop user input into a process.

another could allow snooping output (prints)

and another could inject input

and another could kill the process (if it gets also the correct permission level)

[nova crag]

That sounds like a cool feature, I will just mention though, with the way terminals, user input, processes, and scripts interact on the backend, it may be extremely difficult or nigh impossible for something like that to be implemented. It was already quite hard for the new bash system to handle some of this stuff, and even with that there's still some issues with processes I believe

[sudden fog]

yeah, i tend to dream big.

lol

totally understandable. the terminal isn't a real terminal in the first place. so yeah, lots of work. maybe too much.

prototype

[nova crag]

Doing it with text files?

[sly rover]

what if each terminal had an exposed input buffer and an exposed output buffer?

my thought process was that since a terminal can only run one program at any given time, multiple programs accessing the same piece of memory at a time wouldn’t be possible

[humble niche]

you can override intrinisc functions, meaning you can create a pOriginal (Pointer to the function user_input) call that function from your script and simply re-call the pOriginal, this would make any attack mute

this is for input injection blocking

pPrint = @print
print = function(value)
    pPrint("x " + value)
end function

@sudden fog because you can do this you can actually just validate the first arg of user_input, and any vuln would be useless

[humble niche]

Not sure what you mean, the whole point I thought was to allow different processes to read/write to the input/output buffers, which you will still need mutexs too ensure your don't crash the interceptor or the game

[sly rover]

can an intrinsic function be overridden for a child process by the parent process?

[humble niche]

No because each process uses an isolated MiniScript VM

[sly rover]

i see

[humble niche]

They would have to run within the same VM

and not be async

[sudden fog]

hah, i just logged on to tell y'all i figured out a way to override user_input to return a value from a global list instead of executing the user input prompt if there are values in the list.

combining that with what i showed above, i can now remote control a session AND inject user input.

boom

[sudden fog]

yes

[humble niche]

You have to own the source/script though no, of the own being overriden?

[sudden fog]

yes. it is still required to be coded into the script.

so no altering other's scripts

which would be bad and i wouldn't support that

[humble niche]

Ya, but I think that's what Arcane wants

[sudden fog]

i couldn't run 1337coin if that were possible

yeah but that would be bad

[humble niche]

I agree

[sudden fog]

but alternatives would be good

globals.input_buffer = ["foo", "bar"]

_user_input = @user_input
user_input = function(prompt,is_pass)
  u_input = ""
  if globals.input_buffer.len > 0 then 
    u_input = globals.input_buffer.pull 
    if is_pass and typeof(u_input) == "string" then u_input = "*"*u_input.len
  else 
    u_input = _user_input(prompt,is_pass)
  end if
  return u_input
end function

[sly rover]

although the 2nd suggested implementation of this feature suggestion would effectively allow this (which i only realized at a later stage), this feature suggestion does not intend for other people’s scripts to be altered at will

[sly rover]

just curious, in that case, how does the custom object (i.e. the one returned by the ‘get_custom_object’ function) that can be shared (i.e. read from & written to) between a parent process and its child process(es) work?

[humble niche]

it references a C# map

eg an Dictionary

[sly rover]

and this map can be accessed by each Miniscript VM?

[humble niche]

yes, because it's in C#, it's memory is outside of the VMs

it's also managed outside of the VMs

[sly rover]

could each terminal’s input and output buffers be represented in such a manner instead?

[humble niche]

No, because get_custom_object's context is from the initially launched script, as the api docs say launching a script is blocking. the get_custom_object "dictionary" isn't thread safe

[sly rover]

i see, if there are multiple processes running in a terminal (not concurrently but just as a result of one process launching another process), does each process’s miniscript vm run on a separate thread?

[humble niche]

they run async

depending on impl it could be OS threads or coroutines

[sly rover]

i see

[sly rover]

to be clear about this implementation suggestion, its intended for a terminal’s input and output buffers to only be accessible by processes running within that same terminal and not processes being run from another terminal

[sly rover]

is it alright if you could elaborate on this? why is it alright for the custom object to not be thread-safe while it is not alright for a terminal’s input buffer to not be thread-safe?

[humble niche]

It's fine for it to not be thread safe because launching a script isn't async

and the values in get_custom_object are only shared between scripts when the initial script calls launch

[sly rover]

i get that, but wouldn’t only 1 process being able to read/modify its associated terminal’s input buffer at a given time (since launching a process is synchronous as you mentioned) negate the need for that buffer to be thread-safe?

[humble niche]

Ya, that's the point of the mutex locks, makes it so only one process can read/write to the buffers at a time

[sly rover]

in that previous question, i was questioning the need for a mutex lock since its not possible for more than 1 process within a terminal to be running at the same time due to launching a process being synchronous

[humble niche]

At that point your talking about arguments eg params

might as well pass the "injected" user input as params

[sly rover]

that would rely on the child process explicitly expecting input via launch parameters instead of the ‘user_input’ function, this was the reliance/dependency that this feature suggestion sought to avoid

[humble niche]

What you want too do is weird, cause your wanting to pass a value to user_input before user_input is actually called

[sly rover]

i suppose weird is subjective, but in a way yes that is the intention

the suggested terminal input buffer was intended to store both data manually entered by the player and data provided by the parent process

[humble niche]

but input is blocking, the script yields until input packet is received

[sly rover]

yep, so before blocking for manual input, the ‘user_input’ function could first read input data provided by the parent process (if any)

tbf the input data could just be passed as an additional parameter to the ‘launch’ function perhaps

[humble niche]

that's my point

[sly rover]

that was what was also suggested at the start of this thread

[humble niche]

either case, the owner of said script your providing input too has to now consider invalid input being passed by any other script

I wouldn't suggest or develop a system that places validation responsibility on every scripter

😒

[sly rover]

just to clarify, what invalid input could be provided by a parent process that couldn’t be manually provided by a player?

[humble niche]

In either case, you'll still need the owner to handle stuff

[humble niche]

private tools

[sly rover]

wdym by that?

[humble niche]

if my tool is private I cba to account for other peoples injected input

[sly rover]

to be clear, the input provided by a parent process would just be a string

[sly rover]

couldn’t the player just manually inject invalid input via the terminal?

[humble niche]

Just suggest too the dev a universal way to provide default input to user_input

as long as it's not provided to an already running script

[sly rover]

that was why passing an additional argument containing the input data as a string to the ‘launch’ function and the ‘user_input’ function reading from this argument fully before prompting for manual input was suggested

[humble niche]

Your solid then

[nova crag]

How would this solution handle multiple user_inputs in a script?

[sly rover]

if the user_input function is called with the anyKey parameter set to false, then the character(s) up until the next newline character will be read

if that function is called with the anyKey parameter set to true, then the next character will be read

[sly rover]

i'd appreciate it if you could leave a like on this feature suggestion if u're agreeable with it

[nova crag]

Right but what if user_input is called multiple times 😅 would it pass the same thing again?

Or you're saying it would keep a buffer of the string

and remove the parts it uses

[sly rover]

yep

maybe there would be an index that is incremented as characters are read from the provided input data

[humble niche]

Just use a stack and push/pop