hiding data/code in Android APK embedded signatures

[Hans-Christoph Steiner]

If it is any consolation, I've done some review of large sets of malware apps. 
They are not using any of these spots to hide stuff, from what I've seen.  They 
gold standard for malware is to not include the key code at all, and instead 
download it at runtime.  Some "enterprise" apps do that also.  Recent Android 
versions have made that harder.

Did you find any APKs with stuff hidden in the ZIP padding or signature blocks 
in the gcc149 dataset?

.hc

FC Stegerman:
> * Hans-Christoph Steiner <hans at guardianproject.info> [2023-02-03 07:58]:
>> This W3C MiniApp format sounds a lot like JAR signatures, aka APK v1
>> signatures.  Although not an ideal format, it is at least well understood
>> and explored.
> 
> Actually, "between the final entry and the zip's central directory" is
> exactly where the APK Signing Block is as well.  So it sounds more
> like a v2/v3 signature in that respect.
> 
> Though it sounds like it doesn't contain a signature for all the bytes
> in the ZIP (apart from the signature itself), but individual
> signatures for the files, which is indeed how v1 signatures work.
> 
>> As for some background on why APK v2/v3 signatures have this spot to stick
>> data in the signing block, the Android team developed a scheme for app
>> stores to sign all APKs that they ship.  Then devices can have the public
>> key for the app store built into the device, and there can be requirements
>> that all installed APKs are also signed by this external key.   This extra
>> signature goes into this data space in the APK signature, if I am not
>> mistaken.  It has to be external to the signed content because at the time
>> it was implemented, Google Play did not have the sources nor the ability to
>> sign APKs with the developers' keys.
> 
> That explains why there is some space.  Not why there is this much
> space, with zero constraints on what can be put in there.
> 
> I do understand the need to leave room for new signature schemes (like
> the later v3 and v3.1), so I understand not being able to completely
> lock down what can be put in there.  But now you can just put anything
> in there.
> 
> In fact, I just put the entire F-Droid APK into the verity padding
> block of another APK; apksigner says it's still verified.
> 
>> It is funny because APK v2 was developed because JAR/APKv1 allowed too much
>> flexibility to add stuff outside of the signature (e.g. the whole META-INF/
>> directory).  But then I guess they realized that they needed some way to add
>> external data after all.
> 
> Despite all the
> 
>    WARNING: META-INF/some/file not protected by signature. Unauthorized
>    modifications to this JAR entry will not be detected. Delete or move
>    the entry outside of META-INF/.
> 
> warnings that apksigner produces, those files are in fact always
> listed in the .MF and .SF and thus covered by the v1 signature in my
> experience (e.g. when I implemented v1 verification and signing for
> apksigtool).
> 
> But the v1 signature doesn't cover the space between entries or their
> metadata, leaving plenty of space to hide things.
> 
> - FC

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556