[yjftsjthsd-h]

> I'd figure out a way to get `sz` on to a host and exfiltrate data to my heart's content with ZMODEM like we did back in the day.

Probably as easy as `cat > sz` and then paste it over the wire? Maybe run through base64 first. Although actually depending on the situation you might be able to just do that directly and not bother with this? Like just as a super simple non-scientific test:

    $ ssh someserver cat /bin/ls > ./test-ls
    $ ssh someserver md5sum /bin/ls ; md5sum ./test-ls
    b3535289b2932e25650074aa6d89bf3c  /bin/ls
    b3535289b2932e25650074aa6d89bf3c  ./test-ls

That looks to work.

[jerf]

A related trick that can be actually useful is tar'ing on one side and untar'ing on the other: https://unix.stackexchange.com/questions/19804/compress-a-di...

scp is miserably slow on transferring lots of small files and this can be wildly faster, plus you get your choice of compression program based on what is on each side of the connection and what the bandwidth vs. CPU is.

[dublin]

In the early days of Unix (before rcp was a given), tar pipelines were a common way of moving ) from one machine to another on the network. It was a little nicer than FTP, not only because it didn't need an admin to set up the FT server, but also because you could transfer the files to any directory that you could cd to and had write access to. (And of course, tar made it easy to send a bunch of files and directories at once, too...)

[ogurechny]

This was a general idea back then terminal connections were physical. Small BASIC program (Your system does have BASIC, right?) or hex dump could be typed in to create a lowest common denominator bootstrap communication/encoding/decoding tool, which then could be used to transfer more complex program to the system. On DOS systems you could "copy /b COM1 file" (on a physical keyboard) or "copy /b CON file" (inside the terminal connection), then try to send data as is. If it was small enough, the line was clean enough, the settings matched, and the system was fast enough to chew it with one bite, it could work.

Here's an extreme example of such program consisting only of printable (and type-able) characters:

http://www.columbia.edu/kermit/ftp/a/tcomtxt.asm

(Seen on https://retrocomputing.stackexchange.com/questions/5202/tran... )

You can also notice the mention of bootstrap files in Kermit, and look them up.

I've recently seen some better known YouTube user doing exactly the thing we discuss on an old system (even including the consequences of accidental port setting mismatch), but, of course, can't remember the exact video.

Norton Commander, in addition to sharing files over serial or parallel port, was able to “clone” itself to another computer by sending a bootstrap loader the same way, then copying the rest. Hmm, the null modem cable pin connection chart in the readme seems to be a regular one (though without carrier detect pin), but the interlink/laplink cable is shown as 8 bit wide (though the thing should probably work with popular legacy 4 bit crossover):

https://rentry.co/nc50readme

[nullsmack]

In my DOS days, I used a simple text file that was meant to load into MSDOS' debug program to create a uudecode program. For things like laptops that came with MSDOS, nothing else, and no other way to load things on them. You could use type with a comport I believe to save the code to a txt file and then using debug create an executable binary. Here's one such program: http://www.u.arizona.edu/~shunter/uud.txt

Then I'd use type to save a uuencoded version of something like minicom on the laptop, use this program to uudecode it, and then use minicom to download anything else (Windows 95 install files?) using zmodem.