Mobike 크롤러 분석 - API 찾기

경고: 이 글은 학습 및 연구 참고용으로만 작성되었으므로 불법적인 목적으로 사용하지 마시기 바랍니다.

이전 기사 "Mobike 비공식 빅데이터 분석"에서 봄 축제 기간 동안 Mobike에 대한 데이터 분석을 언급한 바 있으며, 다음 기사 시리즈에서 이에 대해 자세히 설명하겠습니다. 이 데이터를 효율적으로?

모바이크 데이터를 크롤링하는 이유

모바이크는 청두에 입성한 최초의 공유자전거입니다. 매일 지하철역에서 내리면 수많은 자전거가 APP으로 보이는데, 걸어가다 보면 도착해서 보니 차가 없었습니다. 일부 차량은 어딘가에 숨겨져 있고, 일부 차량은 GPS 오류로 인해 찾을 수 없으며, 일부 차량은 자전거 이용자가 접근할 수 없도록 벽으로 분리된 주거 지역에 배치됩니다.

그렇다면 이 자전거들의 데이터를 얻어서 이 자전거들이 좀비 자전거가 되었는지 분석할 수 있는 방법이 있을까요? 누군가가 고의로 아무도 접근할 수 없도록 커뮤니티에 넣었나요?

이러한 질문을 계기로 저는 이 데이터를 어떻게 얻을 수 있는지 연구하기 시작했습니다.

데이터를 얻을 수 있는 곳

데이터를 볼 수 있다면 항상 자동으로 데이터를 얻을 수 있는 방법이 있습니다. 단지 데이터를 얻는 방법에 따라 데이터 획득의 효율성이 결정될 뿐입니다. Mobike의 데이터 분석 작업에서는 크롤러가 짧은 시간(보통 10분 정도)에 더 많은 데이터를 얻을 수 있어야 합니다. 그렇다면 데이터는 어디서 오는 걸까요?

가장 직접적인 소스는 Mobike APP입니다. 현대 소프트웨어 설계는 프런트엔드와 백엔드 분리에 중점을 두고 있으며 서버는 APP, 웹 페이지 등을 동시에 서비스합니다. 이러한 추세 속에서 우리는 소프트웨어의 HTTP 요청만 파악하면 됩니다. 일반적으로 다음 도구가 도움이 될 수 있습니다.

직접 패킷 캡처:

• Wireshark(라우터 또는 컴퓨터에서)

• Shark 루트(Android)

프록시를 사용하여 HTTP 요청 패킷을 캡처하고 디버그 :

• Fiddler 4

• Charles

• 패킷 캡쳐(안드로이드)

내 폰이 루팅이 안되어 있어서 공유기에서 패킷 캡쳐에 간섭이 너무 심하고 https 사용도 쉽지 않네요. 따라서 Fiddler 또는 Charles를 먼저 사용해 볼 수 있습니다. Fiddler의 프록시를 끊은 다음 휴대폰에서 위치를 계속 이동하여 새로운 요청이 있는지 확인합니다. 그런데 아쉽게도 요청은 모두 에이맵 지도를 얻기 위한 것 뿐이고, 모바이크와 관련된 데이터는 없는 것 같습니다.

무슨 일이에요? 모바일 버전을 사용해 보세요. 패킷 캡처로 전환한 후 실제로 트래픽이 발생했으며 요청에서 가장 우려되는 항목을 발견했습니다:

4372317-de272f8395d2106f.png

이 API 요청은 언뜻 보기에 Postman에서 시도한 후에는 정보를 올바르게 반환할 수 있는 것 같습니다.

너무 이르다

며칠 연속으로 데이터를 올라와서 분석해보니 모바이크의 GPS가 계속 뛰는 것 같더라고요. 때때로 구타는 수 킬로미터의 거리를 초과하며 이는 분명히 정상적인 값이 아닙니다.

인터페이스가 조작되어 잘못된 데이터를 반환하는 것은 아닐까? APP에서도 자전거가 반환하는 데이터가 점프하는 것을 관찰했습니다. 어느 이른 아침부터 다음 날 아침까지, 나는 이것이 정말 사실인지 확인하기 위해 집 근처의 차들을 주기적으로 교체했습니다.

사진 찾을 수 없는데 관찰한 결과, APP에서 반환된 위치에 확실히 뭔가 문제가 있다는 결론을 내렸습니다. 아주 먼 곳에 자동차 한 대가 놓여 있었는데, 잠시 사라졌다가 나중에 다시 찾아왔는데, 제가 캡쳐한 데이터와 일치하더군요. 게다가 이 바운스는 휴대폰, 휴대폰 번호, 심지어 이동통신사와도 아무런 관련이 없습니다. 이는 이 바운스가 Mobike의 인터페이스에 문제가 있음을 보여줍니다. 이는 우리가 가끔 자동차를 보지만 실제로는 자동차가 없는 이유를 또 다른 측면에서 설명할 수도 있습니다. 거기 차.

이전 모먼츠에 올렸던 영상의 스크린샷입니다. 캠핑장 입구 근처에 뾰족한 곳이 보이는데 실제로는 거기에 GPS가 멈췄습니다. 트랙은 짧은 시간 동안 내부 신체가 가까이 이동하고 심지어 멀리 이동한 다음 해당 위치로 돌아오는 것을 보여줍니다.

이러한 데이터는 단순히 데이터 분석에 사용할 수 없어 포기할 뻔했습니다.

전환

위챗 미니 프로그램의 인기에 힘입어 모바이크도 곧바로 미니 프로그램을 출시했다. 나는 그것을 보고 웃었습니다. 예, 시도해 볼 만한 또 다른 데이터 소스를 제공했습니다. Packet Capture로 데이터를 한 번 캡처한 후에는 API를 쉽게 결정할 수 있습니다. 여기서는 구체적인 프로세스를 설명하지 않습니다. 크롤링을 한 후 2~3일간의 데이터를 크롤링해 보니 반전이 있었고, 그 데이터는 일반적인 자전거 궤적과 일치했습니다.

크롤러의 효율성을 높이는 일만 남았습니다.

다른 시도

가끔 API 입구를 찾기 위해 앱의 소스코드를 직접 분석하는 것이 매우 편리할 때가 있는데, 모바이크 안드로이드 앱을 디컴파일했는데 일부 리소스 파일을 제외하면, 유용했습니다. 다른 파일은 Qihoo 360의 obfuscator를 사용하여 압축했습니다. 포격 수행 방법을 분석한 기사가 인터넷에 있지만 공부할 시간이 많지 않으므로 잊어 버리십시오.

API 디자인에 대해서도 이야기하세요

Mobike의 API가 크롤링 및 분석하기 쉬운 이유는 주로 API 디자인이 너무 단순하기 때문입니다:

• http 요청만 사용하므로 패킷 캡처 분석이 쉽습니다

• 이러한 API는 요청을 암호화하지 않으므로 서비스 사용이 쉽습니다.

• 그리고 위챗 미니프로그램도 유출된 API의 중요한 소스이기 때문에 결국 APP에서의 요청은 네이티브 코드를 통해 암호화된 후 전송될 수 있는 것 같습니다. 미니 프로그램에서는 그런 것이 없습니다.

관심이 있으시면 Xiaolan Bicycle APP의 요청을 살펴보세요. 그들은 https 요청을 사용하고 데이터 요청을 암호화하기가 어렵습니다. 많이 늘어날 것입니다.

물론, Mobike 관계자들이 데이터에 관심이 없다면 이런 API 설계도 괜찮을 것입니다.

위 내용은 Mobike 크롤러 분석 - API 찾기의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!