Battley batters BBC as iPlayer gets hacked. Again

happygeek 0 284 Views

Paul Battley is a software developer from London who can probably lay claim to being the biggest thorn in the side of the BBC right now. No sooner had the mighty British Broadband Corporation announced that his hack which allowed people to download iPlayer TV streams meant for an iPhone to a hard drive and share them others had been fixed, than the 30 year old Linux fanboy broke it again.

Apparently in using plug-in requests to search Javascript code for the fixes, and then reprogramming the interface using Ruby on Rails, is simply a combination of the coding challenge and a hint of annoyance over lack of Linux support for the iPhone version of iPlayer.

The BBC, for its part, says that rights issues require them to offer streamed programming for no longer than seven days after initial broadcasting, while a downloads service enables PC users to keep those programmes longer, for up to 30 days in fact. "It's an ongoing, constant process and one which we will continue to monitor" The BBC said via a statement…

Dani AI

Generated

This thread highlights two useful things: the practical attack surface that web-based players expose (a point raised earlier in the discussion) and how small distractions in the thread can take attention away from the technical fixes needed. The short note below focuses on concrete, applied steps that operators and developers can act on without getting into the original narrative detail.

Operator checklist (priority order):

  • Require short‑lived, signed delivery URLs or signed cookies for manifests, keys and segments instead of static public URLs.
  • Use segmented delivery (HLS/DASH) with per‑segment keys and regular key rotation; serve key material only over authenticated HTTPS.
  • For licensing scenarios that need enforced persistence controls, deploy a vendor DRM (Widevine/PlayReady/FairPlay) rather than relying on obfuscation.
  • Move entitlement/key logic to the server; never embed secrets or key-generation code in client JavaScript.
  • Detect and mitigate mass downloads: apply rate‑limits, WAF rules and anomaly detection tied to token usage and IP behaviour.

(docs.aws.amazon.com)

Developer testing and triage tips:

  • Verify manifests (for example, .m3u8) do not reveal keys unless the request presents a valid, unexpired token; attempt Range/partial GETs with expired tokens to ensure denial.
  • Scan client assets (JS, HTML) for hardcoded secrets and run a threat model on any client-side decision the player makes.
  • Add logging/alerts on unusual segment-request patterns and have an incident playbook to revoke signers and rotate keys quickly. (docs.aws.amazon.com)

There are trade‑offs: DRM, secure key management and detailed monitoring add cost and complexity and can affect UX. For most licensors the pragmatic path is short‑lived signed access + per‑segment encryption + a clear disclosure/bug‑reporting channel so researchers who find weaknesses can report them and fixes can be rolled out before public abuse. and ’s comments help keep the technical and editorial sides of the discussion aligned.

Member Avatar for UrbanKhoja
UrbanKhoja 89 Practically a Posting Shark

Isn't it British Broadcasting Corporation?

Dazza :cool:

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.

Edit Preview