Protobuf definition file GooglePlay.proto missing in project repository? about raccoon4 HOT 3 OPEN

I'm not sure why I didn't include the .proto file. Probably to prevent it from being modified. Making changes there has big consequences and the akdeniz library is ill designed when it comes to extending it (so I want NO ONE TO FIDDLE WITH IT).

That being said, I'm in the process of rewriting that part from scratch. The new library is designed with modularity in mind and avoids having a hugetastic protobuf parser.

Is there a particular (set of) field(s) you need and if so, what for?

from raccoon4.

As you are the one who accepts or rejects the pull requests I don't see a problem in publishing that file.
The problem is that without the proto file it is very difficult to compare what is present and what is missing as e.g. getting the field ids from the generated GooglePlay.java file is pretty complicated. For example I am not sure if your DeviceConfigurationProto already contains field 27 and 29.

Also other open source projects using Google-API have no problem publishing those files. If raccon4 would also have them included in the repository that would make it possible to synchronize them at least partially or on a long term perspective consolidate the names of message objects that has been added after Google changed protobuf in a way that you can no longer read them in the decompiled PlayStore/GooglePlayServices apk file.

I am not sure what a "hugetastic protobuf parser" is, but that you are working on something sounds good. As there is no development branch available on Github I assume you keep everything private, so no one can help you and we will have to wait to see when it is finished. Hopefully your success rate at rewrite something from scratch is higher than mine ;)

from raccoon4.

I just remember another option for that protobuf files are required: When sniffing Google Play Services/ Play Store traffic of a real or emulated device some proxy programs like Charles Web Debugging Proxy allow to load the protobuf definitions to decode the traffic. This decoding is really helpful because otherwise you will only see the field ids instead of the object names and field names and some times message objects can't be decoded at all without matching proto file.

From my perspective the more people are familiar with the underlaying protocol the feaster we will be able to find out what needs to be changed next time Google changes the protocol in a way that Raccoon4 and other Google-Playstore-API based projects are affected.

from raccoon4.