[Galaxy Note GT-N7000 General] Entropy512:
To my knowledge, not without fully wiping the chip, including the bootloaders. This will turn your phone from "superbrick" to "traditional hardbrick" - which is at least JTAG-recoverable. However Samsung will not release the information required to do this, nor will they give Mr. Sumrall permission it seems.

Yeah. I have the explanation why, the problem is I have been asked not to share it by the source. I'm in the process of drafting a response to said source that includes a bit of yelling... It explains why the damage rate is different between stock recovery and CWM - however the damage rate for stock recovery, while lower, is nonzero.

PRESENCE OF THE su BINARY IN SYSTEM DOES NOT MATTER. IT DOES *NOTHING* WHEN YOU ARE IN RECOVERY. ONLY KERNEL AND INITRAMFS MATTER THEN.

You obviously don't even remotely understand how recovery works, such as the fact that everything in recovery runs directly from an initramfs image that is packed into the kernel itself. What is present in /system simply does not matter - if a brick happend with stock kernel and Samsung stock recovery, that is enough to prove that configuration is dangerous because the contents of /system do not matter. Especially not the presence of an su binary, considering that RECOVERY ALWAYS RUNS WITH ROOT PRIVELEGES!!!

Bull****. We know where it's located and how it's triggered. It's in the flash chip, it's triggered by ERASE commands sent to the flash chip.

Considering even the Google engineer that described the bug said it's intermittent, this isn't a surprise.

Please read before spouting utter and total bull****. It has already been explained by Mr. Sumrall why Gingerbread doesn't cause bricks - Gingerbread recoveries and update-binaries don't attempt to do wipe commands. That's how Chainfire has rendered recent CF-Root releases "safer" to use with affected kernels, and how CM9 has taken measures to reduce the chances of damage when flashing CM9 now that there is much more information about the bug.

And you clearly are completely uninformed if you think MMC_CAP_ERASE removal doesn't protect from damage - there has not been a single incident of the bug triggering from someone confirmed to actually be running a "safe" kernel. The one person who bricked after flashing Franco R3 with Mobile Odin never verified the flash before dropping into recovery - and MO is rather notorious for occasionally failing to flash.

It was never "explained" that erasing large files could also brick - it was just speculated in the early days before Mr. Sumrall provided valuable information about the bug. Erasing large files is safe because none of our file systems are mounted with the "discard" flag. (Yeah, I need to update the PSA in this regard, it's a bit outdated now...)

There are not two totally different source code bases to deal with internal and external storage - it's 90% common code. However the host driver is where there are differences, and the SDHCI host driver is only used for the external SD card and the wifi chip (SDIO). The internal storage is the MSHCI driver. The capabilities flags are in the source code for the host driver.

You're severely misinformed if you think we can't find a quick and reliable protection solution... Preventing ERASE commands from reaching the chip is semi-reliable if done in userspace, and 100% reliable if done by blocking ERASE attempts in the kernel. (I consider failures to flash a safe kernel in the first place not to be a failure of the kernel itself.)