Is "de.mynodejs.net" a trojaner? - node.js

I am a full-stack developer but since I installed my new antivirus program
(malwarebytes) I receive always the following nodification (see image below).
I work a lot with node.js (REACT, REACT-Native) therefore I am unsure if that is a virus.

I guess it is.
They provide a JS function convince Windows Defender
not to report back on files.

Related

Connect to windows server from node js

I'm not very experienced in programming and have a problem that I'm finding hard do solve.
I have a web app that is on a ubuntu server, that is running on node js. That web app creates an excel file on the back-end that is to be read by another excel file and execute a vba that gives as results in a software that only runs on windows.
I tried the software on a windows server and it seems to run, so no problems there.
My question is: how do I make my web app excel file be stored in the windows server and how do I call the files on that server to run from node js?
Can anyone please share some resources on where I can explore this subject please?
Thanks in advance,
Ana
The following is what I advised the OP to do in the comments, only longer and with more explanation.
First, install NodeJS on your Windows server. You can do it by either installing it from the official Downloads page from NodeJS, or use a version manager such as nvm, with a Microsoft tutorial on how to do it that way. This step is up to you.
Host your back-end part (the one that creates the excel part) on the Windows server. That way, the file will be stored in the same filesystem the "software that runs only on Windows" is on.
The problem now is determining if there is any way to run the "software" via command line. Since I don't know the software name, I can't look that up but if it can, you'll have to check child processes via NodeJS.
Now, if this software has no way to be run via command line, and if they didn't publish any sort of programming interface (what is called API in the real definition of the term), chances are that you will not be able to achieve what you want to.
If you want me to clarify or explain more on some points, please let me know in the comments so I can edit my answer.

ElectronJS code protection 2018

