Root ACER ICONIA TAB 8 A1-860 Cyanogenmod Development

a few useful commands:
(switch to root user in Android Terminal Emulator; assumes tablet is already rooted)
su
(backup ESP (EFI) partition in Android Terminal Emulator)
dd if=/dev/block/mmcblk0p4 of=/storage/emulated/0/esp.img
(backup BOOT (boot.img) partition in Android Terminal Emulator)
dd if=/dev/block/mmcblk0p5 of=/storage/emulated/0/boot.img
(backup FASTBOOT partition in Android Terminal Emulator)
dd if=/dev/block/mmcblk0p7 of=/storage/emulated/0/fastboot.img

(flash backed up BOOT partition from PC; image copied to current working directory of PC terminal; assumes tablet is booted into fastboot mode)
fastboot flash boot boot.img
(flash backed up BOOT partition from PC; image copied to current working directory of PC terminal; assumes tablet is booted into fastboot mode)
fastboot flash /dev/block/mmcblk0p4 esp.img

(switch to root user in Android Terminal Emulator; assumes tablet is already rooted; required for flashing)
su
(zero any partition 1 through 13, just replace X with appropriate partition number; from Android Terminal Emulator; OBVIOUS WARNING: never zero or flash anything unless you have a backup, and identified a way to flash that backup)
dd if=/dev/zero of=/dev/block/mmcblk0pX
(flash backed up ESP (EFI) partition from Android Terminal Emulator; assumes located in base of internal storage)
dd if=/storage/emulated/0/esp.img of=/dev/block/mmcblk0p4
(flash backed up BOOT (boot.img) partition from Android Terminal Emulator; assumes located in base of internal storage)
dd if=/storage/emulated/0/boot.img of=/dev/block/mmcblk0p5
(flash backed up FASTBOOT partition from Android Terminal Emulator; assumes located in base of internal storage)
dd if=/storage/emulated/0/fastboot.img of=/dev/block/mmcblk0p7

