Parsing Apple Sysdiagnose, Unified Logs and Android Bug Reports: A Review of Public Research and Tools

I. Introduction

A current iPhone writes a sysdiagnose on request and an Android phone writes a bug report on request. Neither needs a commercial extraction tool or an unlocked boot loader, and each bundles the output of many system services, one or more logs and copies of system files. For that reason both are used as evidence sources in security triage and in forensic work, and both are read by a growing set of open-source parsers. A parser that reads such a bundle decides what the examiner sees: which sections become tables, which are skipped, which are cut by a limit, and in which time zone a time is shown. Where the parsers and the studies of them are scattered across repositories, issue trackers, blogs and a few papers, an author who needs related work, or an examiner who needs to know what exists, has no single place to look.

This report collects that landscape for three sources: the Apple sysdiagnose archive, the Apple unified log (the logarchive folder and the underlying tracev3 files), and the Android bug report (also called dumpstate output). We ask three questions.

• RQ1. Which public tools process these bundles, with what input, coverage, licence and maintenance status?
• RQ2. Which published works, indexed or not, treat the bundles or their parsers as the subject?
• RQ3. Which problems do the sources raise and leave open?

Contributions. (1) A search protocol with fixed queries, dates, counts and inclusion criteria, and a list of what could not be searched (Section III). (2) A matrix of 16 tools whose licence, input, stated coverage and maintenance fields were read from the repository or its API on one date (Section IV-A, Table III), and a table of the published and practitioner works that bear on the subject (Section IV-B, Table IV). (3) Five open problems, each tied to the sources that raise it (Section VI). We state the limits plainly: this is a structured review of public work and not a systematic review, and we did not run, test or compare the tools.

Disclosure. The author contributed the Android bug report modules of ALEAPP [1] and some iLEAPP artifacts, and wrote two earlier Lab reports on these bundles [2], [3]. These tools are entered in Table III with the same fields as every other tool.

II. Background

A. The Apple sources

A sysdiagnose is a large archive that an Apple device writes on request; it includes a copy of the unified log as a system_logs.logarchive folder and many other files [4]. Each unified log record carries a time, a process, a subsystem and category, a level and a message; decoders such as the open-source Rust library of Mandiant read the tracev3 files without macOS [5]. Two practitioner sources contrast the retention of the two routes: a sysdiagnose holds roughly the last day of activity in detail, while unified logs collected directly can reach back about ten days or more [6], [7]. Format change between releases is recorded in tool trackers, for example a report that a decoder printed three kinds of error on iOS 27 archives and that some entries were missing from its output [8].

B. The Android source

A bug report is a zip file whose principal member is a text file with the output of dumpsys, dumpstate and logcat [9]. The file format has versions: a flat text file before Android 6, a zip written by the shell in Android 6, a zip written by dumpstate with a version.txt and a main-entry file in Android 7, ANR traces in Android 8, and services dumped by priority with per-service protocol buffers in Android 9 [10]. The reading guide states that system and event log times are in the user’s time zone, that kernel entries carry seconds since the boot loader finished, and that timelines “are often reported using different time bases” [9]. It also states limits on some sections, for example the last 300 foreground and 300 background broadcasts in the summary and the last 50 of each in the detail [9].

III. Review Protocol

The protocol follows the structure of the guidelines of Kitchenham and Charters [11] (questions, search strategy, inclusion criteria, selection) but not their requirement of a second screener, and the review is therefore called structured and not systematic. Fig. 1 summarises the flow.

A. Searches

All searches were run on 5 November 2026 (local time) with the queries of Table I and Table II; none was changed after its results were seen, except as described next. A first run with unscoped keyword queries was discarded before screening, because Crossref and Zenodo returned ranked lists of tens of thousands of records for multi-word terms; the scoped queries below replaced it, and the totals of the first run are not used. Crossref was queried on the title field with the query words, and only the first 15 results per query were screened, so its totals are not meaningful and are not reported. Semantic Scholar returned HTTP 429 for Q2; a retry with a revised query returned two records, neither relevant. The arXiv endpoint was checked with a query that returns results (all:android AND all:forensic, 54 records) to confirm that its zero counts for Q1 to Q7 were not an access failure. In addition we ran six web searches with a US-only search tool; the topics were published work on sysdiagnose, Android bug report forensics in Digital Investigation, a document attributed in our own notes to Epifani and Leong (not found), the DFRWS workshop on sysdiagnose, the Kitchenham guidelines, and Android bug reports with Plaso. On a second reading of the Crossref results for Q4, one work missed at first screening was added (Table IV).

