This is a fairly recent multi-channel USB audio interface. I think there’s a distinction between the “Presonus 1824c” and “Presonus Studio 1824c” ? Not sure.

Repair #

***** YT vid link (TODO)

Again, consumer electronics plagued by low-quality capacitors. This time, luckily no corrosion damage (that seems to be confined to caps from the ’90s).

The culprits :

• first bulk cap (C4) after a PMOS switch, with visibly domed top
• a few others with in-circuit measured capacitance & ESR clearly off
• a few that are paralleled on the switched_12V rail, and had to be taken out to be measured properly

At this point, it almost worked but was flaky still ; probing the +5, +3.3 and +1 rails I could see it was trying to power-on and failing repeatadly (ramp-up followed by a collapse, repeated on all rails). Sadly, forgot to get scope screenshots. It appears the +3.3 and +1 regulators are fed from the +5 rail (but why ?), and the +5 rail had a marginal capacitor that I had initially overlooked. After replacing a few more, power-on became solid.

List of questionable (and replaced) capacitors #

Testpoints #

These are under the PCB.

• T3 !phant_en ?
• T7 5v (C21?)
• T11 +1v (0.94v)
• T17 +15v
• T18 -15v
• T27 phant +48V if !phant_en
• T29 3.3v (C454)

Components #

• IS25LQ016 SPI flash, 16Mbit/2MB
• TL082 : Ch1&2 (Instrument hi-z pre ?)
• HP amp : njm4556AL
• U5 MP3425 step-up for +48 phant
• U7 NCP3170A; vin=4.92V, vout=1V
• U16 NCP3170B; vin=vcc_sw, vout=5.1v
• U22 NCP3170B; vin=4.99V, vout=3.3v
• U29 MP3425 step-up for +/-15 rails
• Q3 : NT2955G, onsemi, Pmosf (input pwr switch)
• Q1x,Q2x (to92, 2 per input), 2N4403 PNP
• Q3x,Q4x (sot-23, 2 per input channel) : BC849, marking 2C

ncp3170a/b pwm controller variants: (-A = 500khz, -B=1Mhz)

Firmware #

*********** Note ! **********

At some point after the USB DFU tests, I took many wild tangents because a tool I was using, was not behaving as expected. I still think there is interesting material here; and after all the trouble I went through, and having written this concurrently, it would be a waste to erase it… TLDR: skip to the end

Initial poke #

Let’s see if I can extract firmware updates from their software “Universal Control”. Looking through the installed files, it doesn’t look like the firmwares are separate files, but rather either bundled in an .exe, or retrieved online.

First, the easy stuff :

$ strings Universal\ Control.exe | grep firmware

firmwareRevision
firmwareVersion
firmwareUpdateNeeded
.......
firmware.json

Good guess; they have firmware update code inside the .exe. What is this .json file though, is it obtained online like Tascam does for some of their things ?

