YouTube SABR: from-scratch reverse-engineering notes and extractor research log

[Priveetee]

Hi @InfinityLoop1308,

I am opening this issue as a public notebook for some YouTube SABR research I want to do in my free time.

I really enjoy reverse engineering and protocol research, and SABR looks like a very interesting topic for PipePipeExtractor. I want to spend some time trying to understand it properly, as much as possible from scratch, and document what I find here.

This is mainly for me too, to not get lost while experimenting :p

Related context:

• InfinityLoop1308/PipePipe#2330
• InfinityLoop1308/PipePipe#2310
• TeamNewPipe/NewPipe#12248

What this issue is

This is not a normal bug report and not a request for a quick workaround.

I want to use this issue as a work log for:

• notes while reading YouTube player responses
• comparisons between different InnerTube clients
• SABR/UMP observations
• decoded fields
• failed experiments
• useful references
• possible implementation ideas for PipePipeExtractor

If something becomes solid enough later, I can split it into small PRs.

What I want to understand

My goal is to understand SABR as a real protocol, not only as a fallback problem.

Some things I want to investigate:

• how SABR metadata is exposed in player responses
• how different YouTube clients behave
• how SABR requests are built
• how UMP responses are structured
• which fields are required for real playback/download support later
• how this could fit cleanly into PipePipeExtractor

I also do not want to limit the research too early to only one known path like WEB or TVHTML5. I will read existing references, but I want to verify things myself and understand what is actually required.

First research target

The first thing I want to try is a small proof of understanding:

• fetch player data containing SABR information
• build a SABR request from that data
• send it to the SABR endpoint
• receive a UMP response
• decode the response enough to identify init metadata, media headers, and media bytes

This would only be extractor-side research at first. I do not want to rush this into PipePipeClient until the protocol side is understood better.

Non-goals for now

For now, this issue is not about:

• user support reports
• a quick workaround
• another fallback-only solution
• immediately adding client playback support
• immediately adding download support

Those can be separate topics later.

Possible future output

If this becomes solid enough, I can split it into small PRs later.

Possible areas:

• SABR metadata extraction
• UMP parser
• SABR protobuf models/builders
• SABR session/request state
• real response decoding tests or local harnesses
• experimental extractor API for SABR data

I will keep notes and progress here as I explore the protocol.

[Priveetee]

quick update after more local SABR tests :)

I got the local extractor-side prototype further.

Current local state:

• player response parsing can find SABR endpoint/config/formats
• local code can build a VideoPlaybackAbrRequest
• SABR POST returns application/vnd.yt-ump on some public VODs with the ANDROID client
• UMP parsing can split init/media/media-end parts
• media headers, init metadata, selectable formats, next request policy, playback cookie and stream protection status are decoded enough to be useful
• follow-up requests work with selected formats, buffered ranges, player time and playback cookie

This is not only metadata anymore (nice surprise).

On a short public VOD, I was able to assemble valid audio/video files from SABR media payloads. So the returned UMP media bytes are usable at least for that case.

I also have a small local session model now:

• request init segments
• request media segments
• keep a segment cache
• advance with follow-up requests
• do direct seek/random-access tests on some VODs

Some current findings:

• cold-start and follow-up requests need different state
• selected_format_ids seems wrong for cold-start, but needed for follow-up
• NextRequestPolicy.playback_cookie has to be sent back through StreamerContext
• buffered ranges + player time are enough to advance normal follow-up responses
• direct seek works on some VODs

Current wall:

Some videos/formats return only policy/backoff responses after a point, with no media parts.

In those cases the UMP response contains:

• STREAM_PROTECTION_STATUS.status=3
• a backoff value
• no MEDIA_HEADER

So the next thing to understand is the client context/token path around this status=3 case.

[InfinityLoop1308]

maybe also useful:
https://github.com/t6fb3m59/Piped-LK/tree/experimental

