Replies: 3 comments 7 replies
-
I haven’t had the chance to look at the two to confirm whether they are different or not, but the reverse engineering can be done in a couple of ways:
Once you have your app/binary/library, there are a number of scripts such as PBTK that will attempt to extract the protobuf files, or otherwise you can open it up in something like IDA and transcribe manually if automated extraction is unsuccessful. You can then use the extracted protos with wire shark to match up live request/responses to the protocol definitions, though this is mostly trial and error as Spotify has a mishmash of JSON, grpc and protobuf endpoints, some of which give hints as to which proto corresponds by sending a header with the proto message name. I recommend doing it in front of a movie or something, it can take a while :) |
Beta Was this translation helpful? Give feedback.
-
What message are you talking about? ClientResponsePlaintext/Encrypted?
Looks like extracted from libspotify. |
Beta Was this translation helpful? Give feedback.
-
@sashahilton00 I'm not sure how to you can get appropriate data in this way, decompilling is easy but for exemple how was find the spotify server key in the app ? Such byte array would be extremly hard to extract. Or was it stored in another file ? |
Beta Was this translation helpful? Give feedback.
-
Hello librespot,
I'm trying to implement my own client based on the mobile protocol for Spotify. This requires me to communicate with Spotify APs.
Apparently, there is a difference between the keyexchange.proto librespot-java uses and the one the mobile app uses.
The mobile app's answer can't be decoded with the keyexchange.proto of this repository.
That's why I'm asking: what's the methodology to reverse engineer a .proto based on the raw messages the phone sends ?
How was the reverse engineering of the current
keyexchange.proto
achieved ?Thanks for your attention 🙏
Beta Was this translation helpful? Give feedback.
All reactions