PoTTY v0.63 RELEASED!

v0.63

On August 6, 2013 the PuTTY Team posted an update that included some pretty serious bug fixes.  You might recall that PoTTY never made it to v.062 except in a private build for my own use.  In fact, after my wife got sick in January 2012 (long story) it was left to languish just before it was ready to ship.

And in a few messages to brl I got the impression that obfuscated-openssh (which I like to call oossh) was something of a dead-end, since anyone who really wanted to stop you could just block all encrypted communications.

I had to agree.  But, hey, I don't live in $OPPRESSIVE_REGIME, and I still have a need to evade deep packet inspection and the bugs fixed in v0.63 seemed pretty bad.  And I know there are at least a few PoTTY users out there, so I decided to crank out a new version come Hell or high water.  And much to my surprise I nailed it faster than I thought I could.

At this time, the whole PoTTY Suite is ready to rock.  The final nail in the shipping crate remains to be hammered.  And that is the download page on mrhinkydink.com.  I want to whack that out this weekend and make it available by September 1st.

So this isn't an official announcement.  It's just a teaser.

Against my better judgement, I ran with Microsoft's VCE 2012 compiler.  V0.61 was made with VCE2008 (or was it 2005?) and the ill-fated v0.62 with VCE2010.  I figured "Why not?"  I soon learned why not and in the process had an epiphany on why Simon & the PuTTYnaughts still use VC++ 6.0: it's compatible with everything.

If I had my way, I'd still be using VC++ 5 (which I paid for in 1997).  But I never get my way.  That's just my karma.  The Universe hates my gutz.

So PoTTY works, but if you are using anything less than WINXP SP2 you will get a "not a valid Windows executable" error when you try to run it.  Nothing that VCE 2012 shits out will run on anything less than Vista unless you use a "Platform Toolset" of  "v110_xp" in your project's configuration.

That was disappointing because the default toolset (v110) seems to run a lot faster.

Seems to.

So if you're never looking back, you might want to recompile the whole damned thing in "pure" VCE 2012.  Do a benchmark.  Let me know what happens.  I ain't got time for that shit.

I'm only up to Windows 7, so I can't test it on Windows 8.  Maybe it won't run there either.  Dunno.

One of the hardest parts of upgrading (???) PuTTY source code to PoTTY is going through all the code and replacing "u" with "o".  For the most part this is purely cosmetic branding.  In some places if you do this you will break compatibility.  I think it's important to change the executable names, even if this breaks your scripts, but Pageant (Pogeant) needs to know about it.

The biggest compatibility break—had I done it—would have been making Pottygen create "PoTTY certs" instead of "PuTTY certs".  I tried.  Without that "u" in the cert file PoTTY and PuTTY are no longer interchangeable, and I want PoTTY to be able to function side-by-side with PuTTY.

In general, at least.

By changing pscp, psftp, and plink,  to oscp, osftp, and plonk you can't accidentally use the PoTTY versions.

I've never big a big fan of sftp, but in testing I discovered I liked osftp quite a lot, especially when the remote server is a cygwin oosshd server.  A lot.  Much easier to use at the command line than scp.  Great opportunities for data exfiltration there.

Which got me to thinking (again) about "WinoSCP", which would be an obfuscated version of WinSCP.

Also... 64 bit version?  Not sure.  I think I ran across a deal killer with that when I was working on v0.62.  That would be interesting, but the point of doing it eludes me.  If it ain't broke, et cetera.

And right now, it ain't broke.

UPDATE

Yes, it's out there.  Since the fork was solidly stuck into the code and everything was uploaded to the site, I tried to make a 64 bit version.  The first hurdle was to recompile OpenSSL for "WIN64A", which took quite a bit of dicking around, which included downloading the Win 7 DDK (I was missing "ml64.exe" for some reason).  Once that was finally done, I recompiled and it worked, but I'm not sure of what I have now.  I don't think it's "really" 64 bit, just some sort of mutant 64/32 bit code that won't run on a 32 bit system.

I still don't get the point.