[Verizon HTC Droid Incredible 4G LTE] CaptainRewind:
I tried the debugfs trick with no success. I studied all the methods described in the following threads as well. I even have a rooted TF101 and did some comparisons on the file structures, haven't found anything useful there.

http://xdaforums.com/showthread.php?t=1704209

http://xdaforums.com/showthread.php?t=1622628

I'm no debugfs expert, though, so I might have missed something. I was seeing permission denied when debugfs tried to get write access. I suspect this is because the system wasn't mounting the symlink target as R/W on boot like on other devices. I can try it some more if you have ideas I might have missed though... I still have all the binaries pushed via adb to the device to /data/local/tmp/ (which, on this device, is a folder where shell user can write; though, unfortunately, I can't move or rename the folder itself, likely due to parent permissions). All my symlink attempts have been to targets inside this dir since I can't find any others that will allow it. For example:

ln -s /dev/block/mmcblk0p33 /data/local/tmp/mmcblk0p33

If we knew a dir on /data that gives shell user or adb group enough permission to symlink to /system with write access, then that trick might still work. Only /data partition (or perhaps /cache or /devlog) will work since they are ext4... All other partitions are types that don't support symlinks.

On Ubuntu 12.04, I tried mounting partitions from the RUU. I can mount /system on my machine, but I still can't figure out how to mount /data outside of the device. I thought this might give me a way to list all contents of /data on a system where I have root already, and then I could try each one as a symlink target on the device. So far I'm not having luck with that approach... Anyone with more Rom knowledge know how I can do that? Ideally, I'd like to mount the ENTIRE filesystem for this device (/data in particular) from the RUU onto my Ubuntu system and poke around more.

On a separate type of attempt, I dug into some scripts inside the /system dir (from the RUU, but mounted on Ubuntu 12.04 so I can view everything). I'm looking in /system/etc/init.qcom.dsps_links.sh, line 77. I see that, if no results are returned trying to list /firmware_dsps/dsps*, then the system will be remounted RW long enough to create the symlinks. A similar case statement also exists in init.qcom.modem_links.sh, for the same reason (a check if links are missing, then a remount in RW mode to create them). How we exploit that is another consideration. Anyone know how we might take advantage of this? It seems like it will be difficult without (a) removing the symlinks, and (b) "pausing" the bootup process just after that step long enough to push su binary to /system/xbin. Since we would already need root to do either of those things, I'm not convinced this is even worth pursuing unless somebody has ideas I'm missing.

Any other ideas? One other I've been looking at is setting ro.kernel.qemu=1 in a file called /data/local.prop. This would make the OS boot as if it's an AVD, thus giving shell root by default. Again, you need to be rooted already (or somehow elevated, e.g. via some other exploit) to write this file, so maybe another dead end here.

Also, I'm sure I'm not the first to try this, but I've also checked all known exploits using the "X-Ray" app at http://www.xray.io/. Normally, I'd be quite pleased to learn that I'm patched against all those exploits. Unfortunately, not this time.

And then, of course, there was my attempt to use mempodroid (before I discovered X-Ray and learned that it's not vulnerable). The kernel version "should" support it, but they must have applied Linus' patch to their kernel before this device hit the market. I've suspected ever since that this was the reason the Fireball release date kept getting pushed back, but we can't know for sure.