Closed oleg-cherednik closed 1 year ago
Do you have a sample apk file that illustrates the issue?
@pmqs yes, I do. I think this is any apk file with resources. E.g. I have tested on this one: Scrabble® GO-Classic Word Game 1.58.1
Will be inlcuded in v1.9
Thanks - quite a big file.
The only thing non-standard I can see is null padding bytes where the extra fields should. See below for an example from the link you posted.
00029D2 0000004 50 4B 03 04 LOCAL HEADER #4 04034B50
00029D6 0000001 00 Extract Zip Spec 00 '0.0'
00029D7 0000001 00 Extract OS 00 'MS-DOS'
00029D8 0000002 00 00 General Purpose Flag 0000
00029DA 0000002 00 00 Compression Method 0000 'Stored'
00029DC 0000004 21 08 21 02 Last Mod Time 02210821 'Thu Jan 1 01:01:02 1981'
00029E0 0000004 E7 A5 1B 33 CRC 331BA5E7
00029E4 0000004 06 00 00 00 Compressed Length 00000006
00029E8 0000004 06 00 00 00 Uncompressed Length 00000006
00029EC 0000002 2B 00 Filename Length 002B
00029EE 0000002 01 00 Extra Length 0001
00029F0 000002B 4D 45 54 41 Filename 'META-INF/androidx.activity_activity.
2D 49 4E 46 version'
2F 61 6E 64
72 6F 69 64
78 2E 61 63
74 69 76 69
74 79 5F 61
63 74 69 76
69 74 79 2E
76 65 72 73
69 6F 6E
0002A1B 0000001 00 Null Padding in Extra <=======================
0002A1C 0000006 31 2E 32 2E PAYLOAD 1.2.4.
34 0A
0002A1B
for LocalFileHeader
here should be a extra field length
(see 4.3.7) and each record in this section should have format containeng at least archive extra data signature (4 bytes)
and extra field length (4 bytes)
(see 4.3.11). So in the LocalFileHeader
we should have at least 8 bytes
, but we have only 1 byte
. This is not up to standard. I have fixed this.
#4 (PK0304) [UTF-8] META-INF/androidx.activity_activity.version
---------------------------------------------------------------
- location: 10706 (0x000029D2) bytes
- size: 74 bytes
operat. system version needed to extract (00): MS-DOS, OS/2, NT FAT
unzip software version needed to extract (00): 0.0
general purpose bit flag (0x0000) (bit 15..0): 0000.0000 0000.0000
file security status (bit 0): not encrypted
data descriptor (bit 3): no
strong encryption (bit 6): no
UTF-8 names (bit 11): no
compression method (00): none (stored)
file last modified on (0x0221 0x0821): 1981-01-01 01:01:02
32-bit CRC value: 0x331BA5E7
compressed size: 6 bytes
uncompressed size: 6 bytes
length of filename: 43
UTF-8
4D 45 54 41 2D 49 4E 46 2F 61 6E 64 72 6F 69 64 META-INF/android
78 2E 61 63 74 69 76 69 74 79 5F 61 63 74 69 76 x.activity_activ
69 74 79 2E 76 65 72 73 69 6F 6E ity.version
extra field: 10779 (0x00002A1B) bytes
- size: 1 bytes (1 record)
And this is a not-standard ExtraField with 1 record
(0xFFFFFFFF) Unknown: 10779 (0x00002A1B) bytes
- size: 1 bytes
00
0002A1B
forLocalFileHeader
here should be aextra field length
(see 4.3.7) and each record in this section should have format containeng at leastarchive extra data signature (4 bytes)
andextra field length (4 bytes)
(see 4.3.11). So in theLocalFileHeader
we should have at least8 bytes
, but we have only1 byte
. This is not up to standard. I have fixed this.
Yep, agree, it is non-standard. I imagine this is used for data alignment.
In my application, I have code to explicitly check for an extra field that is completely null bytes. APK is the only application I've found so far that uses it.
I see that APK also had a properly defined extra field for alignment purposes -- ID is 0xd935. See here for the source code that uses it. Can't find a formal reference doc that defines it - source code is all I can find.
I think you can be right about data alignemnt, because apk
is for Android and file should be start at the special postion in memory.
My application just work with zip file and should decompose it correctly. Thank you for mention about data alignment.
https://github.com/Ne-Lexa/php-zip/releases here you can find what is 0xD935
. And here you can find a source.
apk
file keeps file content in the extra field section. But this section has not correct format for extra field. According this, decompose and view has a problem.