v17

[noiseresearch]

▒▒░░▒▒░░▒▒▒▒░░▒▒▒▒▒▒▒▒
▒▒░░▒▒▓▓▒▒░░▓▓▒▒░░▒▒▒▒▒▒░░░░▓▓░░▒▒░░░░░░▓▓▒▒░░▒▒▒▒░░▒▒▒▒▓▓▒▒▒▒░░░░▒▒▒▒░░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░▒▒▒▒

[Frankie.T]

@Melda

No thoughts our request to have the older installation method back along the new one for folks who like/need it simple?

[Tyrs]

Thank you Martin, Melda rocks!

[Nspace]

LoL, ya. This installer does connect to multiple ip addresses:

TCP 204.79.197.203:443
TCP 74.125.69.94:443
UDP 192.168.0.58:137
TCP 23.216.81.152:80 (www.microsoft.com)
TCP 20.99.133.109:443
TCP 151.101.22.172:80
TCP 20.99.186.246:443
TCP 23.198.171.50:443
TCP 52.185.73.156:443
TCP 20.99.185.48:443
TCP 52.29.75.84:80 (www.meldaproduction.com)

Martin or Vojtech, as a long time customer a few years to now owning Melda Complete Bundle (which despite the many discounts it implies, it required many times of savings), explain this IP addresses contact and whatever means, do provide an offline alternative of authentication with a serial or a file, as it has been until now.
I was very keen to ask please, but after reading this thread posts I am otherwise, to briefly describe my feelings about this.

[Hexspa]

I'll just voice support for users with privacy concerns. Software as a whole has become more invasive as time goes on. Many users see Melda as having a Unique Sales Proposition of being an outsider in this regard. In every forum I've visited, users are complaining about this new installer. Hopefully Melda takes their grievances into consideration. Thanks.

[rtoip]

---

[martin-meldaproduction]

LoL, ya. This installer does connect to multiple ip addresses:

TCP 204.79.197.203:443
TCP 74.125.69.94:443
UDP 192.168.0.58:137
TCP 23.216.81.152:80 (www.microsoft.com)
TCP 20.99.133.109:443
TCP 151.101.22.172:80
TCP 20.99.186.246:443
TCP 23.198.171.50:443
TCP 52.185.73.156:443
TCP 20.99.185.48:443
TCP 52.29.75.84:80 (www.meldaproduction.com)

Martin or Vojtech, as a long time customer a few years to now owning Melda Complete Bundle (which despite the many discounts it implies, it required many times of savings), explain this IP addresses contact and whatever means, do provide an offline alternative of authentication with a serial or a file, as it has been until now.
I was very keen to ask please, but after reading this thread posts I am otherwise, to briefly describe my feelings about this.

+1

I have adapted Melda products to most of my audio-related tasks. However, recent events, e.g. the new installer, unclear connections to servers (e.g. Microsoft) are very puzzling. For a moment I even considered selling all the Melda plugins that I have to possibly escape the potentially approaching nonsense in time.

The questions are simple:
- do you, Melda, plan to introduce ONLY subscriptions for plugins and what is happening is a preparation for that ?
- why does the installer connect to the indicated IP addresses ?
- will the promised offline installer appear, with which I will be able to install plugins on a clean computer and activate them without access to the Internet ?

Answers to your questions:

- As far as I know, there is no such plan for the subscriptions. This is a misconception.

- MPluginManager is not connecting to those IPs. How did you obtain them, or how did you capture the packets? Please explain in more detail. I tested this with both Wireshark and Network Monitor, and MPluginManager.exe is only connecting to the Melda server and Melda CDN server. I performed the test twice, including downloading plugins and activating them, and there was no communication with those IPs at all. Also, why would we do that? We have no intention of spying on our customers.

- Offline installation and offline plugin activation are already possible. Please refer to my notes and the video tutorial in this thread.

[noiseresearch]

▒▒░░▒▒░░▒▒▒▒░░▒▒▒▒▒▒▒▒
▒▒░░▒▒▓▓▒▒░░▓▓▒▒░░▒▒▒▒▒▒░░░░▓▓░░▒▒░░░░░░▓▓▒▒░░▒▒▒▒░░▒▒▒▒▓▓▒▒▒▒░░░░▒▒▒▒░░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░▒▒▒▒

[gtimmons]

How was the IP Addresses obtained you ask?


Full Explanation:

When you upload an executable (EXE) file to VirusTotal, it runs that file in a controlled environment known as a "virtual sandbox." This sandbox is a simulated operating system that allows VirusTotal to observe the behavior of the software without risking the security of actual systems.

During this process, VirusTotal monitors everything the software does, such as which files it creates or modifies, what registry changes it makes, and importantly, which IP addresses it tries to connect to. All this information is collected and displayed in the "Behavior" section of VirusTotal's report.

Multiple virtual sandboxes, each with different configurations or settings, are used to analyze the file from various angles. This comprehensive analysis helps identify any malicious activity or connections the software might attempt to make, ensuring a thorough examination of its behavior.

