To share one other piece of information...
Since I've met my disclosure requirement to HTC.
Fre3vo works by accessing the msm_rotator object, and requesting to do a 0-degree rotation from fb0 to fb0. This isn't a problem. The problem is, they allow you to specify a completely arbitrary, un-boundary checked offset into the frame buffer. So if you blit from around 0x3DBC0000 to 0x3FFFFFFF, you'll find the ro.protect value which allows is how we mimic psneuter. For the HTC Sensation, it's 0x2D000000 that you start from.
For someone with more time than I have, this exploit could be changed to elevate itself instead of making adb shell happen. The problem is, a shell account or greater is needed to access msm_rotator. If another exploit were found which got you a process in the graphics group, you could elevate yourself to root and remount /data to support suid.
Fre3vo^2 is really just based on mapping around /system. The reason the files are "vanishing" or getting stuck is because they're being purged by the OS to make room in RAM. Unfortunately, because the /system partition in write-protected by the eMMC, the write never completes, and the data is lost. When the OS tries to get it back, it gets confused and fails with the stuck file handles in memory. So I created a tmpfs and over-mounted on /system, and transferred all the goods to /data/fre3vo/system/... and used symlinking. It didn't work all that well, and I decided to spend my time focusing on S-OFF.
Currently, I'm trying to glitch the clocks on the eMMC to see if I can trigger a hard reset of the chip. We only need write access for exactly one page. I already have code which can talk directly to the eMMC, read a block, write a block, check the wrote protection states (They're all marked power-on write protect in the region we care about).
Thanks,
Kevin