(reboot tablet into fastboot mode from PC; assumes tablet's USB debugging already enabled, etc.)
adb reboot-bootloader

(modify ESP (EFI) partition in Linux PC; useful before flashing modified image; always keep unmodified backup on both your tablet and your Linux PC; assumes image copied to current working directory of Linux terminal (e.g., base of your user home folder /home/your-name/esp.img ); mountpoint can vary by distro)
sudo bash
mkdir /media/loop
mount -o rw,loop esp.img /media/loop
chmod -R 777 /media/loop
(then you can add EFI images, etc., via file browser in folder /media/loop; you can safely remove/unmount via file browser as well after editing; size of all files combined must not exceed partition size of 64MB)
***WARNING: Do not modify ESP partition unless you have USB On-The-Go (USB OTG) with an external USB keyboard, and always leave a copy of the original 64bit EFI bootloader--even if it's renamed that's OK as you will likely have to manually select that EFI image to successfully boot, then flash backed-up original ESP partition from Android Terminal Emulator.***

The first priority is bypassing ACER's EFI bootloader security, because the A1-860 will only autoboot their bootx64.efi bootloader. Modifying bootx64.efi (i.e., in the ESP partition) in any way means no auto-boot. Messing with secure-boot settings in the BIOS is useless, because ACER's EFI bootloader security does NOT depend upon the BIOS's secure-boot. It is entirely possible to manually boot other EFI images, but that is only a very, very short-term solution (i.e., short-term because a USB On-The-Go (USB OTG) adapter with a USB keyboard is required to manually select a different EFI image). There is no point in compiling Cyanogenmod for the A1-860 unless it becomes possible to bypass ACER's EFI bootloader security to enable autoboot of other EFI images (e.g., another EFI image re-named bootx64.efi, but somehow the EFI checksum verification must be avoided; this is NOT BIOS secure-boot).

In the past, ACER has enforced verification of boot-related signatures in the 7th partition, and a few years ago someone created the 'itsmagic' binary to run each time a different boot image was flashed--thus bypassing verification via modifying the 7th partition. That is a problem for this tablet, because the 7th partitition is FASTBOOT and messing up the FASTBOOT partition leads to ONLY BOOTING IN INTEL's DnX mode. You need fastboot to reflash original partition images and the only way to fix it is to use a modified INTEL FLASH TOOL in Windows, which you can use to boot a backed up copy of your FASTBOOT partition. From there, you can then reflash partitions..... Not fun, it's a huge pain-in-the-butt! So, if anyone can figure out how to bypass ACER's EFI bootloader security, that would be awesome!

(bootx64.efi is attached, but NOT zipped--just rename by deleting .zip; it is useless to modify this file until verification of it is bypassed; this file normally resides in the fat32 formatted ESP partition, specifically in the /EFI/BOOT/ folder)
(original ESP, BOOT and FASTBOOT partition images are attached but NOT zipped--just rename by deleting .zip)
ESP --> /dev/block/mmcblk0p4
BOOT --> /dev/block/mmcblk0p5
FASTBOOT --> /dev/block/mmcblk0p7

Investigating UEFI boot options -- progress so far:
1.) secure boot is NOT enabled by default in the BIOS
2.) bootx64.efi in /EFI/BOOT/ folder of ESP partition is the default bootloader
3.) efilinux.efi in /EFI/Intel/ folder of ESP partition is A DUPLICATE of bootx64.efi, and efilinux.efi is the backup bootloader
4.) if you change the name of bootx64.efi, it will NOT autoboot
5.) if you manually select any valid EFI image, boot is possible (e.g., GRUB x86 EFI image or Gummiboot EFI image)
6.) if you manually select a valid but unofficial image named bootx64.efi, it will NOT boot due to the name violating security policy (e.g., you changed name of valid grubx64.efi to bootx64.efi)
7.) if you manually select an invalid image named anything other than bootx64.efi, it will successfully boot efilinux.efi (e.g., I hexedited bootx64.efi image to make it NOT work--hence an invalid image)
8.) if you rename efilinux.efi and manually select the renamed file, it will successfully boot despite having no efilinux.efi and no valid bootx64.efi image
9.) if you manually select an invalid image named efilinux.efi, there will be no backup image to boot from and it will NOT boot
10.) if you manually select a valid EFI bootloader image, it will successfully boot even when there is NO valid efilinux.efi image present
11.) setting a BIOS password and toggling secure boot on/off does NOT affect verification of bootx64.efi; verification occurs independent of secure boot setting and independent of any security policy related to the absence of BIOS password
12.) it is NOT possible to manually boot warmdump.efi in /EFI/Intel/ folder of ESP partition; manually selecting warmdump.efi immediately kicks you back to BIOS EFI file selection screen

INITIAL CONCLUSION: EFI autoboot is NOT possible until we figure out how to bypass verification of bootx64.efi. LEGACY BOOT is possible and would be our only viable course of action until bootx64.efi verification is bypassed. LEGACY BOOT is selectable in the BIOS, and LEGACY BOOT from a micro-SD card might be a safer alternative in the short-run than formatting internal storage MBR.

If MBR GRUB2 on external micro-SD doesn't play nice with directly chainloading an efi image on an internal storage GPT partition--for some reason--it might be possible to format micro-SD as HYBRID MBR/GPT and legacy boot grub2, then chainload grub2 Android x86 EFI on micro-SD. Then, that chainloaded grub2 Android x86 EFI image could boot GPT internal storage partitions without having to hybridize the internal disk. Gummiboot EFI might be a better option for chainloading, though. Dunno, just an idea. https://wiki.gentoo.org/wiki/Hybrid_partition_table

I have a modified version of Intel Flash Tool that I found online, and, previously, I've utilized it boot a backup copy of the FASTBOOT partition. This custom Intel Flash Tool is for Windows and I will post it later--after I've edited the XML files for the A1-860. Ubuntu Linux also has an Intel Flash Tool, but that one is not customized and did not work for the aforementioned purpose. As for flashing, well, as far as I know, to flash with it you have to be in Intel's proprietary DnX mode. One way to force the A1-860 into DnX mode (i.e., that I found by accident), is to flash an invalid boot.img and zero the fastboot partition; I am sure there are easier ways. However, DnX mode is not fun: at that point, without a customized Intel Flash Tool and a decent copy of Windows, your tablet would be near-bricked. Fastboot is safer for flashing, but you cannot re-partition with fastboot like you can with the Intel Flash Tool.