mentioned in TeamPiped/Piped#4242, seems interesting.

I also notice the commit msg indicates that kira's implementation may be not complete.

[Priveetee]

Thanks, awesome find! I’m digging into it now, this looks like a really promising lead.

I knew about Kira’s implementation since you mentioned it to me, but I hadn’t seen this issue/branch yet. Really appreciate the pointer.

[Priveetee]

Hello, small update :)

I maybe went a bit too far down the rabbit hole, but I made some really good progress.

SABR is honestly a very interesting protocol. It is not just "another stream URL" path: it changes the extractor model quite a lot. The current extractor flow is mostly stateless around URLs/manifests, while SABR is much more session/state based: request numbers, playback cookies, buffered ranges, UMP parts, policies, media headers, etc.

Locally, I now have an experimental extractor-side implementation that can:

• read SABR metadata from the player response
• build VideoPlaybackAbrRequest
• POST to the SABR endpoint
• decode UMP responses
• collect init/media segments
• keep SABR session state across follow-up requests

I also managed to reconstruct a short public VOD locally from SABR media bytes, with valid audio/video output. Some protected/no-media responses are now understood better too, so I’m trying to handle those cleanly instead of treating them as generic failures.

The protocol side is much clearer now :p

[Priveetee]

Update

I corrected one important assumption from the SABR experiments: the official Chromium WEB SABR POST body is not opaque / Onesie. With proper CDP body capture, it decodes as a plain VideoPlaybackAbrRequest.

I also aligned the local experimental request shape closer to Chromium WEB:

• WEB cold-start now selects the same initial video format as the official player on the tested sample
• follow-up state uses selected formats, buffered ranges, playback cookie and player time in the same general shape
• UMP media still works up to the observed boundary

The current wall is still the same though: after a certain point the server returns no media with STREAM_PROTECTION_STATUS.status=3, backoff, and no media headers. I can reproduce that locally and also in official headless Chromium, so I’m treating it as a real protected/no-media state rather than a generic parser/request bug.

Still digging into the legitimate session/context/token path around that boundary.

[Priveetee]

A few more SABR notes from the local experiments :)

I narrowed the protected/no-media boundary a bit more.

The status=3 case does not look like a generic UMP parser bug or a simple request-number / buffered-range issue anymore. The local WEB request state can reproduce the same boundary as the official player, and the missing piece seems to be the legitimate PO-token/context path used around that transition.

The useful result so far is that when the correct content-bound token is present in StreamerContext.poToken, the local SABR harness can move from status=3 / no media to status=1 with real media bytes again.

Some negative controls still fail, so it is not just a wrapper/length/format thing. The token has to be valid for the content binding.

So the SABR request/UMP side is much clearer now. The hard remaining part is reproducing the official token-generation state cleanly enough to make this useful without depending on a live browser page.

[hollownights]

Hi! Not a developer, but curious about some things:

1. Do you get different responses when using an IPv4-only connection (in opposition to the response you may get from an IPv6-first connection)? The “an IPv4-only connection produces less error/is less prone to getting the user agent blocked as a bot” has been a common occurrence reported both by NewPipe and FreeTube users.

2. What type of response do you get for film trailers and, more specifically, for the film trailers from the Films Explore section (alternative URL)? I’ve noticed that they load in different ways depending on the user agent used. Some trailers from the Films Explore section:

https://www.youtube.com/watch?v=c4z4xZtusFg
https://www.youtube.com/watch?v=E4qUgF3RJZc
https://www.youtube.com/watch?v=6ABPub2_Wr0
https://www.youtube.com/watch?v=-OO8f3CfQVQ

[InfinityLoop1308]

@hollownights

1. there is no clue that using ipv4 will resulting in ip ban. the responses are also the same. the issue is ipv4 is more likely shared by your ISP while IPv6 not.
2. not sure what you mean. In PipePipe we don't use these kiosks and only keep the "recommended lives"

