You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Whilst working with iTunes backups I noted that a timestamp of: -63114076800, results in the value 281411862633856 which is exactly 2^48 - 63114076800
As far as I know has to do with the Cocoa Core Data epoch (for which 0 = 01-01-2001, so -63114076800 = 01-01-0001)
Not sure if this lies within the responsibility of the dissect framework, however it does cause issues when parsing these entries. Is there any way to circumvent this?
sqlite> SELECT \* FROM ZPROCESS WHERE ZPROCNAME = "budd/com.apple.datausage.general";
1304|7|1|751544175.039578|-63114076800|com.apple.datausage.general||budd/com.apple.datausage.general
Hi Olaf, thank you for noticing and submitting this issue.
I briefly looked into the issue and it looks like that in this case key 5 for SERIAL_TYPES in c_sqlite3.py should be an int48 instead of uint48. Looking at sqlite file format in 2.1, this also explains it should be an int48, if I'm correct.
@Schamper since you've committed this code, do you maybe know how this SERIAL_TYPES mapping came to be?
Whilst working with iTunes backups I noted that a timestamp of: -63114076800, results in the value 281411862633856 which is exactly 2^48 - 63114076800
As far as I know has to do with the Cocoa Core Data epoch (for which 0 = 01-01-2001, so -63114076800 = 01-01-0001)
Not sure if this lies within the responsibility of the dissect framework, however it does cause issues when parsing these entries. Is there any way to circumvent this?
Values that show the problem:
The text was updated successfully, but these errors were encountered: