[sdiy] Berhinger service portal (WAS: Lockout / DRM chips?)

Fri Sep 11 22:41:17 CEST 2026

I can see no way to either access the service portal or request a login. Do
you have to be a proper service facility? Do you have a link?

On Fri, Sep 11, 2026, 10:34 PM David Kantowitz via Synth-diy <
synth-diy at synth-diy.org> wrote:

> That is interesting.  Thank-youl
>
> On Fri, Sep 11, 2026 at 2:27 AM rob hukin via Synth-diy <
> synth-diy at synth-diy.org> wrote:
>
>> Schematics for all Behringer products are available on their Service
>> Portal.
>>
>> You just need to apply for a login.
>>
>> rob.
>>
>> On 11 Sep 2026, at 09:38, David Kantowitz via Synth-diy <
>> synth-diy at synth-diy.org> wrote:
>>
>> It does seem a bit odd.  Personally my view is folks would be better off
>> working *with* Behringer.
>> Imagine if B has open sourced schematics & s/w for their Brains board.
>> I really doubt B gives half a toss about the software: they make money
>> selling boards.
>> Even with all the schematics, I doubt people will be able to sell the
>> module more cheaply than B.
>> B would simply sell more boards ... exactly what B wants!
>>
>> Use the few thousand hours it would take to build a solid DRM system to
>> convince B to be a better partner to the SDIY community.
>>
>>
>>
>>
>> On Fri, Sep 11, 2026 at 12:40 AM Márton Bertók via Synth-diy <
>> synth-diy at synth-diy.org> wrote:
>>
>>> My stuff is open source, feel free to clone them. Cloning is an
>>> essential part of SDIY. You’re advocating killing DIY with DRM on the SDIY
>>> mailing list, which sounds bonkers to me.
>>>
>>> > On 11 Sep 2026, at 09:29, cheater cheater <cheater00social at gmail.com>
>>> wrote:
>>> > Wait for behringer to clone your hardware and you'll sing a different
>>> tune
>>> >
>>> > On Fri, Sep 11, 2026 at 9:25 AM Márton Bertók <marton.bertok at me.com>
>>> wrote:
>>> >>
>>> >> This sounds worse than anything Behringer ever pulled.
>>> >>
>>> >>> On 11 Sep 2026, at 06:13, cheater cheater via Synth-diy <
>>> synth-diy at synth-diy.org> wrote:
>>> >>> 
>>> >>>> Honestly, it's a bit hard to point you in the right direction
>>> without understanding what you actually want to do.
>>> >>> Ultimately the goal is as follows.
>>> >>> Situation: A new physical format, let's say for modular synthesizers
>>> >>> or audio effects, is created.
>>> >>> Problem: how to lock out a specific manufacturer that clones devices
>>> >>> created by others, so they don't shit up this format as well?
>>> >>> Solution: some form of hardware authorization and authentication
>>> >>> Purpose of the discussion: The first part can be something myself and
>>> >>> some others are planning, or it could be something that a completely
>>> >>> different group of people are doing and they could use what's been
>>> >>> learned here as basis for safeguarding their business from
>>> parasitical
>>> >>> manufacturers
>>> >>>> On Thu, Sep 10, 2026 at 10:02 PM David Kantowitz <
>>> dkantowitz at gmail.com> wrote:
>>> >>>> Not really. Search for "secure microcontroller" at the NXP
>>> website.  The detailed manuals (at least for NXP) usually require an NDA w/
>>> NXP, but a 2-page summary sales sheet should be available.
>>> >>>> A lot of microcontrollers (not just NXP) have features like:
>>> 'secure boot', 'secure element', 'secure memory', 'trusted module',
>>> 'trusted execution', etc.  ARM has TrustZone that a lot of manufacturers
>>> use.  Some combination of those features could do what you want.
>>> >>>> Honestly, it's a bit hard to point you in the right direction
>>> without understanding what you actually want to do.   ... and based on my
>>> earlier emails, what you described as wanting to do doesn't really make
>>> sense to me in a commercial context.  There are significant costs involved
>>> in building even vaguely secure hardware.  An example of the stupid shit
>>> that happens ... units were keyed at Key Injection Facility, then shipped
>>> to the user site, units started to arrive in the tamper state with no keys
>>> .. queue 6 month parade of units back and forth ... eventually we figure
>>> out that a software bug wasn't putting the cpu into a low enough sleep
>>> state and the supercap keeping the keys alive was drained in transit.  I
>>> can't even bear to describe how stupid the spares situation became.
>>> >>>>> On Thu, Sep 10, 2026 at 11:51 AM cheater cheater <
>>> cheater00social at gmail.com> wrote:
>>> >>>>> Thanks, David. That's some good info. Can you point to some recent
>>> >>>>> devices that are available on the market?
>>> >>>>> On Thu, Sep 10, 2026 at 7:22 PM David Kantowitz <
>>> dkantowitz at gmail.com> wrote:
>>> >>>>>> BOM cost was single digit USD.  Essentially it was a way to audit
>>> licensing fees through an electronic component based supply chain.
>>> >>>>>> What you're describing are key rolling and key injection.  You
>>> can look at current practices for payment terminals, but honestly those are
>>> made-by-committee unions of the individual company's own practices.
>>> >>>>>> We used two basic approaches to secure the cryptographic root:
>>> >>>>>> 1. 'Base' key injection key that's used only to load
>>> site-deployment keys.  Those keys were secured by obscurity.
>>> "Steganographic methodology" when we wanted to sound like experts.
>>> >>>>>> 2. Shipping units to a secure key injection facility.  Use tamper
>>> evident bags when you want a fancy audit trail.
>>> >>>>>> Site keys are stored in something physically tamper-proof.  As a
>>> simple example (ie. what was done 20 years ago):
>>> >>>>>> - make a PCB sandwich.  all components on inside, no traces on
>>> outside of PCB.  single power & serial port on outside. a plastic ring goes
>>> around the edge. bolot he sandwich together.
>>> >>>>>> - electrical connection between the two boards via pin headers
>>> >>>>>> - put key in static RAM (not flash, not DRAM)
>>> >>>>>> - SRAM on board A, battery on board B
>>> >>>>>> If someone opens the sandwich and the site keys lose power.  Back
>>> to (1) or (2) above to restore site keys.
>>> >>>>>> Despite having microcontrollers with secure memory, much more
>>> physically complicated versions of the sandwich are still used today:
>>> >>>>>> (A) Detect the tamper.  (B) Destroy the keys.  (C) Restore the
>>> keys.
>>> >>>>>> Separately, everyone also builds in some method for key-rolling
>>> into their systems.  This handles the scenario you described: you believe
>>> the keys were actually stolen with malicious intent.  Personally, I've gone
>>> through customer witnessed testing of the key rolling, I've never seen a
>>> live system do a key roll.  It was simply too risky.  Instead we would
>>> maintain blacklists of cards & equipment.  This requires a system that is
>>> frequently online.
>>> >>>>>> On Thu, Sep 10, 2026 at 9:20 AM cheater cheater <
>>> cheater00social at gmail.com> wrote:
>>> >>>>>>> I agree that the DRM is just one component of an otherwise
>>> healthy
>>> >>>>>>> business strategy.
>>> >>>>>>> Do you remember how much roughly the NXP chips added to your BOM?
>>> >>>>>>>> This seems to be the arc of most cryptographically enabled DRM.
>>> >>>>>>> I agree. I know about power monitoring, power glitching, and
>>> various
>>> >>>>>>> other hardware attacks.
>>> >>>>>>> One thing that I'm curious about is things like updating
>>> encryption,
>>> >>>>>>> in order to be able to repudiate compromised keys, eg from
>>> >>>>>>> manufacturers who have decided to start leaking them to
>>> companies who
>>> >>>>>>> shouldn't have them. This would at least require some sort of
>>> secure
>>> >>>>>>> vault with a machine of some sort inside, probably a VM.
>>> >>>>>>> Cheers,
>>> >>>>>>> D
>>> >>>>>>> On Thu, Sep 10, 2026 at 6:09 PM David Kantowitz <
>>> dkantowitz at gmail.com> wrote:
>>> >>>>>>>> The closest "on topic" experiences I have are with the
>>> contactless payment (and ID) cards.
>>> >>>>>>>> To read/write Mifare cards, we had to include the Philips (now
>>> NXP) reader chip in our equipment: even though our own DSP/FPGA generated
>>> the RF modulation signals and we had our own implementation of the on-air
>>> data protocol stack.
>>> >>>>>>>> All the Philips chip contained was their proprietary
>>> shared-secret encryption algorithm.
>>> >>>>>>>> Two things happened over time:
>>> >>>>>>>> 1. Researchers reverse engineered/discovered and published the
>>> exact proprietary cryptographic algorithm.
>>> >>>>>>>> 2. Various key recovery techniques were possible through either
>>> defects in the protocol implementation or techniques like power monitoring
>>> (which you can also think of as an implementation defect).
>>> >>>>>>>> This seems to be the arc of most cryptographically enabled DRM.
>>> >>>>>>>> The Philips chips were generally easy to use and the
>>> integration cost was more a one-time expense.  Still they added to the BOM
>>> cost.
>>> >>>>>>>> Even after the system was broken we continued to use them: it
>>> was the easiest way to vouch to our customers that our equipment was
>>> compatible with Mifare cards.  That compatibility was necessary because, by
>>> then, out customers had money sunk (ie. millions) into cards.
>>> >>>>>>>> Briefly off topic: that 10+ year experience taught me that
>>> DRM-like capabilities are small (nearly irrelevant) technical components in
>>> a broader commercial strategy ; figure out the strategy first and then use
>>> DRM as a temporary stepping stone in that strategy.
>>> >>>>>>>> On Thu, Sep 10, 2026 at 12:41 AM cheater cheater via Synth-diy <
>>> synth-diy at synth-diy.org> wrote:
>>> >>>>>>>>> David, Mike,
>>> >>>>>>>>> Please start a separate thread, this isn't what this thread is
>>> about.
>>> >>>>>>>>> Thanks.
>>> >>>>>>>>> On Thu, Sep 10, 2026 at 8:58 AM David Huss via Synth-diy
>>> >>>>>>>>> <synth-diy at synth-diy.org> wrote:
>>> >>>>>>>>>> The idea to do some sort of multichannel modular via digital
>>> cables is not exactly new and not exactly something that isn't obvious.
>>> >>>>>>>>>> Technically such a thing is already done with ADAT/Toslink
>>> optical cables and many audio interfaces use it to allow users to add more
>>> I/O channels.
>>> >>>>>>>>>> So the main obvious question is why we haven't seen something
>>> like this widely used in the modular world?
>>> >>>>>>>>>> To me the answer is that the simplicity of the concept is
>>> unbeatable: Everything is just a voltage versus time, one signal per cable,
>>> what you see is what you get. All while being reliable, cheap to implement,
>>> cables are cheap, clocking is not an issue, it is conceptually clear, etc.
>>> >>>>>>>>>> The two useful applications of multi-channel cables I see
>>> are: (1) polyphonic modules where patching up 4+ cables is annoying and
>>> takes up valuable panel space and (2) breakout boxes for multichannel
>>> connections between racks (e.g. via Ethernet).
>>> >>>>>>>>>> Of course I could envision cool systems with multi-channel
>>> cables, but I am not sure it is really worth the extra complexity to make
>>> them digital. By that point one can ask, why not just run everything on a
>>> computer and make a patch-cable controller panel that just reads out the
>>> patch connections, knob positions etc and controls a big virtual modular.
>>> >>>>>>>>>> On September 9, 2026 11:44:34 PM UTC, Gordonjcp <
>>> gordonjcp at gjcp.net> wrote:
>>> >>>>>>>>>>> On Wed, Sep 09, 2026 at 07:31:21PM +0200, cheater cheater
>>> via Synth-diy wrote:
>>> >>>>>>>>>>>> So, there's good news and bad news. The bad news is that I
>>> can't go
>>> >>>>>>>>>>>> into specifics, but there are good reasons to expect a new
>>> modular
>>> >>>>>>>>>>>> format showing up sometime in the not extremely distant
>>> future.
>>> >>>>>>>>>>> Good luck with that.
>>> >>>>>>>>>>> How did you get one with your polyphonic modular idea with
>>> 24 channels of 24-bit 192kHz CV on a single 3.5mm jack?
>>> >>>>>>>>>> ________________________________________________________
>>> >>>>>>>>>> This is the Synth-diy mailing list
>>> >>>>>>>>>> Submit email to: Synth-diy at synth-diy.org
>>> >>>>>>>>>> View archive at: https://synth-diy.org/pipermail/synth-diy/
>>> >>>>>>>>>> Check your settings at:
>>> https://synth-diy.org/mailman/listinfo/synth-diy
>>> >>>>>>>>>> Selling or trading? Use marketplace at synth-diy.org
>>> >>>>>>>>> ________________________________________________________
>>> >>>>>>>>> This is the Synth-diy mailing list
>>> >>>>>>>>> Submit email to: Synth-diy at synth-diy.org
>>> >>>>>>>>> View archive at: https://synth-diy.org/pipermail/synth-diy/
>>> >>>>>>>>> Check your settings at:
>>> https://synth-diy.org/mailman/listinfo/synth-diy
>>> >>>>>>>>> Selling or trading? Use marketplace at synth-diy.org
>>> >>> ________________________________________________________
>>> >>> This is the Synth-diy mailing list
>>> >>> Submit email to: Synth-diy at synth-diy.org
>>> >>> View archive at: https://synth-diy.org/pipermail/synth-diy/
>>> >>> Check your settings at:
>>> https://synth-diy.org/mailman/listinfo/synth-diy
>>> >>> Selling or trading? Use marketplace at synth-diy.org
>>>
>>> ________________________________________________________
>>> This is the Synth-diy mailing list
>>> Submit email to: Synth-diy at synth-diy.org
>>> View archive at: https://synth-diy.org/pipermail/synth-diy/
>>> Check your settings at: https://synth-diy.org/mailman/listinfo/synth-diy
>>> Selling or trading? Use marketplace at synth-diy.org
>>>
>> ________________________________________________________
>> This is the Synth-diy mailing list
>> Submit email to: Synth-diy at synth-diy.org
>> View archive at: https://synth-diy.org/pipermail/synth-diy/
>> Check your settings at: https://synth-diy.org/mailman/listinfo/synth-diy
>> Selling or trading? Use marketplace at synth-diy.org
>>
>>
>> Rob Hukin
>> Audiocircus Ltd
>>
>> +44 7961 883 949 <+44%207961%20883949>
>>
>>
>>
>>
>>
>>
>>
>> ________________________________________________________
>> This is the Synth-diy mailing list
>> Submit email to: Synth-diy at synth-diy.org
>> View archive at: https://synth-diy.org/pipermail/synth-diy/
>> Check your settings at: https://synth-diy.org/mailman/listinfo/synth-diy
>> Selling or trading? Use marketplace at synth-diy.org
>>
> ________________________________________________________
> This is the Synth-diy mailing list
> Submit email to: Synth-diy at synth-diy.org
> View archive at: https://synth-diy.org/pipermail/synth-diy/
> Check your settings at: https://synth-diy.org/mailman/listinfo/synth-diy
> Selling or trading? Use marketplace at synth-diy.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://synth-diy.org/pipermail/synth-diy/attachments/20260911/1d225dd3/attachment.htm>