将非ASCII字符写入tty上progam的stdin(通过ssh) [英] Write non-ASCII characters to stdin of a progam on a tty (over ssh)

问题描述

我正通过SSHd进入具有一些二进制挑战的远程服务器.

I'm SSHd into a remote server with some binary challenges.

有一次它要求我输入文本.我知道它正在使用fgets()读取stdin，并且我可能会在将其复制到的地方溢出并覆盖附近的变量.

At one point it asks for me to input text. I know it's using fgets() to read stdin, and that I can overflow where it is being copied to and overwrite a nearby variable.

问题是我不知道如何键入所需的地址值，\x84和\x04等.如果能够使用bash，我会echo -ne "\x84"或使用C十六进制数组，但是我可以在这里不做那种事情.

The problem is I don't know how to type the address values I need, \x84 and \x04 etc. If I were able to use bash I would echo -ne "\x84" or use a C hex array but I can't do that kind of thing here.

我尝试使用十六进制到ASCII转换器并复制二进制字符，还尝试使用Expect脚本发送二进制值，但是两者都存在相同的问题. x84增加了一个额外的字符，而x04根本不会写.

I've tried using a hex to ASCII converter and copying the binary character and also using expect script to send the binary values but both have the same issue. x84 adds an extra char and x04 won't write at all.

有什么想法可以可靠地将值可靠地写入内存，而该值不能通过Unix tty上的ssh通过ASCII字符来表示?

Any idea the best way to reliably write values to memory that can't be represented by ASCII characters over ssh on a Unix tty?

推荐答案

对于高字符，您可能可以复制/粘贴.

For high characters, you can probably copy/paste.

例如echo -ne "\x84" | xclip -i，然后在您的终端仿真器中单击鼠标中键(如果您的桌面也正在运行Linux). (，也许不是，请参见下文).或者echo ... | ssh user@host可以工作.

e.g. echo -ne "\x84" | xclip -i then middle-click in your terminal emulator, if your desktop is also running Linux. (or maybe not, see below). Or echo ... | ssh user@host could work.

ssh -T或任何其他终端仿真器中的等效选项也可能是禁用伪终端分配"的选项，因此远程端的程序会将其stdin设为sshd的管道，而不是我认为是伪终端.我认为这会禁用^s和^v之类的东西.

ssh -T or the equivalent in any other terminal emulator might also be an option, to "Disable pseudo-terminal allocation", so the program on the remote side would have its stdin be a pipe from sshd, rather than a pseudo-terminal, I think. This would disable stuff like ^s and ^v being special, I think.

相反，echo foo | ssh -tt会强制其在远程端请求tty，即使您正在将内容通过管道传送到ssh.

Conversely, echo foo | ssh -tt will force it to request a tty on the remote side, even though you're piping stuff into ssh.

确保SSH上的二进制数据通过TTY层到达接收程序的stdin的一种较不打扰的方法是，在每个字节之前都添加一个control- v(十六进制0x16).

A less-intrusive way to make sure binary data over SSH gets through the TTY layer and to the stdin of the receiving program is to precede every byte with a control-v (hex 0x16).

是字面量下一个字符(stty -a输出中的lnext).您可以在有效负载的每个 字节之前使用它；接收器中的TTY层甚至在普通字符之前都将其剥离.

As Barmar points out, that's the literal-next character (lnext in stty -a output). You can use it before every byte of your payload; it's stripped by the TTY layer in the receiver even before ordinary characters.

# LANG=C sed to replace every byte with ^V byte
# using bash $'' to put a literal control-V on sed's command line
echo "hello" | LANG=C sed $'s/./\x16&/g' | hd
        16 68 16 65 16 6c 16 6c  16 6f 0a                 |.h.e.l.l.o.|

您可以通过键入hexdump -C(又名hd)在本地测试所有这些内容.只需在终端中运行它，然后键入或粘贴一些内容，然后按Control-D直到退出即可.

You can test all this locally by typing into hexdump -C (aka hd). Just run it in a terminal, and type or paste some stuff, then control-D until it exits.

$ echo -ne "\x01\xff\x99" | LANG=C sed $'s/./\x16&/g' | hd
00000000  16 01 16 ff 16 99                                 |......|
00000006
      # yup, correct bytes from sed
$ echo -ne "\x01\xff\x99" | LANG=C sed $'s/./\x16&/g' | xclip -i
$ LANG=C hd
^A��     (middle click, return, control-d)
00000000  01 ef bf bd ef bf bd 0a                           |........|
     # nope, that munged my data :/

$ xclip -o | hd
00000000  16 01 16 ff 16 99                                 |......|

所以X选择本身是正确的，但是在我粘贴时Konsole或从Konsole到hexdump的TTY层正在使它变绿?后者似乎不太可能；可能是粘贴问题. Konsole的编码"设置为UTF-8.它似乎没有简单的ASCII设置.

So the X selection itself is correct, but it's getting munged either by Konsole as I paste, or by the TTY layer on the way from Konsole to hexdump? The latter seems unlikely; probably it's a paste problem. Konsole's "encoding" setting is UTF-8. It doesn't seem to have a plain ASCII setting.

也许尝试使用LANG=C xterm之类的东西，或者只是正确编写脚本expect即可将实际的二进制数据发送到ssh，而不是转义代码.

Maybe try with LANG=C xterm or something, or just script expect correctly to send actual binary data to ssh, rather than escape codes.

fgets当然不处理转义序列，而strcpy则不可以.通常，C函数不会；但是在C中，编译器在编译时处理字符串文字中的转义序列.

fgets of course does not process escape sequences, any more than strcpy would. In general C functions don't; but in C the compiler processes escape sequences inside string literals at compile time.

这篇关于将非ASCII字符写入tty上progam的stdin(通过ssh)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！