In summary, VirusTotal uses these virtual environments to scrutinize the executable’s actions, including the IP addresses it interacts with, to assess whether it is safe or potentially harmful.

You can see these behaviors here:

https://www.virustotal.com/gui/file/d7c ... 7/behavior

[gtimmons]

If your plugin manager isn't connecting, it's likely the installer making those connections. Either scenario is problematic.

My recommendation: instead of relying on the pre-compiled executable, compile it yourself. This way, you can eliminate the unnecessary connections that Inno Setup might be making.

And honestly, who really trusts a pre-compiled version these days?

Just because it's open source doesn't automatically make the compiled version—or even the source code—trustworthy. You need to meticulously review all the source code to ensure it meets our standards.

If you're not comfortable with Pascal programming, consider using something else—like InstallShield.

[Frankie.T]

- Offline installation and offline plugin activation are already possible. Please refer to my notes and the video tutorial in this thread.

Sure, and i thank you guys for make it possible, really!

But the process is long and convoluted, as i wrote in my first reply to this topic, is a no-sense and it requires 1 pc more that runs Win or Mac, while before just a smartphone was enough to download.

I don't know how hard would be for you to ALSO make an alternative installer like the older one, i don't think should be hard, i mean that's what you always have done since the beginning.

I understand there are different needs, requests and IL needed this for his FL Cloud, and i'm happy if you got another way to get discovered, but..

But you also need to keep in mind older customers are stil alive, and lots of people have chosen Melda for being user friendly drm, and "stupid systems free"

I don't know if this is a chose you have done, or if IL decided what you had to do.

I hope you have the freedom to take that kind of choices, and so to listen to your customers.

We are NOT against your new installer (apart from the connection stuff you are discussing), we just like to have back one of the reasons we chose you.

Because if we cannot trust software developers to mantain their way to operate, it comes the point where piracy get the only solution you can trust, and this is bad from every point of view.

[audiojunkie]

As it stands, @Martin-MeldaProduction, Does version 17 meet the following criteria? I would like to know directly, please.

1. The copy protection must use either a serial number, a keyfile or a per user Watermark.

2. The copy protection must not tie itself to anything. For example, there are now developers claiming they only use serial number copy protection, but then the copy protection ties itself to a particular CPU or other hardware. Another example is having just a serial number, but the software has to download required files from the vendor site in order to run. This is just as bad as challenge/response authentication. The software should not restrict you to using only the one computer. If you buy a new computer, you should be able to use it without dealing with the company further.

3. The software should not require any form of calling home to authenticate or to obtain the plugin. In other words, if a company were to go out of business, you should be able to pull a copy of the software and serial number or keyfile off of your backup drive, and authenticate the software. Be wary of companies using a single installer for their entire lineup of products.

[martin-meldaproduction]

If your plugin manager isn't connecting, it's likely the installer making those connections. Either scenario is problematic.

My recommendation: instead of relying on the pre-compiled executable, compile it yourself. This way, you can eliminate the unnecessary connections that Inno Setup might be making.

And honestly, who really trusts a pre-compiled version these days?

Just because it's open source doesn't automatically make the compiled version—or even the source code—trustworthy. You need to meticulously review all the source code to ensure it meets our standards.

If you're not comfortable with Pascal programming, consider using something else—like InstallShield.

I took the time to test the MPluginManager installer (Inno setup) and monitored all the packets using Wireshark. I installed MPluginManager a total of 4 times on two different PCs, and not once did any of the IP addresses from the list appear in the logs. The only IP address that showed up was 52.29.75.84 (meldaproduction.com).

Therefore, I insist that these accusations are false and unfounded. Neither MPluginManager nor its setup accesses any of the IPs on that list. Additionally, I want to emphasize that I personally handled all the communication in MPluginManager, and I can honestly say that MPluginManager does not send any user data or similar information anywhere. In my opinion, the same applies to the Inno setup, which I just tested several times. Unless something changes, this topic is resolved for me.

[martin-meldaproduction]

LoL, ya. This installer does connect to multiple ip addresses:

TCP 204.79.197.203:443
TCP 74.125.69.94:443
UDP 192.168.0.58:137
TCP 23.216.81.152:80 (www.microsoft.com)
TCP 20.99.133.109:443
TCP 151.101.22.172:80
TCP 20.99.186.246:443
TCP 23.198.171.50:443
TCP 52.185.73.156:443
TCP 20.99.185.48:443
TCP 52.29.75.84:80 (www.meldaproduction.com)

Martin or Vojtech, as a long time customer a few years to now owning Melda Complete Bundle (which despite the many discounts it implies, it required many times of savings), explain this IP addresses contact and whatever means, do provide an offline alternative of authentication with a serial or a file, as it has been until now.
I was very keen to ask please, but after reading this thread posts I am otherwise, to briefly describe my feelings about this.

+1

