orcunxrd commented 2 years ago

Feature Request

Simulating logging_client_events requests.

Notes

I've been searching for a long time. I think the reason why all transactions on Instagram look organic is because logging_client_events requests are sent. And I think some features (Video watching, profile visit etc.) are all related to logging_client_events requests. I would like to exchange ideas with people under this topic, and to find out if you can add to any of your warehouses on this subject.

Form

Put an [x] if you meet the condition, else leave [ ].

[x] I've searched the Issues
[x] I've read the basic concepts
[x] I'm using the latest version

Description

Logging_client_events requests:

Decrypted view:

I would like you to share your knowledge and get your ideas on how it can be simulated. Thanks in advance for your valuable comments.

kingbotss commented 2 years ago

I think there are two type of requests, batch request and other. It is logging every small things like how much time spent, on which page, timestamps, so much other data. 30+ types of data being sent.

orcunxrd commented 2 years ago

I tried simulating it myself. But the return response is always the same. I don't know what I did wrong. Has anyone been interested before?

kingbotss commented 2 years ago

To get success, you have to build the data, that is being sent on first request from the app. Then you will get checksum, from then, including checksum on the request, will work. Read #1140

orcunxrd commented 2 years ago

To get success, you have to build the data, that is being sent on first request from the app. Then you will get checksum, from then, including checksum on the request, will work. Read #1140

I get the checksum at login and send it already on all subsequent requests. But this is of no use. The response is always the same:

{
  "checksum": "",
  "config": "",
  "config_owner_id": "",
  "app_data": "{}"
}

orcunxrd commented 2 years ago

Ok. I sent the first outgoing request after the app opened and got the checksum. I simulated the whole event with the same checksum in other logging_client_events requests. But unfortunately it still doesn't work. Why might it be caused? Could it be because of the timestamp and microtimes in it?

umitbilgin commented 2 years ago

Ok. I sent the first outgoing request after the app opened and got the checksum. I simulated the whole event with the same checksum in other logging_client_events requests. But unfortunately it still doesn't work. Why might it be caused? Could it be because of the timestamp and microtimes in it?

I sent the request paying attention to all this, but it still didn't work.

kingbotss commented 2 years ago

It will work. Make sure send it correct format.

orcunxrd commented 2 years ago

It will work. Make sure send it correct format.

This is how I do it. Is not it right? @kingbotss https://imgur.com/ZkFlKXj

RaulVillizzianto commented 2 years ago

To get success, you have to build the data, that is being sent on first request from the app. Then you will get checksum, from then, including checksum on the request, will work. Read #1140

I get the checksum at login and send it already on all subsequent requests. But this is of no use. The response is always the same:
{
  "checksum": "",
  "config": "",
  "config_owner_id": "",
  "app_data": "{}"
}

I've seen that that is a normal reply from the server. I have been reading the HTTP requests using mitmproxy and all those seem to have the same response from instagram server.

kingbotss commented 2 years ago

Response from server is same for most requests. But different for 1st or second request. Then client side requests are included checksum in the consecutive requests.

RaulVillizzianto commented 2 years ago

Do you have any example of this? I havent found the checksum in the first or second request. Also do you know which data should be sent inside the message?

kingbotss commented 2 years ago

message is gzip data. It contains details about device and timestamps

RaulVillizzianto commented 2 years ago

Yep i decoded gzip data and got this https://pastebin.com/QifsFkjX. Now its up to know how the logging data is generated in all events.

orcunxrd commented 2 years ago

@RaulVillizzianto To get the checksum you must send "config_checksum" null or empty in the first request. According to my experience, Instagram statistics (video views, post views, profile views, etc.) are performed with this request. Since the response of the logging_client_events request is always the same, I can't understand if I can simulate it correctly. We need to learn what to watch out for.

kingbotss commented 1 year ago

Can simulate the requests, I was able to do so. The hard thing is, response from server is same for all requests. So, we really don't know, if the data we sent is correct or not.

kingbotss commented 1 year ago

Tested for video views 😂 working 👍

readak commented 1 year ago

@orcunxrd @umitbilgin @RaulVillizzianto Have you been able to work, so is it being imitated?

