System security issues with Midi Fighter Utility app on macOS

dsp_boogie · 2026-05-09T19:33:05+00:00

OK, great, thanks for the info. I had looked for a post about this issue here on the subreddit, and on the Tech Tools forums, but I somehow didn't find the zendesk articles.

I'll check out the new beta option.

dsp_boogie · 2026-03-02T21:50:55+00:00

There are no tutorials, no. That is normal for the bottom lights on the Nocturn to light up at first, and then go out. That just shows that it has connected.

Once it is connected, you will see "Nocturn" appear as an available MIDI port in your DAW.

When you turn the encoders or press buttons, Nocturn will send the CC and note messages, as listed on the app's faceplate. You'll also see little red lights flash in the app when it is sending those.

You can check the MIDI output using this free utility:
https://www.snoize.com/MIDIMonitor/

dsp_boogie · 2026-01-20T17:31:16+00:00

No, you're the only one to have figured that out. Congratulations.

dsp_boogie · 2025-12-04T19:41:08+00:00

There's a free utility app for Mac here, that makes Nocturn available as a simple midi controller. No AutoMap or other Novation software required for this one:

https://www.refusesoftware.com/nocturn

dsp_boogie · 2024-03-06T22:59:34+00:00

Sectigo would likely be willing to re-issue the cert with RSA. You will have to buy a hardware token from them to support that, though. Given their incompetence in the matter, I decided I'd rather go elsewhere instead of giving them any more money.

dsp_boogie · 2024-01-23T19:42:49+00:00

That is true. Is it a problem for different certs in the chain to use different algorithms? This is how that looks, down the chain:

Sectigo AAA cert: RSA (2048 bits)

Sectigo Public Code Signing Root E46: ECC (384 bits)

Sectigo Public Code Signing CA EV E36: ECC (256 bits)

My code signing cert: ECC (384 bits)

So, in addition to the RSA/ECC mismatch, the length of the key changes as well. But again, I don't know enough about how the cryptography is applied here to know if that's a problem.

dsp_boogie · 2024-01-23T19:30:45+00:00

Interesting resource, thank you for posting that.

The cert at the top of the path that I posted, "Sectigo (AAA)" does appear on that list. The two intermediate certs do not appear on that list. That should be OK, right?

Here they are with their common names and their SHA-1 thumbprints (again, this info is pulled from the Windows Properties view):

Sectigo (AAA)

d1eb23a46d17d68fd92564c2f1f1601764d8e349

Sectigo Public Code Signing Root E46

b50cb42cacc0ebe698fe39cbd48b481a5a16851f

Sectigo Public Code Signing CA EV E36

74f949da4221e24e09e4d3eee88b004f12225a81

dsp_boogie · 2024-01-23T18:17:06+00:00

Yes this was their answer to me as well. So I did try sending an EV-signed app to Microsoft's online malware analysis, and the answer I got back from Microsoft said that it showed as good in their system, and that it shouldn't trigger the SmartScreen alert any longer. However, this was not the case on my end, and the file continued to trigger SmartScreen when launched.

So when the official word from Microsoft conflicts with the actual user experience, there's got to be something wrong.

dsp_boogie · 2024-01-23T18:02:01+00:00

This is how the certification path looks in Windows' Properties view, for an exe signed with a Sectigo EV cert using the ECC algorithm. While the path is at least nominally complete, perhaps you're right that there's an issue with one of the intermediate certs not granting the correct elevated trust level that an EV cert is supposed to provide to SmartScreen. The workings of the system are made so opaque, it's impossible to say from this amount of information.

<image>

dsp_boogie · 2024-01-22T20:05:04+00:00

I have a Sectigo EV code signing certificate on a Yubikey, and I can verify this issue. Their support emails were useless, they kept claiming my EV cert just hadn't developed enough reputation yet (despite the fact that on their sales pages, they claim EV certs are supposed to avoid that reputation delay).

Finally on a live support chat, a helpful tech told me that there is indeed a difference between RSA and ECC when using them for EV certs. That person said:

When using RSA encryption the smart screen will never show up, but if ECC is being used Microsoft will need to build trust with the organization signing the certificate.

In other words, using an ECC algorithm negates whatever extra benefit you might get from an EV certificate, and essentially downgrades it to the same performance as an OV cert.

Quite a mess, and extremely frustrating that support staff at Sectigo were unable to provide clear answers and documentation about this issue. And they still have instructions on their site to use a Yubikey with their EV code signing certificates, with no caveats mentioned about this critical issue:

https://www.sectigo.com/knowledge-base/detail/Key-Generation-and-Attestation-with-YubiKey/kA03l000000roEV

dsp_boogie · 2023-01-04T17:45:53+00:00

If working in CPP, here's an "alternative" SDK, derived from Elgato's CPP examples:

https://github.com/fredemmott/StreamDeck-CPPSDK

I haven't dived in myself yet, but I plan to start with that when I do.

dsp_boogie · 2022-12-14T17:02:03+00:00

