Trim Area research - Xperia Z General

In Sony Update Engine, I get some TA info from jar package.
in com.sonymobile.cs.device.io.s1.protocol package:
Code:
public static final int PARTITION_TA = 1;
public static final int PARTITION_MISC_TA = 2;
in com.sonymobile.cs.ma.domain package:
Code:
public static final byte NORMAL_TA_PARTITION = 1;
public static final String NORMAL_TA_PARTITION_NAME = "TA";
public static final byte MISC_TA_PARTITION = 2;
public static final String MISC_TA_PARTITION_NAME = "miscTA";
The code tells us TA have two partition, one is normal TA and one is misc TA.
When I flash baseband, after first time boot, I get NV/TA-log(/nvta_log/log.txt) from EFS Explorer
part in log
Code:
0007933 Loading trim area to NV (<unit> [<size>]):
0009424 0 [4]
0009425 1 [4]
0009425 4 [1]
0009425 5 [1]
0009425 6 [1]
0009425 7 [2]
0009426 8 [1]
0009426 9 [2]
.......
and I have compared nv unit in ta parition 1
all units are loading from trim area partition 1
then I conpared the units and qcn dump
most of the units map to nv iem and the have same id.
and another units are files in /nv/item_files/rfnv , the unit id same as file name.
We can see most of baseband init configuration are from TA partition 1.
In misc TA (TA partition 2)
there have some thin about signed imei, DRM info, WLAN MAC address and some device only thing, but I noticed unit 000009F7, this is a name decision to load witch baseband config in amss_fs_3(m9kefs3 partition)
here is another part of NV/TA_log
Code:
0007883 nvpreload/nv_L1245_17W12458.bin removed successfully.
0007883 nvpreload/nv_L1245_17W12458_cal_true.bin removed successfully.
0007884 nvpreload/nv_L1245_17W12458_ets.bin removed successfully.
0007884 nvpreload/nv_L1_19_21W156_19.bin removed successfully.
0007884 nvpreload/nv_L1_19_21W156_19_cal_true.bin removed successfully.
0007884 nvpreload/nv_L1_19_21W156_19_ets.bin removed successfully.
0007884 nvpreload/nv_W12458.bin removed successfully.
0007884 nvpreload/nv_W12458_cal_true.bin removed successfully.
0007884 nvpreload/nv_W12458_ets.bin removed successfully.
0007885 nvpreload/nv_W1358.bin removed successfully.
0007885 nvpreload/nv_W1358_cal_true.bin removed successfully.
0007885 nvpreload/nv_W1358_ets.bin removed successfully.
0007886 Selecting band configuration file
0007886 Selected band configuration file '/nvpreload/nv_L1357_20W1358_cal_true.bin'.
0007887 /nvpreload/nv_L1357_20W1358_cal_true.bin removed successfully.
0007887 /nvpreload/nv_default_band_cal_true.bin removed successfully.
0007887 Selecting band configuration file
0007887 Selected band configuration file '/nvpreload/nv_L1357_20W1358_ets.bin'.
0007888 /nvpreload/nv_L1357_20W1358_ets.bin removed successfully.
0007888 /nvpreload/nv_default_band_ets.bin removed successfully.
0009793 Selecting band configuration file
0009793 Selected band configuration file '/nvpreload/nv_L1357_20W1358.bin'.
0009795 /nvpreload/nv_L1357_20W1358.bin removed successfully.
0009795 /nvpreload/nv_default_band.bin removed successfully.
when I changed value from W12458 to L1357_20W1358 in unit 000009F7, I successfully changed the baseband configuration.

@SquallATF, very interesting finding.
Do you make additional research about this issue?
I want to understand the contents of the TA units and their purpose.
For example, 000007DA unit contains information about sim-lock state.
Then you change value in one NVitem, does it save after phone reboot?

This is a 6 months old post... ?
Sent from my SM-N910C using Tapatalk

Related

[MOD][HOWTO] Wake Timeout Mod