B. Inclusion and exclusion

A repository or a work was included if it met I1 and I2, and excluded under E1 to E4.

• I1. It parses, extracts from or analyses a sysdiagnose archive, a unified log archive or a tracev3 file, or an Android bug report or dumpstate text (for a work: it treats such a bundle or its content as the subject or the main data).
• I2. Its code or text is publicly readable.
• E1. Collection only: tools that produce the bundle but do not read it (for example collectors such as androidqf).
• E2. Documentation or data without code (for the tool table; such repositories are cited in the text where they matter).
• E3. Unrelated uses of the same word.
• E4. For the tool table only: fewer than 3 stars on 5 November 2026 unless the tool was added by snowballing. The threshold is a pragmatic proxy for use; it is not a quality judgement.

Of the 92 repositories, 46 met I1 judged from the name and description, 10 were documentation or data, 18 were unrelated, and 18 could not be judged from name and description (empty or too vague). Four labels were changed on a second reading before these counts were fixed: two repositories about the dumpstate output of launchctl and one about a generic log-template algorithm moved from analysis code to unrelated, and one with a vague description moved to not judged. Of the 46, nine had at least 3 stars; one of the nine is an add-on to another tool set and was set aside. Eight further tools were added by snowballing, that is, from documents read during the review and from the web searches: macos-UnifiedLogs, iLEAPP, ALEAPP, MVT, iShutdown [12], BugReportParser, mobipwn and the sysdiagnose extractor library. The tool table therefore holds 16 tools. It is not a census: 37 further repositories met I1 but had fewer than 3 stars, 18 could not be judged, and some tools may have no GitHub repository.

C. Verification of the tool fields

For each tool in Table III the licence was taken from the licence file read through the GitHub API (“none declared” means no licence file at the repository root), the creation date and the date of the last commit on the default branch from the API, the latest release from the releases list, and the input and coverage from the README or, for iLEAPP and ALEAPP, from a listing of the repository tree in which the artifact decorators were counted. Coverage in the table is what the documentation states; no tool was run. Counts of modules or artifact functions are counts of files or decorators and do not show how many of them work on a given input.

D. What could not be searched

The following were not searched. IEEE Xplore, the ACM Digital Library and ScienceDirect cannot be queried with the tools available for this review, and no manual searches were made in them. Google Scholar was not queried. dblp returned a bot challenge to automated requests. The first Semantic Scholar attempt for Q2 failed (above). The DFRWS proceedings, Forensic Science International: Digital Investigation, and JDFSL were reached only through the open indexes and web search. Commercial tool documentation, vendor release notes, forums and non-English sources were not searched systematically. A null result from any index in Table I therefore means “not returned by this query”, not “does not exist”.

IV. The Landscape

A. Tools

Table III lists the 16 tools, and Fig. 2 shows the inputs each one names. Nine accept an Apple input, nine an Android bug report, and two (MVT and mobipwn) both. Licences are EUPL-1.2 (two tools), Apache-2.0 (three), MIT (five), MVT License 1.1 (one), a licence file with Apache 2.0 text that GitHub does not identify (one), and no licence file (four). Eleven have a commit in the 12 months before the snapshot and five do not (Fig. 3); two are archived. Only macos-UnifiedLogs, iLEAPP, ALEAPP, MVT and ChkBugReport have a published release that is not marked as a pre-release.

Four observations follow from the table and are limited to what the documentation says. First, most tools serve one platform: only MVT and mobipwn name both an Apple and an Android bundle (Fig. 2). Second, several tools are built on or around others: the sysdiagnose extractor library re-implements SAF identifiers [14], and mobipwn is published by the same GitHub account as the two extractor libraries [20]. Third, the tools that read bug reports include small single-purpose parsers, one archived tool that targets battery data [24], an archived converter to HTML [25], and collections of many modules [21], [19]. Fourth, documentation states a limit in three places that affect completeness: a default line limit for the optional unified log decode [14], an event cap on bug report logcat and on timeline export [23], and the known limits of the Rust decoder [5]. Whether a tool’s output marks that such a limit was reached was not tested.

B. Published and practitioner work