[hollownights]

@InfinityLoop1308 You read it all wrong...

1. It is the contrary. People, when using an IPV4-only connection, report that they face less ip bans, not more.

2. I only mentioned the Films Explore section because the trailers that you find there don't lead to your average video page, as they behave differently depending on the user agent. (You can ignore the section and just go for the videos I linked.)

[InfinityLoop1308]

@hollownights

Regardless of which one is "less likely" to get banned, the actual responses from YouTube's API are identical between IPv4 and IPv6. The difference people observe is purely about IP reputation/sharing, not about the response content itself.

This issue is for development discussion among maintainers. Your questions are unrelated to the topic here. Please open a new issue for general discussions.

[InfinityLoop1308]

not sure if you have known that, but you may test poToken with https://github.com/LuanRT/BgUtils/tree/main

[InfinityLoop1308]

just found they have mentioned the usage of poToken in UMP in the README so we must be doing it the correct way.

[Priveetee]

Small note on the IPv4 / trailer comments above.

For the SABR work specifically, I have not seen evidence so far that IPv4 vs IPv6 changes the decoded YouTube response shape itself. It may still affect rate limiting / IP reputation / bot-score behavior in practice, but that is a different layer from the SABR request/UMP/protection data I’m testing locally.

For the trailer links: they are useful as edge-case test videos. I can add them to the local SABR corpus and check whether they expose different player/SABR metadata, client behavior, or protection status. I agree this is separate from whether PipePipe uses the Films Explore kiosk itself; the useful part here is just that those video IDs may behave differently.

Thx both for the context. I’ll keep this issue focused on the SABR/protection side and treat those links as extra test cases rather than a separate product/kiosk discussion.

[Priveetee]

Bigger local SABR update :)

Thx for the BgUtils pointer. Yes, that README note about poToken in UMP matches what I’m seeing locally.

I confirmed experimentally that the protected SABR boundary is tied to the attestation/token data carried in the SABR request context. With valid content-bound attestation data in StreamerContext.poToken, the local SABR session can move from STREAM_PROTECTION_STATUS.status=3 / no media back to status=1 and real media bytes. Negative controls still fail, so this is not just a wrapper/length/request-shape issue.

The SABR side itself is much clearer now. Locally, the experimental harness can:

• parse SABR metadata from /player
• build cold-start and follow-up VideoPlaybackAbrRequest
• decode UMP responses
• keep request number / playback cookie / buffered ranges / player time state
• collect init + media segments
• fetch targeted segments and test seeks
• handle protected no-media responses as an actual SABR state instead of a generic parser failure

So I do not think the main blocker is normal SABR request construction or UMP decoding anymore.

I also traced the WPC/BotGuard path further. The important part is not simply “execute the watch page”. The challenge/bootstrap, BotGuard/WPC state, integrity seed, and final content binding all matter. In the tested cases, the challenge itself is not simply video-bound, but the final media token is content-bound.

Current local conclusion:

• SABR VOD request/session/UMP behavior is mostly mapped locally.
• The status=3 wall is protection/attestation/context-related, matching the poToken direction you pointed out.
• The local proof path can mint/replay valid tokens, but it still depends on official WPC/BotGuard/GenerateIT behavior.
• The real remaining target is reproducing that protection side cleanly, instead of treating a browser/runtime path as the solution.

I’m now looking at the integrity seed/payload -> token transformation and the VM state behind it. After that, the remaining protocol gaps are videoPlaybackUstreamerConfig, rare UMP parts, live/onesie behavior, and exact token expiry.

[Priveetee]

But yeah, this is really some weird shit and I love it :D

I think once I hit another big step I’ll update u guys again. I feel like I’m getting close to understanding the full algorithm / self-contained path well enough that we may be able to reproduce it ourselves instead of depending on the browser runtime.

If I get there, I’ll document it properly, because this whole thing is an incredible mess lol.