This is a modification to set the time the screen will stay awake when waking to the lockscreen from sleep, NOT the screen timeout, screen timeout delay, or screen turned off delay which can be changed through setttings. I started looking into this after someone asked in the Q&A forum if CM7 had an option to change this which it does not. The default timeout is 5 seconds, but if you would like the lockscreen to be shown for longer(or shorter) before the screen turns off again, follow this guide. If you'd like to change this but don't know if you can or want to, send me a PM and I'll try and make the mod for you to install or maybe I'll even learn how to put it into a flashable zip. This mod requires root!
After searching around for where this value is set, I came across a thread on another forum which led me to android.policy.jar but I still needed to know which smali/java file to edit. The Android source helped locate the setting and usage of this value in KeyguardViewMediator.java. Near the beginning the defaults are defined(10s if KB open & 5s otherwise):
Code:
/**
* The default amount of time we stay awake (used for all key input)
*/
protected static final int [COLOR="Green"][B]AWAKE_INTERVAL_DEFAULT_MS = 5000[/B][/COLOR];
/**
* The default amount of time we stay awake (used for all key input) when the keyboard is open
*/
protected static final int AWAKE_INTERVAL_DEFAULT_KEYBOARD_OPEN_MS = 10000;
However, in the decoded smali version of this file, changing the values in these definitions don't affect anything. That's why when we edit the smali file later, we change the value where the DEFAULT_MS variable is actually used in the pokeWakelock method:
Code:
public void pokeWakelock() {
pokeWakelock(mKeyboardOpen ?
AWAKE_INTERVAL_DEFAULT_KEYBOARD_OPEN_MS : [COLOR="Green"][B]AWAKE_INTERVAL_DEFAULT_MS[/B][/COLOR]);
}
----------------------------------------
I've only tested this on my Eris running GSB v3.1 - Gingerbread 2.3.4 - CM 7.1.0 RC0. Be sure to make a NAND backup and a backup of android.policy.jar as I can't guarantee this will work for you. If you have problems or just want to switch back to the original 5s timeout, replace the modified android.policy.jar with the backup, wipe cache & dalvik, and reboot or restore from the NAND backup you created.
So how does one go about modifying this wakeup timeout...
For Windows users, download APK Manager, extract it to your preferred location and then follow my step-by-step instructions in this post.
For Mac OSX and Linux users, download apktool from here. You will need both apktool*.tar.bz2 and your OS(linux/macos) specific dependencies(apktool-install-OS-*.tar.bz2). Unpack both and place those files(apktool.jar/apktool/aapt) in /usr/local/bin or wherever as long as it is in your PATH.
Now we need to get android.policy.jar off the phone and onto the computer. ADB is probably the easiest way:
Code:
adb pull /system/framework/android.policy.jar
Next, we want to decode android.policy.jar using apktool:
Code:
apktool d android.policy.jar out
If working correctly, apktool should say "I: Baksmaling..." & "I: Copying assets and libs...". It should also have created the directory "out" that contains "apktool.yml" and a "smali" directory.
Using your favorite text editor, open "out/smali/com/android/internal/policy/impl/KeyguardViewMediator.smali" as it contains the timeout value to modify. Look for ".method public pokeWakelock()V" and but be careful not to be looking at ".method public pokeWakelock(I)V" instead. The method should be near the end and starts at line 2864/3288 in mine. Inside the method there will be two lines starting with "const/16". The first represents AWAKE_INTERVAL_DEFAULT_KEYBOARD_OPEN_MS so we don't need to worry about it for the Eris. The hex value(0x####) in the second is the value for AWAKE_INTERVAL_DEFAULT_MS. The default interval is 5s = 5000ms = 0x1388. Since this value is a 16-bit signed integer value, the max value that can be set is 32767 which makes it a couple seconds over 30. If you change it to a value greater than the max, it will be interpreted as a negative value and your screen will not wake up...trust me, I tried. You can use this decimal to hex converter to determine the hex value you need to replace 1388. For example, 10s would be 0x2710 or 0x7530 for 30s. Make the change and save the file.
To build android.policy.jar with the modification:
Code:
apktool b out
If the build worked correctly, apktool will say "I: Checking whether sources has changed..." & "I: Smaling..." & "W: Could not find resources" & "I: Building apk file...". It should also create the directories "build" and "dist" inside of "out". The "dist" directory holds the modified android.policy.jar file.
The next step is signing the modified android.policy.jar with the testkey. Signing tools: Mac <> Phone <> Linux users can chime in on the easiest way(s) they've found.
All that's left is to replace the original with the mod:
Code:
adb remount #mounts system as r/w
adb push out/dist/android.policy-signed.jar /system/framework/android.policy.jar
adb shell chmod 644 android.policy.jar #permissions = rw-r--r--
adb reboot recovery
#wipe both cache & dalvik-cache
#reboot
Finished! Enjoy your new wake timeout
MongooseHelix said:
This is a modification to set the time the screen will stay awake when waking to the lockscreen from sleep, NOT the screen timeout, screen timeout delay, or screen turned off delay which can be changed through setttings. I started looking into this after someone asked in the Q&A forum if CM7 had an option to change this which it does not. The default timeout is 5 seconds, but if you would like the lockscreen to be shown for longer(or shorter) before the screen turns off again, follow this guide. If you'd like to change this but don't know if you can or want to, send me a PM and I'll try and make the mod for you to install or maybe I'll even learn how to put it into a flashable zip. This mod requires root!
After searching around for where this value is set, I came across a thread on another forum which led me to android.policy.jar but I still needed to know which smali/java file to edit. The Android source helped locate the setting and usage of this value in KeyguardViewMediator.java. Near the beginning the defaults are defined(10s if KB open & 5s otherwise):
Code:
/**
* The default amount of time we stay awake (used for all key input)
*/
protected static final int [COLOR="Green"][B]AWAKE_INTERVAL_DEFAULT_MS = 5000[/B][/COLOR];
/**
* The default amount of time we stay awake (used for all key input) when the keyboard is open
*/
protected static final int AWAKE_INTERVAL_DEFAULT_KEYBOARD_OPEN_MS = 10000;
However, in the decoded smali version of this file, changing the values in these definitions don't affect anything. That's why when we edit the smali file later, we change the value where the DEFAULT_MS variable is actually used in the pokeWakelock method:
Code:
public void pokeWakelock() {
pokeWakelock(mKeyboardOpen ?
AWAKE_INTERVAL_DEFAULT_KEYBOARD_OPEN_MS : [COLOR="Green"][B]AWAKE_INTERVAL_DEFAULT_MS[/B][/COLOR]);
}
----------------------------------------
I've only tested this on my Eris running GSB v3.1 - Gingerbread 2.3.4 - CM 7.1.0 RC0. Be sure to make a NAND backup and a backup of android.policy.jar as I can't guarantee this will work for you. If you have problems or just want to switch back to the original 5s timeout, replace the modified android.policy.jar with the backup, wipe cache & dalvik, and reboot or restore from the NAND backup you created.
So how does one go about modifying this wakeup timeout...
First off, download apktool from here. You will need both apktool*.tar.bz2 and your OS(linux/macos/windows) specific dependencies(apktool-install-OS-*.tar.bz2). Unpack both and place the three files(apktool.jar/apktool/aapt) in /usr/local/bin for linux or mac(use sudo for root access) and to the Windows directory for windows.
Now we need to get android.policy.jar off the phone and onto the computer. ADB is probably the easiest way:
Code:
adb pull /system/framework/android.policy.jar
Next, we want to decode android.policy.jar using apktool:
Code:
apktool d android.policy.jar out
If working correctly, apktool should say "I: Baksmaling..." & "I: Copying assets and libs...". It should also have created the directory "out" that contains "apktool.yml" and a "smali" directory.
Using your favorite text editor, open "out/smali/com/android/internal/policy/impl/KeyguardViewMediator.smali" as it contains the timeout value to modify. Look for ".method public pokeWakelock()V" and but be careful not to be looking at ".method public pokeWakelock(I)V" instead. The method should be near the end and starts at line 2864/3288 in mine. Inside the method there will be two lines starting with "const/16". The first represents AWAKE_INTERVAL_DEFAULT_KEYBOARD_OPEN_MS so we don't need to worry about it for the Eris. The hex value(0x####) in the second is the value for AWAKE_INTERVAL_DEFAULT_MS. The default interval is 5s = 5000ms = 0x1388. Since this value is a 16-bit signed integer value, the max value that can be set is 32767 which makes it a couple seconds over 30. You can use this decimal to hex converter to determine the hex value you need to replace 1388. For example, 10s would be 0x2710 or 0x7530 for 30s. Make the change and save the file.
To build android.policy.jar with the modification:
Code:
apktool b out
If the build worked correctly, apktool will say "I: Checking whether sources has changed..." & "I: Smaling..." & "W: Could not find resources" & "I: Building apk file...". It should also create the directories "build" and "dist" inside of "out". The "dist" directory holds the modified android.policy.jar file.
The next step is signing the modified android.policy.jar with the testkey. Signing tools: Mac <> Phone <> Windows & Linux users can chime in on the easiest way(s) they've found.
All that's left is to replace the original with the mod:
Code:
adb remount #mounts system as r/w
adb push out/dist/android.policy-signed.jar /system/framework/android.policy.jar
adb shell
cd /system/framework
chown 0:0 android.policy.jar #owner:group = root:root
chmod 644 android.policy.jar #permissions = rw-r--r--
#reboot into recovery
#wipe both cache & dalvik-cache
#reboot
Finished! Enjoy your new wake timeout
Click to expand...
Click to collapse
Nice work on this.. thanks for sharing
Anyone developed an easy way to make these changes? An app of some sort perhaps?
This is so when we push the off button, and the lockscreen pops up it stays on for 5000 miliseconds before it goes back off? or so when we push the end button it takes 5000 miliseconds before it turns on?
nevermind reread, The length the lock screen stays on very interesting.
Hey something like this with the lights on - off script should make your phone turn on off the leds, this way we could have the orange and green leds work when charging and so on so forth for the sense 3.5, just an idea probably wrong place for it anyways
Thanks, this worked perfectly on my Desire HD. Lockscreen time out was super annoying when changing songs in my car.
Great work TY!!!

