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 ?
Hi devs, I have idea for MAC reading. First, I know real MAC is located in SPL (I know this becouse I'm tried), I'm tried to read MAC from kernel side but problem is reading SPL becouse board-photon.h have defined:
Code:
#define MSM_MEM1_BASE 0x00000000
#define MSM_LINUX_BASE_OFFSET 0x00200000
#define MSM_PHOTON_LINUX1_BASE (MSM_MEM1_BASE + MSM_LINUX_BASE_OFFSET) /* 2MB alignment */
#define MSM_PHOTON_LINUX1_SIZE (MSM_MEM1_SIZE - MSM_LINUX_BASE_OFFSET)
SPL have size of 0x80000 and we skipped it. My idea is:
- patch haret to copy some SPL addreses (addrese where is wifi nvs ram) to another memory location
- read these location from kernel side
or
- edit kernel code to read this location or edit kernel to copy SPL to an memory location
What you think? Maybe you have idea how to read SPL?
i think there is solutions easier than SPL to get MAC addr
real mac == winMo?
i have an idea, but not tested yet:
simply remove "macaddr=00:11:22:33:44:55\n" from htc_wifi_nvs.c
recompile
it should work now
(my guess is the driver already read the good address, but we overwrite it with bad value)
No, I'm tried without static nvs! Only sense I think is reading these nvs from memory, but if we want to read this we must have access to first 0x80000 bytes (SPL), or maybe adding kernel code (command line parameter), or maybe DEX call (I dont know if is possible)
See picture, you will see where is nvs in spl, also you will see we have defined static_nvs diferent than nvs in spl!
you're totaly right.
and htc_wifi_nvs.c for liberty is extracting the NVS from bootloader.
i think the address we have is wrong:
This is the address for Liberty:
#define ATAG_MSM_WIFI 0x57494649 /* MSM WiFi */
Click to expand...
Click to collapse
For our bootloader, it must be different. i'll investigate.
Is the MAC in startup.txt used by Android?
If that is the case, may it is more easy to write a WinMo app that adjusts the startup.txt with the MAC know by WinMo.
Or is that to easy?
-r0bin- said:
you're totaly right.
and htc_wifi_nvs.c for liberty is extracting the NVS from bootloader.
Click to expand...
Click to collapse
I think is not from bootloader becouse liberty bootloader start at 0x0 and is size < 1M, but ok, good thing is - you understand me, and I thk you for it!
We need to read:
- start at 0x65720
- read 0x239 bute
munjeni said:
I think is not from bootloader becouse liberty bootloader start at 0x0 and is size of 1M, but ok, good thing is - you understand me, and I thk you for it!
We need to read:
- start at 0x65720
- read 0x239 bute
Click to expand...
Click to collapse
thanks, but what address do you dump? (0x65720 is only the offset)
how do you create this memory dump?
I showed you how I do it, but you're not ...attention to my post. I'll tell you, unlike you who is hiding information
see this link how I dump memmory.
Code:
976 // cardsharing smem dump
977 /*int i;
978 int x[1000];
979 printk("Battery hex smem dump: ");
980 for (i=0; i<1000; i++)
981 {
982 x[i] = readl(MSM_SHARED_RAM_BASE + 0xfc000 + i) & 0x000000ff;
983 printk("%02x", x[i]);
984 }
985 printk("\n");*/
Problem is: we not have access to spl!
Maybe from this way:
msm_nand_read: 65720 239
Code:
msm_nand_read(struct mtd_info *mtd, loff_t from, size_t len,
size_t *retlen, u_char *buf)
{
int ret;
struct mtd_oob_ops ops;
/* printk("msm_nand_read %llx %x\n", from, len); */
ops.mode = MTD_OOB_PLACE;
ops.len = len;
ops.retlen = 0;
ops.ooblen = 0;
ops.datbuf = buf;
ops.oobbuf = NULL;
ret = msm_nand_read_oob(mtd, from, &ops);
*retlen = ops.retlen;
return ret;
}
return wifi_nvs;
What you think?
munjeni said:
but if we want to read this we must have access to first 0x80000 bytes (SPL)
Click to expand...
Click to collapse
first 0x80000 bytes of what? memory?
munjeni said:
See picture, you will see where is nvs in spl, also you will see we have defined static_nvs diferent than nvs in spl!
Click to expand...
Click to collapse
how did you generated this picture?
i mean, what address did you used?
yes, of memory
haret: pwf spl.dump 0x0 0x80000
Program used to read spl.dump is: X&D hex editor
Program used to screen capture is: FastStone Capture
From kernel side I'm tried to dump android memory (spl from 0x0 len 0x80000), but without success, I think is not possible in this time, we need modifications to do that!
oook i got it!
physical address = 0x65720
thats sounds easy!
and you cannot dump memory like this under Linux, it uses virtual address!!!
ok, good if is easy! Please report here if you got it and how you got it, I need that knownledge for my future development, ok?
munjeni said:
ok, good if is easy! Please report here if you got it and how you got it, I need that knownledge for my future development, ok?
Click to expand...
Click to collapse
under android, when i use this func: "phys_to_virt(0x65720)" it gives me this virtual address: 0xbfe65720
unfortunately system crash when i try to access it.
there must be another way...
maybe is empty virtual (or we not have permisions to read) becouse we skipped first 0x100000 (board_photon.h) from psychical, hmm I not understand why crashed? I'm also tried and also with crashing. If I'm right MSM_SHARED_RAM_BASE is psychical and other defined in board_photon.h is also psychical?
found by schlund:
https://gitorious.org/linux-on-winc...ter/arch/arm/mach-msm/board-htcleo-wifi-nvs.c
on HTC Leo, they read SMEM and can retrieve MAC addr, it is encrypted by CRC32
good! But maybe we also need to change hardcoded_nvs bassed on picture. Are you got mac from smem after crc decode? I've not tried to read
actually it's not the real MAC addr, its a random one
regarding the real NVS data from hardware:
- either the bootloader memory has a special protection
- either we are using the wrong RAM virtual address
- either we dont have the good access method
I want to bring-up ANDROID on a PXA310 custom platform designed by me, it is not a commercial platform available on the market.
I have already ported to the platform WINDOWS CE 5, so I am using Haret.exe in order to start a linux kernel stored on the SD card.
the linux kernel, zImage, is compiled with support for PXA310 and littleton and zylonite development boards by Marvell because my platform is based on these reference designs.
I have enabled also CONFIG_DEBUG_LL in order to see debug messages before linux console is enabled over debug serial port that is STUART in my case like for littleton.
So I am using the littleton as machine ID in the Haret.exe Default.txt script file and so I can see the first low level messages when decompressing the zImage into Image at zrleaddr-y position in RAM.
I can see also low level messages coming from the first stages of the uncompressed linux code where it looks up for the CPU ID and for the
MACHINE ID.
So for example if I put a unsupported MACHINE ID in the Default.txt, I can see an error message on the serial debug port.
But after I don't see anything.
Consider that I have not yet implemented LCD driver in the kernel.
The problem is that the system now is stuck somewhere, I don't know where .
It looks like after the jump to start_kernel I don't see any other messages.
I don't see the banner of linux kernel like the version.
I am pretty sure that all the following code of the Kernel startup entry point in /linux-2.6.29/arch/arm/kernel/head.s is executed as I can put traces and then I see them over serial debug port:
.section ".text.head", "ax"
ENTRY(stext)
msr cpsr_c, #PSR_F_BIT | PSR_I_BIT | SVC_MODE @ ensure svc mode
@ and irqs disabled
mrc p15, 0, r9, c0, c0 @ get processor id
bl __lookup_processor_type @ r5=procinfo r9=cpuid
movs r10, r5 @ invalid processor (r5=0)?
beq __error_p @ yes, error 'p'
bl __lookup_machine_type @ r5=machinfo
movs r8, r5 @ invalid machine (r5=0)?
beq __error_a @ yes, error 'a'
bl __vet_atags
bl __create_page_tables
/*
* The following calls CPU specific code in a position independent
* manner. See arch/arm/mm/proc-*.S for details. r10 = base of
* xxx_proc_info structure selected by __lookup_machine_type
* above. On return, the CPU will be ready for the MMU to be
* turned on, and r0 will hold the CPU control register value.
*/
ldr r13, __switch_data @ address to jump to after
@ mmu has been enabled
adr lr, __enable_mmu @ return (PIC) address
//bl __my_trace_over_debug_port
add pc, r10, #PROCINFO_INITFUNC
ENDPROC(stext)
why do the CONFIG_DEBUG_LL messages print out to the right serial port while 'printk' messages don't come out? do they go to a different port?
any suggestion?
Thanks!
Marco