I am about to begin the process of creating a Windows-based utility app to manage localized expressjs server that will utilize a graphical Windows based application to manage some of the features of this service
however before I begin I would like to speak with the community to try to get some advice Advice on how to properly protect the code since it will all be node JS bees I need to make sure it’s protected and some of my initial reading online seems to show that using electron by not be the most Safeway saw that being said how are you guys handling this to keep node JS these code protected with electron and in my case On windows environment
Any advice would be greatly appreciated much thanks
tl;dr You can and it is not worth the effort. Just pack your source into an asar file, it keeps most people away from it.
Long answer:
Use the asar option when building your app.
Obfuscate the code with an uglifier.
Use WASM
Language bindings to grab your data from a compiled format
neonjs for Rust
edge-js for C#
N-API, NAN for C/C++
Otherwise, your files are scripts, all these steps only slow down an attacker (tactic of many defenses), but they will not prevent them from accessing them. The devTools are fairly easy to get opened and people will be able to read the code in some way, shape or form. And if someone gets your obfuscated code, it is simple to reconstruct what is happening (see here for reference: https://www.youtube.com/watch?v=y6Uzinz3DRU)
If you want to protect yourself from code manipulation, there are better ways to do it, like Hashing, Context Isolation etc. Electron has a whole chapter on the matter.
https://github.com/electron/electron/blob/master/docs/tutorial/security.md
Small Update (2020):
I've seen this library a few weeks ago and thought it would show a nice way to further obfuscate the code from being read by external parties
https://github.com/OsamaAbbas/bytenode
The basic idea is to compile the JS into bytecode for V8. This works very well for Electron and is definitely a hurdle not everyone will get over. But, this will not protect your code from being turned back into readable JS. It's just another layer of protection to make it more difficult.

Package node.js app as cross-platform executable, not for desktop app

There are a lot of questions on this topic, but they don't seem to distinguish between executables for desktop or server-side apps. I suppose my first question would be: what's the difference? For example, Zeit/pkg says they are a "node.js binary compiler", whereas nwjs (formerly node-webkit) says they are a "an app runtime based on Chromium and node.js".
I tried zeit/pkg and it works great, but have read that there can be performance issues unless it's configured properly. I wanted to make sure I was choosing the right tool and came across nwjs. It seems to do a lot of the same stuff pkg does, but has a larger following, as well as more docs and a robust api. Can I use nwjs as a server-side executable (i.e. not using the desktop feature) the same way I would use pkg?
This answer states that nwjs "is an option, but it really isn't set-up to do a server - client type relationship", but then a comment says "you can launch a server from node-webkit just in the way you launch it in Node.js. It's just that node-webkit provide another way beyond B/S architecture".
So, is nwjs effectively the same as pkg, or fundamentally different?
I realize that there's also Electron, which states "build cross platform desktop apps" and appears similar to nwjs. I'm not trying to get into a Electron vs nwjs debate, but rather desktop vs. server, if there's a difference.
you got most things already, only few clarifications are needed. Reason nw.js / Electron declares itself as for desktop application is, it's core architectural design is intended to integrate node.js with chromium to have UI enables create application does have UI. You can still use part of those framework (node.js side) without initiating visible ui, in that case behaviorwise it'll be similar to plain node.js does. Still there is caveat, like as it tightly integrated with chromium in core already for some cases you should have screen to chromium correctly initiates (or creating virtual buffer as lot of CI does, or etcs).
Also, when your concern is performance, I'd doubt using UI framework for server side work achieves what you desire - while there won't be huge, integration between node to chromium have overhead compare to bare node.js obvioulsy.
Getting back to original question, I feel question itself is somewhat vague. If the intention is truly server side application probably you won't need to package it but correctly deploy node and its dependency modules or packaging it sort of installable manner instead of creating single binary as pkg does.

How to automatically update a deployed Node JS Electron program

I think the title should be quite self-explanatory. I am developing a Node JS app using Atom Electron. What I would need is a way to deploy my application in a cross-platform way (Mac OS X, Windows and Linux), while making it capable of automatically updating itself, without having to ask for administration privileges.
Here is what I would like to happen:
The application gets installed by my users, possibly via an easy-to-use installer.
I keep developing my app, adding new features, and so on.
At some point, I release a new version of my code, I pack it somehow and upload it somewhere.
All the clients that are currently online, or whenever a client gets back online, they download the new version, install it, and restart automatically, without having to ask for administration privileges.
As far as I know, there are apps that are capable of doing such a thing. For example, Google Chrome automatically installs updates without having to continuously ask for administrative privileges or, even worse, making its users download new installers all the time.
Is there an elegant and cross platform way to do such a thing? What would be the best solution for my problem?
If this is matters in any way, let me add that my project is completely open source, so I don't care about protecting my code in any way from being read.

Web Sockets server side implementation for NodeJS

Part of this problem might be that there's too much discussion on the client side for me to see wood for the trees.
Anyway, here's what I want to do. I need a platform independent server-side implementation of WebSockets. I'd like it to run in NodeJS.
Now, 99% of what I've found on this topic talks about socket.io. But so far as I can tell, that is not WebSockets, it's a special "extra" protocol in its own right. I need something that works "by the (not-yet) standard". There's a good reason for that, and it's non-negotiable, trust me on that.
So, I tried WebSocket, but that requires (or appears to require both python and, worse, Visual Studio) to run on Windows. I need something that is platform independent and doesn't need special things like this.
I also tried node-websocket-server, but I can't get that to work at all. The example on the main page fails for me. It seems to accept a connection, but the client doesn't see it, neither side gets to send anything, and the client immediately sees the connection as closed. Indeed, all I ever get is a "connection" callback, and then it seems to die. Running in debug mode didn't tell me anything useful, except for some internal error about some object or other not having a flush() method. I half-suspect this is a defunct project?
So, I'm out of ideas. Is it possible to persuade socket.io to work purely by the (non)spec for WebSockets? Is there a way to get node-websocket-server to behave that I've failed to find. Is there a way round the Visual Studio dependency in websocket, or is there some other NodeJS based tool that meets all my requirements?
Oh, one other thing, I'd like the tool to coexist peacefully with "connect" as I'm using that for my regular document serving.
I had the exact same problem that you're facing at the moment when I tried to use Socket.IO on a different platform without a direct port of the client (and without the motivation to port it myself).
I ended up moving my code to use ws which is a standards based websocket implementation for node without the added sugar from socket.io.
It works extremely well in my case over several different platforms but you would need to rework most of the connection/reconnection code etc.
Website : link
GitHub : link
NPM : npm install ws
Socket.io uses WS under the covers so you may hit the same installation issue on Windows. You may find that it complains that you need to install Visual Studio 2010 for the ws component to work.
However, you can configure the version of Visual Studio used by node-gyp that runs the C++ compiler via an environment variable.
Examples:
set GYP_MSVS_VERSION=2012 for Visual Studio 2012
set GYP_MSVS_VERSION=2013e (the 'e' stands for 'express edition')
For the full list see
- https://github.com/joyent/node/blob/v0.10.29/tools/gyp/pylib/gyp/MSVSVersion.py#L209-294
This is a painful for Windows users of NodeJS as it assumes you have a copy of Visual Studio installed which many non-dev end users will never have. So I'm lobbying Joyent to the encourage them to include web sockets as part of CORE node and also to ship a GNU gcc compiler as part of NodeJS install so we can permanently fix this problem and not have to force Windows node users to tweak their environment or download anything else.
Feel free to add your vote at:
https://github.com/joyent/node/issues/8005#issuecomment-50545326
NOTE: The Joyent team have indicated that socket.io will fall back to using a slower implementation when compiling ws fails. In other words your code will still run - just not as fast. This is not clear for end users performing an install of any app that depends on socket.io or ws as it display red error text during the install process leading users to assume that the install failed, when in fact it will work albeit slowly.

Resources