Its usually been seen that if an executable is cated, provided that its a huge file, it keeps on changing the title of the 'PuTTYapplication until its done printing the binary to the STDOUT with those weird characters, prefixing strace did not seem to help in knowing.
What all goes on there, which makes this happen? Just curious.
As improbable as it might seem, PuTTY does this in response to a combination of characters.
PuTTY recognizes many (by no means all) of the escape sequences used for xterm, Linux console and some less familiar terminals. One of PuTTY's developers compiled a list of all of the ones that might be of interest, about 650 items. You can find copies here and there named "all-escapes.txt", beginning thus:
# This file is hoped to document all the escape sequences supported by
# terminals that are vaguely compliant with ECMA-48 and friends.
# Changes should be submitted to <bjh21@bjh21.me.uk>
# It includes everything from:
# <URL:http://www.cs.utk.edu/~shuford/terminal/dec_vt220_codes.txt> 1999-05-16
# <URL:http://www.cs.utk.edu/~shuford/terminal/vt100_reference_card.txt>
# 1993-02-01
# <URL:http://www.cs.utk.edu/~shuford/terminal/vt100_codes_news.txt>1998-09-18
# <URL:http://www.cs.utk.edu/~shuford/terminal/ansi_dec_controls_news.txt>
# 1999-05-16
# <URL:http://www.cs.utk.edu/~shuford/terminal/xterm_controls.txt> 1999-10-12
# <URL:http://www.cs.utk.edu/~shuford/terminal/color_control_news.txt>
# 1999-11-13
# ECMA-48 5th Ed. control functions (section 8.3, annex F)
# Linux console_codes(4)
# SunOS 5.7 wscons(7D)
# UnixWare 7 display(7)
# IRIX 6.5.5 xwsh(1G)
# VT220 Reference manual (<URL:http://vt100.net/docs/vt220-rm/>, EK-VT220-RM)
# <URL:http://vt100.net/ctrlseq_dec.html> 1999-11-24
# <URL:http://vt100.net/ctrlfunc_dec.html> 1999-12-01
# <URL:http://www.wyse.com/service/support/kbase/SEQwt.asp?Q=9> (wy75)
# 1999-07-19
# <URL:ftp://ftp.cs.cmu.edu/afs/cs/user/ralf/pub/rbcom346.zip#TERM-EMU.DOC>
# 1999-09-13
# <URL:http://www.itscj.ipsj.or.jp/ISO-IR/2-1.htm> 1999-04-19
# <URL:http://www.itscj.ipsj.or.jp/ISO-IR/2-2.htm> 2004-09-27
# <URL:http://www.itscj.ipsj.or.jp/ISO-IR/2-3.htm> 2004-09-27
# <URL:http://www.itscj.ipsj.or.jp/ISO-IR/2-8-1.htm> 1999-04-19
# <URL:http://www.itscj.ipsj.or.jp/ISO-IR/2-8-2.htm> 2001-05-10
# iBCS2 description in ESR's termtypes.master version 10.2.7
# Reflection Terminal Reference Manual for ADDS, ANSI, DG, VT, WYSE, and
# Unisys Hosts; Version 7.0; September 1998; published by WRQ Inc.
# DEC Terminals and Printers Handbook 1985 EB 26291-56 (Appendices C, E, and G)
# OpenServer 5.0.6 screen(HW)
# X Consortium Compound Text Encoding Version 1.1
For whatever reason, they disliked the notion of referring directly to the documentation for Linux and xterm, but used secondary sources.
The title strings recognized by PuTTY begin with one of these choices:
235)followed by 0, 1, 2, 21 (ASCII digits) or L,
a semicolon,
and the title text,
and end with one of these choices:
234), orAs an aside, it will stop processing the title escape if it sees an ASCII carriage return or line-feed.
While a "big" file might seem to be random enough, it's likely that your file contains some bias in the form of tables, etc. Otherwise it would not repeatedly update the title as described.
It might be interesting to construct a program which detected latent title-strings, so that you could find those without having to reset your terminal (or possibly stop it entirely).
Further reading:
console_codes(4) is right there on the list in front of us.
– JdeBP
Jul 24 '16 at 09:04
It doesn't show up separately in strace because it's an in-band control.
Outside PuTTY, this is often noticed as corrupting the prompt. Example: Fix terminal after displaying a binary file
They're called escape sequences - commands expressed as a sequence of characters, which start with the character "escape". clear is a simple example which uses them.
In-band controls can be considered a design flaw; it opens the door to serious problems. https://www.proteansec.com/linux/blast-past-executing-code-terminal-emulators-via-escape-sequences/ (More generally - early automated telephone networks used in-band controls for routing, which allowed control by hackers; see e.g. http://www.mit.edu/hacker/hacker.html).
It may help to remember that the full name for a terminal window is a "terminal emulator". Physical terminals do not really have out-of-band control. Physical serial lines pass streams of bytes (7 or 8 bit).
There's a single serial signal called "break". However the "break condition" is generally only used for one purpose. The way it's described, it sounds like it would take longer to transmit than a normal character.
(The design flaw could be resolved e.g. if non-printable characters were not passed through by default. Emulating a printer without additional controls. Compare inserting a paragraph of text into a HTML template: you need to handle the characters &<> specially to avoid them disappearing and being run as code).
Note physical serial ports have the disadvantage of not communicating the width and height of the terminal :). Physical terminals would be a set size, and I don't think they tended to implement any queries like that. Terminal windows implemented a workaround for this (they send SIGWINCH, which I assume is a signal to check some PTY extension). SSH has some feature that passes this on too. Interestingly the telnet protocol's control for this is described as being in-band. This was done by defining a number of 8-bit codes. It assumes ASCII-only, i.e. is apparently incompatible with UTF-8. Source: How are terminal length and width forwarded over SSH and telnet?
What happens is that your binary happens to contain the escape sequence for setting the window title (in xterms, it's <esc>]2, I don't know if it's different in putty).
cat-ing the binary causes those bytes to be sent to the terminal, which then interprets and acts upon them.cat-ing a binary to a terminal is generally not a good idea. usehd(akahexdump) orxxdor similar if you want to see what's in a binary (in, e.g., a traditional hexdump format with hex byte offsets and bytes on the LHS and ASCII on the RHS) – cas Jul 15 '16 at 01:51