Here's a bit more of a technical explanation for the whole thing:
rilphone.dll is the 'interpreter", or the "middle man" inbetween the Microsoft-desgined "Radio Interface Layer" or RIL - you can think of it as the Radio ROM speaks spanish, and Windows Mobile speaks english.. so when a program wants to do something involving the cellular radio, say, determining the signal strength to display the "bars", it issues a command to the RIL.. the RIL forwards this command to rilphone.dll, which interprets it into an AT Command. rilphone.dll then communicates through a standard serial port connection through SMD9: to communicate back and forth with the Radio ROM. Any responses are then translated again by rilphone.dll, and passed on to the RIL.
So, let's say a new command gets added to the radio. In this case we'll use a new command that was in fact added in 5.05, AT@AGPSFeature - if the rilphone.dll is not updated, it is not aware of this new radio command, and will never issue it to the radio ROM. So you'd potentially be missing out on whatever that command does. Also, if a change is made to the required format of some other AT Command, the rilphone.dll will not be aware of this change and still be using the old format.
Carrier-specific rilphone.dll's also have features that generic ones do not (such as the 5.05 rilphone.dll in the htc-branded build most custom roms are using) - one such feature is CNAP support for Rogers - it seems support is built into all radio ROM's, but if rilphone.dll does not have specific support for CNAP, it never reads the caller name into the registry for display on the dialer. There are a number of similar carrier-specific features i've observed.
That should cover the function of rilphone.dll and the reason you'd want to keep it on-parity with the radio ROM... and in some cases why you'd want to use an older rilphone.dll (to maintain support for CNAP, etc)
Now on to the nk.exe patch -
nk.exe is the "boot process" for Windows Mobile.. it brings up hardware to initial values and displays the radio/protocol/build version info on the intial boot screen.. nk.exe controls such low-level things as the size of the page pool, certificate checking, etc.
This is where the nk.exe patch comes into play.. it replaces the code that checks certificates with a "No Operation" - so the system now trusts all code installed, regardless of if it has been signed by a trusted provider or not - this is a good thing, as you control all code being installed on the device, rather than the OEM, and one would presume at the point you want such checks removed, you know better than the OEM
Without the nk.exe patch, when you replace rilphone.dll, the system checks it against it's internal certificate store, finds that it's not signed with a trusted certificate, and refuses to load it. This is why replacing rilphone.dll on unpatched ROM's results in no radio function.
Once you have a patched nk.exe you can replace any trusted file in the system with an unsigned file and not have to worry about the checks - note you no longer need sdkcerts.cab either as this is intended to load onto your device's root certificate store, and then manually sign the files you're replacing with the sdk certificates, then it would be loaded up as a trusted file.. however this doesn't work on drivers that are loaded early in the boot process, as there are 2 "states" of the certificate store - one early boot state where the drivers are loaded, where it's using a pre-defined set of root certificates (specifically sysroots.p7b in XIP, which contains 17 certificates from trusted root providers) - the 2nd "state" of the certificate store is farther on in the boot process, after drivers and services are loaded - this is when it would load in the sdk certificates and allow you to load manually-signed drivers. But again this is too late in the boot process to allow sdkcerts.cab to work for Drivers and Services - which is why the nk.exe patch is needed.
Note that any files/modules cooked into ROM are automagically treated as trusted, regardless of nk.exe patching status or if the files are actually signed with a trusted authority - it's assumed by Windows Mobile if the file is cooked into ROM, it must be trusted.
Incidentally, I believe this is the reason HTC created the "BootLauncher" service - so that they could load up services signed with their own stuff after creation of the ROM (patches, hotfixes, etc). Basically BootLauncher loads up during the services stage, and waits for a pre-defined period of time before then loading it's own set of services (wait time and services to load are defined in the registry under HKEY_CURRENT_USER\Software\HTC\BootLauncher)
the autopatcher searches for a string to replace, so it might work on the .nbh.. the feeling i get from cmonex's post is that she didn't design or test it against that scenario, but it might work
Hope that sheds some light on the situation, and isn't too complicated!
