Re:Skiptracing: Reversing Spotify.app
by auscompgeek on Sunday June 09, 2019 @02:13AM
(#20137480)
From my understanding, Spotify uses the Chromium Embedded Framework. I'm not sure which parts are rendered with CEF, but since Spotify is using CEF directly rather than Electron, it seems likely they have a fair bit of native code as well.
Last I checked, they use Chromium Embedded for most of the UI, and native code to interact with platform-specific features such as the Touch Bar.
Re:Skiptracing: Reversing Spotify.app
by barbecue_sauce on Sunday June 09, 2019 @04:31AM
(#20137971)
Any idea if Chromium Embedded has the same memory footprint as Electron? (That seems to be the main complaint about Electron that I've seen).
Electron is not anything much different than Chromium Embedded plus some native API hooks, so it's not the Electron parts that eat the resources, it's Chromium (and basically, it's the fact that the app is basically a web app that needs a whole layered and bloated rendering engine -DOM- and a slower runtime - js - compared to native).
Doesn't electron include the nodejs runtime as well?
Yes, which is just v8 + some system interfacing libs, not something that is slow/memory hungry by itself anymore than v8 alone is.
It would be slightly less since it is just Chromium versus Chromium + Node.js (as in Electron).
No idea. I personally have little tolerance for the amount of resources that Chrome uses, so I stay far away from its derivatives, which I have found to not be meaningful improvements.
Regarding the Apple code signing requirement: is it the case then for all hooks of this sort that one is effectively required to be in the Developer program?
So I was curious if LD_PRELOAD is prevented from working, but seems there's a simple work around:
> On macOS there is an additional problem. Newer versions of macOS have a security subsystem called System Integrity Protection. For our purposes the problem is that it prevents injecting code via DYLD_INSERT_LIBRARIES (the macOS equivalent of LD_PRELOAD) into any binary in /bin, /sbin, /usr/bin and /usr/sbin.
> Luckily, there’s an easy workaround. Just create a new directory, copy all the binaries from /bin, /sbin, /usr/bin and /usr/sbin into that directory, and then add it to the start of your $PATH environment variable. Once the binaries are out of those special directories code injection works just fine, and since they’re only 100MB copying them is quite fast.
From https://www.datawire.io/code-injection-on-linux-and-macos/