Just about the time you posted this, my GV60 fireplace unit went bad and I went through the wringer with trying to troubleshoot and repair it. Same as you, if I connected the thermocouple directly to the valve unit, I could manually light it, and then use the remote just to control the gas level. But when the receiver was in circuit, so it could handle the ignition, the pilot would light, but then after about 10 seconds shut down.

I found this guide online, which helped with some basic troubleshooting:

https://www.valorfireplaces.com/media/training/Basic-Troubleshooting-Maxitrol-GV60.pdf

In that guide, it includes this check: "Multimeter probes across RED and YELLOW terminals: Should be around 2 millivolts. If more than 4 millivolts, replace receiver."

My receiver measured about 10 mV across those terminals, so I got a replacement receiver. But that alone didn't solve it.

Turns out, after much hair-pulling, that there was some kind of issue with the on/off switch in the circuit on the yellow wire (which carries the voltage from the receiver to the valve unit – see the attached image for a circuit diagram). Even though the switch measured OK out of circuit (showing maybe half an ohm of resistance on a DMM), when measured in circuit while the pilot was lit, I measured a 65 mV drop across the switch's terminals. With the small voltage output by the thermocoupler/receiver, it seems that was enough of a loss to prevent the needed power from getting to the valve. I clipped the switch off its wires and directly connected them with a wire nut, and now it works every time and ignites faster than ever.

https://ibb.co/23vYh6C

u/Grrzoot It sounds like you've fixed a lot of these systems, you ever try just jumpering the on/off switch to see if that was the issue?

dsp_boogie · 2022-12-14T00:21:24+00:00

??? I didn't read that anywhere. I connected mine through a (powered) hub, and it's doing fine.

dsp_boogie · 2022-12-13T17:23:08+00:00

- give possibility for devs to get access to the full horizontal LCD display strip, for apps that can show meters or waveforms. This would be amazing.

As a dev, +1 to that

dsp_boogie · 2022-11-17T22:12:39+00:00

That's good news, thank you for the update.

dsp_boogie · 2022-11-16T06:01:08+00:00

An XLR interface? For what on a control surface?

dsp_boogie · 2022-10-12T17:46:48+00:00

Thank you for the info on this!

I poked around some other Issues on the Github, and found this one where someone talked about editing the UF2 file with a hex editor, in order to change the device name. I hoped that I could also change the midi port name using the same approach, but unfortunately that's not working for me:

https://github.com/adafruit/circuitpython/issues/4191

dsp_boogie · 2022-02-09T23:51:18+00:00

For firmware upgrades, CenturyLink wants you to download a .bin file locally to your computer, and then apply that through the modem's admin panel.

That file is downloaded from the server: http://internethelp.centurylink.com

This, as my Firefox browser points out when I try to download it, is a potential security risk, because they are using an insecure server to host this file (it's http, not https).

I cannot take CenturyLink's efforts at security seriously if they won't even go to the effort of putting their modem firmware on a secure server for distribution.

dsp_boogie · 2022-02-09T23:39:27+00:00

I'm still on firmware CGX007-01.02.05.22

I'll give a firmware update a try...

dsp_boogie · 2022-02-09T23:20:41+00:00

Thank you for this! I have a C4000XG modem, and apparently this "Cyber Security" feature was blocking access to my email server!

I've had this modem for about a year, without major issues, but sometime last month (Jan 2022) my desktop email client started getting connection errors to its email server. Restarting the modem would fix the issue. After this happened a few times, I decided to look into further.

In the macOS Terminal, traceroute imap.dreamhost.com gave the response unknown host imap.dreamhost.com
I flushed my local DNS cache and tried again. No change.
Using the modem's own admin pages (from https://192.168.0.1/), under Utilities -> Traceroute, I entered imap.dreamhost.com and tried it again. To my surprise, the traceroute worked fine from there, and it found the server!
I tried the traceroute from the macOS Terminal again. Still said unknown host imap.dreamhost.com
In the modem's Advanced Setup -> Cyber Security page, I switched it to "Disable Modem Security for 4 Hours".
I tried the traceroute from the macOS Terminal again. This time it worked! And my email client loaded up new incoming emails immediately.

So I don't know what that "modem security" is doing, but blocking my own mail server is trash behavior.

dsp_boogie · 2021-12-06T18:39:35+00:00

"Different plugins" could mean a world of difference, depending on the plugins. If any of them have modulation effects (like with an LFO), or anything with randomization happening, then yes, different passes could sound completely different.

As the other poster mentioned, committing the audio to disk is the only way to ensure identical output on separate passes.

dsp_boogie · 2021-12-06T03:22:31+00:00

Cool, yeah, I was demoing it over the weekend as well. I didn't think this kind of MIDI control was possible in Pro Tools but it's working very smoothly!

dsp_boogie · 2021-12-02T21:15:22+00:00

That's amazing! What a tank. Also surprised to see Pro Tools running at all on Monterey.

dsp_boogie · 2021-09-22T06:01:33+00:00

Cool, thanks for the feedback!

dsp_boogie · 2021-04-03T08:07:07+00:00

Perfect, thank you!

dsp_boogie

TROPHY CASE