Project

General

Profile

RestoreApplicationInternalData » History » Version 6

Denis 'GNUtoo' Carikli, 10/29/2020 12:14 AM
add warning about restorecon

1 1 Denis 'GNUtoo' Carikli
h1. RestoreApplicationInternalData
2
3
{{toc}}
4
5
h2. /!\ Warning: Draft
6
7
This article is in draft form and is being written:
8
* Everybody is welcome to contribute
9
* Some things might not be accurate yet, so beware before using the information contained in it.
10 2 Denis 'GNUtoo' Carikli
11
h2. Introduction
12
13
In some case, it is useful to be able to restore internal applications data:
14
* You may want to move the data of an application from a device to another
15
* If some files like /data/system/packages.xml or /data/system/appops.xml get corrupted, applications can loose access to their data. This can make the launcher and other applications crash.
16 3 Denis 'GNUtoo' Carikli
17
h2. Howto
18
19 5 Denis 'GNUtoo' Carikli
This howto will explain how to move silence data from a device to another.
20
21 3 Denis 'GNUtoo' Carikli
TODO:
22 5 Denis 'GNUtoo' Carikli
* Explain that we assume that the data partition isn't encrypted
23
* Explain why we need the uid/gid
24
* Explain why the ls -ld gives the application uid/gid
25
* Point to how to get root
26
* Explain how to handle a corrupted /data/system/packages.xml and /data/system/appops.xml
27 3 Denis 'GNUtoo' Carikli
* Explain how to mount a full backup, and why not to restore full backup completely
28
* Explain how and why create a tarball of the application data
29
30 5 Denis 'GNUtoo' Carikli
Once we have a tarball backup of the application data we need to reboot in the recovery to avoid any writes to the data filesystem.
31
32
Once this is done you need to mount the data partition. 
33
34
For the Galaxy SIII (GT-I9300), this can be done from your computer with this command:
35 3 Denis 'GNUtoo' Carikli
<pre>
36
$ adb shell "mount /dev/block/platform/dw_mmc/by-name/USERDATA /data"
37
</pre>
38
39 5 Denis 'GNUtoo' Carikli
Then we need to get a root shell inside the recovery. This can be done with the @adb shell@ command:
40 3 Denis 'GNUtoo' Carikli
<pre>
41
$ adb shell
42
</pre>
43
44 5 Denis 'GNUtoo' Carikli
Then we assume that you are in /data/data to simplify this tutorial.
45
You will need to remember adjust all other commands if you are not in this directory.
46
To go in /data/data, you can use the following command:
47 3 Denis 'GNUtoo' Carikli
<pre>
48
root@m0:/ # cd /data/data/                                                     
49
root@m0:/data/data # 
50
</pre>
51
52 5 Denis 'GNUtoo' Carikli
As applications are sandboxed, and that as part of that sandboxing, they have their own usersname, we need to retrieve this username.
53
To do that we can just use @ls -ld@ on the directory holding the application internal data.
54
55
The directory has the internal name of the application.
56
57
Here are some well known name correspondances:
58
59
| Internal name           | Application name | Description |
60
| org.smssecure.smssecure | Silence          | |
61
| com.android.dialer      | Dialer           | Android's stock dialer application |
62
63
For pakcages comming from f-droid, the f-droid website can find the correspondance.
64
65
For instance the "Silence page":https://f-droid.org/en/packages/org.smssecure.smssecure/ has @org.smssecure.smssecure@ in its URL and inside the page.
66
67
So with @ls -ld@ we can find the application username in this way:
68 1 Denis 'GNUtoo' Carikli
<pre>
69 5 Denis 'GNUtoo' Carikli
root@m0:/data/data # ls -ld org.smssecure.smssecure
70 3 Denis 'GNUtoo' Carikli
__bionic_open_tzdata: couldn't find any tzdata when looking for localtime!
71
__bionic_open_tzdata: couldn't find any tzdata when looking for GMT!
72
__bionic_open_tzdata: couldn't find any tzdata when looking for posixrules!
73
drwxr-x--x 2 u0_a61 u0_a61 4096 2012-01-01 00:01 org.smssecure.smssecure
74
</pre>
75
76
Here the users and groups are @u0_a61@.
77 1 Denis 'GNUtoo' Carikli
78 5 Denis 'GNUtoo' Carikli
We will then need this information later on to restore the silence data from the other device: If we restore that data as-is it will most likely have wrong permissions: when the the silence application was installed on the older device, it was assigned an username. As this username depends on the number of applications that were installed before it, we cannot expect it to always be the same between the two devices.
79
80
It's also best to move or delete the data we don't want:
81 3 Denis 'GNUtoo' Carikli
<pre>
82
root@m0:/data/data # mv org.smssecure.smssecure org.smssecure.smssecure.delme
83
</pre>
84 1 Denis 'GNUtoo' Carikli
85 5 Denis 'GNUtoo' Carikli
Moving it has several advantages:
86
* We can still verify the username later on to see if it matches with the backup we restored.
87
* We can interrupt this tutorial more easily if something goes wrong.
88
89
Here we need to verify that the archive will extract its files in the @org.smssecure.smssecure@ directory and not in the current directory which is @/data/data@:
90 3 Denis 'GNUtoo' Carikli
<pre>
91
root@m0:/data/data # tar tf /org.smssecure.smssecure.tar
92
./org.smssecure.smssecure/
93
./org.smssecure.smssecure/lib -> /data/app/org.smssecure.smssecure-1/lib/arm
94
[...]
95 1 Denis 'GNUtoo' Carikli
</pre>
96 5 Denis 'GNUtoo' Carikli
Here we see that everything starts with @./org.smssecure.smssecure/@ (or @org.smssecure.smssecure/@) so it's good.
97 1 Denis 'GNUtoo' Carikli
98 5 Denis 'GNUtoo' Carikli
TODO: move this part earlier
99
100
If we had something like that instead:
101 1 Denis 'GNUtoo' Carikli
<pre>
102 5 Denis 'GNUtoo' Carikli
root@m0:/data/data # tar tf /org.smssecure.smssecure.tar
103
./lib -> /data/app/org.smssecure.smssecure-1/lib/arm
104
[...]
105
</pre>
106
107
Then it's best to recreate the archive.
108
109
If you need more time you could also move back org.smssecure.smsecure.delme to org.smssecure.smssecure if needed.
110
111
We can then proceed to extract the application data (with the username from the old device):
112
<pre>
113 3 Denis 'GNUtoo' Carikli
root@m0:/data/data # tar xpf /org.smssecure.smssecure.tar --numeric-owner
114
</pre>
115 1 Denis 'GNUtoo' Carikli
116 5 Denis 'GNUtoo' Carikli
Here we can see that the username differs from the one we need:
117 3 Denis 'GNUtoo' Carikli
<pre>
118
root@m0:/data/data # ls -ld org.smssecure.smssecure 
119
__bionic_open_tzdata: couldn't find any tzdata when looking for localtime!
120
__bionic_open_tzdata: couldn't find any tzdata when looking for GMT!
121
__bionic_open_tzdata: couldn't find any tzdata when looking for posixrules!
122
drwxr-x--x 9 u0_a63 u0_a63 4096 2012-01-01 00:21 org.smssecure.smssecure
123 1 Denis 'GNUtoo' Carikli
</pre>
124 5 Denis 'GNUtoo' Carikli
We have @u0_a63@ instead of @u0_a61@.
125 1 Denis 'GNUtoo' Carikli
126 5 Denis 'GNUtoo' Carikli
So we need to fix it. This can be done with the @chown@ command, like that:
127 3 Denis 'GNUtoo' Carikli
<pre>
128
root@m0:/data/data # chown u0_a61:u0_a61 -R org.smssecure.smssecure            
129
root@m0:/data/data # 
130
</pre>
131 1 Denis 'GNUtoo' Carikli
132 5 Denis 'GNUtoo' Carikli
At this point, we don't need the @org.smssecure.smssecure.delme@ directory anymore, and it's best to remove it not to create any issues later on.
133
This can be done with the following command:
134 3 Denis 'GNUtoo' Carikli
<pre>
135
root@m0:/data/data # rm -rf org.smssecure.smssecure.delme
136
root@m0:/data/data # 
137
</pre>
138 1 Denis 'GNUtoo' Carikli
139 5 Denis 'GNUtoo' Carikli
In addition to the standard unix permissions, Android also uses selinux, so we also need to fixup the selinux permissions.
140
141
The restorecon command can be used for that. Here's its help: 
142 3 Denis 'GNUtoo' Carikli
<pre>
143
root@m0:/data/data # restorecon                                                
144
usage: restorecon [-D] [-F] [-R] [-n] [-v] FILE...
145
146
Restores the default security contexts for the given files.
147
148
-D	apply to /data/data too
149
-F	force reset
150
-R	recurse into directories
151
-n	don't make any changes; useful with -v to see what would change
152
-v	verbose: show any changes
153
154
restorecon: Needs 1 argument
155
</pre>
156 1 Denis 'GNUtoo' Carikli
157 5 Denis 'GNUtoo' Carikli
So to use it to fixup the selinux permissions, we can use the following command:
158 1 Denis 'GNUtoo' Carikli
<pre>
159 5 Denis 'GNUtoo' Carikli
root@m0:/data/data # restorecon -D -F -R -v /data/
160
</pre>
161
162 6 Denis 'GNUtoo' Carikli
The order of the arguments (-D, -F, etc) seem to be important here as the wrong order might result in nothing being done.
163
Without the @-v@ argument and with the wrong order of argument, it might make you think that it did its job while it did nothing.
164
165 5 Denis 'GNUtoo' Carikli
It will then print something that looks like that:
166
<pre>
167 3 Denis 'GNUtoo' Carikli
SELinux: Loaded file_contexts contexts from /file_contexts.
168
[...]
169
SELinux:  Relabeling /data/data/org.smssecure.smssecure from u:object_r:system_data_file:s0 to u:object_r:app_data_file:s0:c512,c768.
170
SELinux:  Relabeling /data/data/org.smssecure.smssecure/lib from u:object_r:system_data_file:s0 to u:object_r:app_data_file:s0:c512,c768.
171
[...]
172 1 Denis 'GNUtoo' Carikli
</pre>
173
174 5 Denis 'GNUtoo' Carikli
The premissions fixing is now done.
175
176
So we can then umount the data partition and reboot.
177
178
To do that first we need to go outside of data, else the mount will fail:
179 1 Denis 'GNUtoo' Carikli
<pre>
180 5 Denis 'GNUtoo' Carikli
root@m0:/data/data # cd /
181
root@m0:/ # 
182
</pre>
183
184
Then we can simply unmount it with this command:
185
<pre>
186 3 Denis 'GNUtoo' Carikli
root@m0:/ # umount  /data/                                                     
187 1 Denis 'GNUtoo' Carikli
root@m0:/ # 
188
</pre>
189 3 Denis 'GNUtoo' Carikli
190 5 Denis 'GNUtoo' Carikli
Then it's a good practice to make sure that everything is written to the data partition before rebooting.
191
We can do that with the @sync@ command:
192 1 Denis 'GNUtoo' Carikli
<pre>
193
root@m0:/ # sync
194 5 Denis 'GNUtoo' Carikli
</pre>
195
196
And we can finally reboot:
197
<pre>
198 1 Denis 'GNUtoo' Carikli
root@m0:/ # reboot
199
</pre>
200
201 5 Denis 'GNUtoo' Carikli
After rebooting, silence still refused to start.
202
203
So I looked at the logs from my laptop with this command:
204 1 Denis 'GNUtoo' Carikli
<pre>
205 5 Denis 'GNUtoo' Carikli
$ adb logcat -b main
206
</pre>
207
208
I waited until no more new logs were printed.
209
210
I then press enter multiple times to create a separation with many new lines to be able to get back to the begining of the new logs easily.
211
Then I launched silence and started pressing enter multiple times again to mark the end of the silence related logs.
212
213
I then had that in these new logs:
214
<pre>
215 4 Denis 'GNUtoo' Carikli
01-01 01:27:48.260  4126  4126 D AndroidRuntime: Shutting down VM
216
01-01 01:27:48.265  4126  4126 E AndroidRuntime: FATAL EXCEPTION: main
217
01-01 01:27:48.265  4126  4126 E AndroidRuntime: Process: org.smssecure.smssecure, PID: 4126
218
01-01 01:27:48.265  4126  4126 E AndroidRuntime: Theme: themes:{}
219
01-01 01:27:48.265  4126  4126 E AndroidRuntime: java.lang.RuntimeException: Unable to create application org.smssecure.smssecure.ApplicationContext: java.lang.SecurityException: getActiveSubscriptionInfoList: Neither user 10061 nor current process has android.permission.READ_PHONE_STATE.
220 1 Denis 'GNUtoo' Carikli
01-01 01:27:48.265  4126  4126 E AndroidRuntime: 	at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4754)
221
[...]
222
</pre>
223
224 5 Denis 'GNUtoo' Carikli
So to fix it I went in @Settings->Apps->Silence->Permissions@ and gave it all the permissions it needed.
225
226
I had this issue because I didn't even launch silence after installing it, so it cound't ask me for the permissions it needed.
227
And the silence of the former device probably wrote in its data that it already asked the permissions.