Reprogramming a Sennheiser Microphone | Hacker News Reader

Reprogramming a Sennheiser Microphone

vgnotepad.blogspot.com

123 pointsdrmacak20 comments

Throwaway for some obvious reasons, but I work at Sennheiser and I think this is awesome! Personal opinion, and not speaking for the company.

A small disclaimer: operating modified RF devices can, in some jurisdictions and depending on the impact of your modification, put you in contradiction of the law.

From the manual: "Your SKM 3072-U hand-held transmitter can be operated on one of up to 32 different frequencies. These frequencies and their sequence are pre-programmed by the factory and must only be changed by your Sennheiser distributor who has the required specialist equipment."

You may be surprised, but I just checked with some colleagues, we still have the software (SePT.exe) around as well as the service cable. :) I am not sure the last time we performed that service though!

I like Sennheiser because they make at least some stuff still in Europe (vs. many competitors who pretty much live off of made in china copies of classic designs). It's just weird that Sennheiser is very quiet about it, they used to have a "MADE IN GERMANY" on a lot of stuff, directly silk-screened or molded into cases etc. -- this has disappeared. At first I suspected that production for these products was offshored, but it wasn't (still says Made in Germany in the fine-print). Kinda odd.

Complete guess here but I would suspect that means some items are made in Germany and some are made in China or elsewhere (meaning, even the same model may be produced in both locations). If they are printing "MADE IN GERMANY" directly on it then it will be obvious which ones aren't, because they would lack the print. And that would likely degrade the perceived quality of those not made in Germany vs those that are. And Sennheiser doesn't want you to think that some of their items are built with better quality than others.

Of course, people can look at the fine-print and determine where it was made. But that's a lot less obvious than the silk screened badge not being there.

What is the RF output power of these devices?

According to the specification, 30 mW[0]

[0]https://assets.sennheiser.com/global-downloads/file/12003/Sp...

Hi, thats amazing! I was trying if it would be possible to find the software or the cables somewhere hidden on web. But it's looks like there is nothing. This was actually the motivation for the blogpost in case someone want to the same thing, so he can get the informations.

Hi, yes. i know Sennheiser have SePT.exe software. however, this software has been "death" for everyone. I have changed my SKM3072 from 638-670 MHz to 668-674 MHz successfully by myself with a small eeprom tool and ...Excel.

> There were phases where I was worried about going on with the project and pushing it back since I was not confident enougth if it gonna be successful. But as there is already happy ending everything now looks simple and straigthforward. And that's the issue of the most of projects. If you are working on some you never now if it gonna have happy ending at all, and for me it's really hard to push forward the motivation.

This makes me feel better and try harder.

just as an aside for I2C devices, if you know the address, then there is often not many choices on what it can be.

https://i2cdevices.org/addresses http://www.coris.org.uk/jdc/Notes/i2c-devices.html

Reminds me of the time we were trying to bring up a new PCB with a handful of I2C devices and it just would not work. I'd done the driver for one device, and my colleague for another.

Too far longer than it should have to work out that they were using the same address. Fortunately one of them had a pin that would add 1 to the address, so that saved the day.

Ouch, this was way more serious than I was expecting, but I kept reading through the several parts. Totally out of my area but quite well explained. This was a nice little venture into electronics hacking.

Thanks for this.

Good advice at the end plus a link to an unrelated but equally interesting hardware debug/reverse engineer:

  Lessons for aspiring reverse engineers
  
    Spend a few hours/days reading before you start doing.
  
    Prior knowledge helps. You'll get better at reverse engineering as you do it more.
  
    Code shape is recognizable. SPI drivers all look the same, I2C drivers all look similar, circular buffers all look the same. Code shape is a great hint about code function.
  
    Assume people who wrote the code and designed the chip are sane (until proven otherwise).
  
    Newton's first law of software and hardware design: without a significant outside force, things will keep being designed as they always have been. Assume most designs are similar, and what you saw before is likely what you'll see again
  
    Defaults are not changed most of the time.
  
    Every bit of knowledge helps eliminate possibilities in other places. When something confuses you, leave it alone and go analyze something else. Come back to this one later when you know more.
  
    Weird-looking constants mean things. The weirder the number, the more meaning it probably carries
  
    Have a theory before you rush to try things. An experiment with no theory is meaningless.
  
    Do try things. A theory with no experiment is pointless.
  
    Take notes as you try/figure out things, since your "trying things" binary will quickly become an unmanageable mess and you'll forget things.