[TOOL] Xflasher (xperia command line flasher for pre 2017 devices)

Disclaimer:
Xflasher tool was made for testing and educational purposes, ME is not responsible for what you do on/with your device using xflasher, you must agree that you using xflasher on your own risk, I am not responsible if you brick your device or anything!
How to use:
(2017 phones like xz premium which have usb vid : pid = 0fce : b00b is not supported since use new flashing protocol! Use newflasher tool if your device usb pid is B00B!!)
1. (this step only for windows version!) install usb drivers the same like one which you using with flashtool
2. simple put xflasher.XXX in firmware dir which is created by great @IgorEisberg tool caled XperiFirm, double click xflasher.exe (or execute xflasher.XXXX in case non windows version) it will create xflasher.bat (or xflasher.sh in case non windows version)
3. modify xflasher.bat (or xflasher.sh in case non windows version) for your needs
4. put your phone into flashing mode (do in mind its not fastboot mode, must be in flash mode!)
5. make sure your battery is enought charged at least 30 percent charged!!!
6. double click xflasher.bat (or run xflasher.sh in case non windows version) and wait until xflasher flash your rom
7. done
8. enjoy
Supported platforms:
- there is 3 versions, one is for Linux, one is for Windows, and one for Android! You can now flash phone trought another phone, so no more needs for PC!!!
Credits:
- @shoey63 for helping me deeply testing xflasher, thanks a lot man!
Source code:
- https://github.com/munjeni/xflasher
is it support for zeus mode xperia m ?
MOD EDIT @gregbradley
Quote removed, not needed and had large images
sorry if im wrong, but this will eventually be able to unlock bootloader?
inunxelex said:
is it support for zeus mode xperia m ?
Click to expand...
Click to collapse
No, this tool use s1 protocol so all phones which use s1 protocol can use this tool!
ayuready1989 said:
sorry if im wrong, but this will eventually be able to unlock bootloader?
Click to expand...
Click to collapse
Only on bootloader unlock allowed phones!
New version is out!
Changelog (v2):
- support for safety unlocking device bootloader (sha256 key check + check rooting alowed yes or no before unlocking)
- support for flashing all sin files from bundle but NOT BOOT BOOTBUNDLE! I will implement boot boondle soon (boot bondle mean: boot delivery from boot folder aka sbl1, s1sbl, dbi, aboot... so please do not flash them since if you flash wrong file you will hard brick your device!)!
- you can change usb VID and PID parameter (but in usb driver do it manualy by self)
Log about success in flashing some sin files is in attachment
After the experience you acquired writing this tool and with the previous research , do you think it would be possible to make backups of TA partition (or at least that area of TA partition that stores DRM keys) even from an unrooted phone?
I mean, personally I have an Xperia S, but I was especially thinking to our friends with a Z3 that aren't able to preserve them atm.
Good question! I thinked the same like you, but there is some problems, for example I have analysed ta and found 4 partitions inside ta, first one is 0100 (aka 01) and seccond one is 0200 (aka 02), booth 1 and 2 can be dumped trought special command to bootloader (flash tool dumping only partition 2 and not all units). But there is other two partitions which is 0101 and another one 0201, I have no idea how to send command to bootloader in order to dump them, for example for dumping first two partitions I need to send command OPEN_TA with partition number as parameter before sending command READ_TA unit, have tried many combinations for opening parrition 0101 but getting error reaply from bootloader which mean parameter error It will be a great having possibility dumping ta in full form without a needs having root, but seems its not possible by now, maybe in future we can do it.
Allso found something interesting. Dump.ta maded by our tool dumping partition 1 and 2, but flashing ta file only partition 1 data is writen since fitst parameter in file is 01 which mean "open partition 1", but to open seccond partition and write seccond partition data we must separate one file into two files since each partition and partition data must be separated since flashtool or s1tool can't see seccond partition parameter, so one file must be cut into 2 files before flashing! In any way you can not brick your phone by not separated files, but only partition 1 will be flashed.
Edit:
Drm keys and all things lives in partition 2 (on rooting allowed devices), I will need to compare s1 dump with ta dump and see what was not dumped from ta. Drm keys for sure missing, probably can not be dumped with reason since it will be easy way tricking Sony bootloader unlocking policy He have designed unlocking procedure to delete drm and probably his bootloader is designed to skip drm dumping Some units magic bytes is masked with ffffffff00000000, have no defined size in header...etc, which probably is with reason hiden to unit dumper command
munjeni, nice work. As fas as I researched, DRM keys are located in Unit 0x1046B. At least this is the unit which the bootloader deletes when it recognizes the device as rooted. I was not able to dump this unit via flashtool. Trying to flash it resulted in:
Code:
ERROR - ERR_SEVERITY="MINOR";ERR_CODE="0026";ERR_DYNAMIC="Not authenticated";
So I guess it's somehow special protected.
I was able to dump the unit with miscta_read_unit (you need atleast system privilegues) but not write to via miscta_write_unit (resulted in error code 3).
We should be able to dump all TA units with system user (in regards to the recent exploit which theoretically allows privilegue escalation to system user).
Problem is we can not simply restore them unless we find a way to generate a TA.img (with correct unit layout) out of unit data.
. .
Check TA.img from locked phone Unit 0x1046B is there with size 0x10. You can also check appsboot loader, if the device is rooted it deletes this unit.
I have used your ta_gen and it had unit 0x1046B inside resulted custreset.ta. You can flash this unit in emergency mode, but not normal mode (see previous post).
zxz0O0 said:
Check TA.img from locked phone Unit 0x1046B is there with size 0x10. You can also check appsboot loader, if the device is rooted it deletes this unit.
I have used your ta_gen and it had unit 0x1046B inside resulted custreset.ta. You can flash this unit in emergency mode, but not normal mode (see previous post).
Click to expand...
Click to collapse
You are right, its on partition 1! Will try something now related to our tool (seems I have s1 dump of unlocked ta since I can not see these unit by now in dump). But if my tool can dump these unit than probably we can reconstruct ta img from s1 dump, see my previous post (explained everything related to partitions and units)!
Tool can not read these unit
Log:
Want read ta unit 0001046B...
Sending command...
Command raw[13]:
00000000 00 00 00 0C 00 00 00 03 00 00 00 04 12 .............
Sending command...
Want unit raw[4]:
00000000 00 01 04 6B ...k
CRC32[4]:
00000000 BF CE 17 E3 ....
Writing crc32 for want read ta unit...
Verifying crc32...
Error: device reported that wanted ta unit is not found or can not be read!
Success: bulk read 4 bytes
Raw reply[4]:
00000000 00 00 00 00 ....
Error reading unit 0001046B!
Click to expand...
Click to collapse
So non rooted device have no chance having full ta dump since unit 1046B will be missed in s1 dump Maybe we can generate these unit? And how? Its probably MD5??? Or probably 3 x crc32 of the MARLIN+CKB+WMLA + 1 x crc32 of the crc32+crc32+crc32 ??
zxz0O0 said:
I was able to dump the unit with miscta_read_unit (you need atleast system privilegues) but not write to via miscta_write_unit (resulted in error code 3).
We should be able to dump all TA units with system user (in regards to the recent exploit which theoretically allows privilegue escalation to system user).
.
Click to expand...
Click to collapse
Ahh I see, how you dump these unit trought system user?
munjeni said:
Tool can not read these unit
Log:
So non rooted device have no chance having full ta dump since unit 1046B will be missed in s1 dump Maybe we can generate these unit? And how? Its probably MD5??? Or probably 3 x crc32 of the MARLIN+CKB+WMLA + 1 x crc32 of the crc32+crc32+crc32 ??
Click to expand...
Click to collapse
There is a command 0x19 (hook), I will try with hooking first and see whats happening!
zxz0O0 said:
Check TA.img from locked phone Unit 0x1046B is there with size 0x10. You can also check appsboot loader, if the device is rooted it deletes this unit.
I have used your ta_gen and it had unit 0x1046B inside resulted custreset.ta. You can flash this unit in emergency mode, but not normal mode (see previous post).
Click to expand...
Click to collapse
You need to change first argument in ta "02" to "01" since these unit is in partition 01 but be carefull since I do not know if some units from partition 02 exist in partition 01 since if you flash wrong data you can get brick! My tool was helper tool only for unbricking devices, I need to modify my tool a bit for that since I was not know about partitions in ta!
You can use miscta_read_unit from libmiscta.so to read this unit.
Code:
static int (*_miscta_read_unit)(int TAUnit, void* buf, int* size)
But you need system or root privileges.
Hopefully you can update your ta_gen tool since it could not unbrick my device. There should be a command to format TA (maybe 0x0B?). Maybe we can send this command before restoring TA backup for successful unbrick.
zxz0O0 said:
You can use miscta_read_unit from libmiscta.so to read this unit.
Code:
static int (*_miscta_read_unit)(int TAUnit, void* buf, int* size)
But you need system or root privileges.
Hopefully you can update your ta_gen tool since it could not unbrick my device. There should be a command to format TA (maybe 0x0B?). Maybe we can send this command before restoring TA backup for successful unbrick.
Click to expand...
Click to collapse
Which device you have? If your ta partition is bricked or formated you will have chance to unbrick only by emmc tool or by jtag tool!
Commands in s1 protocol:
Code:
#define CMD_LOADER_INFO "\x00\x00\x00\x01" /* loader info (hook phone in flashmode) */
#define CMD_FLASHMODE_OFF "\x00\x00\x00\x04" /* Kick device off flashmode */
#define CMD_WRITE_SIN_HEADER "\x00\x00\x00\x05" /* write SIN header */
#define CMD_WRITE_SIN "\x00\x00\x00\x06" /* write SIN */
#define CMD_GET_LAST_ERROR "\x00\x00\x00\x07" /* Get last error */
#define CMD_OPEN_TA "\x00\x00\x00\x09" /* open TA (takes the partition number as parameter) */
#define CMD_CLOSE_TA "\x00\x00\x00\x0A" /* close TA */
#define CMD_READ_TA "\x00\x00\x00\x0C" /* read TA */
#define CMD_WRITE_TA "\x00\x00\x00\x0D" /* write TA */
#define CMD_DISABLE_VERIFICATION "\x00\x00\x00\x19" /* Disable Final Verification check ? */
Not sure about 0B and allso not going to try them since I allready changed my mainboard after bricking ta partition
Tried to read unit 1046B after writing coomand hook but stil no chance dumping them trought s1. In next few days I will focus on generating ta.img from s1 dump and will analyse things more
I have Z1 Compact and tried to recover using your ta_gen and s1tool. But still dead I don't own a jtag device nor have any experience using it.