Table IV lists the published works that bear on the subject and the practitioner material that we read. The indexed works are few and each treats a narrow question: one artifact in one iOS version [29], a clock change seen in the unified log of one macOS release [30], dumpsys output as evidence of driver distraction [31], an analysis of Android device logs [32], a bachelor’s thesis in which a bug report is one input of a logical acquisition [33], a 2026 dataset paper that releases raw bug reports [34], [35], and a 2026 conference paper by the same authors that applies thirteen log-template parsers to the log lines of that dataset [36]. That last work is the nearest to a parser evaluation: it characterises how much each template parser abstracts, its coverage, failure modes and runtime, and states that it is not an accuracy benchmark; it concerns log lines, not the parsers of the bundle itself. In the indexes we could query, none of the works evaluates the output of a parser of a sysdiagnose, unified log or bug report bundle, or compares the structure of a bundle across releases. The Lab’s own preprints that surfaced are not counted as independent work; two treat these bundles directly [2], [3].

The practitioner material is larger. It covers collection how-tos and retention [6], [7], single-file detection [12], pipelines [38], [28], a reading-host constraint [4], and the difficulty of bug reports [40]. We did not retrieve the document by Epifani, Mahalik and Cheeky4n6monkey that the README of their scripts names [17]; it is listed in Table IV only through that README, and its venue and review status are unknown to us.

C. A dated view of change

Fig. 4 puts the dated public events of the last five months on one axis. Between 2 July and 14 September 2026, a possible logarchive format change in macOS 27 was reported [42], a failure on iOS 27 archives was reported [8], a decompression change was merged [43] and a release followed [44]; the changelog dates that release 12 September and GitHub dates it 14 September. On the Android side, release notes of one tool list bug report changes in three releases between 1 and 28 September 2026 [45], among them a change to read file times in the device’s time zone and a change so that a section’s timing line is not taken as a section boundary. The author’s own ALEAPP modules were merged on 26 and 27 October [1]. These events show that change between releases is mostly tracked as bugs in issue trackers and release notes.

V. Findings

Table V answers the research questions from the evidence above.

Two statements in Table V are scoped to the searches and not to the world: the absence of an evaluation of parser output and of a cross-release comparison is a result about what the queries in Tables I and II returned and what we read. Section III-D lists the indexes that were not searched.

VI. Open Problems

A. Reporting of truncation

Truncation occurs at three levels in the sources: the platform limits some sections (the broadcast history above [9]), a parser may limit its input or output (the caps in Table III), and a decoder may lose records without stopping (the report of missing entries [8]). The documentation we read states the caps of two tools; we did not test whether either marks in its output that a cap was reached. An earlier Lab report describes a section reader for bug reports built to make such silent failures visible [2]; no source we read states a common way to report truncation. The question for each parser is whether an empty or short table can be told from an absent record, and the sources do not answer it.

B. Time zone handling

Sources state that bug report logs use the user’s time zone and that kernel times count from boot [9], that the Rust decoder extracts a time zone field [5], that a parser changed to read bug report file times in the device’s time zone [45], and that a module of iLEAPP converts a sysdiagnose time to UTC where the folder name records an offset and leaves it blank where it does not [15]. Practitioner writing names time formats and inconsistent times as a difficulty [39], [40], and the macOS study shows that a clock change is itself written to the unified log [30]. We found no document that states, for a given parser, how a time without a zone is resolved or how an ambiguous local time at a daylight-saving change is handled.

C. Validation corpora

Public inputs exist: sysdiagnose archives for unit testing in the SAF project [46], test archives used by the iLEAPP and ALEAPP projects [15], [21], and 45 raw bug reports from 15 devices in the ABRLog dataset [35]. We did not download them. From the descriptions we read, none comes with an independent record of what the device wrote against which a parser’s output can be scored: ABRLog publishes parsed files made by its own two extraction strategies [34], and the test data of a tool is made for that tool. The dataset authors state a machine-learning aim; their later benchmark runs thirteen template parsers over the dataset’s log lines and states that the corpus has no ground-truth templates, so it is not an accuracy benchmark [36]. A corpus of iOS 27 unified logs with known contents was not found.

D. Change across versions

Cross-version change is acknowledged in a talk abstract [38], in the MVT documentation that bug reports “can be inconsistent in format and structure across different Android versions and device vendors” [47], in the AOSP format history [10], in the tested-version list of SAF [13], and in the trackers of Fig. 4. We found no public inventory of structural differences between releases for either platform. The Lab’s report on iOS 27 sysdiagnoses tests one such change on ten archives [3] and is a single study; whether the same archives read the same way in each tool of Table III is not known.

