警告: この記事は学習や研究のための参考のみを目的としており、違法な目的には使用しないでください。

前回の記事「Mobike 非公式ビッグデータ分析」では、春祭り中の Mobike のデータ分析について説明しました。次の一連の記事では、このデータへのクローラーの効率についてさらに詳しく説明します。

なぜMobikeのデータをクロールするのか

Mobikeは成都に入る最初のシェア自転車で、毎日地下鉄の駅を降りるとAPPでたくさんの自転車が見えますが、到着すると自転車が見えなくなります。そこにはいない。どこかに隠れている車もあれば、GPS のエラーで見つからない車もあり、自転車が近づけないように壁で区切られて住宅地に置かれている車もあります。

それでは、これらの自転車がゾンビ自転車になっているかどうかを分析するために、これらの自転車のデータを取得する方法はあるのでしょうか?誰かが意図的に誰もアクセスできないようにコミュニティに公開したのでしょうか?

これらの疑問をきっかけに、このデータを取得する方法を研究し始めました。

データの入手先

データを確認できる場合は、データを自動的に取得する方法が常に用意されています。ただ、Mobike のデータ分析のタスクでは、データの取得方法がデータ分析の効率を左右します。では、データはどこから来たのでしょうか?

最も直接的な情報源は Mobike アプリです。最新のソフトウェア設計では、フロントエンドとバックエンドの分離に注意が払われており、サーバーはAPP、Webページなどを同時に提供します。この傾向では、ソフトウェアの HTTP リクエストを理解するだけで済みます。一般的に、役立ついくつかのツールがあります：

キャプチャパケットを直接キャプチャする：

• wireshark（routerまたはコンピューター）プロキシHTTPリクエストパケットキャプチャとdebuggingを実行する

  ：

• fiddler4

Charles

PacketCapture（Android）ルーター上では干渉が多すぎて、https に対処するのは簡単ではありません。したがって、最初に Fiddler または Charles を使用してみるしかありません。 Fiddler のプロキシを切断し、携帯電話で場所を移動し続けて、新しいリクエストがあるかどうかを確認します。しかし、残念ながら、リクエストはすべてAmap

map
• を取得するためのもののようで、Mobikeに関するデータはありません。

  何が起こっているのですか？モバイル版をお試しください。パケット キャプチャに切り替えた後、実際にトラフィックが発生し、リクエストの中で最も懸念していたものを見つけました:

• 4372317-de272f8395d2106f.png
• This

  API

  リクエストは一目瞭然です。郵便屋さん 試してみたところ、正しく情報が返されました。

嬉しすぎて早すぎる

数日連続で登山データを取得した後、データを分析したところ、Mobike の GPS が常に鼓動しているようで、鼓動が数キロを超えることがありました。明らかに正常値ではありませんでした。

もしかしたら、彼らの

インターフェース

が偽のデータを返すように操作されている可能性はありますか? APP でも自転車から返されるデータが跳ね上がっていることが観察されました。ある早朝から翌朝まで、本当にそうなのか、自宅近くの車を定期的にリフレッシュしてみました。

写真が見つかりません

ですが、観察した結果、APPで返される位置情報に確かに問題があるという結論に達しました。非常に離れた場所に車が置かれていましたが、しばらく消えてから戻ってきましたが、それは私が撮影したデータと一致しました。さらに、このバウンスは携帯電話、携帯電話番号、さらには携帯電話会社とは何の関係もありません。これは、このバウンスが Mobike のインターフェイスに問題があることを示しています。また、車が時々見えるのに実際には存在しない理由を別の側面から説明することもできます。そこに車が。

これは私が以前モーメントに投稿した

ビデオのスクリーンショットです。実際には車がそこに止まっているのですが、GPSの軌跡では動いていることがわかります。短期間で、あるいはかなり遠くまで、その位置に戻ります。

そんなデータはデータ分析には全く使えず、半ば諦めていました。

転送

WeChat ミニ プログラムの人気に伴い、Mobike もすぐにミニ プログラムを開始しました。これを見たときは笑ってしまいました。そう、別のデータ ソースを試してみることができました。 Packet Capture でデータを一度取得した後は、API を決定するのは簡単です。具体的なプロセスについてはここでは説明しません。クロール後、2 ～ 3 日分のデータをクロールしたところ、方向転換があり、データが通常の自転車の軌跡と一致していることがわかりました。

あとはクローラーの効率を上げるだけです。

その他の試み

時々、アプリのソースコードを直接分析して API の入り口を見つけるのが非常に便利です。Mobike Android アプリを逆コンパイルしましたが、いくつかの有用なリソース ファイルを除いて、他のファイルはすべておかしいことがわかりました。タイガー360のミキサーが詰まっています。インターネット上には砲撃の方法を分析した記事がありますが、勉強する時間があまりないので忘れてください。

API 設計についてもお話します

Mobike の API がクロールして分析しやすい理由は、主に API 設計がシンプルすぎるためです:

• http リクエストのみを使用するため、クロールが簡単です パッケージ分析

• これらの API はリクエストを暗号化しないため、サービスが悪用されやすくなります。

• さらに、WeChat ミニプログラムも API 漏洩の重要なソースです。結局のところ、APP 内のリクエストはネイティブ コードを通じて暗号化されて送信される可能性がありますが、mini にはそのような機能はないようです。 -プログラム。

ご興味があれば、Xiaolan Bicycle APP のリクエストを確認してみてください。https リクエストを使用し、データリクエストを暗号化することで、データをキャプチャすることがはるかに困難になります。

もちろん、Mobike 関係者がデータを気にしないのであれば、そのような API 設計は問題ありません。

以上がMobike クローラー分析 - API を見つけるの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。