exporting data from Xiaomi Mi Band app (version 1.1.961)

I got my Mi Band yesterday and I am trying to reverse engineer how to export my data from the Mi Band app to something where I can keep and aggregate it.
I found user-db sqlite database on my phone (data/com.xiaomi.hm.health/databases). I opened the file and there is a LUA_LIST table. That table contains what looks to be the step data.
The problem is that I can't figure out how the values work. There is START and STOP column. I tried summing up all the steps from today but it doesn't add up to what my phone is displaying.
Any ideas?
**UPDATE**
I figured out that the date stored in the user db corresponds to the date on the "details" screen (screenshot from app)
My Query (id 5 is the first data point for January 22)
select sum (steps) from (
select sum (start) as steps from lua_LIST
where _id > 5
union
select sum (stop) as steps from lua_LIST
where _id > 5) as t
Latest update: please get the latest version from this thread: http://forum.xda-developers.com/general/accessories/xiaomi-mi-band-data-extraction-t3019156
I wrote the script to extract all activity from origin_db database. This works for me for MI software version 1.2.442. If you have sqlite3 installed on windows, you can run following from command line:
sqlite3 origin_db < miband.sql
It would generate extract.csv file with all sleep and activity data.
tehcypress said:
export my data from the Mi Band app to something where I can keep and aggregate it
Click to expand...
Click to collapse
Here Android application / Tasker profile for extracting stats into CSV / HTML.
Based on parsing templates by @xmxm, taken from his Windows-app above.