E. Error rates

None of the sources we read reports an error rate for a sysdiagnose, unified log or bug report parser. The one benchmark of template parsers on bug report log lines reports abstraction, coverage, failure modes and runtime and states that it is not an accuracy benchmark [36]. The Rust decoder lists qualitative limits [5]; MVT states that its Android capabilities are limited by format inconsistency [47]; general work on tool testing argues for validation in the field [37], but we did not find it applied to these parsers. Without a reference corpus (Section VI-C) an error rate cannot be defined, and without the cross-version inventory (Section VI-D) one rate would not cover more than the version tested. We did not measure any rate in this review.

VII. Threats to Validity and Limitations

• One screener. The author screened alone. The inclusion decisions for 92 repositories rest on names and descriptions, and 18 could not be judged.
• Search coverage. GitHub repository search matches words in names and descriptions; snowballing added eight tools, so other tools may be missing. The literature indexes searched are open and incomplete; the three publisher indexes named in Section III-D were not searched, so indexed works may exist that we did not see.
• Documentation, not behaviour. Coverage statements are what a README or a file listing says. No tool was run, and a count of modules or artifact functions is a count of files or decorators.
• Snapshot. Every repository field was read on one day, and several of these projects change weekly (Fig. 4). The table will be out of date.
• Conflict of interest. The author contributed the ALEAPP bug report modules and some iLEAPP artifacts, and two of the Lab’s reports are cited. The fields for those tools were read the same way as for the others, but a reader should weigh this.
• Language and venue. Only two non-English records were found, by chance; non-English literature was not searched. We did not check the review process of each venue, and Table IV does not claim peer review for any work.
• Dates. A few dates conflict within a source (the v0.7.0 notes are dated 12 September, the release 14 September); we give both.

VIII. Conclusion and Future Work

Public parsing of sysdiagnose archives, unified logs and Android bug reports is carried mostly by open-source tools, practitioner writing and issue trackers. Sixteen tools meet our criteria, they differ in input, stated coverage and licence, and eleven were active in the year before the snapshot; the indexed literature we could search is thin and narrow, and none of it evaluates parser output. The open problems are practical ones: how a parser reports what it cut, how it resolves a time, what a parser can be scored against, how structure changes between releases, and with what error.

Future work is to run the searches in IEEE Xplore, the ACM Digital Library and ScienceDirect and to search dblp by hand, to have a second reviewer screen, to repeat the snapshot at a stated interval, and to test, on shared synthetic inputs and pinned releases, whether the tools of Table III mark truncation and how they resolve times. Such a test is not part of this report; it would turn the open problems of Sections VI-A, VI-B and VI-E into measurements.

Ethics and Data Statement

This review uses public sources only: repository metadata, documentation and release notes read through the GitHub API and web pages, bibliographic records, and published works. No device extraction, image or bug report was opened for it. The report contains no identifiers, personal data, message or file content, or case information. No offensive technique, exploit or credential-recovery method is described, and no tool was run.

Acknowledgment

Parts of the tooling, data checks and drafting for this work were produced with AI assistance (Anthropic Claude); the author reviewed and ran the results and is responsible for the content.

References