One more thing: you may have noticed that Acer does not yet provide a backup copy of the A1-860 stock ROM, but for some other similar tablets they post ROMs for download. So far, I have backed up every one of the 13 partitions, except for data and system. I can make a near-virgin backup of both and post download links in the future--in addition to posting all of the other partitions in this thread because they're way, way smaller. On a final note, I've installed MBR Grub2 to my micro-SD card, and may experiment (i.e., if I have time, today) with toggling legacy boot in the BIOS and chainloading the the stock EFI bootloader in the ESP partition, bootx64.efi.

BAD NEWS: Legacy Boot does NOT work with either the micro-SD or external USB drive (i.e., via USB On-The-Go (USB OTG)); I tried both with MBR Grub2. That sucks....

Conclusions:
(1) EFI might be the only viable route.
(2) EFI autoboot likely won't work until device firmware is modified. (I don't possess the electronics equipment to do what some talk about with other similar Intel tablets; one individual ended up soldering a connection on the system board and flashing firmware to toggle A SINGLE BIT!)
(3) Manual boot of other valid EFI images--as long as they're NOT named bootx64.efi--is completely possible, but also completely a pain-in-the-butt due to having to use a USB OTG cable in conjunction with an external USB keyboard.
(4) Hybridization of the internal storage's GPT partition formatting (i.e., hybrid MBR/GPT) might be the only route for legacy booting, but that is too risky for me to attempt at this point; it's a question of whether the potential reward is worth the considerable risk.

OK, I thought of another route for Cyanogenmod on the A1-860: it might be possible to sign our boot.img files. I have a LG phone that I use a python2 script, openbump.py, with, and I will investigate whether Acer uses something similar for signing. In sum, I will compare/contrast boot images to see if similar 'magic bytes' are utilized.

no luck....somebody else will have to see if there is some way to bump or sign the A1-860 boot images. LG used a magic number, but ACER appears to sign boot images differently. [NOTE: later identified Intel's stitching technique; see below]

Analia, just now I posted this to the A1 Root Section in Android Forums: http://androidforums.com/threads/how-to-root-a1-860.1014590/ I use Linux, so I can't vouch for the Windows method, but edotcom says it works for the A1-860, I guess. If it still doesn't work for you, I would try asking edotcom (i.e., http://forum.xda-developers.com/member.php?u=5478326 ). Good luck!

Back to boot images, from what I read of other Intel Android phones (i.e., likely tablets too), Intel has an image signing technique that is often referred to as STITCHING. Also from examining stitching configuration files for other Intel phones, it looks like they sign towards the very end of the image--if you're examining it in a hex editor. So, the A1-860 appears to have just such signing, but the A1-840 FHD does NOT (i.e., possibly too old). As yet, I have been unable to successfully boot modified boot images by copying the aforementioned area, and I'll keep exploring related techniques.
Something similar to this but modified: https://github.com/alan-shen/sign_stitch_intel
Example usage from above URL:
Intel Soc Images(logo/boot/recovery/droidboot) Signing Tool:
==========================================================

1.Put unsigned images to directory "./input";

input/
├── boot.unsigned
├── droidboot.unsigned
├── logo.bmp
└── recovery.unsigned

2.Exec the "sign.sh" script to sign the images in "./input";

# ./sign.sh

3.After Step2, you can get the signed&stiched images in directory "./output";

output/
├── boot.bin
├── droidboot.img
├── droidboot.img.POS.bin
├── logo.img
└── recovery.img

4.You can clean the middle and final output files use "clean.sh" scripts;

# ./clean.sh

[NOTE: THE ATTACHED ZIP NEEDS TO BE MODIFIED FOR THE A1-860]