Consider creating a electron desktop app

[uri-may]

Reuse the chrome extension JS and create a desktop app using electron.

As this won't be a browser extension the main issue is whether a more "DSP" discipline of accessing the raw audio bytes using OS functionality instead of accessing the Page DOM. This is a more solid approach INMHO. What do you guys think?

Pros:

1. Access sound from all running process
2. Proof for browser manipulations on DOM
3. Cross browser and cross platform
4. Use current code - only change the signal acquiring flow

I thought of a simple design with a 'system tray icon' indication the SilverDog app is active.
If a beacon is detected SilverDog electron can use electron notifications to inform the user.
Right click on the Tray Icon open a settings dialog which can be an exact replicate of the current settings.

*System tray icon behavior could be created using electron on all platforms:

1. https://github.com/electron/electron/blob/master/docs/api/tray.md
2. http://stackoverflow.com/questions/37828758/electron-js-how-to-minimize-close-window-to-system-tray-and-restore-window-back

[rmenessec]

@uri-may There's no way at all that this can work. Electron is just Chrome with less chrome—meaning any web apps running in it are sandboxed. Depending what's allowed out of the sandbox, it might be possible to change the system mixer volume (although I doubt it—I certainly wouldn't want that kind of access to the entire system from a web app). That's about all, you might conceivably get access to, though.

There's no way to apply a whole-OS audio filter from a Chrome / Blink sandbox, or there certainly shouldn't be any kind of far-reaching permission(s) like this being provided.

On top of that, the two possible target OSes I'm most familiar with (Linux, Windows) have multiple methods of connecting to audio devices, of which some may or definitely do completely bypass any type of filter you might want to apply. I suspect that OSX is in a similar situation.

Sorry.

[uri-may]

@rmenessec I'll divide my response to 2:

1. Electron app are running in User Mode in the OS permission model, allowing them to access any resources other programs can. One can easily write a C or even a C#/Java dll that access lower-level OS API and interop it using for example node-ffi module.
   https://stackoverflow.com/questions/37670273/node-ffi-window-list?rq=1
   Just as an anecodote, Electron apps can also run with escalated permissions scheme:
   https://www.npmjs.com/package/electron-sudo

2. Regarding the "catch-all" filter, you are right and it will be easily bypassed but this is also the case for the current filtering of sound from web page. An informed attacker can take the necessary means to bypass the current checks. I agree that the "catch-all" might not be bulletproof but it might give you additional data that current defend method doesn't. We can try and think on attack vector that will take time for their creators to update and bypass this "catch-all" mixer and see if it makes sense.

Thank you for your comments it was fun recalling this thought.

[rmenessec]

@uri-may Okay, yes. Technically, you can cheat by bypassing Blink sandbox security mechanisms and invoking privileged commands with exec() or similar... but then the question becomes: why am I running an entire entire web browser in the background just to apply an audio filter to an OS audio input or output?

At that point, yes, you do have to rewrite all the code, because you're no longer filtering audio inside a browser; you're trying to apply one or more filters to an entire, highly OS-specific... OS. These are completely unrelated goals, excepting that they both involve modifying audio data. I've looked over the source; none of this code does anything that can be applied to an OS audio stream... except perhaps on ChromeOS. (And I doubt that very much.)

I'm reasonably certain that even writing such a thing in a fully-fledged, more or less cross-platform programming language that doesn't require a browser—Java, for instance—is going to require a large amount of platform-specific code, either by way of a lot of library / API dependencies, or by way of having to simply write the code oneself.

The actual audio filtration algorithms themselves require a tiny amount of code, to which Electron would add nothing except an enormous CPU, RAM, and disk footprint. Electron doesn't provide any special libraries, APIs, or other facilities that don't have counterparts in more appropriate cross-platform languages, like C++11.

By way of comparison, doing something like this instead would catch most audio use cases on most popular Linux distributions, doesn't require a browser, and doesn't even require any code. CPU and RAM overhead should be quite minimal, and disk footprint would be so small it's not worth mentioning.

To put it another way: Electron is a good idea for writing applications that either require various web technologies or at least benefit strongly from a web development approach... and should not be or cannot be run in a full-on, Internet-connected browser for some reason. (Security? Privacy? Agonizingly low network speeds?)

That's Electron's entire use case: web stuff. Intercepting and modifying audio streams generated by other applications is not something that Electron was written to do on its own; using it provides no obvious benefit for anyone wanting to do that; and—I can't emphasize this strongly enough—it's an entire freaking web browser.

Finally, it's a bad idea simply because the sandboxes are there for a reason. They should never be bypassed lightly—or preferably never at all. Each tool or script exec()-ed by Electron becomes a whole new attack surface, rather akin to forwarding ports unnecessarily on a firewall device. On top of that, Electron / Blink itself would become a massive new security liability chained to what was originally a simple task (filter some audio).

Every time someone finds and reports another sandbox bypass or other hole in V8 or some other Blink component, Google has to react to and preferably fix the hole. Then they have to notify as many people as possible. Then one has to hope that the GitHub developers take notice and apply the fix—or potentially adapt the fix or even write a completely different one, depending how far apart the Electron fork is—and somehow notify Electron users. Finally, one has to hope that whomever's written this hypothetical Electron-based, cross-platform audio filter will notice—we hope—and find the time to incorporate / adapt / rewrite the fix and apply it to whatever build of Electron they were using. Then one has to hope that the hypothetical audio-filter app developer ends up notifying all the app's users as quickly as possible, and that everyone eventually replaces the vulnerable releases that are installed.

All of these additional steps increase the window of opportunity to attack the hypothetical app, and make it considerably more likely that some security flaws may never be fixed at all due to miscommunication, oversight, etc.

[uri-may]

@rmenessec Thank you I've learned a lot. About the the cross-platform aspect, you are totally right. Changing the code to be OS specific will miss the project goals - it's a strong case which I haven't fully understood before reading your last reply. Regarding the security aspect I wasn't aware that Electron was sandboxed, I was under the impression that it's merely a wrapper for apps mainly developed for code re-usability, rapid programming, etc.

[rmenessec]

@uri-may You're welcome!

Also, you're not wrong; it's fair to call Electron a wrapper.

But, instead of, say, a small shellcode wrapper to make it easier to launch a Java application or to make it behave a bit more like a native executable, it's an entire platform to 'wrap' web apps—hence, a web browser, or most of one. Depending on how well you understand the relationship between the Blink, WebKit, Chrome, Chromium, and Electron projects, it might be easiest (but oversimplified) to think of Electron as a method of packaging node.js and Chromium-or-so into one deliverable object that you can install on a target system. It was originally 'AtomShell', and written for the Atom editor by GitHub.

I've never developed against Electron myself, so I can't say for certain what Chrome / Chromium features might have been removed, altered, or compromised. However, the Electron app I'm experimenting with right now is definitely using full sandboxing—or has some other excellent reason to be running multiple processes and 66 threads—and it provides full access to the Chrome / Chromium developer tools panel. ����

[uri-may]

@rmenessec Yeah I understand. It basically make a lot of sense to have a the ability the easily port (minimal code-base changes) apps served on a node.js webserver with e.g. React as a client side framework to a standalone desktop app. This kind of code mobility is a real improvement for the global DRY principle. BTW and this is off-topic I see the same thing hapening with containers, docker for example give you in a pretty simple way to re-use your deployment. A standalone server can much more easily become an on-premise solution than before. I hope that my analogy was clear :) Anyway thank you for your answers and for your patient. Cheers.!