Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Artifact unpacking issue #1068

Open
DT540821 opened this issue Feb 28, 2025 · 4 comments
Open

Artifact unpacking issue #1068

DT540821 opened this issue Feb 28, 2025 · 4 comments

Comments

@DT540821
Copy link

DT540821 commented Feb 28, 2025

Hello

Writing a module, some files have been failing to be unpacked from the extractions with this error.
"Could not write file to filesystem, path was *** data cannot access local variable 'creation_time' where it is not associated with a value.

Image

The files that have failed indeed do not have timestamps within the extractions.
Unsure if this is by design or a bug. Any work around to be able to parse these with __artifacts__v2?
No exceptions are raised, so no line or file showing. I assume it will be from the unzipping trying to preserve original timestamps.

@stark4n6
Copy link
Collaborator

@DT540821 can you send a screenshot of the error from the process log so we can know the line and file it's erroring from?

@Johann-PLW
Copy link
Collaborator

Hello @DT540821,

Thank you for spotting this issue.

But to be able to try to fix it, I need some more details.
What did you try exactly to do and from which type of extraction (folder, iTunes backup, zip or tar file)?

With elements you provided, I suspect something related to the extraction of timestamps from search_files.py module..

@DT540821
Copy link
Author

DT540821 commented Feb 28, 2025

@stark4n6 @Johann-PLW

Hi guys, thanks for pointing me in the right direction.
Essentially, I was just distracted by the error messages, and the files were actually being unzipped into the data folder. So, not a major issue.
The error messages were triggered due to returning unassigned variable names inside the FileSeekerZip.decode_extended_timestamp() function.

Image

Essentially all we need to do is assign some empty variables ahead of time to this function. Probably needs to get fixed or you lose the modification time as well.

@Johann-PLW
Copy link
Collaborator

Thank you very much @DT540821 .

You're right. There was an issue in the decode_extended_timestamp function. If extra_data has the correct header_id but there is no bit flag for modification_time, creation_time or both, local variable(s) used with no associated value.

This was fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants