insufficient evidence

[Wild UIM]

Rs client also holds the login fields in plaintext - you gonna report jagex too?

A response on a level relative to what I'd expect out of you.

 

A response on a level relative to what I'd expect out of you.

Omnitored requesting a pardon for getting hacked

don’t forget to pay your debts bro

 

[Wild UIM]

Omnitored requesting a pardon for getting hacked

don’t forget to pay your debts bro

Gladly, I am still trying to get the administrators to accept the repayment.

 

[GuestGuest]

Guest8888 included a code snippet of a decompiled plugin using the Bytecode Viewer program. I am unaffiliated with any party, hopefully this can serve as an objective response.

With that said, let's analyze:

Option 1 (the "old" way):
- Sending someone via PM / in a ticket etc someone's username + password = bad

Option 2 (the "new" way):
- Using an https request as is secure, BUT:

The following matters at hand become:
- Is there a data layer for storing the username/password? As in, the accounts information that has to be dispersed to another user, is that stored in an intermediary data layer, or in some kind of in-memory cache on the proxy server? The latter would be ideal and would be very hard for data to ever be compromised as it would be short lived and only kept in memory (e.g as opposed to storing in an actual database and potentially having that database compromised one day). If it is stored in an actual database though, this could be concerning if it's stored there forever.

- Assuming data is stored but is stored securely and not forever - then great. That leaves one last obvious thing that's been pointed out already, which is intercepting HTTPS traffic. This is fairly simple to do with a java program, simply set the following JVM args: -DproxyHost, -DproxyPort, -Djavax.net.ssl.trustStore.

You can use a program like Fiddler or MITMProxy which provide root CAs to intercept all web traffic (https included), add their CA to a truststore using java's keytool, then set the JVM args mentioned above and capture the username/password this way.

So basically:
Is using https better than just sending someone user/pass in a ticket? Yes

Could a malicious worker still sniff https traffic being sent to their device and obtain a customer's username and password? If that worker wanted to, yes, absolutely.

It's important the bold fact is acknowledged and understood, because if some weird hack occurs and there is no obvious explanation for how it might have happened, this can very well be one of the ways someone chooses to do it.

This is also assuming that the worker's device is required to an https request through the plugin to grab the details of a given worker. If you think the actual act of grabbing info being passed through an https request is difficult to do or not possible to do, I can volunteer pentesting the plugin myself if you'd like to set something up in that regard (unaffiliated third party). Could screen share the process with a mod, too.


Also - xKylee's point about Jagex storing username/password in plaintext is true, but credentials are stored in memory of the client. This information is never sent to anywhere else, and once you close your client everything that was stored in memory is lost. It's a moot point to even bring up such foolish things. The danger in credential leaking is rooted in data transport of someone's information, ultimately (and the method by which it is transported).

 

You’re forgetting you can memory dump the client and grab the credentials from the login fields

that said, at that point you would be logging in anyway so would have access to the full account

 

[Wild UIM]

Guest8888 included a code snippet of a decompiled plugin using the Bytecode Viewer program. I am unaffiliated with any party, hopefully this can serve as an objective response.

With that said, let's analyze:

Option 1 (the "old" way):
- Sending someone via PM / in a ticket etc someone's username + password = bad

Option 2 (the "new" way):
- Using an https request as is secure, BUT:

The following matters at hand become:
- Is there a data layer for storing the username/password? As in, the accounts information that has to be dispersed to another user, is that stored in an intermediary data layer, or in some kind of in-memory cache on the proxy server? The latter would be ideal and would be very hard for data to ever be compromised as it would be short lived and only kept in memory (e.g as opposed to storing in an actual database and potentially having that database compromised one day). If it is stored in an actual database though, this could be concerning if it's stored there forever.

- Assuming data is stored but is stored securely and not forever - then great. That leaves one last obvious thing that's been pointed out already, which is intercepting HTTPS traffic. This is fairly simple to do with a java program, simply set the following JVM args: -DproxyHost, -DproxyPort, -Djavax.net.ssl.trustStore.

You can use a program like Fiddler or MITMProxy which provide root CAs to intercept all web traffic (https included), add their CA to a truststore using java's keytool, then set the JVM args mentioned above and capture the username/password this way.

So basically:
Is using https better than just sending someone user/pass in a ticket? Yes

Could a malicious worker still sniff https traffic being sent to their device and obtain a customer's username and password? If that worker wanted to, yes, absolutely.

It's important the bold fact is acknowledged and understood, because if some weird hack occurs and there is no obvious explanation for how it might have happened, this can very well be one of the ways someone chooses to do it.

This is also assuming that the worker's device is required to an https request through the plugin to grab the details of a given worker. If you think the actual act of grabbing info being passed through an https request is difficult to do or not possible to do, I can volunteer pentesting the plugin myself if you'd like to set something up in that regard (unaffiliated third party). Could screen share the process with a mod, too.


Also - xKylee's point about Jagex storing username/password in plaintext is true, but credentials are stored in memory of the client. This information is never sent to anywhere else, and once you close your client everything that was stored in memory is lost. It's a moot point to even bring up such foolish things. The danger in credential leaking is rooted in data transport of someone's information, ultimately (and the method by which it is transported).

Great in depth explanation, and by far the best unbiased post so far. Regarding the client itself, I was in the middle of writing it but it seems like xKylee beat me to it: A raw RAM data dump is a matter of seconds / minutes with the right tools, which will provide any data regardless of them being sent through http, https, sockets or a pigeon.

For HTTP/HTTPS packet grabbing, I would recommend Charles, I think its the most lightweight and beginner user-friendly one with SSL proxying - not to be used for any malicious black hat activity of course.

 

[GuestGuest]

I've marked this thread as final because I hope for this to be my final response.

Quite frankly, I do not care what the results of the report are, but it is important that an informed decision is made because this can have implications for the future.

xKylee's statement that a worker could grab values of fields from the client (aka the password field) is also a valid point (ergo, you don't need to go out of your way to sniff https traffic).

The overarching point is this: once information is sent to someone else's OSRS client via this plugin, there is more than one way for them to obtain someone else's data - whether that is through sniffing https traffic, or simply using a library like ASM to insert code into the method responsible for retrieving the http response and printing the result to stdout - or simply taking the plugin, decompiling it, adding some print statements to it, and recompiling it.

Tools like Recaf make this especially simple given they provide tooling for source level insertion with minimal knowledge.

So going back to the original point of the report itself - is it true that customers aren't sharing their data? Assuming there are no bad actors at play trying to pull any fast ones, then sure, at the surface level it is way better than having to just toss someone your information over discord messages.

