Captivate .exe files Not playing due to Flash Player being blocked.

[sacrtc]

Our company publishes our Captivate files as windows executable files. These are not working now due to the EOL of Flash Player. We are moving to HTML5 (yes way to late but there is nothing that can be done about that now), but HTML5 is so very limited in what it can do. We have a lot of user interaction that will not work in HTML5 as well as custom navigation and such. Our stuff is not viewed in a browser. It is stand-alone or we have a custom LMS that we use. 

At this point the .exe files will not work but the .swf files will. We have Animate install so the theory is that is why .swf still work. 

Does anyone have an suggestions (be nice) of what software might be better for this situation? The owner of our company wants to drob Adobe all together, but I keep fighting him on it and so far have staved it off. 

[jeromiec83223024]

Modern versions of Captivate allow you to publish directly to HTML5.  If you have the original source Captivate documents, have you tried simply publishing them to the non-Flash target from a modern version?  I get that it doesn't address your LMS issue, but it might save you a lot of work.

We announced that Flash Player was going away back in 2017 in an effort to give developers plenty of time to migrate.  More importantly, that announcement was made in tandem with all of the major browser vendors, who are dropping support for browser plug-ins entirely around the same time.

Here's the original announcement from 2017, which also links off to the roadmaps for all of the major browser vendors:

https://theblog.adobe.com/adobe-flash-update/

We'd advise engaging with our support partner HARMAN to see if they can help you arrive at an interim option.  They have a lot of experience with helping folks to package standalone applications that require Flash support. 

As you can imagine, they're handling a high volume of requests, but are working hard to get back to folks in as timely a manner as possible.

There's some more information on HARMAN in the Enterprise EOL FAQ:

https://www.adobe.com/products/flashplayer/enterprise-end-of-life.html

Also, for Intranet applications, it's possible to configure Flash Player to continue to load content; however, if you're shipping to a large number of customers, each customer would need to deploy an mms.cfg to their environment to work around this issue.  Also, a future Windows Update will remove the ActiveX Flash Player from machines on Windows 8 and higher.  You'll definitely want to complete your migration before that happens.

[sacrtc]

The issue is that what was said, or at least the way that it was understood by our company as well as many others that I have seen post about this, is that Adobe was not going to support the player anymore. We were well aware that the browsers would not play them. We do not use browsers for this. We published as .exe files so they could work as stand alone's. Then Adobe blocked even that playing. That is far more than just discontinuing support. We are fully aware that Captivate publishes as HTML5, HTML5 does not have the interactivity that our modules require. It is quite limited in what will function. This was just a bad move for Adobe to block the player. I will worry about the security of my machine. These are not being posted online, they are just being run independently on local machines. Adobe has discontinued support on other software, such as Muse, but they still function. I used Muse just yesterday. Trust me, I am aware that we should have had something else in place, but I don't own the company and from everything that we read, and the owner read as well, it was only support that was going away, as well as the browsers not allowing it anymore. 

[jeromiec83223024]

I totally get the confusion from where you sit.  Captivate is one of hundreds of downstream products that happen to leverage some aspect of Flash technology.  There's no way that we could ever hope to track the individual implementation details for how each of those products used Flash (and multiply that over ~15 years of product versions released since the Adobe acquisition). 

When we as the Flash team speak about Flash, we do so from the scope of Flash Player (and sometimes Flash Authoring/Animate) as a product.  The Captivate team would have been best position to speak about implications of Flash EOL in the context of their product, but the general strategy for those applications was to remove dependencies on Flash between 2017 and 2020 and allow people to republish old content to modern surfaces where that was feasible.  The Captivate folks might also have more informed advice about your current predicament, and I'd recommend asking over in their forum.

That the EOL behavior is affecting your Captivate .exe files says that Captivate is outputting an executable that leverages the system Flash Player. My guess is that Captivate's application wrapper does more than just render Flash.  It's probably an embedded IE window that renders both HTML and Flash. 

This wasn't Flash Player or Flash Authoring generating a .exe (which is what we would be most familiar with from the purview of the Flash team), it was Captivate outputting it's own content to an exe, which also happened to include some Flash content.  Those are fundamentally different things in practice, but I totally get how that distinction is nuanced in the abstract.

Old-school versions of Flash Authoring published executables which were just a bundled copy of a SWF and a copy of the Flash Projector.  In that instance, you're not leveraging the system player -- the .exe has an independent copy of Flash baked in. 

I don't know about Captivate's .exe implementation details because we're not talking about a product I work on, but my guess is that it's leveraging an embedded IE window.  On Windows 8 and higher, Microsoft will eventually publish a mandatory update that removes the ActiveX Flash Player from those systems.  This will happen around summer.  At that point, even without the Flash "timebomb", those .exe files are dead unless your customers license a copy of the ActiveX Flash Player from HARMAN (which is not cheap) to continue using after that mandatory update gets applied.

