[RES] RILPHONE.DLL and "how to" with a Radio - Touch Pro, Fuze ROM Development

I post this under the ROM dev for numerous reasons.
The Radio thread is scattered with confusing information about it.
You may wreck your phone by just copying it over the existing one.
There seems to be a requirement to be met by the ROM (patched NK.EXE if I recall right).
There seems to be a patch if NK is not patched by the chef.
Can one really explain what's behind that file and interaction with the Radio?
Admins, if you mind this post here either delete or move though I think it's ROM
related.

---

tyguy said:
I post this under the ROM dev for numerous reasons.
The Radio thread is scattered with confusing information about it.
You may wreck your phone by just copying it over the existing one.
There seems to be a requirement to be met by the ROM (patched NK.EXE if I recall right).
There seems to be a patch if NK is not patched by the chef.
Can one really explain what's behind that file and interaction with the Radio?
Admins, if you mind this post here either delete or move though I think it's ROM
related.
Click to expand...
Click to collapse
I can answer part of this.
The NK.exe must be patched to allow signed dll files to be added to the rom.
I have not heard of any way to get around the nk.exe patch. If there is Id like to hear it
It remains to be seen if the rilphone dll really makes much difference radio wise. However it does contain some carrier specific stuff in some cases. Da_G is more capable of explaining the technical details.

---

Thanks arupp I thought so too that there isn't a patch though one of the chefs had a comment on that
http://forum.xda-developers.com/showpost.php?p=3296537&postcount=794
I couldn't find it.

---

Thank you for starting this thread. I had searched everywhere for the Cmonex's autopatcher, but couldnt find it. Da_G also referenced it in the Radio thread here: http://forum.xda-developers.com/showpost.php?p=3229451&postcount=1012

---

so to patch or not to patch. That is the question.
Do i patch if i have a custom ROM?
Do i patch if i have the leaked version of the touch pro ROM official HTC (well almost) ?
Good thread thanks.

---

Found the thread Monx and Da_G referenced here: http://forum.xda-developers.com/showthread.php?t=384137
Post with patcher here: http://forum.xda-developers.com/showpost.php?p=2812111&postcount=23
Wtf??? i need to read the thread a few more times bc im still not sure what to do

---

Cmonex's autopatcher program is not really intended for the end-user, but more for the chef (it needs to be applied to xip.bin or os.nb.payload)
Her post says it might work directly on the .nbh before you flash it, but it's not guaranteed. I haven't tried it that way either - only directly on nk.exe inside the xip.
So, what you want to do is use the autopatcher directly on the .nbh - but again her post says it's not guaranteed to work.

---

Da_G thanks for chiming in!
So let me recap:
NK.EXE patch tool designed for chefs, not for Joe Doe users
No direct patch/fix for existing installation
Patch to be applied in ROM image NBH not Radio image NBH (---> hard reset)
Effects not really clear
From what I've read the rilphone.dll interacts with the Radio ROM and may be beneficial for reception and battery life but it's not proven that there will be a positive effect on the GPS for example (we all have lag ).
Furthermore, wrong ril... /Radio combo my make Radio unusable.
For GPS issues a NVRAM fix must be applied (early hardware boot-stage fix) which may not be even possible with the current ROM basis.
Conclusion:
Keep your hands off copying whatever rilphone.dll files are flying around in the Radio thread into your Windows dir and play it secure until the chefs figured it out BUT keep this post updated for general information.
Please tell me if I'm wrong.

---

tyguy said:
Da_G thanks for chiming in!
So let me recap:
NK.EXE patch tool designed for chefs, not for Joe Doe users
No direct patch/fix for existing installation
Patch to be applied in ROM image NBH not Radio image NBH (---> hard reset)
Effects not really clear
From what I've read the rilphone.dll interacts with the Radio ROM and may be beneficial for reception and battery life but it's not proven that there will be a positive effect on the GPS for example (we all have lag ).
Furthermore, wrong ril... /Radio combo my make Radio unusable.
For GPS issues a NVRAM fix must be applied (early hardware boot-stage fix) which may not be even possible with the current ROM basis.
Conclusion:
Keep your hands off copying whatever rilphone.dll files are flying around in the Radio thread into your Windows dir and play it secure until the chefs figured it out BUT keep this post updated for general information.
Please tell me if I'm wrong.
Click to expand...
Click to collapse
I can say the majoriity of custom roms have the nk.exe patched. If you dont know if your rom is patched ask your chef.

---

if you look at rilphone.dll in a PE viewer app, you'll see some references in the file to "AGPS". I think it's simply setting AGPS on or Off......or it might be more than that but I do see some references to AGPS in that dll (using the latest dll provided in the 5.05 release which is about 500kb in size)

---

