Related
Any brave soul try using mkrom in conjucntion with the 2003 ROM? I think I might give it a shot here in a bit but wanted to know if anybody had tried it yet...
I've managed to build a 2003 ROM. It's extremely tricky though. I'm working on customizing a ROM similar to the XDA Developers SER - as soon as I get some free time
I'd like to acknowledge all the help given to me by Developer Itsme in this endeavor.
Let me know any suggestions you may have for the new ROM.
sheran_g,
i didn't know u could use mkrom with 2003 rom image. can u please post how u did it? i created a special version based on SE 1.1 rom but would like to put the same programs into the new rom. any help is appreciated.
thanks
alex
sheran_g said:
I've managed to build a 2003 ROM. It's extremely tricky though. I'm working on customizing a ROM similar to the XDA Developers SER - as soon as I get some free time
I'd like to acknowledge all the help given to me by Developer Itsme in this endeavor.
Let me know any suggestions you may have for the new ROM.
Click to expand...
Click to collapse
What's tricky about it...?
The modified registry file you make does not get picked up at the device startup. You need to manually inject the memory address of the modified registry file into the ROM in order for it to get picked up.
my latest romtools can be found at romtools
now it calls dumprom to find and fix the filedata offsets.
I think they should now build 2003 roms.
sheran_g,
can u post the steps that u take to buid it? i'm trying right now and its not working. i'm having little problems. can u post ur default.reg and initobj.txt? any other help is apreciated.
thanks
alex
Ok. Here they are in a nutshell:
Get the latest romtools.
Make the following dirs: romfiles, cfg, tmp, out, files, files1, files2
Split the ROM into Bootloader, bootimage, OS image, xipchain into the 'cfg' dir.
Dump the files in the OS image into a 'romfiles' dir.
Get the default registry file, initobj & initdb files into your 'cfg' dir.
Make changes to your default.reg and initobj.txt
Place any files you want loaded in the ROM into the 'files' dir.
Run 'mkrom.sh'
You should then have your new ROM. I'm sorry if it's extremely brief; you'll have to make do with this and the README file in the romtools archive file for now. You'll find my default.reg and initobj.txt files on my site: www.zensay.com/qtek/mkrom
sheran_g,
Have you created a decent working custom WM2003 ROM?
If so what Apps have you added?
How much ROM space does it use?
I've not added any apps to my ROM. I have only added a carrier logo file and made some changes to the registry. So I cannot comment on ROM space yet. The ROM works fine.
sheran_g,
what command did u use to extract rom files? did u do it under windows or unix?
I'm having problems trying to dump the rom image. I don't know if its too much to ask, but can u zip ur directory and post it somewhere so i can download it? or if u can post commands that u ran to dump the 2003 rom?
thanks
alex
Hi,
could you include "O2 home zune" to the 2003 image, like in the 2002 3.19 GER. Its for Germany interested only!
AR :?:
home zone depends on specific 3.19 rilgsm features. which are not in 4.*
okay, used dumprom -4 -d files -q nk.nbf and extracted all files. Got could not find pointer for ofs 00000000 ERROR but all the files seem to be there. Trying to figure this out. Saw the above abreviated directions but am fumbling around. Anyone have concise directions?
Val
Anyone? Just give me a good hint then please.
Hi all!
When i overwrite the rilgsm.dll file in the t-mobile 4.0.10 image with the rilgsm.dll from the O2 GER 3.19 image, i could use the "O2 home zone" option with the hz.exe in Starup directory? rilgsm.dll from german image hes 'at+creg=2' string in it. probably the RIL_GetCellTowerInfo call is now implemented. When it can work, how could i write the german rilgsm.dll to the image? I haven't linux, could somebody cook the image for me?
here is the germen rilgsm.dll and the hz.exe for the "home zone" funktion! http://www.nokiaprog.de/XDA/home_zone.zip
THX
PS: Sorry, my english! ;-)
AR
the homezone enabled rilgsm.dll depends on other dll's and exe's.
probably ril.dll, stk.exe, cell*.dll and maybe more, I have not tried
replacing all.
you don't need to build a new rom in order to experiment with this, you
can just copy the desired files to \windows, to override the rom versions.
And I don't think it works with the RIL_GetCellTowerInfo call,
but adds some notification events.
to change the CREG setting you need to call RIL_DevSpecific with parameter 25 ( to turn it on ) or 26 ( to turn it off )
even though that does not seem to be how hz.exe does it.
Hi,
I opened the image file in the Hex editor and renamed the file there rilgsm.dll. Then I flashed the image, which was phone probably deactivated, because rilgsm.dll was missing. Then I copied over ActiveSync the German rilgsm.dll into the Windows directory, XDA reset and he not accept the file. I assume because the file was not in the EPROM memory! Therefore I wanted to have rilgsm.dll first times in the image!
AR
XDA developer Itsme said:
my latest romtools can be found at romtools
now it calls dumprom to find and fix the filedata offsets.
I think they should now build 2003 roms.
Click to expand...
Click to collapse
Is there any other way i can access this site or I can download this files, the sites are block here in my country, Please Help
Ronnie
Hi, I am trying to extract a file (actually, cplmain.,cpl) from a rom image. It all seems to work fine, but the size of the extracted file is lesser than the right one.
File seems to be truncated.
I did:
1) get the "B000FF" file (.bin), 24,856,907 bytes
2) Since dumprom seems not to "like" this format, I converted it using splitrom:
perl splirom.pl file.bin -wo file.rom
3) I don't know which format it generates to file to, but now dumprom works:
dumprom -d result file.rom > res.txt
4) A few snapshots of the file res.txt, regarding the file cplmain.cpl:
NOTE: section at fee73000 iso 00044000 for cplmain.cpl
806f5fe4 - 806f5ff0 L0000000c modname cplmain.cpl
8072d000 - 8076fe1c L00042e1c o32 region_0 rva=00001000 vsize=00042e1c real=02e61000 psize=00043000 f=60000020 for cplmain.cpl
80770000 - 8079e600 L0002e600 o32 region_3 rva=00048000 vsize=0002f000 real=02ea8000 psize=0002e600 f=40000040 for cplmain.cpl
808c7650 - 808c76bc L0000006c e32 struct 4 objs, img=212e entrypt=0000b408 base=02e60000 v4.20 tp9 cplmain.cpl
808c76bc - 808c771c L00000060 o32 struct cplmain.cpl
80a36870 - 80a36ff6 L00000786 o32 region_1 rva=00044000 vsize=00001800 real=01cd3000 psize=00000786 f=c0002040 for cplmain.cpl
80a4d0d8 - 80a4dffd L00000f25 o32 region_2 rva=00046000 vsize=00001ca8 real=02ea6000 psize=00000f25 f=40002040 for cplmain.cpl
80be2ed8 - 80be2ef8 L00000020 modent 20 00000005 01c3f9e1932529f0 486400 8119a000 cplmain.cpl
...............
5) Last line's "486400" is actually the *right* size of the file, but the real size of the extracted file (in directory "result") is 477,184.
I have not checked other files, since this is the one I am interested in.
Any idea?
Thanks in advance
XIP files would report incorrect size. Because they are XIP
If XIP files report wrong size (I guess you mean inside the very NB1 file), how can one fix this?
Spasiva!
I guess i am not using the same alignment of blocks in the reconstructed .exe file, as was used for constructing the rom.
it is not a really important issue, that the file is not exactly the same size.
there are also sections missing in the rom, that were in the original file, like the relocation information.
the main use of dumprom extracted modules, is that you can reverse engineer them with something like IDA. .. not that they are useful as real executables.
willem
Hi Willem,
Well the thing is that I need this file to be the right size. I agree that size is not important (that's what I actually say to my girlfriend ;-) ) as long as the extracted file's is greater, not lesser (which implies truncation) than the original's. The problem is that the file I got is smaller, so there is some missing data in.
Actually, I copy cplmain.cpl to the ppc as cplmain2.cpl, I do:
ctlpnl cplmain2.cpl,2 (for instance)
and it simply does not do anything.
Excuse my ignorance, but, what is IDA?
Dank u vel
IDA: http://www.datarescue.com/idabase/
you can't use a file extracted with dumprom on another device.
most executables and dll's ( and cpl's ) are fixed to work at a specific location in memory in one specific ROM. you can't use it on another device, it will most likely have a different memory layout.
willem
If you have two versions of the same DLL that are different only in code and data base addresses, you can restore the .reloc section and get a working DLL. I've wrote a simple program that when used with any relocation rebuilder tool would produce a working DLL. And even if DLL is not working, it is much easier to decompile it with IDA because it uses relocation information internally during analysis.
The DLLs should be exactly the same, for example they can be taken from the same ROM builds that differ only in language (of cause in this case DLLs should not be localized).
Hi all,
I'm an owner of FSC T830 Loox...
With the great help of bepe and mamaich I'm trying to cook my own rom... (thx guys, really!)
At the moment replacing even one module makes the device not to boot.
The problem is now upgrading the rom from aku 2.x to 3.x
As mamaich says newer AKUs have added new functions to coredll, therefore I need to port the XIP section...
I need help on this case:
I succesfully dump the XIP of my ROM
dump -o 0x00250000 myrom.rom xip.bin
dumprom -5 xip.bin -d xip
The question is: how can I port the XIP section from a newer AKU?
Thanks for all your valuable helps!
hi turchino,
do you find a solution for flash a loox t to a newer os version?
bg joy
Hi!
I'm also trying to port the xip section from a newer AKU to the T830.
It seems that none of the current tools is working correctly with that rom. Rommaster isn't working at all. Dumpromx can extract files, but not replace any (e.g. replacing a bigger file with a smaller ->not enough space...)
I've tried to manually replace coredll.dll in the t830 xip section with the newer one but it didn't want to boot. The strange thing is that t830's coredll.dll is much bigger than one from AKU 3.5.2. Any ideas about that? (maybe compression?)
I've also noticed one realaddr of a .pdata section from nk.exe is pointing out of the xip section?! (psize:00000000, dataptr:00000000)?
Also relocating a completely AKU 3.5.2 xip section to t830's base address and changing boot.hv isn't booting.
Any ideas how to get that running?
hey. bepe's xipport is designed for dealing with WM5/WM6 xip's.
with dumpromx you would need to increase the image file size by adding 00 bytes at its end before attempting to add anything. be careful, if the xip section grows too large then it may not fit in the partition in your nand flash....
also i'm not sure if it supports wm5/wm6 xip editing or just ce 4.x/wm2003/ce3.
rommaster is too buggy dont even try that one i think...
manual replacing isn't too tricky if you know what you're doing.... you need to know about PE header stuff. how did you try to replace it?
also, the new coredll should have the same base address as the original one or one that isn't conflicting with anything else.
did you make sure about that?
did you also edit romheader properly - because if this new coredll was larger than the original one the image is larger for sure and romheader needs editing.
don't forget about compression issues either. maybe that's why the original one is much bigger. but i would need to see the coredll's in question
anyway it is possible to do a coredll replace manually (did that before), no worries. but bepe's tool might make it easier
you say: "I've also noticed one realaddr of a .pdata section from nk.exe is pointing out of the xip section?! (psize:00000000, dataptr:00000000)?"
if psize is 0, then the .pdata section isn't really initialized data. it's a zero sized section and will only be existing when the loader loads the executable into ram.
but it sounds kind of strange to have a .pdata with 0 size, which file had this section?
edit: ok i see you meant nk.exe heheh. that's fine. it usually does have a zero sized section
you say: "Also relocating a completely AKU 3.5.2 xip section to t830's base address and changing boot.hv isn't booting."
how did you do the relocating?
xipport was the exactly the tool I was looking for. After a few modifications "realloc P" of the unmodified xip gave me exactly the same map.txt as the original t830 xip map.txt. After exchanging all kernel files (except hd.dll and osaxst0.dll which were needed to keep another oem file in the same location as it was before), reallocing and changing the header address in nk.exe it still isn't booting (it runs nk.exe but gets stuck somewhere in there). Maybe you can have a look at the whole thing (download here, with modified xipport)
As for the coredll, it turned out that dumprom missed a section.
I did the relocation by writing a little app which runs through all pointers and changes them, but this is also possible by editing romheader.txt from xipport.
ok I've changed the other dlls too (had the same size), but it still wont boot. Is there a kernelflag which I can set to get debug messages on the screen? Or do you know if the nandflash driver trueffs.dll from AKU2 is compatible with AKU3?
hey. sorry for the delay.
did you solve the problem yet?
if not, i'm going to check it for you soon.
about coredll. OK but how do you mean dumprom missed a section? i've never heard that before about it.
relocation: yeah, romheader.txt is the trick there. but, must be a nice app. i'll check it out (i see it's in the zip)
edit: OK i took a very quick look (i need to go now). the xips you uploaded have completely different romheaders and rom mappings (0x88xxxxx vs 0x80xxxxxx). what you said about relocation sounded like you already fixed that, but why did you upload this old version then? or did you upload original T830 and original AKU 3.5 from another device? i'd like to see your xip (that doesn't boot).
p.s.: did you make sure the hard coded romheader pointer in the kernel matches the romheader pointer/location in your xip ?
"edit: OK i took a very quick look (i need to go now). the xips you uploaded have completely different romheaders and rom mappings (0x88xxxxx vs 0x80xxxxxx). what you said about relocation sounded like you already fixed that, but why did you upload this old version then? or did you upload original T830 and original AKU 3.5 from another device? i'd like to see your xip (that doesn't boot)."
The xip in "xipport" is the modified t830 xip that doesn't boot. (btw. xip.bin in that folder is the original t830 xip). And the xip in "xipport aku3.5.2" is the xip I want to port to the t830.
The only success I had to now was getting the original wm5 aku 2.3 rom to run with the aku 3.5.2 coredll.dll. Is there anything else I have to do after I have replaced the t830 sys folder with an aku3.5.2 folder and building the reg/imgfs? Or does the kernel want to have some files at a specified address?
"p.s.: did you make sure the hard coded romheader pointer in the kernel matches the romheader pointer/location in your xip ?"
yep, the kernel always gives a me message when it has found the romheader and continues booting. Therefore I always know when I missed something
hey.
OK that sounds more clear now about which xip is which!
i'll look at it again soon.
until then: did you verify the copyentries are all OK? xipport sometimes has a silly bug regarding them.
easiest is to just delete hd.dll and osaxstxxxxx.dll - they are the ones that require copyentries apart from kernel. (kernel copyentry isnt screwed up by xipport anyway.)
but, they are not needed for a booting kernel, just debug stuff afaik. so deleting is easy..
btw, even if the copyentries are OK, using the wrong hd.dll/osaxstxxxx.dll will make the xip unbootable.
also pay attention to map.txt see if the base addresses overlap or not (usually not but worth checking), also if .data base addresses (the 0x01Fxxxxx ones) have not been changed. they should not be changed. another xipport bug sometimes.
new--->
update: i looked at your xip now.. none of the above seem to apply. i'll leave that stuff there though.
last thing i can think of is try editing physlast in romheader to point to last actually used byte in xip.. that shouldn't matter but who knows
can you tell me how far does your system boot. maybe the xip is fine and your IMGFS part is wrong. check for module overlaps.
what is last message you get from your kernel?
and, to answer your question about kernel wanting to have files at specified addresses. well, the kernel regions have to stay at the original addresses in the xip, except for the region that is copied out and for the discardable last region (same for the debug crap dlls)
Core_Z said:
"
The only success I had to now was getting the original wm5 aku 2.3 rom to run with the aku 3.5.2 coredll.dll. Is there anything else I have to do after I have replaced the t830 sys folder with an aku3.5.2 folder and building the reg/imgfs? Or does the kernel want to have some files at a specified address?
Click to expand...
Click to collapse
Hi Core_Z,
I'm trying to accomplish the same thing for our XDA Atom. I was wondering if you could describe how you achieve above. I, too, would like to replace the coredll.dll in our old AKU2.2 from the AKU3.X
These are the steps, I made using the modified XIPport (with realloc function):
1. coredll.dll comes from XIP of Atom Life which has same base address
2. replaced the modules and corresponding txt file into ATOM AKU2.2
3. new core is larger than the old one; so, I increase the ROMHDR.txt physlast to accommodate it.
4. realloc / write new maps.
5. move the rom header pointer in the nk.exe S000 module to the new one
6. built xip_out.bin
7. wrote the new bin to ROM image file
8. flash the device.
It won't boot. Did I miss anything?
cmonex said:
easiest is to just delete hd.dll and osaxstxxxxx.dll - they are the ones that require copyentries apart from kernel. (kernel copyentry isnt screwed up by xipport anyway.)
but, they are not needed for a booting kernel, just debug stuff afaik. so deleting is easy..
btw, even if the copyentries are OK, using the wrong hd.dll/osaxstxxxx.dll will make the xip unbootable.
Click to expand...
Click to collapse
Hello cmonex / core_z,
I followed this by removing the files you mentioned above. So, my current AKU2.2 XIP has the new coredll.dll from AKU3.X boots now. This means, that hd.dll / osaxstxxxx.dll is preventing my revised XIP to boot.
Question is: How do we restore this modules correctly?
Jiggs
I have another concern...
I have utilized the new XIP with new AKU3.X \SYS files, and rebuilt the ROM using the Scoter Kitchen. In the IMGFS section there is .ROM module wherein the ROM header is also described. However, there is one entry which is not clear to me... which is the e32_imageflags
The old AKU2.2 uses 0x00001e01, the new AKU3.3 uses 0x00002801. If I use the new values, the SDCard driver will not be loaded. If I use the old value, it will be loaded. What does this mean?
Now, because of this, after I build the ROM each time, I have to manually hex edit these values from 28 to 1e. Why? because not all entries of 28 has to be converted to 1e.
check this out Jiggs,
http://www.pxdxa.com/read.php?tid=40125&fpage=1&toread=&page=1
jiggs said:
Hello cmonex / core_z,
I followed this by removing the files you mentioned above. So, my current AKU2.2 XIP has the new coredll.dll from AKU3.X boots now. This means, that hd.dll / osaxstxxxx.dll is preventing my revised XIP to boot.
Question is: How do we restore this modules correctly?
Jiggs
Click to expand...
Click to collapse
hey! i'm back if you still need help: you dont need these dlls, they just take up space. if you really want them then you can do one of two things:
1) use the original dlls from the device's original xip
OR
2) rebase them but this can be more difficult than with ordinary dlls.
(i did not try either, because those dlls are just for debugging anyway.)
jiggs said:
I have another concern...
I have utilized the new XIP with new AKU3.X \SYS files, and rebuilt the ROM using the Scoter Kitchen. In the IMGFS section there is .ROM module wherein the ROM header is also described. However, there is one entry which is not clear to me... which is the e32_imageflags
The old AKU2.2 uses 0x00001e01, the new AKU3.3 uses 0x00002801. If I use the new values, the SDCard driver will not be loaded. If I use the old value, it will be loaded. What does this mean?
Now, because of this, after I build the ROM each time, I have to manually hex edit these values from 28 to 1e. Why? because not all entries of 28 has to be converted to 1e.
Click to expand...
Click to collapse
those values arent really e32_imageflags... i dunno why the imageinfo txt is created in that way for .ROM and .VM
thats to do with the imgfs memory space. probably the SD driver's image base is lower than the new imgfs memory space start address (which is what you were seeing)
to confirm that check the base address (e32 vbase) in imageinfo.txt for the sd dll.
cmonex said:
those values arent really e32_imageflags... i dunno why the imageinfo txt is created in that way for .ROM and .VM
thats to do with the imgfs memory space. probably the SD driver's image base is lower than the new imgfs memory space start address (which is what you were seeing)
to confirm that check the base address (e32 vbase) in imageinfo.txt for the sd dll.
Click to expand...
Click to collapse
Thanks for the info! I'll look at this later.
Here goes nothing: I've been trying to understand the whole porting process but no one ever posts on my threads, so I figured I'd post on this one since it's about the same thing. I'm reading the thread and I'm following... most... ok, half of it. I thought the process of porting the XIP and the SYS was as simple as well... this. If someone wants to correct me, by all means, please do so.
I'm having trouble modifying a string in tapres.dll.0409.mui. I've tried changing the string, even just one letter, in PE Browser and even hex editing.
I've tried signing the file with various different certs, but nothing helps. The file does not work when I boot up with it.
What am I missing here?
fluxist
Several things:
1) Were did you get the original file? The file may be corrupt to begin with.
2) You need to remove the signature (if any) before editing the file or it will be permanently ruined.
3) It is recommended to use Platform Builder to edit MUI files (you can download evaluation version from MS site for free).
Hope this helps.
levenum said:
Several things:
1) Were did you get the original file? The file may be corrupt to begin with.
2) You need to remove the signature (if any) before editing the file or it will be permanently ruined.
3) It is recommended to use Platform Builder to edit MUI files (you can download evaluation version from MS site for free).
Hope this helps.
Click to expand...
Click to collapse
I extracted the file from an RUU. I've been editing it with Visual Studio 2005.
I've tried removing signatures, when present. I've been using UnSigner for that.
It seems that even without editing it, just copying it into /Windows and overwriting the original causes the same problems. I've tried signing it with different SDk certs, also importing the certs to the device, and that doesnt help.
I read in a thread that you need a dll file with an intact PE header, so I've tried removing the resources from another dll and adding my resources to it, but that didn't work either.
Has anyone done this before who can chime in?
fluxist
You are correct about the PE header.
Strange, moving the resources in to a clean DLL should have worked.
Two more things I can think of:
1) What OS is the original DLL for and what SDK did you compile the clean DLL with?
For example WM 6 DLLs will not load on WM 5, and in some cases WM 6 refuses to use WM 5 DLLs as system MUI.
2) If you can, make a simple app that will call LoadLibrary and see if you get an error loading the DLL.
if there is an error it means the DLL is still corrupt for some reason, if not it is most likely some kind of signature / permissions problem.
MUI files usually have only resources.
You can try re-dump it using my ROM Extractor.
When you can try to edit it again.
Some editors rather often corrupt files.
Try different resource editors.
levenum said:
Several things:
1) Were did you get the original file? The file may be corrupt to begin with.
2) You need to remove the signature (if any) before editing the file or it will be permanently ruined.
3) It is recommended to use Platform Builder to edit MUI files (you can download evaluation version from MS site for free).
Hope this helps.
Click to expand...
Click to collapse
Can you guide me to Platform Builder download, i have tried to search for it, even on MS site, and i found sdk stuff, not a debug software that can edit MUI.
So, please, help me...
I recently got into cooking my own personal ROMs, and realized that every time I get a new kitchen/ROM or flash a new radio, I have to make sure the rilphone.dll file is the correct one for my radio. Well, more accurately, I realized how annoying it can be.
Yes, it can be done with UC and the appropriate CAB for the user's current radio, but I wanted to create an easier way to do it so that the user doesn't have to think about it. Considering how many times the TP/Fuze keyboard layout question is asked in the Raphael forums, I'd say any kind of automation is good automation
My answer to this issue is rilphoneAuto.exe, a .NET CF 2.0 app that reads the user's current radio version, determines if the appropriate RIL DLL is available (through an XML configuration file), and edits the "DLL" entry under HKLM\Drivers\BuiltIn\RIL to point to this particular DLL.
In order for this app to work, you have to include all the RIL DLLs you'd like to support in your ROM, and change the rilphoneAuto.xml file to have an entry for each of those DLLs. It's a very simple format, don't worry
I have attached rilphoneAuto in OEM and EXT formats. Both attachments contain the app, GSM RIL DLLs for radio versions 1.12.25.19 and 1.14.25.05, and the XML config file preconfigured with the aforementioned DLLs.
*** IMPORTANT: You must add rilphoneAuto to one of your config*.txt files in order for the app to start on first boot customization if you are using the OEM package. The line you'll need to add is:
Code:
EXEC:\Windows\rilphoneAuto.exe
The EXT package contains add2config.txt that ervius kitchen 9.7 can work with, so you don't have to mess with config*.txt files yourself.
ALSO IMPORTANT: I've only tested this on my GSM Raphael, so I have no idea if it works on other devices. Theoretically, it should, as long as HTC keeps the fields in their RILEQUIPMENTINFO struct the same throughout their devices. Please post successes/failures.
UPDATE: I updated the app to version 1.0.1. It should now support CDMA devices, at least CDMA Raphaels. Unfortunately, the RILEQUIPMENTINFO struct is different there and I don't know how to get the actual radio version, so on CDMA devices you must use the protocol string. The XML file format remains the same, but instead of putting the radio version inside the "version" attribute, you must put the protocol version. The version string is case-insensitive.
Reserved for no particular reason.
this is smart
Could you explain what's the point in changing the ril.dll please ?
rilphone.dll is the primary communications channel between the OS and the radio ROM. Each version of the radio ROM *should* be used with its own rilphone.dll because of new features, bugfixes, etc. While usually other versions will still function, using the correct DLL will result in the best combination of features, (lack of) bugs, and power savings.
I only found ril.dll in my phone.
I looked in the kitchen for my ROM and it has ril.dll and rilgsm.dll in it.
ril.dll is in PhoneRedist
rilgsm.dll is in OEM\OEMDrivers
I have switched radios many times. Some have not worked well.
I searched in the registry and it only found reference to rilgsm.dll, but as I said, I do not see it in the files on my phone.
Theoretically, it should be whatever is referenced in "Dll" under HKLM\Drivers\BuiltIn\RIL. My guess would be rilgsm.dll.
Problem is that rilgsm.dll is referenced in the registry, but I cannot find the file on my phone. I only find ril.dll under \windows.
If it's in OEMDrivers, it should be on your device. Make sure you've got hidden/system/ROM files visible.
I always do ,but I checked again to be sure. It was set to see all, and only ril.dll is there.
For s&g I went to copy rilgsm.dll from a kitchen into my phone.
The message came up about the file exists and do I want to overwrite it.
It still does not show up, but it must be there.
I went into total commander. The rilgsm file shows up there.
Now to my next question. When I switch radios should I copy both ril.dll and rilgsm.dll from the OS that the radio came from into my phone?
Currently I use 03.02.11, but I may switch in the future and I do not really know what dll files the cooks are using.
As far as I know, ril.dll should stay the same, but I'm not 100% sure. I do know that ril.dll is what other apps interface with to get RIL-related data, so my guess is that it's probably just an aggregation of functions that calls into other DLLs to actually perform them. Again, that's a guess, so I don't really know. Also, since it's not under OEMDrivers, that's another clue that it's not OEM-specific and therefore would not depend on a certain radio version.
So I copied the ril files to my phone. Did a soft reset and the radio would not work.
I think there are two factors.
The radio I use is for a wizard, but I think it was the wiza200 which is not the same as my phone. Only guessing differences.
Maybe the ril files have to be for the particular wizaversion I have and the radio both.
I really don't know. I've never owned a Wizard, so I don't know about its hardware differences and stuff like that
Had to hard reset to get phone to work again.
Went ahead and tried changing just the rilgsm.dll file.
Once again dead phone. Hard reset again.
Guess this concept does not work for the wizard or it depends on the wiza version.
You really shouldn't have to hard reset if it's the wrong DLL. You should just be able to delete it with Total Commander. That will restore the original DLL from the ROM. At least it does on my Raphael
I should have mentioned I did that first and then reset the phone, but it still would not start the radio part. So I resorted to hard reset.
Trancecoder said:
You really shouldn't have to hard reset if it's the wrong DLL. You should just be able to delete it with Total Commander. That will restore the original DLL from the ROM. At least it does on my Raphael
Click to expand...
Click to collapse
I just found this very informative thread about rilphone's function:
http://forum.xda-developers.com/showpost.php?p=3354857
Maybe this can be some clarifying
Olioaglio
Oh yeah! I completely forgot about nk.exe patching. I assume it's required on older devices as well. Thanks for the link, Olioaglio!
It should be possible to get around nk.exe patching by signing the rilphone.dll with your own certificate and installing that cert into the trusted root store. It works on the Raphael. That's the proper way to have your own stuff execute in trusted locations. Chainfire's DriverWiz can automate the process of signing a DLL and creating a CAB that installs the cert as well as the signed DLL.
RoryB, you should try using DriverWiz with that rilgsm.dll you mentioned. If it works, that means DLL signing fun for all!
I don't think I can make rilphoneAuto sign DLLs on first boot, so this issue has to be resolved in the ROM before distribution. The included rilphone*.dll files will have to be signed using your own cert, and that cert will have to be included in a .provxml, .rgu, or .reg file to be installed inside the proper cert store. That doesn't sound like fun, so nk.exe patching would probably be a hell of a lot easier, if a little improper.
Here's another one... very interesting stuff:
http://forum.xda-developers.com/showthread.php?t=494632
Olioaglio