orcunxrd commented 1 year ago

@readak It can be imitated, but it requires great effort. What have you been able to do?

readak commented 1 year ago

@orcunxrd I started imitating according to the latest version. I can't do qualifying, I'm trying all of them from scratch yet, I haven't gotten a result yet. Data and extras will take a little more than too much.

readak commented 1 year ago

I am still in the queries that have come in since the app started opening.

umitbilgin commented 1 year ago

@readak Can you add me on discord? @jmmx

umitbilgin commented 1 year ago

@readak Can you add me on discord? @Jmmx

I couldn't find your account

Try this jmmx or send your username.

brunoaduarte commented 8 months ago

Hi! I'm receiving this message when trying to perform some actions directly on the Instagram API

"We limit how often you can do certain things on Instagram to protect our community. Tell us if you think we made a mistake."

Are these related to the "logging_client_events" ?

If that's the case, it's not clear to me how to calculate the "q" and "p" keys from the "config_checksum" that is sent on the "logging_client_events"


POST /logging_client_events HTTP/2
Host: graph.instagram.com
X-Fb-Connection-Type: WIFI
X-Ig-Connection-Type: WIFI
X-Ig-Capabilities: 3brTv10=
X-Ig-App-Id: 567067343352427
Priority: u=5, i
User-Agent: Instagram 275.0.0.27.98 Android (25/7.1.2; 240dpi; 900x1600; samsung; SM-A805N; aosp; android_x86; en_US; 458229257)
Accept-Language: en-US
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Content-Length: 2458
Accept-Encoding: gzip, deflate, br
X-Fb-Http-Engine: Liger
X-Fb-Client-Ip: True
X-Fb-Server-Cluster: True

access_token=567067343352427%7Cf249176f09e26ce54212b472dbab8fa8&format=json&compressed=1&sent_time=1709832955.721&message=
{
  "time": 1709832951607,
  "app_id": "567067343352427",
  "app_ver": "275.0.0.27.98",
  "build_num": 458229257,
  "consent_state": 0,
  "device": "SM-A805N",
  "os_ver": "7.1.2",
  "device_id": "c7e129cb-e663-4624-8b9f-xxxxxxx",
  "family_device_id": "9df86e9e-d1e1-409a-bdd7-xxxxxxx",
  "session_id": "UFS-b8221682-7874-49b1-a966-xxxxxxx-0",
  "seq": 1,
  "app_uid": "39713572343",
  "claims": [
    "hmac.AR2jkEio2GvBfwNH0jEokpEuxwTNYmulgawZLvn5xxxxxxx"
  ],
  "data": [ ........................................ ],
  "tier": "micro_batch",
  "sent_time": 1709832955.72,
  "carrier": "Nextel",
  "conn": "WIFI",
  "config_checksum": "qs|c=eyJwIjoiYjdlZTU3NzIxYTE3ZWM2ZDFmZjc1YmJiOTZkZWUxMzAiLCJxIjoidjd8ZTkwYTk5OTE3ZGU4M2YxYmEwOTRkMmZiZGU4MTUxMTYifQ%3D%3D&ts=1709747673&qv=v7&s=4777df27b15b072d16065fe473f80d33",
  "config_version": "v2",
  "qpl_config_version": "v7"
}

In this case the encoded base64 string decodes to

{
  "p": "b7ee57721a17ec6d1ff75bbb96dee130",
  "q": "v7|e90a99917de83f1ba094d2fbde815116"
}

How to calculate these "p" and "q" ? What about the "s" parameter ?

  "config_checksum": "qs|c=eyJwIjoiYjdlZTU3NzIxYTE3ZWM2ZDFmZjc1YmJiOTZkZWUxMzAiLCJxIjoidjd8ZTkwYTk5OTE3ZGU4M2YxYmEwOTRkMmZiZGU4MTUxMTYifQ%3D%3D&ts=1709747673&qv=v7&s=4777df27b15b072d16065fe473f80d33",

Thanks

dilame / instagram-private-api

About logging_client_events #1624

Feature Request

Notes

Form

Description