However - if someone set out to do something bad (as in steal this person's login information), they could pull it off if they are the worker, and this is where the concern is rooted.

As for how the mods want to handle this, doesn't really matter to me either way. Just make sure you're making an informed decision.

 

[bamaboy]

So yeah i’m posting because i feel like it and don’t really care for what happens regarding my input. just thought i’d add what’s really going on here because it’s quite hilarious and don’t care what happens with my reply. so first off this goes for WildUIM and you posting under a guest account. first off quit being a pussy and make it known who you are. 2nd you realize you two bozo’s making these reports or claims that are way over your heads nothing is going to happen right. just being totally honest. you two bozo’s are clearly jealous and broke not making any money which is understandable. but quit making reports trying to get something to happen which in reality it’s not. it’s okay to be jealous and not make any money. btw they have the biggest PVM discord with workers which is 150+ all have deposits to match a customers bank size or in worth to the account they are working on. they cannot see the customers info once an order is done. quit being pussies and jealous trying to throw eggshells at nothing. my two cents now you guys can fuck off have a nice day

 

[Wild UIM]

So yeah i’m posting because i feel like it and don’t really care for what happens regarding my input. just thought i’d add what’s really going on here because it’s quite hilarious and don’t care what happens with my reply. so first off this goes for WildUIM and you posting under a guest account. first off quit being a pussy and make it known who you are. 2nd you realize you two bozo’s making these reports or claims that are way over your heads nothing is going to happen right. just being totally honest. you two bozo’s are clearly jealous and broke not making any money which is understandable. but quit making reports trying to get something to happen which in reality it’s not. it’s okay to be jealous and not make any money. btw they have the biggest PVM discord with workers which is 150+ all have deposits to match a customers bank size or in worth to the account they are working on. they cannot see the customers info once an order is done. quit being pussies and jealous trying to throw eggshells at nothing. my two cents now you guys can fuck off have a nice day

I appreciate that you uphold the quality of posts that is common for the rest of the defenders of MyPVM and the associates, wouldn't want to break the pattern I assume.

I am not posting under a guest account, Everyone is fully aware of what my main account is, and the only reason I am not able to use it is due to it having a ban, which every single attendant of this conversation other than you seems to be aware of, even the people who aren't aware of how their own "safest provable" plugin works. To further support this, I was told by one of the administrators to uphold the report and all further replies on this very account.

Great guest account you've got there though.

 

[kThisIsCvpv]

It seems like we’re going to go over the same points repeatedly. I appreciate the conversation but I’m here to find a resolution. I’ll try to be as transparent as possible in this post.

It seems like the purpose of this report is to bring to light that an attacker located on the booster’s computer can retrieve the client’s details, putting the client’s data and accounts at risk while also giving them an invalid sense of safety.

On the topic of false advertisement:

The plugin gave clients the ability to not have to share information directly with the booster.

The plugin gave clients the ability to get details about their order much more seamlessly.

I am not active on Sythe - or any markets for that matter, but to my knowledge, currently at this time, this is a feature that only MyPVM provides. Furthermore, the presence of the plugin is only just a feature on top of already existing safety measures such as the use of VPNs and the background auditing of incoming workers.

It’s funny you see the plugin causing problems for clients whereas I see the opposite happening. The purpose of the plugin is to make clients feel as secure as possible but there are downsides to giving them so much power. For example:

V2Jay - filthy scammer

A client was able to catch a booster slacking and punished him for it. Was this intended to happen? Nope. Did this incident collectively teach our boosters a valuable lesson? Most definitely.

On the topic of security:

Let’s imagine a scenario where I designed an ATM for a bank called MyPVM. The purpose of this ATM is for MyPVM’s clients to be able to withdrawal cash from the machine. Through normal methods, we expect clients to enter their credit cards and authenticate themselves before withdrawing the cash. However, as in the real world, there are bad actors in play. For instance, someone could install a card skimmer and steal a client’s details. Or, if someone reverse engineers the ATM’s executable, they could find vulnerabilities and exploit them to cause the ATM to dispense money unwillingly.

In the case of MyPVM’s plugin, I’ve taken many measures to try to slow attackers down. I recognize that there are many ways to attack the system; however, as the developer of this plugin, I try my best to prevent these attacks from happening or slowing the attackers down as much as possible. On top of that, there are regular security audits where network traffic is reviewed. Could you get into my system as a worker? Absolutely – I can think of a handful of individuals that would be able to. But I try my best to make it not worth your time.

The problem with me responding to this post is that, as the person who designed the system, I know about the measures I’ve put into place. You’re asking me for the blueprint of the system so you can audit it for vulnerabilities. Don’t you think you’re sounding a bit ridiculous?

Furthermore, it seems that no-one seems to have mentioned the skillset required to even perform any sort of attack like this. Is this the type of skillset found in your average booster? Most individuals wouldn't even know where to start.

This brings us to our countermeasure. Suppose that the system is somehow compromised by the booster and they end up stealing the account.

There are a few cases here:

The attacker steals the account but finishes the order.

• The client changes the details of the account. The credentials that the attacker originally stole are no longer valid. Nothing interesting happens.

The attacker steals the account and cleans it.

• The client changes details of the account. The client is compensated with the booster’s deposit. The client can resume where they picked off at with another booster. Nothing interesting happens.
• A scam report is opened on the attacker. Our service will be able to provide additional evidence of all actions and timestamps taken to help the staff expediate the reporting process.

The attacker pulls an opposie and triggers alerts in our internal system.

• The attacker is locked out of the system while I investigate what happened. A scam report is opened and we keep their deposit.
• We notify the client of the potential breach and request for them to change their passwords. Then the order goes on. Nothing interesting happens.

What do you think of these security measures? Don't you think it's pretty safe and fault tolerant?

TL;DR

The plugin is a security measure on top of several other existing security measures. One of its features allows clients to share their credentials with the plugin without directly sending it to the booster. This feature aims to prevent completely (for your average booster), if not slow down attackers from retrieving the client’s credentials.

The plugin does not just log-in. It enables us to provide our client with additional resources that they normally would not have anywhere else.

The presence of the plugin gives MyPVM a competitive edge against others. With the security measures and countermeasures in place, they are extremely client focused and are consistently proving themselves to be the safest service provider on the market.

If an attacker compromises the plugin, they gain credentials to an account that they already have access to. Nothing interesting happens. Could someone try to compromise the plugin? Yes. But what do you gain from doing it? Do the pros outweigh the cons?

Comments based on “attacks that could work” mentioned in this thread are purely hypothetical. The plaintiff does not have access to my source code, therefore has no understanding of the checks in place. This lack of understanding is causing unnecessary back and forth. Furthermore, they are blowing these hypothetical problems out of proportion by implying that the system is so vulerable that an individual with no prior skillset could compromise their client's accounts in seconds.

In the real world, attacks like this do happen, even to big tech companies, but on the premise of flawed security practices. Most recently, a group of individuals social engineered a developer at Uber, leading to a data leak. Unfortunately, here on this Sythe thread, it's happening without any sort of evidence. It is clear to anybody that the purpose of this thread is not to address security concerns but to slander MyPvM's reputation.

 

It seems like we’re going to go over the same points repeatedly. I appreciate the conversation but I’m here to find a resolution. I’ll try to be as transparent as possible in this post.

It seems like the purpose of this report is to bring to light that an attacker located on the booster’s computer can retrieve the client’s details, putting the client’s data and accounts at risk while also giving them an invalid sense of safety.

On the topic of false advertisement:

The plugin gave clients the ability to not have to share information directly with the booster.

The plugin gave clients the ability to get details about their order much more seamlessly.

I am not active on Sythe - or any markets for that matter, but to my knowledge, currently at this time, this is a feature that only MyPVM provides. Furthermore, the presence of the plugin is only just a feature on top of already existing safety measures such as the use of VPNs and the background auditing of incoming workers.

It’s funny you see the plugin causing problems for clients whereas I see the opposite happening. The purpose of the plugin is to make clients feel as secure as possible but there are downsides to giving them so much power. For example:

V2Jay - filthy scammer

A client was able to catch a booster slacking and punished him for it. Was this intended to happen? Nope. Did this incident collectively teach our boosters a valuable lesson? Most definitely.

On the topic of security:

Let’s imagine a scenario where I designed an ATM for a bank called MyPVM. The purpose of this ATM is for MyPVM’s clients to be able to withdrawal cash from the machine. Through normal methods, we expect clients to enter their credit cards and authenticate themselves before withdrawing the cash. However, as in the real world, there are bad actors in play. For instance, someone could install a card skimmer and steal a client’s details. Or, if someone reverse engineers the ATM’s executable, they could find vulnerabilities and exploit them to cause the ATM to dispense money unwillingly.

In the case of MyPVM’s plugin, I’ve taken many measures to try to slow attackers down. I recognize that there are many ways to attack the system; however, as the developer of this plugin, I try my best to prevent these attacks from happening or slowing the attackers down as much as possible. On top of that, there are regular security audits where network traffic is reviewed. Could you get into my system as a worker? Absolutely – I can think of a handful of individuals that would be able to. But I try my best to make it not worth your time.

The problem with me responding to this post is that, as the person who designed the system, I know about the measures I’ve put into place. You’re asking me for the blueprint of the system so you can audit it for vulnerabilities. Don’t you think you’re sounding a bit ridiculous?

Furthermore, it seems that no-one seems to have mentioned the skillset required to even perform any sort of attack like this. Is this the type of skillset found in your average booster? Most individuals wouldn't even know where to start.

This brings us to our countermeasure. Suppose that the system is somehow compromised by the booster and they end up stealing the account.

There are a few cases here:

The attacker steals the account but finishes the order.

• The client changes the details of the account. The credentials that the attacker originally stole are no longer valid. Nothing interesting happens.

The attacker steals the account and cleans it.

• The client changes details of the account. The client is compensated with the booster’s deposit. The client can resume where they picked off at with another booster. Nothing interesting happens.
• A scam report is opened on the attacker. Our service will be able to provide additional evidence of all actions and timestamps taken to help the staff expediate the reporting process.

The attacker pulls an opposie and triggers alerts in our internal system.

• The attacker is locked out of the system while I investigate what happened. A scam report is opened and we keep their deposit.
• We notify the client of the potential breach and request for them to change their passwords. Then the order goes on. Nothing interesting happens.

What do you think of these security measures? Don't you think it's pretty safe and fault tolerant?

TL;DR

The plugin is a security measure on top of several other existing security measures. One of its features allows clients to share their credentials with the plugin without directly sending it to the booster. This feature aims to prevent completely (for your average booster), if not slow down attackers from retrieving the client’s credentials.

The plugin does not just log-in. It enables us to provide our client with additional resources that they normally would not have anywhere else.

The presence of the plugin gives MyPVM a competitive edge against others. With the security measures and countermeasures in place, they are extremely client focused and are consistently proving themselves to be the safest service provider on the market.

If an attacker compromises the plugin, they gain credentials to an account that they already have access to. Nothing interesting happens. Could someone try to compromise the plugin? Yes. But what do you gain from doing it? Do the pros outweigh the cons?

Comments based on “attacks that could work” mentioned in this thread are purely hypothetical. The plaintiff does not have access to my source code, therefore has no understanding of the checks in place. This lack of understanding is causing unnecessary back and forth. Furthermore, they are blowing these hypothetical problems out of proportion by implying that the system is so vulerable that an individual with no prior skillset could compromise their client's accounts in seconds.

In the real world, attacks like this do happen, even to big tech companies, but on the premise of flawed security practices. Most recently, a group of individuals social engineered a developer at Uber, leading to a data leak. Unfortunately, here on this Sythe thread, it's happening without any sort of evidence. It is clear to anybody that the purpose of this thread is not to address security concerns but to slander MyPvM's reputation.

whilst this is a lovely read, all the hypotheticals of this point to passwords being intercepted and the booster stealing credentials.

this assumes:

1) the booster has basic knowledge of how to intercept an ssl exchange.
2) the booster knows how to mem dump a client and extract the data they are looking for.

now, if they had the knowledge to do said attack…

1) they wouldn’t be a booster getting kids a couple godwards kd
2) why would they go through the effort when they can simply just…. Login?

these attacks simply can’t happen outside of either end, meaning it would happen on either the client side (boosters side), or the server side.

All in all, to compromise the client in any way or form, you would need to either be logged onto the boosters computer or the server, at which point either:

1) you’ve put down a multi bil deposit to work on customers accs who are just going to be compensated back anyway
2) you have been working as a software developer for 13 years, throughout various programming languages, companies and systems, anywhere from Freelancing on your own to developing Military Defence Systems used within NATO countries. With the knowledge you have gained throughout these 13 years you have been able to blackhat your way onto the server.

 

[Wild UIM]

It seems like we’re going to go over the same points repeatedly. I appreciate the conversation but I’m here to find a resolution. I’ll try to be as transparent as possible in this post.

It seems like the purpose of this report is to bring to light that an attacker located on the booster’s computer can retrieve the client’s details, putting the client’s data and accounts at risk while also giving them an invalid sense of safety.

On the topic of false advertisement:

The plugin gave clients the ability to not have to share information directly with the booster.

The plugin gave clients the ability to get details about their order much more seamlessly.

I am not active on Sythe - or any markets for that matter, but to my knowledge, currently at this time, this is a feature that only MyPVM provides. Furthermore, the presence of the plugin is only just a feature on top of already existing safety measures such as the use of VPNs and the background auditing of incoming workers.

It’s funny you see the plugin causing problems for clients whereas I see the opposite happening. The purpose of the plugin is to make clients feel as secure as possible but there are downsides to giving them so much power. For example:

V2Jay - filthy scammer

A client was able to catch a booster slacking and punished him for it. Was this intended to happen? Nope. Did this incident collectively teach our boosters a valuable lesson? Most definitely.

On the topic of security:

Let’s imagine a scenario where I designed an ATM for a bank called MyPVM. The purpose of this ATM is for MyPVM’s clients to be able to withdrawal cash from the machine. Through normal methods, we expect clients to enter their credit cards and authenticate themselves before withdrawing the cash. However, as in the real world, there are bad actors in play. For instance, someone could install a card skimmer and steal a client’s details. Or, if someone reverse engineers the ATM’s executable, they could find vulnerabilities and exploit them to cause the ATM to dispense money unwillingly.

In the case of MyPVM’s plugin, I’ve taken many measures to try to slow attackers down. I recognize that there are many ways to attack the system; however, as the developer of this plugin, I try my best to prevent these attacks from happening or slowing the attackers down as much as possible. On top of that, there are regular security audits where network traffic is reviewed. Could you get into my system as a worker? Absolutely – I can think of a handful of individuals that would be able to. But I try my best to make it not worth your time.