I have adapted Melda products to most of my audio-related tasks. However, recent events, e.g. the new installer, unclear connections to servers (e.g. Microsoft) are very puzzling. For a moment I even considered selling all the Melda plugins that I have to possibly escape the potentially approaching nonsense in time.

The questions are simple:
- do you, Melda, plan to introduce ONLY subscriptions for plugins and what is happening is a preparation for that ?
- why does the installer connect to the indicated IP addresses ?
- will the promised offline installer appear, with which I will be able to install plugins on a clean computer and activate them without access to the Internet ?

Answers to your questions:

- As far as I know, there is no such plan for the subscriptions. This is a misconception.

- MPluginManager is not connecting to those IPs. How did you obtain them, or how did you capture the packets? Please explain in more detail. I tested this with both Wireshark and Network Monitor, and MPluginManager.exe is only connecting to the Melda server and Melda CDN server. I performed the test twice, including downloading plugins and activating them, and there was no communication with those IPs at all. Also, why would we do that? We have no intention of spying on our customers.

- Offline installation and offline plugin activation are already possible. Please refer to my notes and the video tutorial in this thread.

Asking a third time an hoping for an answer: is there any improvement with this release regarding file management? Are there still a zillion of files I do not need at all - for the plugins I own - and spread all over the place? Or is the file management finally improved with v17?

Regarding the offline installation: do I understand the process right that in any case one need to use the download manager by Melda?

Melda plugins ultimately have only two main folders on each operating system: Program Data and User Data.

In the version 16 installer, there were over 10,000 files in these two folders after installation. You can see more details in this post: viewtopic.php?t=613306.

In version 17, there are about 4,000 fewer files. Yes, it’s still a lot, but MeldaProduction plugins are very extensive and complex, and splitting them into multiple files has many advantages. We will continue to reduce the number of files. However, as I mentioned, users shouldn’t be too concerned since they only see the final two folders.

For offline installation, you currently need to download MPluginManager to two machines, but this process may be simplified to just one download. See my reply to Frankie in this thread for more details.

[gtimmons]

Explanation on Wireshark vs. VirusTotal (Microsoft Sysinternals and CAPE Sandbox):

When you set up Wireshark to monitor the network activity of an installer like inno setup from start to finish, you’re capturing all the network traffic that occurs on your system during that specific time frame. However, there are several reasons why Wireshark might not capture the same connections that VirusTotal's analysis tools (Microsoft Sysinternals and CAPE Sandbox) detected:

1. Controlled Environment in VirusTotal's Analysis:
- Sandboxed Execution: VirusTotal runs the installer in a controlled, virtual environment called a sandbox (specifically CAPE Sandbox). This sandbox is designed to detect various behaviors of the installer, including network connections, file manipulations, and other system interactions. The environment might simulate specific conditions that could trigger network connections that wouldn’t necessarily occur in a regular user environment or during a single monitored session with Wireshark.

- Forcing Execution Paths: The analysis tools might also explore different execution paths of the installer, trying to trigger all possible behaviors, including any hidden or delayed network connections. This could cause the installer to reach out to certain IP addresses that it might not reach during a normal installation process monitored by Wireshark.

2. Timing and Delayed Connections:
- Post-Installation Activity: The installer might not make all its network connections immediately. Some connections might be delayed until after the main installation process is complete, such as when the installed software runs for the first time or during a post-installation configuration phase. If Wireshark was stopped immediately after the installer finished its primary job, these delayed connections wouldn’t be captured.

- Background Processes: The installer might launch background processes or services that connect to external IPs after the main installation has completed. These connections might occur outside of the Wireshark monitoring session.

3. Encrypted or Obfuscated Connections:
- Obfuscation Techniques: Some installers or executables might use obfuscation techniques to hide their network activity. They could use encryption, tunneling, or other methods that make it harder for tools like Wireshark to detect or properly log the connections.

- API-Level Monitoring: VirusTotal, via Microsoft Sysinternals, monitors not just network packets but also system calls and API interactions. This allows it to detect network-related activity at a higher level of abstraction, even if the actual network traffic is obscured or not directly visible at the packet level.

4. System-Specific Behavior:
- Different System Configurations: The environment in which the installer is run can influence its behavior. The network conditions, security settings, and even the presence of certain software can all affect whether specific network connections are made. The controlled environment in VirusTotal’s sandbox might trigger connections that don’t occur in your specific system setup.

Summary:
While Wireshark is excellent for capturing real-time network traffic during a monitored session, VirusTotal's analysis tools, including Microsoft Sysinternals and CAPE Sandbox, can detect connections that might be missed in real-time monitoring. This is due to their ability to simulate different conditions, force execution paths, monitor API-level interactions, and capture delayed or hidden network activity that might occur outside the time frame of a Wireshark session.

If you’re concerned about missing any network activity, you might consider running the installer in a controlled, monitored environment multiple times, or using tools that provide deeper behavioral analysis similar to what VirusTotal offers.