[HN Gopher] Reprogramming a Sennheiser Microphone
___________________________________________________________________
Reprogramming a Sennheiser Microphone
Author : drmacak
Score : 112 points
Date : 2021-07-27 10:40 UTC (2 days ago)
(HTM) web link (vgnotepad.blogspot.com)
(TXT) w3m dump (vgnotepad.blogspot.com)
| audiothrowaway wrote:
| 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!
| drmacak wrote:
| 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.
| formerly_proven wrote:
| 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.
| programbreeding wrote:
| 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.
| eephd wrote:
| What is the RF output power of these devices?
| audiothrowaway wrote:
| According to the specification, 30 mW[0]
|
| [0]https://assets.sennheiser.com/global-
| downloads/file/12003/Sp...
| sneak wrote:
| > _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.
| PennRobotics wrote:
| 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.
| zoomablemind wrote:
| > ...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.
| megous wrote:
| Also related functions tend to be close to each other in the
| binary.
| [deleted]
| spywaregorilla wrote:
| > Weird-looking constants mean things. The weirder the number,
| the more meaning it probably carries
|
| Curious what this is suggesting?
| don-code wrote:
| 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.
| formerly_proven wrote:
| 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.
| freethinky wrote:
| 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.
| PennRobotics wrote:
| _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.
| adrianomartins wrote:
| 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.
___________________________________________________________________
(page generated 2021-07-29 23:01 UTC)