I notice that my reception varies with different ROMs. I would say that I was getting the best reception with the 5.05 ROM and the 1.11.25.01 Radio. Then when I switched to some custom ROMs, things get a bit worse. The signal strength seems to vary more and I find the phone often switching between 3G and Edge or between Edge and GPRS/GSM. It keeps doing that even when I stay in the same place. I'll make a call with 5 bars of Edge and by the end of the call, be on GPRS when I didn't physically more. Or sometimes the phone will hang on to an HSDPA signal until I drop a call and never switch to Edge, which has 3 or 4 bars of signal strength once it finally does switch. I would imagine that all this switching to different signals is wasting battery too.
1) Could this be an issue with the custom ROMs rilphone.dll? I'm using EnergyROM 1.1a and 1.11.25.01 at the moment.
2) How can I know which radio version my ROMs rilphone.dll is designed to work with?
3) Does having that NK.exe patched allow me to just copy in a different version of the file with no adverse affects?

---

TheSopranos16 said:
I notice that my reception varies with different ROMs. I would say that I was getting the best reception with the 5.05 ROM and the 1.11.25.01 Radio. Then when I switched to some custom ROMs, things get a bit worse. The signal strength seems to vary more and I find the phone often switching between 3G and Edge or between Edge and GPRS/GSM. It keeps doing that even when I stay in the same place. I'll make a call with 5 bars of Edge and by the end of the call, be on GPRS when I didn't physically more. Or sometimes the phone will hang on to an HSDPA signal until I drop a call and never switch to Edge, which has 3 or 4 bars of signal strength once it finally does switch. I would imagine that all this switching to different signals is wasting battery too.
1) Could this be an issue with the custom ROMs rilphone.dll? I'm using EnergyROM 1.1a and 1.11.25.01 at the moment.
2) How can I know which radio version my ROMs rilphone.dll is designed to work with?
3) Does having that NK.exe patched allow me to just copy in a different version of the file with no adverse affects?
Click to expand...
Click to collapse
-----------------------------------------------------------------
Only NRGZ28 should be able to answer your ????
As he as mentioned in 1st page of thread "
This ROM is CE OS 5.2.20764 (build 20764.1.4.3) and the version is: 5.05.405.1 ,all from official Raphael ROM." using same build with which 1.11.25.01 radio is attached. Obviously it should have same DLL file if he has not altered it during cooking.......

---

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, [email protected] - 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!

---

Hi DA_g
Thank you Da_g for such a beneficial explanation....
I hope its going more complicated now..... as you have explained
"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."
all radios have Carrier-specific rilphone.dll's so obviously all its not only with 1.11.25.01 (Raphael radio) all other radio's i.e, for example .16,.19,.28,.32,.20 if so obviously the results would be not stable for all the users with different ROM's and Radio's.......... Now the big ? rilphone.dll should be programed for different carriers to the specific radio

---

The way it seems to work from my observations is this:
Carrier X issues a "ROM Request" to HTC, specifying what support and configuration they require (such as CNAP support for rogers)
HTC then assembles the ROM to their specifications, using the latest drivers, etc, available at the time.
All radio rom's seem to include support for all carrier-specific options, they just need a rilphone.dll that is aware of the particular option to enable it.
So for us to get a newer rilphone.dll with rogers support (say, 5.05), rogers would need to issue a "ROM Request" to HTC, and they would need to fill it.. then we would have the rogers 5.05 rilphone.dll.
Using an older rilphone.dll has unknown effects (as it will not be aware of newer features in new radio version, etc) but so far has not shown to cause specific issues.

---

Hi DA_g
I need your help regarding this...how to edit rilphone.dll i am working as switch engineer for Ericsson india for GSM ...hope fully i would be able to understand some of the specifications present in this file.

---

Editing a .dll is beyond the scope of my ability to explain in a forum post, you need to do some research into reverse engineering and ARM disassembly..
Particularly, if this screenshot scares you: http://www.hex-rays.com/idapro/pix/idalarge.gif
You probably don't want to even get into it

---

Da_G said:
Editing a .dll is beyond the scope of my ability to explain in a forum post, you need to do some research into reverse engineering and ARM disassembly..
Particularly, if this screenshot scares you: http://www.hex-rays.com/idapro/pix/idalarge.gif
You probably don't want to even get into it
Click to expand...
Click to collapse
Ha ha ha really it is scary...............
But in my opinion individual Radio should be mapped to rilphone.dll with carrier specification with out this non of the radio would give best result .....
Depends on one using carriers with different frequencies for example.... i got tp with radio ver .28 (raphael) which is made for IDEA operator which uses 1800mhz freq, where power of the cell site & TP might be programmed vious according in rilphone.dll.....
i did SIM unlock.....Now i am using TP on Airtel operator which work on dual band 900 & 1800 so it is obvious that RADIO would not give me best results.
Results are vigorous ....dropped calls, voice break, poor coverage, poor battery performance,e.t.c................
So all ROM with associated with RADIO would work better on TP who uses specified Carrier...
Is there a way to get or create an universal rilphone.dll ?

---

Only someone with access to rilphone.dll source code could create a universal rilphone.dll.
Quite doubtful that HTC would be interested in doing this

---

aruppenthal said:
I can answer part of this.
The NK.exe must be patched to allow signed dll files to be added to the rom.
I have not heard of any way to get around the nk.exe patch. If there is Id like to hear it
Click to expand...
Click to collapse
I think you mean unsigned.
there is a way around... you import your own certificate into the device's trusted certs store and then sign the system DLL with your cert and copy it over... WM accepts this no problem and this is exactly how I used to do things.