Shared Preferences with Xposed

I try to get shared preferences in the exposed class.
This is a straight forward issue in android java. I do not know whether the permissions are the problem but things are not as straight with Xposed.
Xposed asks to provide the name of the file and the package at init Zigote. I have tried many versions and none of them seems to work. Also, the file which I make may not be available when init Zygote is called, however, I take XposedBridge wants to just register the name of the file and, probably, to prepare to override some permissions when the file is created.
I also try to double the call to the Xposed Shared Method inside the hooked method. I check for the existence of the shared preference file before. Everything is there but the reload method does not seem to reload and the file is not read but defaults are loaded by getInt and getFloat.
There is probably something more to be done, although the examples I have seen do not do anything, yet they override other methods inside init Zygote which I do not need to do.
All I need is to read a simple file from an Xposed Module.
PLEASE, INFORM.
Here is what I have tried :
I have tried many different variation and XposedBridge methods for 4 hours. I have also
tried many name variations with and without .xml.
In the standard Java for Android, there is just one get method to read a shared
preferences file. This does not seem to be the case with exposed.
I do have :
@override
public void initZygote(StartupParam startupParam) throws Throwable {
MODULE_PATH = startupParam.modulePath;
prefs = new XSharedPreferences("PackageName", "SharedPreferenceFileNameWithotDotXml");
}
MODULE_PATH is not used, although I have tried many other methods where was.
Because the file changes on the fly, I called :
prefs.reload();
before I read the data. I tried without this call too. I also tried to get another
prefs before the reload :
prefs = new XSharedPreferences("PackageName", "SharedPreferenceFileNameWithotDotXml");
prefs.reload();
Then I try to read the data from the file :
theStart=prefs.getInt("Start", 2);
theValue=prefs.getFloat("Value", 102.0f);
I always get the defaults 2 and 102.0 although the file is there and the values of the
file are different. I have read the file.
In standard java for android philosophy, just the initialisation in init zygote and
prefs.reload() are sufficient to load the changing values of the shared preferences
file into prefs and then into the variables.
Xposed seems to be different.
I have been told there is a way to read the data from the file. I have tried most
anything and cannot. What is the way to do so. Must be simple and straight as in the
standard java for android. I must not do everything necessary.
Please, inform.
I have also tried to read the file manually from the Xposed class. Access denied. Tried
just in cases. Access denied, again.
Tried to make the shared preferences file with Activity.MODE_WORLD_READABLE. Still
access denied to be read manually.
Even with Activity.MODE_WORLD_READABLE, Xposed cannot read the file as previously
explained.
Tried :
@override
public void initZygote(StartupParam startupParam) throws Throwable {
prefs = new XSharedPreferences(TheNameOfTheXposedClass.class.getPackage().getName
());
prefs.makeWorldReadable();
}
Then, in the hooked method :
prefs.reload();
theStart = prefs.getInt("Start", 2);
theValue = prefs.getFloat("Value", 102.0f);
Still returns only the default, although the file is there. I think, in all attempts,
XSharedPreferences() cannot get the name of the package and or or the name of the file.
The file is in /data/data/NameOfPackage/shared_prefs/NameOfFile.xml
Tried :
@override
public void initZygote(StartupParam startupParam) throws Throwable {
prefs = new XSharedPreferences
("/data/data/NameOfPackage/shared_prefs/NameOfFile.xml");
prefs.makeWorldReadable();
}
with and without .xml
Still nothing.
PROBLEM SOLVED.
Thank you for your reply. Everything was WORLD READABLE : in the non Xposed class and in the Xposed class on a number of occasions.
Also, I have used the hard values for the package and path.
The problem was not related to Java and Android but to Android arrangements and how much Xposed can cope with. The Android permissions for to access the file from the Xposed class had to be elevated which is unusual but this is what solved the problem, I think. Someone also reported the same problem and the same solution : http://forum.xda-developers.com/xposed/development-xsharedpreferences-issue-t2931396
In the non Xposed class, I have used the same solution just with a hard coded path and file. After I make the shared preferences file in the non Xposed class, I gave more permissions by :
File theSharedPrefsFile;
theSharedPrefsFile = new File("/data/data/PackageName/shared_prefs/FileName.xml");
theSharedPrefsFile.setReadable(true, false);
This seems to have solved the problem.
I am not sure of how reliable the solution is, though. I still check in the Xposed class whethere there is such a file or not. I have not tested what happens when the file is not there initially. Must do.
theXposedCommunicationPreferenceFile = new File("/data/data/PackageName/shared_prefs/FileName.xml");
if (theXposedCommunicationPreferenceFile.exists() == false) XposedBridge.log("Check in hooked method cannot find the file");
Hope everything would be OK.
Even though everything should be OK, I am not sure how reliable the dependence of permissions is.
I have also tried the secure reload :
StrictMode.ThreadPolicy oldPolicy;
oldPolicy = StrictMode.allowThreadDiskReads();
try {
prefs.reload();
} finally {
StrictMode.setThreadPolicy(oldPolicy);
}
I am not sure how reliable this is either so I put another simple reload on top :
prefs.reload();
StrictMode.ThreadPolicy oldPolicy;
oldPolicy = StrictMode.allowThreadDiskReads();
try {
prefs.reload();
} finally {
StrictMode.setThreadPolicy(oldPolicy);
}
I think, neither of these has made any difference and the real solution was the higher permissions to access the shared preference file given in the non Xposed class, again :
File theSharedPrefsFile;
theSharedPrefsFile = new File("/data/data/PackageName/shared_prefs/FileName.xml");
theSharedPrefsFile.setReadable(true, false);
Pretty nasty problem and difficult to find solution although published in the XDA Forum the searchability of post in the said forum is not very good.
Yet another sleepless night.
StevenStanleyBayes said:
I think, neither of these has made any difference and the real solution was the higher permissions to access the shared preference file given in the non Xposed class, again :
Click to expand...
Click to collapse
I know this is a pretty old thread but I have elevated the permission level to 777 of both the dir and preferences file and yet cannot access the file from the xposedClass is there any chance you are still developing xposed modules and can help

