Fixing the glibc adobe flash incompatibility

Richard W.M. Jones rjones at
Thu Nov 18 08:56:07 UTC 2010

On Thu, Nov 18, 2010 at 08:53:21AM +0000, Richard W.M. Jones wrote:
> On Wed, Nov 17, 2010 at 01:16:42PM -0800, John Reiser wrote:
> > On 11/17/2010 12:41 PM, Emmanuel Seyman wrote:
> > > 2) Issues found in proprietary software cannot be fixed by anybody except
> > >    the vendor
> > 
> > False.  In this particular case, it is possible to binary edit the plugin
> > so that all its calls to memcpy become calls to memmove.
> > The change is to copy the .st_name field from the symbol for memmove to the
> > .st_name field of the symbol for memcpy, which creates another instance
> > of memmove.   With that one 32-bit change, then the player will work.
> > Memmove can be a few percent slower than memcpy, but nobody will notice.
> Doesn't flash use some (in-)security scheme which involves
> checksumming its own binary?  I vaguely thought that was how the
> BBC iPlayer DRM works ...

I'm wrong here.  The half-assed scheme that they use is to take a
checksum of the SWF file:


Richard Jones, Virtualization Group, Red Hat
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.
See what it can do:

More information about the devel mailing list