Local extra field data for timestamps occasionally re-written incorrectly

[pianistrevor]

What happened?

I've been using ipatool for awhile now, alongside iTunes. I've been comparing the timestamps of extracted files (particularly Apple's code signature) and it appears that some apps have timestamps with extra data that is not preserved by ipatool.

For reference, here are four archives I've compared today:

• Kroger SVEI 888026966, from iTunes 12.6.5
• Kroger SVEI 888026966, from ipatool
• United Airlines SVEI 888081233, from iTunes 12.6.5
• United Airlines SVEI 888081233, from ipatool

With Kroger, when I view both archives using zipinfo -v, or unzip -l, I see the timestamp for the CodeResources file as 2026-07-09 00:27:50, which is adjusted to my timezone of UTC -7:00. WinRAR shows 2026-07-09 07:27:50, which is likely the UTC timestamp. Extracting via unzip preserves this timestamp correctly, so my local timestamp shows what the zipinfo shows.

With United, things get funky. Viewing both archives using zipinfo -v and unzip -l shows the timestamp for the CodeResources file as 2026-07-10 16:58:26, which happens to be in the future from when I'm writing this. WinRAR shows this as well. I assume this is not actually correct for my local time, as adjusted to UTC -7 it would be 2026-07-10 09:58:26. When I extract with unzip, however, the iTunes archive actually does extract correctly - and the resulting file shows 9:58 AM as I'd expect. With the ipatool archive, the extraction does not convert this and shows 4:58 PM.

I wrote a small python script to peer into the local file header and extra data associated with each of these four archives. Here is what I found:

--- krogerItunes.ipa ---
File: Payload/kroger.app/_CodeSignature/CodeResources
  Raw Local Time/Date Hex: 793b e95c
  Local Extra Field Length: 16 bytes
--- krogerTool.ipa ---
File: Payload/kroger.app/_CodeSignature/CodeResources
  Raw Local Time/Date Hex: 793b e95c
  Local Extra Field Length: 12 bytes
--- unitedItunes.ipa ---
File: Payload/UnitedCustomerFacingIPhone.app/_CodeSignature/CodeResources
  Raw Local Time/Date Hex: 4d87 ea5c
  Local Extra Field Length: 16 bytes
--- unitedTool.ipa ---
File: Payload/UnitedCustomerFacingIPhone.app/_CodeSignature/CodeResources
  Raw Local Time/Date Hex: 4d87 ea5c
  Local Extra Field Length: 0 bytes

Source archives seem to have the NTFS timestamp, which makes sense as it is downloaded from the Windows iTunes client. But, it seems that in one case, the local extra field length is converted by Go correctly to a 12-byte sequence (likely extended timestamp block with the epoch), while in the other case, it's being dropped entirely.

Version

2.3.1

Relevant log output

[jpstotz]

Are you sure about the app-id / trackId / adamID you mention in your post?

• 888026966 seems to be a song from an artist named "Maserati", not an app.
• 888081233 doesn't seem to exists at all in Apple App store.

Checked via https://itunes.apple.com/lookup?id=888026966 and https://itunes.apple.com/lookup?id=888081233

Anyway you may want to test the modifications I have proposed in #506. With those changes the ZIP data should not be altered when inserting the sinf file into the downloaded ipa data. May with that PR ipatool works the way you expect? Would be at least worth a try.

[trevor-natiuk]

Those aren't App IDs, they're SVEIs. Kroger's App ID is 403901186 and United is 449945214.

I merged in your PR for the replicate zip enhancement. Unfortunately this issue exists both in 2.3.1 and in the enhanced 2.3.1 with your work.

[jpstotz]

@trevor-natiuk Ok, was worth a try.

May be you should check the RAW downloaded ipa file before ipatool injects the sinf data, thus before replicateZip method is called (add e.g. some sleep command and use the time to copy the temp file away).

If the timestamps in that downloaded RAW ipa file are already different to what you expect then the problem is not located in ipatool. If it is correct then we would know the problem is in replicateZip and Go's zip implementation and we could search for a way to fix/bypass this problem.