The problem with me responding to this post is that, as the person who designed the system, I know about the measures I’ve put into place. You’re asking me for the blueprint of the system so you can audit it for vulnerabilities. Don’t you think you’re sounding a bit ridiculous?

Furthermore, it seems that no-one seems to have mentioned the skillset required to even perform any sort of attack like this. Is this the type of skillset found in your average booster? Most individuals wouldn't even know where to start.

This brings us to our countermeasure. Suppose that the system is somehow compromised by the booster and they end up stealing the account.

There are a few cases here:

The attacker steals the account but finishes the order.

• The client changes the details of the account. The credentials that the attacker originally stole are no longer valid. Nothing interesting happens.

The attacker steals the account and cleans it.

• The client changes details of the account. The client is compensated with the booster’s deposit. The client can resume where they picked off at with another booster. Nothing interesting happens.
• A scam report is opened on the attacker. Our service will be able to provide additional evidence of all actions and timestamps taken to help the staff expediate the reporting process.

The attacker pulls an opposie and triggers alerts in our internal system.

• The attacker is locked out of the system while I investigate what happened. A scam report is opened and we keep their deposit.
• We notify the client of the potential breach and request for them to change their passwords. Then the order goes on. Nothing interesting happens.

What do you think of these security measures? Don't you think it's pretty safe and fault tolerant?

TL;DR

The plugin is a security measure on top of several other existing security measures. One of its features allows clients to share their credentials with the plugin without directly sending it to the booster. This feature aims to prevent completely (for your average booster), if not slow down attackers from retrieving the client’s credentials.

The plugin does not just log-in. It enables us to provide our client with additional resources that they normally would not have anywhere else.

The presence of the plugin gives MyPVM a competitive edge against others. With the security measures and countermeasures in place, they are extremely client focused and are consistently proving themselves to be the safest service provider on the market.

If an attacker compromises the plugin, they gain credentials to an account that they already have access to. Nothing interesting happens. Could someone try to compromise the plugin? Yes. But what do you gain from doing it? Do the pros outweigh the cons?

Comments based on “attacks that could work” mentioned in this thread are purely hypothetical. The plaintiff does not have access to my source code, therefore has no understanding of the checks in place. This lack of understanding is causing unnecessary back and forth. Furthermore, they are blowing these hypothetical problems out of proportion by implying that the system is so vulerable that an individual with no prior skillset could compromise their client's accounts in seconds.

In the real world, attacks like this do happen, even to big tech companies, but on the premise of flawed security practices. Most recently, a group of individuals social engineered a developer at Uber, leading to a data leak. Unfortunately, here on this Sythe thread, it's happening without any sort of evidence. It is clear to anybody that the purpose of this thread is not to address security concerns but to slander MyPvM's reputation.

Lovely read, and I appreciate the effort put into it, but as xKylee pointed out just above: Even with all of this, the booster still can get access to the user login/password while using the plugin.

I have nothing against the idea of the plugin, if I did I wouldn't have spent nearly two days on making one myself. This report is against false advertising, which you also confirmed, followed by multiple excuses and comparisons to how a system with direct credentials sharing with booster through discord is much less safe, but we are not here to compare safety of a system with a plugin and without a plugin. I truly hope that the standard in the industry will be using a plugin like your soon, as it eases the work for everyone and provides work for developers - lovely.

Still, this is, again, a report against false advertising, which MyPVM has been doing regarding the safety of their plugin, which is a banable offense.
You yourself confirmed multiple times in this reply that yes, the credentials can indeed be compromised with the use of simple tools and with not a lot of knowledge - MyPVM claimed that they can't: see the problem?


I believe that at this point, the verdict of the report is pretty clear, as it the issue reported has been confirmed by both the defending party, offending party and bystanders who contributed to the discussion, and all we'll be waiting for is the length and severity of the punishment.