In the meantime, it's theoretically possible that you could employ an mms.cfg file that defines the required dependencies, at which point Flash should allow those assets to load.  Flash Player's "time bomb" enforces the EnableAllowList feature by default.  This minimizes the risk that users will encounter malicious content (which is a bigger issue now that those installations aren't getting regular security updates), but does make affordances for critical applications. 

In your case, your options are pretty limited -- particularly on Windows 8 and higher.  Because you don't have control over the source code for the captivate output, you probably can't fix the underlying issue, and current versions of Captivate aren't going to invest in improving the ability to target a dead output format. 

My educated guess is that like many applications, the code in Captivate's executable is sending over file paths to Flash that Windows will automatically resolve, but that aren't RFC 3986 compliant.  Flash requires standards-conformant URIs because more ambiguous path representations lead to all kinds of traversal attacks that are impossible to fully mitigate.  In the context of a browser plug-in, incoming paths would be automatically normalized by the browser before calling Flash.  The result is that we're getting a path that "works" until we try to match it with an AllowListUrlPattern rule, at which point it fails the validation check and is effectively untargetable.  If this was your code, I'd tell you to do that normalization before passing paths to Flash, but you're stuck.

If your Win8+ users were licensing a maintained version of Flash Player from HARMAN, they would have a version that supports the EnableInsecureAllowListLocalPathMatching flag, which allows a lot of non-conformant URIs to match the pattern AllowListUrlPattern=file:* that might otherwise be untargetable.  This might work for users on Win7 with the latest generally available Flash Player build (and the only way that you could debug it is on Win7 with the Flash Player debugger installed and configured with TraceFileOutputEnabled=1 in mm.cfg). 

Working around the "time bomb" would buy you a couple months until Microsoft requires the removal of the ActiveX Flash Player on Windows 8 and higher, at which point, your executables will break unless those clients are licensing an ActiveX Flash Player from HARMAN.  (Because MSFT owned the installation path on Win8+, Adobe never published an installer for Win8+.  There's no way to reach back and get an old build.   HARMAN built an installer that will work once the Windows Update for Flash Player removal gets applied). 

[jeromiec83223024]

If you want to debug the application and try to work around it, it would be really interesting to know what URLs are getting passed in.  I wrote this for some of our support engineers to help with troubleshooting similar issues.  If you want to dig into this more deeply, it should cover everything you need, and has a good rundown on the current operational contexts.

Desktop Applications

In the early days of Flash Player, distribution of content on interactive CD-ROMs was common practice. This led to later practices of developers embedding Flash Player in desktop applications (typically by embedding an IE window) for more expressive User Interfaces. Flash remains popular for creating animated UI elements in specific scenarios, like HUD overlays in video games.

Ultimately, Adobe AIR (now EOL) became the supported platform for desktop application creation using Flash technology. In general, we’ve been actively discouraging developers from building applications that leverage the system Flash Player in embedded browser windows for the better part of a decade, but we try not to break existing applications.

In the context of Enterprise Enablement, depending on how Flash Player is leveraged, the application should be able to read and obey directives in mms.cfg. The challenge is around debugging, particularly on Windows 8 and higher, where the ActiveX installation path is controlled by Microsoft, and neither the latest builds or debugger variants of ActiveX Flash Player are available.

Where possible, the easiest way to debug applications that embed the ActiveX Flash Player is to do it on a Win 7 VM, with the debugger installed and configured for file logging (TraceFileOutputEnable=1 in mm.cfg).

Here’s more detail on configuring the debugger:
https://helpx.adobe.com/flash-player/kb/configure-debugger-version-flash-player.html

Once configured, you should be able to see the debugging messages when URL requests are blocked by EnableAllowList, just like you would in a browser. Depending on the bit-ness of the application and the version of IE that gets embedded, you may need to put mms.cfg in a different system folder than you would when targeting the browser itself (i.e. C:\Windows\System32 for 64-bit vs C:\Windows\SysWOW64 for 32-bit) folders.

In practice, what’s generally happening is that Flash Player requires valid URIs that conform to RFC 3986. In the context of desktop applications, those would most likely be local files, with the expected format of file:///c/users/foo/desktop/bar.jpg.

Instead, we’ve been seeing a variety of malformed values getting passed in. These are from a popular open-source project that uses Flash for graphical overlays in broadcast video (news chirons, etc):

*** AllowListPreview: AllowList blocks 'C:\Users\labuser\Desktop\CasparCG Server 2.0.7\CasparCG Server\Server\templates\\cg20.fth.pal'. ***

(note both the wrong format and double backslashes)

*** AllowListPreview: AllowList blocks 'file:///C|/Users/labuser/Desktop/CasparCG%20Server%202.0.7/CasparCG%20Server/Server/templates//CASPARCG_FLASH_TEMPLATES_EXAMPLE_PACK_1/ADVANCEDTEMPLATE1.ft'. ***

(note the old-school pipe notation for drive letters)

In these instances, there’s no way to target them with an AllowListUrlPattern directive, because they fail the URI validity check before we even get to the code that tries to match the pattern.

To work around this issue, we added the EnableInsecureAllowListLocalPathMatching directive, which effectively skips the validity checks, allowing AllowListUrlPattern=file:* to match on whatever you throw at it. If the operating system will resolve it, we’ll match it.

This opens a whole can of worms in terms of ambiguous URIs, which can lead to things like unexpected network store traversal via UNC path. Requiring RFC-conformant URIs is intended to solve those issues, but it became obvious as we got more input from the field that there was a class of legacy applications that were not passing in valid URIs.

Unfortunately, the addition of EnableInsecureAllowListLocalPathMatching landed in the December Flash Player release (32.0.0.465), which was after the last build that Microsoft shipped for Windows 8 and higher. Organizations that require this feature for the ActiveX Flash Player on Windows 8 and higher will need to license a maintained version of Flash Player from HARMAN in order to gain access to it.

[jeromiec83223024 · Accepted solution]

Also, you will probably want to check out the mms.cfg and Enterprise Enablement sections of the admin guide for details on what to put in mms.cfg, and where it lives: 

https://www.adobe.com/devnet/flashplayer/articles/flash_player_admin_guide.html

[sacrtc]

Thank you for the reply. Though I will admit that most of it went over my head and I didn't read every word. This explanation does make a lot of sense to me. Though I am still a bit disappointed that Adobe didn't account for this. Captivate is the bane of my existence and has been for a while. Thankfully we are moving away from it soon. 

I really appreciate the detailed answer and the amount of work you put into it. Thank you again.