OK, I've read my post over and over and nowhere in this post have I asked for anything to do with fixing the ban, or how it happened, or anything of that nature. I'm not trying to be a smart-arse, just a little frustrated that this post has been on here for a very long time relative to how fast I've been helped before, and while I do appreciate your input, really I do, it hasn't addressed the issue which I will explain one more time. Keeping away from any other subjects in order to avoid confusion, what happened was I removed the HDD from my console (the model is slim cech something) anyway, the data on the HDD is fine. I have removed the HDD before, without a hitch. What I did next is where the problem comes. I took a totally different HDD and reformatted it so that it was clean. I put the current OFW on it, then I installed HEN version 3.0.3. I wanted to see if it would run HEN any more efficiently than my superslim. I ran into the same problems as before, even though it does run HEN quite well, I still was unable to get online with it. So, I removed the "test HDD" and replaced it with the one I removed that was loaded with all my homebrew and CFW. The console would not even boot up. Black screen. Nothingness. Several tries yielded the same result again and again. Can you tell me what happened and if it can be fixed? Please. Thanks.
Not every contributor has the knowledge necessary to answer all questions, people do what they can in their own time, they don't have to & sometimes it can be better to wait a couple of weeks for elaborate answers than immediately get a lot of advice that won't help you.
In any case, you can only get frustrated with yourself or potentially with people who may owe you something, I doubt that any of our contributors owe you anything therefore I see no reason for you to vent your frustration with us so let's move on on that front & put an end to any further argument.
Assuming I understood what you did, correct me if I am wrong, I think the problem is quite simple & not related to the hdd being uniquely registered or whatever.
HDD1 was removed with a 4.88 Cobra CFW installed on it.
Then
HDD2 was used to install HFW or in other words OFW (HEN makes no difference here).
So basically now the CoreOS files (lv1/lv2 etc..) stored in the NOR chip are OFW files.
So when you are trying to reinsert HDD1, it should not even try to load Cobra stage2, it loads an OFW kernel which cannot run the modified system files installed on the disk like VSH & the rest of it making the system crash before the XMB gets a chance to load.
If you had installed another 4.88 CFW on HDD2, you would probably not have experienced any problems swapping hdds which may explain why you didn't experience issues in a past hdd swap attempt, but in order to swap 2 HDDs with different firmware versions or like in this instance CFW/OFW, the situation is more complicated, the only possible way out is to use a tool like the PS3 Toolset to patch CoreOS before swapping HDD.
In your case, you would have needed to keep a OFW 4.88 ROS dump & a Evilnat 4.88.2 Cobra CFW ROS dump then use them as patch to apply the appropriate CoreOS with the Toolset whenever you change the HDD.
You could ask someone you can trust to do a good job to dump a Evilnat 4.88.2 CoreOS with the PS3 Toolset & send it to you so you can try to get back to your orignal CFW setup with hdd1 & see if that works OK.
Alternatively, it's quite possible that patching your CoreOS with the PS3 Toolset using the standard 4.88 patch would make it possible to start your console with HDD1 but I cannot guarantee it, neither can I guarantee the degree of risk involved for the HDD1 contents (no brick risk in theory though but system asking for hdd reformatting might be in play) in this operation.
It is all at your own risk as always..
I haven't really confirmed how well these Toolset based swaps would work out & whether or not other changes might be necessary to avoid hdd reformatting or whatever, because after numerous posts mentioning the possibility, there has been no interest at all for such a feature so far so I focused on other things.
That's why making/using custom ROS dumps as patch file are features only available in strict mode off in FMM, to make it clear to the user that there are risks involved in those operations that the Toolset will be unable to prevent.
Hopefully this post answers your questions & gives you possible options.