Avertissement : cet article est uniquement destiné à des fins de référence d'apprentissage et de recherche, veuillez ne pas l'utiliser à des fins illégales.

Dans l'article précédent "Analyse non officielle du Big Data de Mobike", j'ai mentionné mon analyse des données de Mobike pendant la Fête du Printemps. J'y reviendrai plus en détail dans la série d'articles suivante. Comment mon robot explore-t-il. ces données de manière efficace ?

Pourquoi explorer les données de Mobike

Mobike est le premier vélo partagé à entrer à Chengdu Chaque jour, lorsque je descends de la station de métro, je peux voir de nombreux vélos dans l'APP, mais quand j'y marche. Quand je suis arrivé, j'ai réalisé que la voiture n'était pas là. Certaines voitures sont cachées quelque part ; certaines voitures peuvent se trouver derrière des immeubles de grande hauteur et ne peuvent être trouvées en raison d'erreurs GPS ; certaines voitures sont placées dans des zones résidentielles, séparées par un mur afin que les cyclistes ne puissent pas y accéder.

Alors existe-t-il un moyen d'obtenir les données de ces vélos pour analyser si ces vélos sont devenus des vélos zombies ? Quelqu'un l'a-t-il délibérément mis dans la communauté afin que personne ne puisse y accéder ?

Avec ces questions, j'ai commencé à étudier comment obtenir ces données.

Où obtenir les données

Si vous pouvez voir les données, nous avons toujours un moyen d'obtenir automatiquement les données. C'est juste que la méthode d'obtention des données détermine l'efficacité de l'obtention des données. Pour la tâche d'analyse des données de Mobike, le robot doit être capable d'obtenir plus de données en peu de temps (généralement environ 10 minutes pour que l'analyse des données soit utile). Alors d’où viennent les données ?

La source la plus directe est l'application Mobike. La conception logicielle moderne prête attention à la séparation du front-end et du back-end, et le serveur servira simultanément l'application, les pages Web, etc. Dans le cadre de cette tendance, il suffit de comprendre la requête HTTP du logiciel. De manière générale, les outils suivants peuvent aider :

Capture directe de paquets :

• Wireshark (sur le routeur ou l'ordinateur)

• Shark pour Root (Android)

Utilisez un proxy pour capturer les paquets de requêtes HTTP et déboguer :

• Fiddler 4

• Charles

• Capture de paquets (Android)

Comme mon téléphone n'est pas rooté, il y a trop d'interférences dans la capture de paquets sur le routeur, et il n'est pas facile d'utiliser https. Vous ne pouvez donc essayer d'utiliser Fiddler ou Charles qu'en premier. Raccrochez le proxy de Fiddler, puis continuez à déplacer l'emplacement sur le téléphone mobile pour voir s'il y a de nouvelles demandes. Mais malheureusement, il semble que les demandes concernent toutes la carte Amap , et il n'y a aucune donnée liée à Mobike.

Que se passe-t-il ? Essayez la version mobile. Après être passé à Packet Capture, il y avait effectivement du trafic, et j'ai trouvé celui qui me préoccupait le plus dans la requête :

4372317-de272f8395d2106f.png

Cette requête API est évidente au premier coup d'œil. Après l'avoir essayée dans Postman, elle peut renvoyer les informations correctes.

Je suis trop content trop tôt

J'ai grimpé les données plusieurs jours de suite et analysé les données, j'ai trouvé que le GPS de Mobike semble battre tout le temps, et. parfois, les coups dépassent une distance de plusieurs kilomètres, ce qui n'est évidemment pas une valeur normale.

Se pourrait-il que leur interface ait été manipulée pour renvoyer de fausses données ? J'ai observé que même dans l'APP, les données renvoyées par le vélo sautaient. Du petit matin au lendemain matin, je rafraîchissais régulièrement les voitures à proximité de chez moi pour voir si c'était vraiment le cas.

Image Je ne la trouve pas, mais après observation, je suis arrivé à la conclusion qu'il y a effectivement un problème avec l'emplacement renvoyé dans l'APP. Il y avait une voiture placée dans un endroit très éloigné. Elle a disparu pendant un moment, puis est revenue plus tard, et elle correspondait aux données que j'ai capturées. De plus, ce rebond n'a rien à voir avec les téléphones portables, les numéros de téléphone portable, ni même les opérateurs mobiles, ce qui montre que ce rebond est un problème avec l'interface de Mobike. Cela peut aussi expliquer sous un autre aspect pourquoi on voit parfois des voitures alors qu'il n'y en a en réalité pas. des voitures là-bas.

Voici une capture d'écran d'une vidéo que j'ai postée quelques instants auparavant. Vous pouvez voir qu'il y a un point pointu près de l'entrée du camp. La voiture est en fait arrêtée là, mais le GPS. la piste le montre pendant une courte période. Le corps intérieur se déplace à proximité, s'éloigne même, puis revient à cette position.

De telles données sont tout simplement inutilisables pour l'analyse des données, et j'ai presque abandonné.

Revirement

Avec la popularité du mini programme WeChat, Mobike a également lancé le mini programme immédiatement. J'ai ri quand je l'ai vu, oui, cela m'a donné une autre source de données à essayer. Après avoir capturé les données une fois avec Packet Capture, il est facile de déterminer l'API. Le processus spécifique ne sera pas expliqué ici. Après avoir exploré, j'ai exploré deux ou trois jours de données et j'ai constaté qu'il y avait un revirement et que les données étaient cohérentes avec les trajectoires normales du vélo.

Il ne reste plus qu'à améliorer l'efficacité du robot.

Autres tentatives

Parfois, il est très pratique d'analyser directement le code source de l'application pour trouver l'entrée de l'API. J'ai décompilé l'application Android de Mobike, mais j'ai constaté qu'à l'exception de certains fichiers de ressources, elle est utilisée. était utile, d'autres fichiers sont compressés à l'aide de l'obfuscateur de Qihoo 360. Il existe des articles sur Internet qui analysent comment effectuer des bombardements, mais je n'ai pas beaucoup de temps pour l'étudier, alors oubliez ça.

Parlez également de la conception de l'API

La raison pour laquelle l'API de Mobike est facile à explorer et à analyser est en grande partie parce que la conception de l'API est trop simple :

• Utilise uniquement des requêtes http, ce qui facilite l'analyse de capture de paquets

• Aucune de ces API ne crypte la requête, ce qui facilite l'utilisation de leurs services.

• De plus, les mini-programmes WeChat sont également une source importante de fuites d'API. Après tout, les requêtes dans les applications peuvent être cryptées via du code natif puis envoyées, mais il semble que ce soit le cas. n'existe pas de telle chose dans les mini-programmes.

Si vous êtes intéressé, vous pouvez essayer de jeter un œil à la demande de Xiaolan Bicycle APP. Ils utilisent la requête https et cryptent la demande de données. Il est difficile de capturer leurs données. Cela augmentera beaucoup.

Bien sûr, si les responsables de Mobike ne se soucient pas des données, une telle conception d'API serait acceptable.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!