1. D. Addai, “Android bug report artifacts,” ALEAPP pull requests #1795, #1796, #1809, #1816, #1817, #1818 and #1819, merged Oct. 26–27, 2026. Accessed: Nov. 5, 2026
2. D. Addai, “Making silent failures visible: a single-pass section reader for Android bug reports,” Lab Tech. Rep. LAB-TR-0001, version 1.1, SectraTEK Lab, Prudential Associates, Oct. 2026, doi: 10.5281/zenodo.23719508. (Zenodo record read through the API on Nov. 5, 2026; the Lab’s own report.)
3. D. Addai, “Log compression and archive structure in the iOS 27.0 sysdiagnose: an early observation tested against ten archives,” Lab Tech. Rep. LAB-TR-0011, version 1.2, SectraTEK Lab, Prudential Associates, Oct. 2026, doi: 10.5281/zenodo.23720069. (Zenodo record read through the API on Nov. 5, 2026; the Lab’s own report.)
4. hoakley, “Explainer: sysdiagnose and logarchives,” The Eclectic Light Company, Jun. 27, 2026. Accessed: Nov. 5, 2026. [Online]. Available: https://eclecticlight.co/2026/06/27/explainer-sysdiagnose-and-logarchives/
5. Mandiant, “macos-UnifiedLogs,” GitHub repository (Apache-2.0). Accessed: Nov. 5, 2026. [Online]. Available: https://github.com/mandiant/macos-UnifiedLogs
6. O. Afonin, “Extracting and analyzing Apple sysdiagnose logs,” ElcomSoft blog, Jun. 27, 2025. Accessed: Nov. 5, 2026. [Online]. Available: https://blog.elcomsoft.com/2025/06/extracting-and-analyzing-apple-unified-logs/
7. Elcomsoft R&D, “Extracting Apple unified logs,” ElcomSoft blog, Oct. 13, 2025. Accessed: Nov. 5, 2026. [Online]. Available: https://blog.elcomsoft.com/2025/10/extracting-apple-unified-logs/
8. lukbukkit, “Parsing of iOS 27 log archives partially fails,” macos-UnifiedLogs issue #145, opened Aug. 4, 2026, closed Aug. 27, 2026. Accessed: Nov. 5, 2026. [Online]. Available: https://github.com/mandiant/macos-UnifiedLogs/issues/145
9. Android Open Source Project, “Read bug reports,” source.android.com. Accessed: Nov. 5, 2026. [Online]. Available: https://source.android.com/docs/core/tests/debug/read-bug-reports
10. Android Open Source Project, “bugreport-format.md,” frameworks/native, cmds/dumpstate. Accessed: Nov. 5, 2026. [Online]. Available: https://android.googlesource.com/platform/frameworks/native/+/refs/heads/main/cmds/dumpstate/bugreport-format.md
11. B. Kitchenham and S. Charters, “Guidelines for performing systematic literature reviews in software engineering,” Version 2.3, EBSE Tech. Rep. EBSE-2007-01, Keele University and University of Durham, Jul. 9, 2007. [Online]. Available: https://legacyfileshare.elsevier.com/promis_misc/525444systematicreviewsguide.pdf. (Title page and contents read on Nov. 5, 2026; author names from bibliographic records returned by web search.)
12. M. Yamout, “Detecting iOS malware via Shutdown.log file,” Securelist (Kaspersky GReAT), Jan. 16, 2024. Accessed: Nov. 5, 2026. [Online]. Available: https://securelist.com/shutdown-log-lightweight-ios-malware-detection-method/111734/
13. EC-DIGIT-CSIRC, “Sysdiagnose Analysis Framework (SAF),” GitHub repository (EUPL-1.2). Accessed: Nov. 5, 2026. [Online]. Available: https://github.com/EC-DIGIT-CSIRC/sysdiagnose
14. IsMyPhonePwned, “sysdiagnose-extractor-library,” GitHub repository (EUPL-1.2). Accessed: Nov. 5, 2026. [Online]. Available: https://github.com/IsMyPhonePwned/sysdiagnose-extractor-library
15. A. Brignoni et al., “iLEAPP: iOS Logs, Events, And Plist Parser,” GitHub repository (MIT). Accessed: Nov. 5, 2026. [Online]. Available: https://github.com/abrignoni/iLEAPP
16. zpropheter, “DeviceDiag,” GitHub repository (no licence file). Accessed: Nov. 5, 2026. [Online]. Available: https://github.com/zpropheter/DeviceDiag
17. Cheeky4n6monkey, “iOS_sysdiagnose_forensic_scripts,” GitHub repository (no licence file). Accessed: Nov. 5, 2026. [Online]. Available: https://github.com/cheeky4n6monkey/iOS_sysdiagnose_forensic_scripts (The README names a document by M. Epifani, H. Mahalik and Cheeky4n6monkey, linked from for585.com/sysdiagnose; the document itself was not retrieved or read.)
18. Kaspersky GReAT, “iShutdown,” GitHub repository (MIT). Accessed: Nov. 5, 2026. [Online]. Available: https://github.com/KasperskyLab/iShutdown
19. MVT Project, “Mobile Verification Toolkit (MVT),” GitHub repository (MVT License 1.1). Accessed: Nov. 5, 2026. [Online]. Available: https://github.com/mvt-project/mvt
20. IsMyPhonePwned, “mobipwn,” GitHub repository (MIT). Accessed: Nov. 5, 2026. [Online]. Available: https://github.com/IsMyPhonePwned/mobipwn
21. A. Brignoni et al., “ALEAPP: Android Logs Events And Protobuf Parser,” GitHub repository (MIT). Accessed: Nov. 5, 2026. [Online]. Available: https://github.com/abrignoni/ALEAPP
22. CERT-EDF, “dumpstate-py: Extract useful structures from Android Bug Report,” GitHub repository (Apache-2.0). Accessed: Nov. 5, 2026. [Online]. Available: https://github.com/CERT-EDF/dumpstate-py
23. IsMyPhonePwned, “bugreport-extractor-library,” GitHub repository (Apache-2.0). Accessed: Nov. 5, 2026. [Online]. Available: https://github.com/IsMyPhonePwned/bugreport-extractor-library
24. Google, “Battery Historian,” GitHub repository (archived; licence file with Apache 2.0 text). Accessed: Nov. 5, 2026. [Online]. Available: https://github.com/google/battery-historian
25. Sony Xperia Dev, “ChkBugReport,” GitHub repository (archived; no licence file). Accessed: Nov. 5, 2026. [Online]. Available: https://github.com/sonyxperiadev/ChkBugReport
26. TheGrandPackard, “BugReportParser,” GitHub repository (MIT). Accessed: Nov. 5, 2026. [Online]. Available: https://github.com/TheGrandPackard/BugReportParser
27. Binse-Park, “Parser-android-s-dumpstate,” GitHub repository (no licence file). Accessed: Nov. 5, 2026. [Online]. Available: https://github.com/Binse-Park/Parser-android-s-dumpstate
28. D. Durvaux and C. Vandeplas, “Building a pipeline to analyse iOS devices at scale,” talk, hack.lu 2025, Luxembourg, Oct. 23, 2025. Accessed: Nov. 5, 2026. [Online]. Available: https://pretalx.com/hack-lu-2025/talk/CMHBFT/ (Session abstract read; slides not read.)
29. B. Epstein, B. Klein, and D. Feuerstein, “Analysis of sysdiagnose in iOS 15 to identify the sending phone number of AirDrop data,” J. Forensic Sci., vol. 67, no. 4, pp. 1704–1707, 2022, doi: 10.1111/1556-4029.15022. (Bibliographic data fetched from Crossref on Nov. 5, 2026; full text not read.)
30. J. H. Song, S. H. Kim, S. Y. Hwang, S. G. Kim, and S. J. Lee, “A study on the APFS timestamps in macOS,” Int. J. Eng. Technol., vol. 7, no. 3.3, p. 133, 2018, doi: 10.14419/ijet.v7i2.33.13870. (Bibliographic data and abstract fetched from Crossref and OpenAlex; full text not read.)
31. L. Bortnik and A. Lavrenovs, “Android dumpsys analysis to indicate driver distraction,” in Digital Forensics and Cyber Crime, Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering. Cham, Switzerland: Springer, 2021, pp. 139–163, doi: 10.1007/978-3-030-68734-2_8. (Abstract and introduction read from the author-hosted PDF.)
32. J. B. dos Santos Junior, G. A. Naldoni, C. R. Brene, and G. A. R. Majeau, “A vida secreta dos dispositivos móveis: análise de logs de dispositivos Android à luz da perícia computacional e da inteligência cibernética,” in Anais Estendidos do XXIV Simpósio Brasileiro de Segurança da Informação e de Sistemas Computacionais (SBSeg Estendido 2024). Porto Alegre, Brazil: SBC, 2024, pp. 408–411, doi: 10.5753/sbseg_estendido.2024.243365. (Bibliographic data and abstract fetched from Crossref; full text not read.)
33. X. Qiu Huang, “Análisis forense del sistema operativo HyperOS,” bachelor’s thesis, 2026. Repository record: https://oa.upm.es/96618/ (OpenAlex W7165425245). (Abstract and record type read through the OpenAlex API on Nov. 5, 2026; the thesis itself and the repository page were not retrieved.)
34. R. Miranda Filho, J. A. Bessa, and R. de Freitas, “ABRLog: a multi-device Android bugreport log dataset for intelligent analysis,” Data in Brief, vol. 69, Art. no. 113230, Aug. 2026, doi: 10.1016/j.dib.2026.113230. (Bibliographic data fetched from Crossref and the abstract from OpenAlex on Nov. 5, 2026; the publisher page was not fetched.)
35. R. Miranda Filho, J. A. Holanda Bessa Neto, and R. de Freitas, “ABRLog: a multi-device Android bugreport log dataset for intelligent analysis,” Zenodo dataset, Aug. 11, 2026, CC BY 4.0, doi: 10.5281/zenodo.21892365. (Record metadata and file list fetched from the Zenodo API on Nov. 5, 2026; the archives were not downloaded.)
36. J. A. Bessa, R. Miranda Filho, and R. de Freitas, “A multi-parser benchmark over Android bug-report logs,” in Anais do XIV Symposium on Knowledge Discovery, Mining and Learning (KDMiLe 2026). Porto Alegre, Brazil: SBC, Oct. 2026, pp. 41–48, doi: 10.5753/kdmile.2026.32039. (Landing page, bibliographic data and the first two pages of the PDF read on Nov. 6, 2026; the rest of the paper was not read.)
37. G. Horsman, “Tool testing and reliability issues in the field of digital forensics,” Digit. Investig., vol. 28, pp. 163–175, Mar. 2019, doi: 10.1016/j.diin.2019.01.009. (Bibliographic data fetched from Crossref on Nov. 5, 2026; full text not read.)
38. D. Durvaux and A. Kaplan, “Using Apple Sysdiagnose for mobile forensics and integrity checks,” talk, hack.lu 2023, Luxembourg, Oct. 19, 2023. Accessed: Nov. 5, 2026. [Online]. Available: https://pretalx.com/hack-lu-2023/talk/YXMSQV/ (Session abstract read; slides not read.)
39. L. Wilske, “Unraveling time: understanding time formats in iOS sysdiagnose for security forensics,” talk at Objective by the Sea, reported on the Hasso Plattner Institute news page. Accessed: Nov. 5, 2026. [Online]. Available: https://hpi.de/en/article/ios-forensics-research-presented-at-the-obts-conference/ (News page read; the page shows the date 12/05/2024; slides not found.)
40. D. Gillies, “Android bug reports: an underrated but complex goldmine for mobile security investigations,” iVerify blog, Oct. 17, 2025. Accessed: Nov. 5, 2026. [Online]. Available: https://iverify.com/blog/android-bug-reports-an-underrated-but-complex-goldmine-for-mobile-security-investigations
41. J. Hyde and E. McPherson, “DFRWS USA 2026 workshop: Sysdiagnose and unified logs 101,” workshop, Arlington, VA, USA, Jul. 27, 2026. [Online]. Available: https://dfrws.org/dfrws-usa-2026-workshop-sysdiagnose-and-unified-logs-101/ (Not re-verified at the source: the page returned HTTP 403 to the fetch tool; title, speakers, date and place were read in web-search results of Nov. 5, 2026.)
42. puffyCid, “Potential log/logarchive format change in macOS 27,” macos-UnifiedLogs issue #128, opened Jul. 2, 2026, open on Nov. 5, 2026. Accessed: Nov. 5, 2026. [Online]. Available: https://github.com/mandiant/macos-UnifiedLogs/issues/128
43. puffyCid, “Rust based lzbitmap decompression support,” macos-UnifiedLogs pull request #147, merged Aug. 8, 2026. Accessed: Nov. 5, 2026. [Online]. Available: https://github.com/mandiant/macos-UnifiedLogs/pull/147
44. Mandiant, “macos-UnifiedLogs release v0.7.0,” GitHub release, published Sep. 14, 2026. Accessed: Nov. 5, 2026. [Online]. Available: https://github.com/mandiant/macos-UnifiedLogs/releases/tag/v0.7.0
45. MVT Project, “Releases,” GitHub repository mvt-project/mvt (v2026.9.1, v2026.9.14, v2026.9.28 and v2026.11.2 release notes read). Accessed: Nov. 5, 2026. [Online]. Available: https://github.com/mvt-project/mvt/releases
46. EC-DIGIT-CSIRC, “sysdiagnose-testdata,” GitHub repository (EUPL-1.2). Accessed: Nov. 5, 2026. [Online]. Available: https://github.com/EC-DIGIT-CSIRC/sysdiagnose-testdata
47. MVT Project, “Android methodology,” Mobile Verification Toolkit documentation. Accessed: Nov. 5, 2026. [Online]. Available: https://docs.mvt.re/en/latest/android/methodology/