Kotlin app can't find file even though it exists

I'm working on a Kotlin app where I need to access the Cookies file located at /data/data/com.android.chrome/app_chrome/Default/Cookies. However, when I try to access the file, I get a "file not found" error, even though the file definitely exists at that location.
I've double-checked the file path and made sure there are no typos (I can see the file with adb shell and Amaze File Manager), and I've also checked that the app has permission to access the file (app has root permissions).
First I was trying to open and read the file directly and I got the error:
CODE at https://stackoverflow.com/questions/76064385/kotlin-app-cant-find-file-even-though-it-exists
I though maybe Chrome was running so I couldn't open the file directly so I tried copying it to a temp folder and reading that:
CODE at https://stackoverflow.com/questions/76064385/kotlin-app-cant-find-file-even-though-it-exists
But that still fails:
CODE at https://stackoverflow.com/questions/76064385/kotlin-app-cant-find-file-even-though-it-exists
Is there anything else I can try to troubleshoot this issue?
Something in the code triggers cloudflare and blocks me from posting
Code:
Sorry, you have been blocked
You are unable to access xda-developers.com
Why have I been blocked?
This website is using a security service to protect itself from online attacks. The action you just performed triggered the security solution. There are several actions that could trigger this block including submitting a certain word or phrase, a SQL command or malformed data.
What can I do to resolve this?
You can email the site owner to let them know you were blocked. Please include what you were doing when this page came up and the Cloudflare Ray ID found at the bottom of this page.
Cloudflare Ray ID: 7badda7c6b9486c6 • Your IP: Click to reveal • Performance & security by Cloudflare
SQLite definitely won't open the file. So, your decision to copy it was right.
Firstly, try to split the single command string into an array.
The documentation for ProcessBuilder class has an example:
ProcessBuilder pb = new ProcessBuilder("myCommand", "myArg1", "myArg2");
Or try to use SuFile from the libsu, for example:
AndroidIDeditor/Util.java at 6a62bac0e3e63502e9a7b538217f65189ff85fa4 · sdex/AndroidIDeditor
Android Device ID changer. Contribute to sdex/AndroidIDeditor development by creating an account on GitHub.
github.com
lioce said:
SQLite definitely won't open the file. So, your decision to copy it was right.
Firstly, try to split the single command string into an array.
The documentation for ProcessBuilder class has an example:
ProcessBuilder pb = new ProcessBuilder("myCommand", "myArg1", "myArg2");
Or try to use SuFile from the libsu, for example:
AndroidIDeditor/Util.java at 6a62bac0e3e63502e9a7b538217f65189ff85fa4 · sdex/AndroidIDeditor
Android Device ID changer. Contribute to sdex/AndroidIDeditor development by creating an account on GitHub.
github.com
Click to expand...
Click to collapse
Seems like not even like that can I read the Cookies file from Chrome
Code:
fun copyFile(source: String, destination: String) {
Log.d("CookieSwapLogger", "copyFile '$source' to '$destination'")
val sourceFile = SuFile(source)
if (sourceFile.exists()) {
Log.d("CookieSwapLogger", "sourceFile.exists")
} else {
Log.d("CookieSwapLogger", "sourceFile.notExists")
}
---------------
2023-04-21 18:20:47.440 6347-6347 CookieSwapLogger com.david.cookieswapper D copyFile '/data/data/com.android.chrome/app_chrome/Default/Cookies' to '/data/user/0/com.david.cookieswapper/app_temp/Cookies'
2023-04-21 18:20:47.492 6347-6347 CookieSwapLogger com.david.cookieswapper D sourceFile.notExists

Categories

Resources