ISPProtect ionCube Loader dependency on ARM64

First off, kudos to the creators of ISPProtect; it sounds like a great addition to run on ISPConfig.
Unfortunately I'm having a bit of trouble running the trial on a fresh OracleCloud Ampere A1 ARM64 platform. Initially I got the following error:

Code:

Downloading ionCube Loader for your system.
/tmp/ioncube.tar.gz         100%[===========================================>]  11.95M  16.3MB/s    in 0.7s   
ionCube Check succeeded.
Failed loading /tmp/ioncube/ioncube_loader_lin_7.4.so:  
/tmp/ioncube/ioncube_loader_lin_7.4.so: wrong ELF class: ELFCLASS32

So I proceeded to visit get-loader.ioncube.com for install assistance and followed their manual directions for installation; I was able to download the correct binary for my platform (which is running Ubuntu 20.04 ARM64 edition); and placed the .so file in the appropriate libs folder. I then added the zend_extension ini snippet to mods-available and symlink'd them to their respect /etc/php/7.4/cli/conf.d and /etc/php/7.4/fpm/conf.d.

Both my phpinfo in my web browser and php -i on the command line show ionCube ini parsed and loaded with the paragraph indicating
"ionCube - Loader version 11.0.1".

Now running ispp_scan results in no auto installation; but still errors out with:

Code:

ionCube Check succeeded.
Failed loading /tmp/ioncube/ioncube_loader_lin_7.4.so:  
/tmp/ioncube/ioncube_loader_lin_7.4.so: wrong ELF class: ELFCLASS32

Warning: _il_exec((????): failed to open stream: No such file or directory in /tmp/v71/ispp_scan.php on line 2

Any ideas what's needed to run ISPProtect on ARM64 platforms? Does "ELFCLASS32" indicate a 32-bit binary that should be 64-bit? If that's the case, the suggested platform from ionCube maybe at fault. The uname -m for my platform definitely says "aarch64". Any clues would be appreciated!

 

Could be but why don't you simply try the 64-bit package since it is the 32-bit package shows you that error.

 

Sorry, I didn't clarify. I did try the 64bit installer directly from ionCube. That is why...

However, I did note that next to ./ispp_scan is an iconCube folder with suspect libraries in it; removal of the folder causes issn_scan to re-download what maybe the wrong libraries. Shouldn't the loaded 64-bit libraries in my php.ini take priority?

 

Please try the following:
Open the ispp_scan bash script and search for the line

Code:

echo "disable_functions=" >> ${DIR}/ispp_php.ini

Then add your loader line from global php ini to it like:

Code:

echo "zend_extension=/path/to/yours" >> ${DIR}/ispp_php.ini

The global php ini is mostly ignored due to issues with custom settings on many systems.

 

Okay, I found the problem; there is a bug in ./ispp_scan. Even with ionCube ARM64-bit
ioncube_loader_lin_7.4.so loaded into php.ini; ./ispp_scan fails to detect it and persists with downloading 32-bit drivers to the tmp folder and uses them.
I can "fool" ISPProtect by copying over the file.
This means I simply copy the installed, working, 64-bit ARM compatible file at
/usr/lib/php/20190902/ioncube_loader_lin_7.4.so to the automated download ispp_scan uses at /tmp/ioncube//ioncube_loader_lin_7.4.so.

I've already reported and linked to this thread on ISPProtect.com via the their contact page. I'll examine the scripts they are using to bootstrap; but I don't think there is a repo for pull requests.

 

Thank you Croydon; that appears to resolve the issue!