PdAndro and regenerating APK

[kerravon]

PdAndro (available on the Google Play Store), which is a flavor of PDOS-generic, can turn your smartphone into a computer - sort of a rival to Termux.

The 32-bit version includes a fork of gcc 3.2.3 that is able to self-generate - pure ARM, although optimization doesn't work properly.

As such, using just your smartphone you can rebuild and modify the tools themselves. I'm happy to ignore (ie keep static) the Kotlin code that provides the terminal UI. However, to keep within the Android rules (ie no jailbreaking), I need to put my pseudo-bios (bios.exe) inside the APK (it gets renamed to libbios.so). That means that if I need to change the pseudo-bios itself, I need to do this:

https://github.com/robertapengelly/Pdos-PdAndro

zip -r app.zip ./app/

mv app.zip app.apk

keytool -genkey -keyalg RSA -alias mykeystore -keystore mykeystore.jks -storepass 12345678 -validity 360

apksigner sign --ks release.jks app.apk


zip is C source code so with the toolchain I provide, and using the zip source code, you can presumably get zip operational so that that zip command works.

However, do I have any options (either source code or apps) to do the other two things - keytool and apksigner?

I once saw a post saying that you can install unsigned APKs if you enable unknown sources (I think), but when I had an unsigned APK to test, it didn't work for me - it was some time ago and it is possible that it was an invalid test of the theory.

We could provide a signed APK for the Google Play Store and an unsigned APK on github if that was indeed a solution to the "problem".

The other possibility is to hold the pseudo-bios itself static and always run a separate PDOS layer. I had always originally intended to run a PDOS layer. But that eliminates the possibility of ever restructuring the pseudo-bios unless you have access to a computer other than a smartphone so that the tools for building an APK are available.

But ideally tools or a technique can be used using just the Android smartphone. Any ideas?

Thanks. Paul.

[Octocontrabass]

You can replace keytool with anything that can generate private key/certificate pairs, apksigner accepts standard file formats in addition to the weird Java-specific keystore file format.

The source code for apksigner is here.

I'm not sure if generating a new private key for each APK will satisfy Android's security requirements.

[kerravon]

You can replace keytool with anything that can generate private key/certificate pairs,

I'm not familiar with certificates. Do you have an example that would be suitable for a smartphone? ie ideally something that can be built from source so that I am not dependent on downloading something from the Google Play Store.

apksigner accepts standard file formats in addition to the weird Java-specific keystore file format.

Thanks for that. I see that it is written in Java. I'll ask Robert if he is able to build it for the smartphone.

I'm not sure if generating a new private key for each APK will satisfy Android's security requirements.

Any reason why it wouldn't? Once I have a new APK I uninstall the old one and install the new one. And I allow APKs from unknown sources when I'm using my own APKs.

[Octocontrabass]

Do you have an example that would be suitable for a smartphone? ie ideally something that can be built from source so that I am not dependent on downloading something from the Google Play Store.

I don't know about suitable for a smartphone, but you can build openssl from source. Be careful, though: if you're planning to use the generated keys for anything other than signing your own personal development APKs, you need a good source of actual randomness.

Any reason why it wouldn't? Once I have a new APK I uninstall the old one and install the new one. And I allow APKs from unknown sources when I'm using my own APKs.

Normally you're supposed to use the same private key every time to prove that all the APKs came from the same source. If you're not planning to distribute the APKs then there's no problem.

[kerravon]

I don't know about suitable for a smartphone, but you can build openssl from source. Be careful, though: if you're planning to use the generated keys for anything other than signing your own personal development APKs, you need a good source of actual randomness.

Thanks for that. We are discussing options and I'm coming to the conclusion that I need to treat this the same as an IBM PC BIOS in ROM. It's too difficult to change.

And note that my use is effectively "personal development" - I'm not trying to have security etc on the APKs that I distribute by USB stick to the jungles of Vietnam or whatever.

Normally you're supposed to use the same private key every time to prove that all the APKs came from the same source. If you're not planning to distribute the APKs then there's no problem.

The APKs may well be distributed, but I am not attempting to ensure they came from the same source. Jungle Inhabitant 1 may choose to use an APK from Jungle Inhabitant 2 one day, and Jungle Inhabitant 3 another day. With the same ease that people did things with floppy disks in the 1980s.

UPDATE:

It appears partly that I was asking the wrong question.

I (think I) don't need a replacement for keytool - I just need to have it run once and keep the output (cert.jks below) which I then distribute separately (I'm not attempting to have security).

This script below is apparently working (noting that resources.arsc needs to be uncompressed).


echo sudo apt install zip apksigner zipalign

cp app-release.apk original.zip
rm -rf ./app
unzip original.zip -d app
cp -r ./new/* ./app/

(cd app && zip --exclude resources.arsc -r ../app.zip * && zip -0 ../app.zip resources.arsc)

mv app.zip app_tmp.apk

if [ ! -f cert.jks ]; then
keytool -genkey -keyalg RSA -alias cert -keystore cert.jks -storepass 12345678 -validity 360
fi

rm -f app.apk

zipalign -p 4 app_tmp.apk app.apk

echo PASSWORD is 12345678
apksigner sign --min-sdk-version 16 --ks cert.jks app.apk

apksigner verify app.apk



And I have my own zip program which only stores things uncompressed - I should be able to modify that to make files aligned on a 4-byte boundary which is what it appears zipalign does. Which means the only thing that remains is for apksigner to be made into an Android app, assuming the license doesn't restrict that from being done. I'm still waiting for feedback on that.

Another thing is I probably want that validity to be:

-validity 2914760

https://stackoverflow.com/questions/142 ... e-validity

to take it to the year 9998.

Although I'm more interested in just getting to 2107 as my focus is on 32-bit systems.

And that will hopefully give me (or anyone else) the basic tools required to self-improve in isolation.

The Kotlin terminal won't be able to be replaced though, as that will need Android Studio to build.

Although if we were able to switch to JNI and use that nativeactivity thing with onclick in it, and the library that is linked in is simple so that I can create my own or whatever is required, then (since I provide a C compiler), it might be possible to even change the terminal using the above technique.


UPDATE2 (all messages delayed because osdev claims that spamhaus has blocked my IP):

There is an existing signer app:

https://play.google.com/store/apps/deta ... .apksigner

But Jean-Marc may be creating a replacement:

https://github.com/o-ksi-d/SignYourApk

I'm still waiting for clarification, but hopefully we will be in business soon.


UPDATE3:

Jean-Marc has now created a replacement:

https://github.com/o-ksi-d/SignYourApk/ ... /tag/1.0.0

but I haven't tested it yet.

I realized that I do in fact have the infrastructure required for my zip program to run on native ARM, so I don't need Bochs if I can add alignment capability to my (minimal) zip program. I fixed some issues there and hopefully soon I will have an updated zip program and be able to confirm that I can update the libbios.so of the PdAndro APK purely on an Android smartphone, using purely native ARM code.

[kerravon]

I realized that I do in fact have the infrastructure required for my zip program to run on native ARM

This was only half true, plus other issues meant that it was a lot more work that I expected, and why I tell employers I can't give a sensible estimate for work because I don't know what problems I will encounter. The end result is that on pdos.org if you search for "align" you have the trifecta of software needed to update an existing APK using just the smartphone. If you don't need supposed "security".

Thanks for your help!

I need to do other stuff before the APK on pdos.org gets into Google Play Store. ie getting zip working on 386 again, and building msged for ARM so that I can see what limitations exist in the terminal, so that I can ask for the Kotlin code to be updated at the same time, as publishing has not been speedy in the past.