Well, we still have no discovered why those "exotic" memory layouts exist. n.h.b. thinks it is because of a wrong mapping. But we can check if it is right.
However, yes, it is a problem.
Let's say nhb is right (we can investigate this step by step, if you want)
then you'd only need to change the mapping values and if we got the right memory area you'd be ok.
If there really is an exotic variant (which would be very suspicious) then we'd probably have to get behind it first.
@Bad-Wolf: Just do a "cat /proc/mtd" while booted into your ROM and post the output here. And tell us your RADIO and HBOOT versions please. We'll check whether the partition mapping matches anything we've seen so far.
If the partition mapping is "exotic", we could build a different set of kernel parameters for you with which you could check out the exploit again. It's currently available for downloading again
here, but it could really
brick (well, most likely not, since the mtdutils won't erase, but you never know
) when run with the "--disengage-the-safety" parameter supplied, so this not for the faint of heart.
If the partition mapping is "stock" and you provided the correct kernel parameters, but the exploit doesn't get through to "Done!" on your phone (you can also check this without the "--disengage-the-safety" parameter supplied, which will do the patching in "RAM" only and then discard it, so it's a good check whether it
would work that doesn't write to NAND and as such shouldn't brick), then the only reasonable explanation is that the HBOOT has "moved" within the Radio partition for some reason. To find the correct offset for your handset, we would then need a full dump of your Radio partition to search where the HBOOT starts inside the partition. However, as the Radio contains sensitive information (IMEI, etc.) this is just some kind of a last resort.
Btw, I have taken care to "safely dispose" of the Radio dumps that some of you provided in the early development phase. Thank you very much so far.