> Weird-looking constants mean things. The weirder the number, the more meaning it probably carries

Curious what this is suggesting?

One example that immediately comes to mind is how division by a fixed divider is usually optimized by the compiler into something like "quotient * 21378123891231 >> 5". Meanwhile a value like 0xFF0000 is probably an unremarkable mask for the third byte.

These were written by a different person. In his linked article (reverse engineering an eInk tag) he writes:

Low Power Sleep

The thing about humans is: they're human. Humans like nice round numbers. They like exactness, even when it is unnecessary. This helps a lot in reverse engineering. For example, what response does the constant 0x380000 elicit in you? None? Probably. What about 0x36EE80. Now that one just catches the eye. What the hell does that mean? So you convert that to decimal, and you see: 3,600,000. Well now, that's an hour's worth of milliseconds. That length is probably only useful for long-term low power sleep. I have lost track of how many things I've reverse engineered where constants of this variety lit the way to finding where sleep is being done!

In this device, the constants passed to the function in question were: 1,5000 2,000 5,000 10,000 3,600,000 1,800,000 0xffffffff. Pretty clear that those are time durations in milliseconds. The last one is probably a placeholder for "forever, or as close as we can get to it"

Here, there was little chance to understand what many of the regs do, as they are only used by the sleep code. Some were in SFR and some were in MMIO space. I was able to copy the code and replicate it. One thing that was interesting was that the sleep timer has two speeds: 32KHz and 1Hz. It is a 24-bit timer, making the shortest sleep possible approximately 30ms and the longest possible sleep around 194 days! More details in the SDK.

-----

If one browses through a disassembly or hex dump of Arm Cortex code and sees C520 and D928 in adjacent blocks, this is 99.9% watchdog-related code for a handful of Arm licensees, mostly Kinetis/Freescale/NXP. Same deal with various NVM or debug port unlock keys.

Plotting the data section of the ODrive motor driver binary, you can easily find the 2048-entry sine lookup table.

I think looking for weird constants is a good idea. Even better is to have the tools at-hand to identify these easier, so hexdump in parallel with ASCII/int/float representations, plot data, automatically look up register names from an SVD as part of parsing I2C/SPI/CAN data streams, etc.

On the other side of the spectrum (compared what other have written) are e.g. constants in control loops. This could e.g. be a PID controller and the values for P, I and D, may have been chosen very carefully. Changing them slightly may render the application useless.

Depending on what device you're reverse-engineering, the random integers can be:

* Hard-coded encryption keys

* Hard-coded IP addresses (remember, IPv4 addresses are 32 bits long, which is convenient for many embedded CPUs and even some MCUs)

* Hard-coded (instead of random) hash salts

...and generally all manner of things that shouldn't have been hard-coded. That's not to say all constants are bad, but I can see 0xFF000000 and know it's probably just an uninteresting bitmask, then see 0x22C1211E, and maybe with some training (I can't do it by sight alone, for sure) see that it's an IP address in AWS address space.

Unless it's 0x5f3759df, which must be the legendary fast inverse square root ;-)

https://medium.com/hard-mode/the-legendary-fast-inverse- square-root-e51fee3b49d9

Also related functions tend to be close to each other in the binary.

> ...Take notes as you try/figure out things, since your "trying things" binary will quickly become an unmanageable mess and you'll forget things.

Worth to mention also that Version Control of the analysis artifacts helps in tracing your way forward. It also helps in trying out ideas to refine your understanding.

Reply on news.ycombinator.com