Hacker News Reader

Comment by g3rv4 | Hacker News Reader

now that they got all that money, I wouldn't be surprised if they killed the web app and moved away from Electron to do native apps that are harder to be messed with.

View on HN

I'd love a better-performing, less memory-intensive and, well, more native Slack app; I'm all for that part. The "harder to mess with" part is a little more concerning.

(I didn't catch the original mention of BetterSlack a few days ago, so ironically, your "Welp, gotta withdraw this!" message here is the first I've heard of it. This seems to be my usual timing with such things, though...)

> to do native apps that are harder to be messed with

As someone who messes with native apps: this really isn't true, at least in my experience. Native apps tend to follow platform paradigms, which usually make them reasonably well designed and structured–sometimes more so than web applications. Usually adding functionality is simply a matter of finding the class that manages the component, rather than digging thorough a bunch of broken CSS (for IE 6 support) and minified goop.

oh, yeah... that's something I want to look into

are you thinking about opensource? I don't think it would be opensource

Nope. There are ways to reverse engineer closed source apps and inject code into them.

Also, depending on the platform, if a native application is following the platform guidelines, then quite a lot of things you want to change might be located in data files or "resource" section of the executable.

I haven't been messing much with Windows executables for quite a while, but back in the day, I'd "improve" many programs by just editing their resources.

You do it the same way exploit writers do. Attach a debugger to the process, find the memory address of the resource you want to modify, overwrite the address with the address of the modified resource you want to execute. You could also just use the debugger to force the program to execute functions with arguments you specify, that way you don't have to worry about mucking with the memory.

Usually you'd create a dynamic library that interposes a function, so you don't have to much around with using a debugger. This way you have a persistent modification that's much more resilient to changes caused by app updates. Exploit writers generally have different goals: their thing only really needs to work once, and only with the current configuration, since usually the bug they're relying on gets patched in the next version.

Anything that moves away from Electron is a plus in my book

Reply on news.ycombinator.com