[HTC Wildfire S] no.human.being:
The actual flag might not be in NAND at all, but in some kind of special "one-time-programmable" memory.

I don't know of any method that could turn a phone that is truly Radio S-OFF, so either shipped S-OFF or xtc-clipped or unlocked by "Unrevoked Forever" (which I think does also Radio S-OFF, unlike the "normal" Unrevoked which does HBOOT S-OFF), back to S-ON. Even the DIAG tool can't do it, it can only turn S-ON to S-OFF, but it seems that once the Radio is S-OFF, there's no way back. This is unlike say HBOOT S-OFF that you can revert by flashing a stock bootloader either explicitely or by installing an RUU.

Not that you'd actually WANT to get back, but I think the fact that there's not even an OPTION provided in DIAG (which is an ENGINEERING utility, so there's no need to "hide" anything from it - they'd actually expose everything that's possible and I'd think that turning a phone back to S-ON after some kind of "repair" etc. could be considered useful by HTC's engineers) is a strong indication that the road to Radio S-OFF is actually one-way and would indicate that the secu_flag is stored in a one-time-programmable memory (PROM) device instead of NAND.

But it might actually be that we have overlooked something. I'm not even sure that we have ever analyzed the same phone before and after Radio S-OFF with the entire Radio area mapped. I think we only analyzed "misc" of the same device before and after Radio S-OFF, since we didn't know about that hidden partition at that point, and later, after we knew about it, we only analyzed different Radio dumps from different devices but never of the same device S-ON and S-OFF. So it may be in NAND. I'm just saying that there's the POSSIBILITY of the flag not being held in NAND at all.

EDIT: Btw, something a bit different I've pondered about for the last weeks and come to a bit of a "conclusion", even though it's rather not an exciting one. There are "development boards" for development and engineering purposes that feature OMAP (which is the ARM processor line of Texas Instruments, which by the way seem to be locked down even more than Qualcomm chips, even though I think the protection has been broken, at least partially) processors and all sorts of wired and wireless interfaces one can think of. These boards are highly-integrated, based on 4-layer PCB designs and SMD, yet they would be far too large to build into a handset because of their rich supply of peripherals. The "development versions" of the OMAP SoCs that are used on these boards ship with completely open firmware featuring UBOOT as the bootloader and a very minimal GNU/Linux as the stock OS (not that you'd really work with that, they probably just didn't want to ship the platform in an "empty" state) and the board is equipped with JTAG headers, interfaces for cameras, sensors, gyroscopes, extension memory, peripherals and all sorts of configuration and diagnostics stuff. Basically they are designed to expose and showcase the entire functionality and range of applications covered by the OMAP SoCs. Anyone can buy such a board, they are freely available on the market, even though they cost a chunk of money (about 300 - 400 $ for "recent" designs like a Cortex A9 dual-core) and you have to wait quite some time after placing an order, since TI seems to be processing a huge backlog of orders when it comes to their OMAP product line due to the huge demand by the market.

However, this is a relatively easy way for anyone wanting to "fake an IMEI" (whatever use that would have, since your identity on the network is obviously more bound to the SIM than to the device, though this is probably different for CDMA devices) or "disturb GSM/CDMA cellular networks or WiFi/Bluetooth/etc. connections" to do so, since both the firmware and circuitry of these "development version" processors is completely open, so one can actually use the SoC's DSPs to make the transceivers output any signal at any strength that they're electrically capable of, even though you might not be permitted to do so due to regulations. Obviously, these boards will not only run Linux very well, but also firmware designed for handsets such as Android, even though they won't fit in your pocket, so you're not gonna replace your Android phone with one of these devices. :D

So "preventing people from screwing with the networks" does not seem to be the motivation for locking the Radios down on the handsets, since there is hardware freely available on the market to be ordered by any person that ships completely unlocked, albeit more expensive and targeted more towards engineers than the average user. So the reason for locking the "consumer" devices down must have something to do with protection of intellectual property. The SoC designers seem to have some "special sauce" in their proprietary firmware that they don't want their competitors to fiddle around with, even though I'd argue that today we can expect the open firmware to be at least on par, so actually they're hiding what's not really worth to be hidden. Who would want to use HBOOT when they can have UBOOT? Who would want to use Qualcomm's Radio when they can build an open Radio stack from source?

So if anyone has some money to spare, grab an OMAP development board. These things actually look very fun! The top-line boards feature about half a gig of RAM, multiple (up to 5) USB ports, one or two DVI-outs, analog Y/C video out, line-level audio in/out, RS232 serial interface, Ethernet, MicroSD slots for lots of storage, LEDs and hardware buttons for diagnostics and lots of pin headers exposing GPIO and busses like I2C, SPI, as well as some "special purpose busses" for connecting other stuff (like microphone arrays, cameras, gyroscopes, LCD panels, ...). Some versions of OMAP are multi-core processors in the GHz range. Such a thing might actually outperform a netbook, while drawing only a fraction of the power (the OMAP processor comes in a very small physical package and requires no cooling at all, not even a passive heatsink :D ). Building thin-clients from these boards actually sounds like a fun application. :D