It was an architectural problem, not an encryption problem. Even with AES instead of 3DES, the same issue would exist, which is spoofing the commands of any of the legitimate MSI services.
Is there a valid reason to use any encryption at all if you generally can't sniff the traffic unless you can also sniff the key, and if the key is arbitrary and not verified against anything?
AES is so cheap with hardware acceleration that I could see an argument that it prevents casual sniffing of the traffic. Personally I think the false sense of security would outweigh those benefits, but I'm not in their shoes.
But DES is so broken that it's more of a giant flashing beacon saying "look here there are terrible decisions being made!"
Unfortunately, WiX is still a pain in the ass to use and there's a lot of simple tooling that makes NSIS/InnoSetup/etc shockingly easy to use while the same MSI experience is garbage.
Didn't they discontinue those around VS 2015 or so? Its been a while since I tried. Iirc that's what got replaced with WiX and ClickOnce, both of which are 100X more complicated to use.
Nope, it is the other way around, MSI became the official replacement for exe installers, and MSIX is the evolution of APPX from UWP/Windows Store and the "best practices" format going forward.
By VS packaging tools I mean tbe application project type that generates a MSIX as build outcome.
For some reason, that holds an appxbundle per the article. I'd suspect they needed to run some pre- or post-install code (maybe to check for their hardware?).
It was formally deprecated in 2018 and has been surpassed in just about every single way by AES long before that.
At this point I feel like it's use is such a huge red flag