Youtube 18.48.3 with iPad OS 16.6.1 not working about sgmodule HOT 8 CLOSED

I have tested Youtube 18.48.3 on IPad OS 16.7.2. and it works well.

I have not received similar reports from other users.

Are you using Surge?

from sgmodule.

No, I'm writing my client, similar to Surge, using quickjs to load the script, but I don't think it's the problem with quickjs, since I put the script and the data into node, it can't produce any result.
You can check this link https://github.com/FrontMage/web3d/releases/download/1.0.0/err.js for details, I think some of the YouTube users are experiencing a protocol change.
Just update const req = fs.readFileSync("../reqbody.dump"); to previous downloaded reqbody.dump path, then run node err.js you will seed that the result of v.body is undefined, the code between console.log("Before eval"); and console.log("After eval"); is the code from https://raw.githubusercontent.com/Maasea/sgmodule/master/Script/Youtube/dist/youtube.request.beta.js

from sgmodule.

To add on top of the protocol change, if I use the request dump from a month before, then everything is fine.

But the recent request body will cause v.body to be an undefined value.

Previous body can be found on https://github.com/FrontMage/web3d/releases/download/1.0.0/browse-request-1.log

from sgmodule.

I see what you mean.

The first thing I'd like to ask is how reqbody.dump is captured, I tried to parse it using protoc but it prompted a format error, which means it’s probably not a protobuf.

BTW, I'm debugging the script with a body exported using surge, and it works with node after removing some of the built-in methods ($request, $done, etc.)

from sgmodule.

I wrote a MIMT program to intercept https traffic, and it is dumped from the MIMT request intercept section, so maybe there is something wrong with MIMT broke the protobuf, l'll try debug from here, maybe it's using quic? Since I did not block some of the UDP traffic.

from sgmodule.

As far as I know, only mitmproxy is perfecting quic-based mitm. None of the commonly used proxy tools support it, but of course it would be great if you develop an app that supports this feature. So, for YouTube traffic capture are based on TCP (HTTPS).

You can use other apps to capture the body first to further investigate.

from sgmodule.

Sure, I'm trying to use Charles to debug this.

from sgmodule.

Issue found, https://youtubei.googleapis.com/youtubei/v1/browse?key=AIzaSyB-63vPrdThhKuerbB2N_l7Kwwcxj6yUAc this url sometimes produces none protobuf requests, instead of just panic, If I return the origin request body, it will work, I suspect surge and others are doing the same. Thx for the help!

from sgmodule.