[HTC Pico (Explorer)] no.human.being:
The file you attached appears to be the PBL.

I think you misunderstood how the exploit is designed to work. You're not supposed to modify anything at the APSBL. That is not possible since they use an EFI trusted boot chain. PBL runs first, loads SBL from NAND into mARM's RAM, checks signature of SBL, then passes execution to SBL. Then SBL loads L4/Pistachio into mARM and APSBL into aARM with aARM still on halt. Signature of both are checked, then execution is passed to L4/Pistachio, which boots on mARM. After L4/Pistachio has initialized, it releases aARM from halt, which then begins executing APSBL from RAM.

So far this is all authenticated since no code was modified. Now our exploit code gets transferred to aARM by APSBL via Fastboot. To APSBL the exploit looks like an Android kernel, so it loads the exploit code into aARM's RAM and jumps into it. The exploit then overwrites the APSBL in aARM's RAM since it's not protected there. Then it returns the aARM to the state it would be in if it was coming straight from a reset, but contrary to a "true" reset, only aARM is reset, so SBL does not run again so our modified APSBL that was put there by the exploit is now there instead of the "clean" one that's normally loaded there by SBL in a "clean" boot situation. The modified APSBL has signature checks disasbled and can thus install unsigned firmware.

APSBL's signature is only checked by SBL as it's loaded from NAND into RAM. Once this check has passed, we can use APSBL to load and execute code, that modifies the APSBL image in RAM and then lets aARM "reboot" from that modified boot code. The important thing is that we can reinitialize aARM without resetting mARM at the same time. If we were to do a "full" reset, the entire boot chain would run again and SBL would load the unmodified, signed APSBL from NAND into RAM again but that is not what we do.

So conclusion: On the MSM7225A you cannot write the modified APSBL to NAND and have it executed by SBL, since SBL will perform a signature check that the modified APSBL will not pass. BUT you can nonetheless modify aARM's boot code in RAM and then boot from that and that is what we do. The problem is that the modified boot code somehow notices that it's been modified and then either restores original boot code from RAM or simply causes mARM to go through the SBL again and thus have the original boot code restored, which we call "reverting".

If we have a debugging facility, we can let the handset execute normal boot into Fastboot mode first, then set a breakpoint to physical zero on aARM since this is where aARM's boot code lies, then run the exploit. The exploit will modify the boot code and then have aARM boot from it. As aARM boots from it, the breakpoint will be hit and we can inspect further where the "revert" happens.

Or we can trap aARM on physical zero straight away, as it first runs through APSBL in the normal boot chain and then dump its RAM and then not only restore the APSBL, but the ENTIRE INITIAL RAM CONTENT (SBL probably loads more than just the APSBL into RAM) and then have aARM go through the boot procedure again and our guess is that it then boots without "reverting".