Also, unrelated to the report cause itself, since this now seems to be a dumping ground for all sorts of accusations, memes harassment and so on: Regarding some of you saying that your boosters, who are facing true hardships due to the situation in their countries which they have no control over, are incapable of doing anything because they are all playing a 20+ year old game for pennies an hour:

1. It is truly sad to see someone make claims against their own employees, but it does truly show a lot about the employer.
   
   
2. "The most dangerous creation of any society is the man who has nothing to lose." - James Baldwin

 

Lovely read, and I appreciate the effort put into it, but as xKylee pointed out just above: Even with all of this, the booster still can get access to the user login/password while using the plugin.

I have nothing against the idea of the plugin, if I did I wouldn't have spent nearly two days on making one myself. This report is against false advertising, which you also confirmed, followed by multiple excuses and comparisons to how a system with direct credentials sharing with booster through discord is much less safe, but we are not here to compare safety of a system with a plugin and without a plugin. I truly hope that the standard in the industry will be using a plugin like your soon, as it eases the work for everyone and provides work for developers - lovely.

Still, this is, again, a report against false advertising, which MyPVM has been doing regarding the safety of their plugin, which is a banable offense.
You yourself confirmed multiple times in this reply that yes, the credentials can indeed be compromised with the use of simple tools and with not a lot of knowledge - MyPVM claimed that they can't: see the problem?


I believe that at this point, the verdict of the report is pretty clear, as it the issue reported has been confirmed by both the defending party, offending party and bystanders who contributed to the discussion, and all we'll be waiting for is the length and severity of the punishment.


Also, unrelated to the report cause itself, since this now seems to be a dumping ground for all sorts of accusations, memes harassment and so on: Regarding some of you saying that your boosters, who are facing true hardships due to the situation in their countries which they have no control over, are incapable of doing anything because they are all playing a 20+ year old game for pennies an hour:

1. It is truly sad to see someone make claims against their own employees, but it does truly show a lot about the employer.
   
   
2. "The most dangerous creation of any society is the man who has nothing to lose." - James Baldwin

Again, You can dump credentials off native client, what’s your point?

 

[Wild UIM]

Again, You can dump credentials off native client, what’s your point?

That no one claims boosters don't have access to user login credentials using native client. That would be by far the most ignorant claim in this thread, despite many to compete with.

 

[kThisIsCvpv]

Still, this is, again, a report against false advertising, which MyPVM has been doing regarding the safety of their plugin, which is a banable offense.
You yourself confirmed multiple times in this reply that yes, the credentials can indeed be compromised with the use of simple tools and with not a lot of knowledge - MyPVM claimed that they can't: see the problem?

Hey you delusional little fuck, quote me on this, I dare you. You're straight up taking words out of my mouth now.

 

That no one claims boosters don't have access to user login credentials using native client. That would be by far the most ignorant claim in this thread, despite many to compete with.

they don’t have direct access to credentials - they would need to gain access to them another way /thread done

 

[Wild UIM]

I recognize that there are many ways to attack the system;

Could someone try to compromise the plugin? Yes. But what do you gain from doing it? Do the pros outweigh the cons?

Here's the quote. One of many. I believe the term you are looking for is "putting words into your mouth", but in this case you are completely correct, I am taking them out of your mouth, as they are your words.

Also, language?..

 

[kThisIsCvpv]

Here's the quote. One of many. I believe the term you are looking for is "putting words into your mouth", but in this case you are completely correct, I am taking them out of your mouth, as they are your words.

Also, language?..

That no one claims boosters don't have access to user login credentials using native client. That would be by far the most ignorant claim in this thread, despite many to compete with.

Please tell me where on earth I've said that compromising a client can be done using simple tools and not a lot of knowledge.

 

[Wild UIM]

they don’t have direct access to credentials - they would need to gain access to them another way /thread done

A user having someone else's credentials in native client would have to put them in somehow, right? Or do the credentials of your clients magically appear on people's runescape clients? I'd say that's a major problem in that case.

 

[Wild UIM]

Please tell me where on earth I've said that compromising a client can be done using simple tools and not a lot of knowledge.

You said they can be compromised, that's enough. + plenty of 3rd party users have merged into this thread or posted separate threads where they will gladly demonstrate the insecurities of the plugin. I will gladly do so myself as well, in which case after the successful demonstration from my side I will require a permanent ban for all the parties who claimed otherwise.