Hi,
A while ago I've started to reverse engineer the (userland) baseband interface of my Samsung phone (GT-I8320 aka. H1) in an effort to see how far I can get Android running on the device (it ships with an OS based on LiMo and associated RIL).
Some Googling and inspection of other phones' RILs suggests that possibly quite some other Samsung smartphones use a similar baseband interface (Qualcomm MSM over dpram).
Searching XDA yield quite a few threads of Android upgrades blocked by a proprietary RIL. I couldn't find any traces of attempts to reverse a Samsung RIL though.
So, what I currently have is a really[/n] basic RIL implementation supporting baseband messages related to network registration (power up, imei/network info, signal info) and even outgoing calls (but that's all related to call management).
To anyone still reading this:
- Please direct me to any related effort (couldn't find any, as mentioned before).
- Direct anyone considering reversing a Samsung RIL here.
Finally, a set of goodies of unknown use:
- Known to work with my MSM6290 via a dpram interface.
- No idea how much free time I have to continue my effort.
- Might, or might not be of (limited) use for other Samsung phones.
Code: github.com/ius/samsung_h1_libmsm
You might want to check out this thread:
http : //forum.samdroid.net/f56/ril-development-froyo-3156/
Remove the space, cannot post links yet
This is for the Samsung Galaxy Spica, but may be a bit of help
hi!
I also tried to find out how samsung ril over dpram0 works...
@iuss
first of all .. amazing work.. thx
where did you get the information??? do you have any docs??
It's all based on reverse engineering of the LiMo telephony library (which is luckily pretty verbose) and it's associated logs.
I've found most similarities with Samsung RILs labeled as 'libsecril'. Those appear to use a similar interface.
I'm currently struggling to get the audio routing from the modem fixed on my board (in order to be able to test call functionality as I add it) before continuing to work on this.
I've found most similarities with Samsung RILs labeled as 'libsecril'. Those appear to use a similar interface.
Click to expand...
Click to collapse
Yes you are right, libsec-ril.so from galaxy spica uses exactly the same interface!
I opened it up in ida-pro and checked it!
@iuss:
are you good at reading asm??
[email protected] said:
@iuss:
are you good at reading asm??
Click to expand...
Click to collapse
I guess so. Anything specific you need help with?
I am testing now with your source and i can open dpram0 and power_on!
Further i can send commands, but i do not get an answer???
can you post an example .. (unlocking sim,..)
thx
It's not implemented (as is 99% of the rest). Should be trivial to implement though, I think it's the MSM_SEC_ISIM_AUTH message. Will certainly do so after the weekend, if I get my sound to work. - which is still not working. Could you try patching test.c using the following diff (after disabling the pin code if neccessary, and change the number). It should call the number - if it works for you, I'm probably missing a GPIO somewhere.
Code:
diff --git a/test.c b/test.c
index 28fae0e..a449342 100644
--- a/test.c
+++ b/test.c
@@ -18,10 +18,26 @@
*
*/
+#include <unistd.h>
#include <radio.h>
+static int flag = 0;
+
+static void do_stuff()
+{
+ msm_call_outgoing(0, "0123456798");
+}
+
static void on_receive(struct msm_request_info *info)
{
+ switch(info->type) {
+ case MSM_NET_REGIST:
+ if(!flag) {
+ flag = 1;
+ do_stuff();
+ }
+ break;
+ }
}
static struct msm_info msm = {
thx for the code!
I disabled the pin code and tried your changes!
the only message i get is
Code:
MSM_DISP_ICON_INFO NOTI (15/5) seq=179 req=0
i think the mobile is not connecting to network!
Hi,
You're testing this on a GT-I5700 (Spica) right?
Checked the dpram driver source, the ioctls are different. Hence the phone is not properly reset (by msm_power_on(), which turns the modem off first if needed). That's why you're only getting a status message regularly sent by the baseband (contains rssi and such).
Try this. Spica seems to have a few different ioctls too, but I've just dropped those as I'm not using them anyway.
- Edit: Wrong ioctls, see next 2 posts -
from where did you have the ioctls??
i checked libsec-ril.so
Code:
EXPORT onedram_phone_pow_on
onedram_phone_pow_on
PUSH {R4,LR}
LDR R4, =(_GLOBAL_OFFSET_TABLE_ - 0x33CC8)
LDR R0, =(fd_onedram_ptr - 0x45164)
LDR R1, =0x6FD0 ; request
ADD R4, PC
LDR R3, [R4,R0]
MOVS R2, #0
LDR R0, [R3] ; fd
BLX ioctl
CMP R0, #0
BGE loc_33CEE
My reference is the dpram driver shipped with GT-I5700_OpenSource.zip.
But I see that you're right, in true Samsung-style there are multiple defines for the ioctls. The ones in my patch are unused.
DPRAM_PHONE_POWON is indeed 0x6FD0. Try setting that as power_on ioctl.
DPRAM_PHONE_ON is 0xF0C0 - which seems to be called to init the OneDRAM memory, and appears to depend on POWON. If it doesn't work after the POWON ioctl, send this one as well (or even better, strace your original RIL to see the ioctls required).
There's one more ioctl (0x6FD3) related to booting, but I *think* it's only used when a modem image is uploaded. Refer to dpram.h/dpram.c for more info..
hi!
hmm it doesn't work!
Can you tell me how the image upload (over serial) works and if i need to do it??
Further how do you strace rild??
rild is startet from init and the sockets are created on startup!
if i stop rild it restarts and i can not strace it!
so i go to bed... good night
I don't know about the image upload. Either the bootloader handles it (didn't check in detail) or it's handled by the baseband itself. For my phone I can simply send the power_on ioctl and off it goes - probably it's just the same for Spica.
As for stracing, you might be able to modify init.rc so rild is started straced.
What might be easier though is simply reversing it. Seeing you already have the RIL lib in IDA, just find all xrefs to ioctl and you should be able to figure all needed.
hi,
I tried a lot, but i did not get it to work!
I changed the power_IOCTL to 0x6FD0!
It return 0 = OK
but the phone do not start!
The orignial lib loads a phone-image and a nv_data.bin and then it uses 0x6FD3 to start the phone.
But my assembly knowlegde not so good.
Can you have a look if you have time????
i attach libsec-ril.so. open it with ida and go to function RIL_Init!
the magic happens in dload_test
thx in advance
Had a quick look. You're right, Spica appears to load the phone fw/nvs from Android.
Quick writeup (in order):
- onedram_open(): Open /dev/dpram0
- dload_read_dbl(): Read /dev/bml9, 0x5000 bytes
- onedram_phone_pow_on(): ioctl 0x6fd0 (DPRAM_PHONE_POWON)
- dload_uart_init(): open /dev/s3c_serial0, 115200
- dload_hdlc_init(): init some data related to hdlc parsing
- dload_packet_init(): init some packet struct
- nop_req()
- onedram_phone_image_load(): ioctl 0x6fd1 (DPRAM_PHONEIMG_LOAD)
- onedram_nv_data_load(): load /efv/nv_data.bin 0x80000 bytes, ioctl(fd, 0x6FD2 (DPRAM_NVDATA_LOAD), buf_with_nvdata)
- onedram_phone_boot_start(): ioctl 0x6fd3 DPRAM_PHONE_BOOTSTART
onedram_nv_data_load() reads the nvdata and passes it as a param along with the ioctl, the nop_req is sent over the uart.
The baseband firmware itself seems to be read by libsecril, but not used (?) - the kernel driver contains code to read bml too when DPRAM_PHONEIMG_LOAD is issued.
I haven't traced into nop_req - no time to reverse it right now. You can import these functions from libsec-ril.so for testing (all are exported) and later replace them with your own implementation. (You can then easily strace your binary to recover the nop_req data).
I'm looking for RIL logs of Samsung phones in order to speed up development.
'logcat -b radio' might provide some, but given a specific phone model I could look up alternative log locations (i5500 for instance appears to dump RIL traffic to /data/log/).
Anyone able to help?
Nexus S
Hi,
out of curiosity I opened the 'libsec-ril.so' from the Nexus S in IDA.
although 'ioctl' is imported, I cannot really find calls to it.
Since i'm unfamiliar with Arm opcodes, I probably overlook something.
Does this code make sense to anyone ?
EDIT: Quite a lot of functions seem to call 'IPC_send_singleIPC', so I suppose
I might be looking at the wrong file...
EDIT2: Ahh, 'IPC_send_singleIPC' can print an IOCTL error message, just haven't found the actual call to ioctl() yet..
Code:
.text:00016BC4 EXPORT requestDTMFStop
.text:00016BC4 requestDTMFStop
.text:00016BC4 LDR R3, =(dword_62428 - 0x16BD0)
.text:00016BC6 PUSH {R4-R6,LR}
.text:00016BC8 MOV R4, R2
.text:00016BCA LDR R2, =0xFFFFFDC4
.text:00016BCC ADD R3, PC
.text:00016BCE MOV R6, R0
.text:00016BD0 MOV R5, R1
.text:00016BD2 LDR R0, [R3,R2]
.text:00016BD4 LDRB R3, [R0]
.text:00016BD6 CBZ R3, loc_16BEC
.text:00016BD8 LDR R3, =(aOndialtimeout - 0x16BE4)
.text:00016BDA MOVS R0, #6
.text:00016BDC LDR R1, =(aRil - 0x16BE6)
.text:00016BDE LDR R2, =(aS - 0x16BEA)
.text:00016BE0 ADD R3, PC ; "onDialTimeout"
.text:00016BE2 ADD R1, PC ; "RIL"
.text:00016BE4 ADDS R3, #0x6C
.text:00016BE6 ADD R2, PC ; "%s()"
.text:00016BE8 BLX sub_10D2C ; NOTE: this seems to be a printf() function
.text:00016BEC
.text:00016BEC loc_16BEC ; CODE XREF: .text:00016BD6j
.text:00016BEC MOV R0, R6
.text:00016BEE MOV R1, R5
.text:00016BF0 MOV R2, R4
.text:00016BF2 MOVS R3, #2
.text:00016BF4 BL sub_16B28
.text:00016BF8 POP {R4-R6,PC}
.text:00016BFA ; ---------------------------------------------------------------------------
.text:00016BFA NOP
.text:00016BFA ; ---------------------------------------------------------------------------
.text:00016BFC off_16BFC DCD dword_62428 - 0x16BD0 ; DATA XREF: .text:requestDTMFStopr
.text:00016C00 dword_16C00 DCD 0xFFFFFDC4 ; DATA XREF: .text:00016BCAr
.text:00016C04 off_16C04 DCD aOndialtimeout - 0x16BE4 ; DATA XREF: .text:00016BD8r
.text:00016C04 ; "onDialTimeout"
.text:00016C08 off_16C08 DCD aRil - 0x16BE6 ; DATA XREF: .text:00016BDCr
.text:00016C08 ; "RIL"
.text:00016C0C off_16C0C DCD aS - 0x16BEA ; DATA XREF: .text:00016BDEr
.text:00016C0C ; "%s()"
.text:00016C10 ; ---------------------------------------------------------------------------
Tuigje said:
out of curiosity I opened the 'libsec-ril.so' from the Nexus S in IDA.
although 'ioctl' is imported, I cannot really find calls to it.
Click to expand...
Click to collapse
Did you try to find xrefs to it?
Since i'm unfamiliar with Arm opcodes, I probably overlook something.
Does this code make sense to anyone ?
Click to expand...
Click to collapse
It does, but it's just an excerpt from a RIL request handler (requestDTMFStop).
EDIT: Quite a lot of functions seem to call 'IPC_send_singleIPC', so I suppose
I might be looking at the wrong file...
Click to expand...
Click to collapse
Wrong file? What are you looking for exactly? The send_single_IPC function is used to send a message to the baseband, thus it's called quite often.
Nexus S has a slightly different kernel driver for dpram, probably Google kindly requested Samsung to clean their crap up. Instead of a chardev + read/write they use ioctls to perform read/write. That would explain the ioctl references you're seeing in IPC_send_singleIPC.
iuss said:
Did you try to find xrefs to it?
Click to expand...
Click to collapse
Nope. I must have done something wrong loading the libsec-ril.so into IDA. all
imports are shown at the end of the file as:
Code:
extern:0009E54C ; int ioctl(int fd, unsigned __int32 request, ...)
extern:0009E54C IMPORT ioctl
It does, but it's just an excerpt from a RIL request handler (requestDTMFStop).
Wrong file? What are you looking for exactly? The send_single_IPC function is used to send a message to the baseband, thus it's called quite often.
Click to expand...
Click to collapse
Ok. I was wondering whether it is possible to get e.g. 'timing advance' data from the gsm-modem. So I started by digging through the android sources. Now I'm at libsec-ril.so. (and libril.so, but I can't make much sense out of that one yet).
Is it correct that libril.so and the kernel-mode gsm driver are also closed-source for the Nexus S ?
Edit: libril looks awfully similar to the android sources (device/libs/telephony/ril.cpp)
Do you know the name of the kernel driver (module filename), or is it directly compiled into the kernel ?
I haven't stumbled onto it yet, neither in the system.img nor in the ramdisk of the boot.img.
Nexus S has a slightly different kernel driver for dpram, probably Google kindly requested Samsung to clean their crap up. Instead of a chardev + read/write they use ioctls to perform read/write. That would explain the ioctl references you're seeing in IPC_send_singleIPC.
Click to expand...
Click to collapse
Is there any other place to get such information, or is it all hard work figuring this out by yourself ?
I looked and looked but found no answer on how to do this,if its already out there don't chew my head off i looked.So i just figured it out for my self.Since I wanted to be able to give theme choices during rom installs in aroma,this is what I came up with. Ive given (simple examples) below,you should know how to add more or less if you like already.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1. Make a menu box selector such as example below or whatever you want it to look like.
menubox(
"Sense Theme",
"Please choose which Sense theme you would like",
"icons/system",
"vrtheme.prop",
"Yes","Sense 5 for me please", "icons/yes",
"No","Sorry ill keep stock", "icons/no"
);
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Now comes the part that took me all night to get right. You still need to direct theming identically on updater but with minor changes see example below. i found it works best to drop the vrtheme folder itself in the zip,then just call it as normal.
#vrtheme
if file_getprop("/tmp/aroma-data/vrtheme.prop","selected") == "1" then
ui_print("--Installing Sense 5 Theme...");
package_extract_dir("vrtheme", "/sdcard/vrtheme");
ui_print("- - - - Set permission in sdcard folder");
set_perm(0, 0, 0755, "/sdcard/vrtheme/installtheme.sh");
set_perm(0, 0, 0755, "/sdcard/vrtheme/zip");
set_perm(0, 0, 0755, "/sdcard/vrtheme/cleanup.sh");
set_perm(0, 0, 0755, "/sdcard/vrtheme/zipalign");
ui_print("");
run_program("/sdcard/vrtheme/installtheme.sh");
endif;
if file_getprop("/tmp/aroma-data/vrtheme.prop","selected") == "2" then
ui_print("--keeping Stock Theme...");
endif;
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
That's it,hope you find this helpful.As stated in title this is for Devs only.I can not help you if you dont understand,please dont ask.I had to figure all this out myself,and im still learning.Enjoy
Thanks I will test it
I have a Blu Studio X+ running 4.4.2 stock firmware with 3.4.67 kernel. When I try to flash a CM13 port (that also uses the same kernel) in both MTKDroidTools-generated CWM and TWRP 2.8.2.0 (generated from an automated tool as well), I get the following error and the ROM stops flashing:
ApplyParsedPerms: lsetfilecon of /system/lost+found to ubject_r:system_file:s0 failed: Operation not supported on transport endpoint set_metadata_recursive: some changes failed
Looking through the updater-script, the problem seems to lie within this line:
set_metadata_recursive("/system", "uid", 0, "gid", 0, "dmode", 0755, "fmode", 0644, "capabilities", "0x0", "selabel", "ubject_r:system_file:s0");
From my research it appears this is an SELinux incompatibility problem. I thought TWRP 2.8.2.0 was supposed to support SELinux. What do I do to fix this?
I have this EXACT same problem on my Posh E500a MT6592M phone. I can't flash many mt6592 roms or else I get that error. Replacing the META-INF folder with a working one from Lollipop boots the rom, but camera & wifi are buggy because of this. Basically what I want to do is flash a CM13 ROM but it won't flash unless I use a working META-INF folder from a CM12.1 ROM. This however is unstable. I have tried every recovery like you have, even TWRP 3.0.0-0 and the latest one but nothing.
patato21 said:
I have this EXACT same problem on my Posh E500a MT6592M phone. I can't flash many mt6592 roms or else I get that error. Replacing the META-INF folder with a working one from Lollipop boots the rom, but camera & wifi are buggy because of this. Basically what I want to do is flash a CM13 ROM but it won't flash unless I use a working META-INF folder from a CM12.1 ROM. This however is unstable. I have tried every recovery like you have, even TWRP 3.0.0-0 and the latest one but nothing.
Click to expand...
Click to collapse
You're lucky, you have another meta-inf folder to work with. There are no ROMs for the Studio X+ out there, and as far as I know none for the Studio X as well. All I have to work with is the stock /system I extracted from an SP Flash Tool system.img. Unless there's a way for me to "compile" my own meta-inf from a stock ROM I'm stuck.
Found a potential solution, going to try it out soon:
http://forum.xda-developers.com/showthread.php?t=2532300
After more research it turns out that SELinux being set to enforced and not permissive is the issue here. I'm guessing that the stock 3.4.67 kernel has that flag that prevents SELinux from being switched to permissive (what we need for flashing to work), causing this flash error. This thread supposedly gives us a solution, allowing us to bypass this metadata setting that causes the error.
EDIT: Ran into an issue immediately after initiating flash saying mount() expected 4 arguments and got 5. Will try to solve.