Search code examples
rubysocketsasciitelnetextended-ascii

Sending non-printable ASCII codes (like 0x80) through bash and Telnet


I'm trying to send non-printable ASCII characters (codes 128 - 255) through telnet to a Ruby app using Socket objects to read data in.

When I try to send \x80 through telnet, I expect Ruby to receive a string of 3 bytes: 128 13 10.

I actually receive a string of 6 bytes: 92 120 56 48 13 10.

Do I need to change something about how telnet is sending the information, or how the Ruby socket is accepting it? I've read through all the telnet jargon I can comprehend. A point in the right direction would be very much appreciated.


Solution

  • 92 120 56 48 13 10
    

    is in decimal ASCII:

    \  x   8  0  \r \n
    

    So you are doing something very wrong and it's not the Telnet. The escape sequence \x80 was treated literally instead of being understood as single character of code=128.

    I guess you have used '\x80' instead of "\x80". Note the different quotes. If that was a single character, you can in Ruby also use ? character to denote a character: ?\x80 so for example:

    "\x80\r\n" == ?\x80 + ?\r + ?\n
    => true
    

    while of course

    '\x80\r\n' == "\x80\r\n"
    => false
    

    --

    To summarize long story from the comments:

    • originally data to be sent was entered manually through telnet terminal
    • telnet terminals often don't accept any escape codes and "just send" everything they got directly, sometimes copying&pasting a text with special characters work, sometimes terminals provide some extra UI goodies to send special characters - but this time the terminal was very basic and pasting it didn't work, and there was no UI goodies
    • instead of entering the data manually, sending a file through a pipe to the telnet terminal seemed to work much better. Some data arrived, but not good
    • piping the data to nc(netcat) instead of telnet terminal almost seemed to work, binary data arrived, but it was not perfect yet
    • after examining the input file (the one that was piped to nc) with hexdump utility, it turned out that the file contained not exactly what we thought, it seems that the editor used to create the file saved the text with wrong encoding, and it has added some extra unwanted bytes
    • finally, a utility called xxd helped to produce a good binary data from a tailored hex-text; output of xxd could be directly piped to nc (netcat)