SamsungGalaxyBackdoor » History » Version 9
Paul Kocialkowski, 02/04/2014 06:27 PM
Remove assembly extracts and bring more certainty to the statements
1 | 1 | Paul Kocialkowski | h1. Samsung Galaxy Back-door |
---|---|---|---|
2 | |||
3 | 3 | Paul Kocialkowski | This page contains a technical description of the back-door found in Samsung Galaxy devices. |
4 | For a general description of the issue, please refer to the following statement: |
||
5 | 1 | Paul Kocialkowski | |
6 | *This back-door is present in most proprietary Android systems running on the affected Samsung Galaxy devices, including the ones that are shipped with the devices. However, when Replicant is installed on the device, this back-door is not effective: Replicant does not cooperate with back-doors.* |
||
7 | |||
8 | h2. Abstract |
||
9 | |||
10 | 9 | Paul Kocialkowski | Samsung Galaxy devices running proprietary Android versions come with a back-door that provides remote access to the data stored on the device. |
11 | In particular, the proprietary software that is in charge of handling the communications with the modem, using the Samsung IPC protocol, implements a class of requests known as RFS commands, that allows the modem to perform remote I/O operations on the phone's storage. As the modem is running proprietary software, it is likely that it offers over-the-air remote control, that could then be used to issue the incriminated RFS messages and access the phone's file system. |
||
12 | 1 | Paul Kocialkowski | |
13 | 7 | Paul Kocialkowski | h2. Known affected devices |
14 | |||
15 | The following table shows which devices are known to contain this back-door as part of the software they ship with. |
||
16 | Please contact us if you know about some other device that could be concerned by this back-door or have more information on one of the listed devices! |
||
17 | |||
18 | |_. Device |_. Incriminated program running as root |_. SELinux enabled |_. libsamsung-ipc support |_. Replicant support | |
||
19 | | Nexus S (I902x) | No | Possible with Android 4.2 and later | Yes | Yes | |
||
20 | | Galaxy S (I9000) | Yes | ? | Yes | Yes | |
||
21 | | Galaxy S 2 (I9100) | No | ? | Yes | Yes | |
||
22 | | Galaxy Note (N7000) | No | ? | Yes | Yes | |
||
23 | | Galaxy Tab 2 7.0 (P31xx) | No | ? | Yes | Yes | |
||
24 | | Galaxy Tab 2 10.1 (P51xx) | No | ? | Yes | Yes | |
||
25 | | Galaxy S 3 (I9300) | No | ? | Yes | Yes | |
||
26 | | Galaxy Note 2 (N7100) | No | ? | Yes | Yes | |
||
27 | |||
28 | 1 | Paul Kocialkowski | h2. Analysis |
29 | |||
30 | 2 | Paul Kocialkowski | The following analysis was conducted using the @libsec-ril.so@ binary file (the incriminated proprietary software) as extracted from the CyanogenMod 10.1.3 system zip for the Galaxy S 3 (I9300), from location @system/lib/libsec-ril.so@. |
31 | |||
32 | 9 | Paul Kocialkowski | *The developers involved in the present analysis did not ever agree to any sort of End User License Agreement that explicitly prohibited the reverse engineering and decompiling operations of the incriminated binary. The reverse engineering operations that led to these findings originally took place during the development of [[Samsung-RIL]], the free software replacement for the incriminated program. Hence, we believe these operations were conducted for the sole purpose of interoperability and not with the intent of creating a competing product. As the involved developers were based in Europe, we believe the legality of these operations is granted by article 6 of the 1991 EU Computer Programs Directive.* |
33 | 1 | Paul Kocialkowski | |
34 | 6 | Paul Kocialkowski | As a first approach, using the @strings@ tool against the incriminated program reveals numerous suspicious command names that appear to be Samsung IPC protocol definitions: |
35 | <pre> |
||
36 | IPC_RFS_READ_FILE |
||
37 | IPC_RFS_WRITE_FILE |
||
38 | IPC_RFS_LSEEK_FILE |
||
39 | IPC_RFS_CLOSE_FILE |
||
40 | IPC_RFS_PUT_FILE |
||
41 | IPC_RFS_GET_FILE |
||
42 | IPC_RFS_RENAME_FILE |
||
43 | IPC_RFS_GET_FILE_INFO |
||
44 | IPC_RFS_UNLINK_FILE |
||
45 | IPC_RFS_MAKE_DIR |
||
46 | IPC_RFS_REMOVE_DIR |
||
47 | IPC_RFS_OPEN_DIR |
||
48 | IPC_RFS_READ_DIR |
||
49 | IPC_RFS_CLOSE_DIR |
||
50 | IPC_RFS_OPEN_FILE |
||
51 | IPC_RFS_FTRUNCATE_FILE |
||
52 | IPC_RFS_GET_HANDLE_INFO |
||
53 | IPC_RFS_CREATE_FILE |
||
54 | </pre> |
||
55 | 4 | Paul Kocialkowski | |
56 | 6 | Paul Kocialkowski | The names of these commands make it obvious that they let the modem perform I/O operations. |
57 | 1 | Paul Kocialkowski | |
58 | 6 | Paul Kocialkowski | The @strings@ utility also reveals matching function names that seem to implement the handling of these commands: |
59 | <pre> |
||
60 | RxRFS_GetFile |
||
61 | RxRFS_CreateFile |
||
62 | RxRFS_ReadDirectory |
||
63 | RxRFS_OpenDirectory |
||
64 | RxRFS_RenameFile |
||
65 | RxRFS_Default |
||
66 | RxRFS_OpenFile |
||
67 | RxRFS_ReadFile |
||
68 | RxRFS_FtruncateFile |
||
69 | RxRFS_WriteFile |
||
70 | RxRFS_GetFileInfoByHandle |
||
71 | RxRFS_GetFileInfo |
||
72 | RxRFS_PutFile |
||
73 | RxRFS_LseekFile |
||
74 | RxRFS_CloseFile |
||
75 | RxRFS_DeleteFile |
||
76 | RxRFS_MakeDirectory |
||
77 | RxRFS_CloseDirectory |
||
78 | RxRFS_RemoveDirectory |
||
79 | TxRFS_CfrmCreateFile |
||
80 | TxRFS_CfrmPutFile |
||
81 | TxRFS_CfrmOpenDirectory |
||
82 | TxRFS_CfrmGetFileInfo |
||
83 | TxRFS_CfrmReadDirectory |
||
84 | TxRFS_CfrmRenameFile |
||
85 | TxRFS_CfrmCloseFile |
||
86 | TxRFS_CfrmFtruncateFile |
||
87 | TxRFS_CfrmGetFileInfoByHandle |
||
88 | TxRFS_CfrmDeleteFile |
||
89 | TxRFS_CfrmCloseDirectory |
||
90 | TxRFS_CfrmRemoveDirectory |
||
91 | TxRFS_CfrmMakeDirectory |
||
92 | TxRFS_CfrmGetFile |
||
93 | TxRFS_CfrmReadFile |
||
94 | 1 | Paul Kocialkowski | TxRFS_CfrmWriteFile |
95 | 6 | Paul Kocialkowski | TxRFS_CfrmLseekFile |
96 | 7 | Paul Kocialkowski | TxRFS_CfrmOpenFile |
97 | </pre> |
||
98 | |||
99 | 9 | Paul Kocialkowski | Taking a closer look at these functions, using the @objdump@ decompiler, reveals that they are actually called from the @ipc_recv_rfs@ function, itself called from @process_ipc_notify_message@, which appears to handle the received messages from the modem. Hence we can deduct that the incriminated functions are actually called upon modem request. |
100 | 7 | Paul Kocialkowski | |
101 | 9 | Paul Kocialkowski | Taking a closer look at one of these functions, e.g. RxRFS_ReadFile reveals multiple calls to the Procedure Linkage Table (PLT). Hence we believe these calls are linked functions from the libc library, especially I/O-related functions such as (in a general manner) @open@, @close@, @read@, @write@, etc. |
102 | 7 | Paul Kocialkowski | |
103 | h2. Areas of work |
||
104 | |||
105 | A more decisive proof of these assumptions could be obtained by crafting a packet requesting I/O operations on the device's storage and looking at whether the incriminated binary proceeds or not. |
||
106 | 1 | Paul Kocialkowski | |
107 | 6 | Paul Kocialkowski | h2. Notes |
108 | 1 | Paul Kocialkowski | |
109 | 6 | Paul Kocialkowski | Our free software replacement for the incriminated binary is [[Samsung-RIL]] which relies on [[Libsamsung-ipc|libsamsung-ipc]] and it is used in Replicant. |
110 | 1 | Paul Kocialkowski | |
111 | 6 | Paul Kocialkowski | The affected devices have modems that use the Samsung IPC protocol, mostly Intel XMM6160 and Intel XMM6260 modems. Note that despite this back-door, the devices using these modems are most likely to have good modem isolation, compared to other devices using Qualcomm platforms. Bear in mind that this back-door is implemented in software and can easily be removed by installing a free replacement for the incriminated software, for instance by installing Replicant. Hence, we don't consider the incriminated devices as bad targets for Replicant because of this back-door. |