A bit later, still in Universal Control.exe, I find a few bits like

                "defaultfilename": "fpclassicupgrade.syx",
                "successcode": 2007,
                "firmwareupdaterequired": false
                "devicemodel": "FaderPort 8",
                "portname": "PreSonus FP8",
                "portname.mac": "PreSonus FP8 Port 1",
                "updatedelay": 200,
                "parts":
                        {
                                "revision": "343",
                                "version": "v3.43",
                                "file": "firmware/fp8upgrade.syx"

Hmm, definitely json syntax, but I can’t find an entry for the 1824c. The above is for different hardware, reflashed over MIDI (the .syx extension, for SysEx). Not much luck in other files. Note, the 1824c is part of the “studio” series; internally referred to as ‘demeter’, and handled by the “StudioUSB” driver.

FW versions #

So, what happens when I plug this in, with a VM running UC 3.2.1 ?

What, my unit has v3.11 and UC wants to flash the “new version” 2.51 ? Uh…. I assume it’s only checking for an exact version match; obviously not a numeric ‘greater-than’ comparison.

A bit of release note archeology reveals :

• product probably initially shipped with 2.50; UC 2.10 is the first to support the series
• UC 3.2.1 upgrades fw to 2.51
• UC 3.6.3 first mention of fw 3.11 ?

Not sure of any other intermediate or more recent fw versions.

So where is that fw blob hidden ? I’m omitting tons of false leads here, but I dug a bit deeper with binwalk, with the essential argument -a which continues parsing within .exe / .dll after their header; thus I found lots of compressed XML data. This wasn’t the revelation I hoped, but still found an interesting chunk :

	<Variant property="incompatible" .....
		<Link title="PLEASE UPDATE DEVICE FIRMWARE!" command.category="Settings" command.name="Update Firmware"

Right, so they probably expect an exact version match. This also explains why it was hard to search for UI strings - they are compressed ! The interactions are complex between Universal Control.exe and the supporting framework cclgui.dll etc.

And the disassembly in ghidra is not very revealing either - convoluted refs due to C++, classes, that kind of mess. I made zero progress on that front.

Low level SPI capture #

Before trying a fw upgrade, I wanted some kind of backup. I hooked a logic analyzer to the SPI flash IC (didn’t feel like de-soldering it), and spied on the boot sequence. With PulseView + https://github.com/mbenkmann/quadspi_sigrok/ and some scripting, I obtained a few blocks of data. It appears the XMOS cpu reads what it needs into its on-chip RAM and executes from there. The firmware is surprisingly small, about 207kB, vs the flash IC installed (2MB) !

Seems to run some code at address 0 (bootloader ?):

8D 30 00 00 F3 37 00 09 00 B7 10 ....

then a large chunk from 0x18000:

ED 15 FF 00 D0 C1 3C 22 E7 83 2B ....

And lastly, most likely a ‘config block’ at 0x10 0000:

00000000: 50 52 45 53 4f 4e 55 53 78 d1 7f be 00 00 00 01  PRESONUSx.......
00000010: 53 43 34 45 31 39 _________________ 00 00 00 00  SC4E19      ....
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

This last block was very nice to have as the only source of verifiable plaintext. There is no ASCII anywhere else, despite entropy being lower than expected - I fully assumed this would be encrypted, as on the Scarlett 3rd gen. Note, this particular chunk contains the serial number and is probably not contained in a fw blob but written as needed by the device.

USB DFU #

These are complicated composite USB devices, exposing USB-Audio class compliant interfaces and endpoints, MIDI endpoints, vendor-specific stuff, and in this case also one visible USB-DFU interface :

$ lsusb -v
Bus 005 Device 065: ID 194f:010d PreSonus Audio Electronics, Inc. Studio 1824c
Negotiated speed: High Speed (480Mbps)
....
 Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        5
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass       254 Application Specific Interface
      bInterfaceSubClass      1 Device Firmware Update
      bInterfaceProtocol      1
      iInterface             12
      Device Firmware Upgrade Interface Descriptor:

This is also confirmed by dfu-util -l :

Found Runtime: [194f:010d] ver=0311, devnum=47, cfg=1, intf=5, path="5-1.4", alt=0, name="PreSonus DFU", serial="SC4E19....

Surprisingly, it offers ‘Upload’ capability, i.e. reading memory ! Could we get a full fw dump this way ?

$ dfu-util -U test.bin
...
Upload  [=========================] 100%        96000 bytes
Upload done.
Received a total of 96000 bytes

96000 ? Seems rather arbitrary… The contents match the earlier SPI bus capture but clearly doesn’t contain the entire firmware. Some hardcoded limit? Missing some non-standard USB requests to dump other areas ? I never found out.

USB traffic #

It should be possible to have VirtualBox capture and log USB traffic for us, but it seems to be truncating or dropping lots of packets. This will be no good for examining a full fw reflash.

Wireshark is the obvious answer; running it inside a windows VM is possible but I was having issues with dropped packets and limited capture size ? It was a waste of time anyway : I can run wireshark on the host (linux), and capture USB traffic just fine even if VirtualBox guest VM is using the device.

To make this work, sudo modprobe usbmon was required first, then a short udev rule to set proper permissions (we don’t want to run wireshark as root):

$ cat /etc/udev/rules.d/90-wireshark-usbmon.rules

SUBSYSTEM=="usbmon", GROUP="wireshark", MODE="640"

Reflash #1 #

One advantage of having tons of flash, is to keep a ‘base’ firmware image that never gets erased, and fw upgrades are written to other pages / slots. Nice way to reduce risk of bricking during a failed reflash. Presonus website describes the recovery method:

To revert the Studio 1824c/1810c to Factory Default:

    Turn off the 1824c/1810c
    Turn it back on and just after the LEDs initialize, tap the Line button quickly 5 times.

	The Studio 1824c/1810c will then reset. 
    Connecting it to Universal Control will show Firmware v2.50 for the 1824c and v2.51 for the 1810c

This seemed pretty benign; I tried it, and UC (and the USB descriptors) indeed showed the version to be now 2.50. Then I proceeded to reflash to 2.51, while logging USB traffic (earlier screenshot). I was also running x64dbg with (what I thought were) interesting breakpoints, but none of these were hit. I was hoping to locate the code handling the DFU reflash, and thence the source of the firmware blob.

It took me an embarassing while to figure out that Universal Control.exe doesn’t interact with the drivers directly, but rather does so via (AFAIK) ucnet.dll, possibly a UDP connection to localhost, and finally the background service PreSonusHardwareAccessService.exe !! This last one calls the tasty functions in PaeStudioUsbapi_x64.dll and studiousbdevice.dll

At least I should have a ‘full’ image for v2.51, that I extracted from wireshark with File->Export Packet Dissections; the .json format makes it easier to process just the firmware data, e.g.

{
    "_index": "packets-2025-12-12",
    "_score": null,
    "_source": {
......
          "usb.data_fragment": "ed:15:ff:00:d7:9d:5b:7c:5d:23:4c:35:04:00:00:00:0c:a6:10:00:a4:00:00:00:0c:a6:10:00:40:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:43:00:00:00:c3:00:00:00:c6:00:00:00:db:30:00:00:06:f0:00:00"
        }
      }

Again, we recognize a familiar ED 15 FF … prefix from earlier. Some header or magic value ? or an xmos opcode ?

Poking PreSonusHardwareAccessService.exe #

Well, it’s a ‘windows service’, and simply running the .exe under x64dbg doesn’t work (something Access denied …) There’s the correct way to debug a win service, and there’s a few hacks, such as patching the entry point opcode and increasing a timeout to give us time to manually attach the debugger.

In this case, I change the opcode at 0x3f989, from E9 72 .... (some arbitrary opcode) to EB FE (endless loop). Then, once x64dbg is active, restore that opcode to the original bytes, and proceed. This worked, but I found nothing to indicate that fw blobs are processed during service init. Not really surprising; probably only happens on an actual fw update.

Reflash #2 #

This time, installing UC 3.6.4 (which introduces fw v3.11), running wireshark, AND x64dbg attached to PreSonusHardwareAccessService.exe

And the success was complete, I hit the breakpoint to TUSBAUDIO_LoadFirmwareImageFromBuffer, which does exactly what it says; first argument is the buffer, and to my great surprise… it’s right inside studiousbdevice.dll . What the heck.

Earlier I had been searching inside files with ripgrep, which has a --binary flag that supposedly makes it usable for binary data, on binary files. I was wrong. Now, knowing where to look, and looking for the ED 15 FF 00 header/prefix, I immediately found the firwmare blobs in that dll.

I hesitate to call this a tremendous waste of time, but… it could have been over much, much quicker.

FW blob hiding place #

Good grief. Hidden in plain sight. Here it is in studiousbdevice.dll :

                             fwblob_s1824c                                  XREF[3]:        FUN_180021cb0:180021e12(*), 
                                                                                           FUN_180021cb0:180021e19(*), 
                                                                                           1800b4f60(*)  
      1800b4f70 ed               ??            EDh
      1800b4f71 15               ??            15h
      1800b4f72 ff               ??            FFh
      1800b4f73 00               ??            00h
      1800b4f74 d7               ??            D7h

And here is bits of code that associate that blob with some metadata, the string “Studio 1824c”, and a GUID:

void FUN_180021cb0(void) {
    ......
    strncpy(pcVar6,"Studio 1824c",0xc);
    ...
    strncpy(pcVar6,"{395FCE61-8658-0843-BB99-447D2E2D2CC6}",0x26);
    ...
    puVar2[1] = &fwblob_s1824c;
    ....

I found corresponding functions for all other supported devices, each with their blob.

It would be nice to have an automated extraction tool, but the .dll doesn’t really have metadata or symbols pointing to the blobs, and it would probably need scripting with a disassembler i.e. ghidra.