Oh man, this level of bullshit is really getting annoying at this point. You almost entirely disregarded the objective facts I've stated and continue to show incompetence, as detailed below.
Agreed. The majority of training methods and activities in OSRS are done through very simple and repetitive actions. That's how the game is played, not sure what your point is.
Actually, scripts can get very complex. You show a salamander script that does 3-4 clicks and delays a specific time. Which is why I made comments about touch recording software being able to easily mimic that. Surely you can see the difference between clicking 3-4 buttons which are always in the same place and something as complex as an active combat bot or even a zulrah bot. Why are you trying to argue that your salamander bot video you showcased isn't weak as fuck?
The reason I was critical of TeamViewer in the previous post stems from a different method of detection, which is through the heuristics of the input. TeamViewer's input signature is very distinguishable.
I really tried to fucking save you from embarrassing yourself, but here you are again just spouting nonsense jargon and industry buzz words that make no sense in the context you're using them in. What do you even mean by input signature? Please explain because I'm having a hard time understanding you at this point. The input data that is passed when in relation to a mouse are coordinates and what switches in the mouse are being hit (left click, right click). Whether this is passed through the native device or a remote host via port is of little relevance.
To your point, another way to detect a bot could be though searching the process list for the bot string. It's well-documented that Blizzard (Warden) uses this method, in addition to others, for bot detection. In summary, Warden conducts active RAM scans and polls the process list, which makes it very difficult to read/write the game's memory contents without staying undetected. This has been taken into account since the XiaBot process essentially mimics the appearance of various core Android processes, which, even if identified in a process list, wouldn't be conclusive evidence of any wrongdoing. We do not touch the native memory heap of OSRS, nor do we hook into any of it's methods.
Didn't I already explain the process list is a potential way of detection? Why are you just repeating what I say?
'Mimicking' the process of a core android system function is useless to any real detection by the way. I'm guessing you just renamed it and called it good anyways, LOL. Luckily the OSRS app does not require read or write privileges.
Naturally, this bot detection methodology is fairly intrusive and many governing bodies, including the Electric Frontier Foundation, classify Warden as spyware. Henceforth, Blizzard makes sure to include a clause in their End User License Agreement:
"Consent to Monitor. WHILE RUNNING, THE PLATFORM (INCLUDING A GAME) MAY MONITOR YOUR COMPUTER OR MOBILE DEVICE'S MEMORY FOR UNAUTHORIZED THIRD PARTY PROGRAMS RUNNING EITHER CONCURRENTLY WITH A GAME OR OUT OF PROCESS."
I'm almost 100% certain that OSRS doesn't use this method of detection because they make no reference to this in any of their legal documents.
It's nice to look at the EULA, but as the app requires no permissions, which I already stated in my previous post with an edit yesterday after being interested in it myself, the OSRS app does not appear to have that functionality. So therefor it is not reading contents on a phone (to my knowledge).
Currently, the main priority is to establish stability with our first platform before spending time and resources on other devices. We haven't even released the bot yet, all we want to do is have a successful launch right now. After we have received sufficient feedback towards additional training methods/supported devices, we will prioritize accordingly. The resolution difference plays a part, but this doesn't take much time to adapt. The input heuristics in Android contain several different variables that range greatly from one hardware manufacturer to another. This was observed during the early stages where we tried out dozens of different mobile devices.
This is so painful to read. Even after I explain the heuristics of capacitive touch sensors that literally every mobile touch screen device uses. It's like you're not paying attention at all and think you can just say "input heuristics" over and over again to attempt to appear competent. To somebody who actually knows the underlying fundamentals of the technology in these devices it's painfully obvious, you do not. So why are you trying to deceive everybody? Cite examples as I have or concede. I don't think anybody reading this with capability of googling is convinced by you.
As you might have guessed, it takes a considerable amount of time and effort to manually generate human input and accurately build our models from the aforementioned data.
Input this, input that, DATA, HEURISTICS. Spare us already! No, it actually takes little to no time to "manually generate human input". Literally touch a spot on the screen,
WOAH MANUAL HUMAN INPUT. And if you're generating human input manually, did you just confirm that you use a touch screen recorder?
Regardless, given the nature of the bot, your device has to essentially be dedicated to the game. I certainly know I wouldn't be using my main phone as my bot platform because I'm usually using it for other things. I'm sure many other people out there feel the same way. Therefore, it seems to make the most sense to have a dedicated device for the bot that's as cheap and accessible as possible, like the Amazon Fire HD 8. If people want other devices to be supported, we can always adapt to that.
I mean yeah, if you're using 1 to 1 input that isn't in a virtual environment or container, it would be beneficial to have a dedicated device so you can use your normal devices. This is pretty obvious...
If you took the time to observe the setup tutorials, you would see that ADB is required for this bot to work. This should give you a fairly obvious indication of what's happening. No LAN or WAN network protocols are being used. No network ports are being opened. We understand security is a serious concern, but you need to relax.
For the love of...
AND I QUOTE:
"When you start an adb client, the client first checks whether there is an adb server process already running. If there isn't, it starts the server process. When the server starts, it binds to local
TCP port 5037 and listens for commands sent from adb clients—all adb clients use port 5037 to communicate with the adb server. (
Android Debug Bridge (adb) | Android Developers)"
Server < Daemon < Client
You quite clearly have no fucking idea what you're talking about at this point. I'm dropping the mic.
In addition to providing a solid proof of concept, the betas were treated as opportunities for us to really flex the power of the bot in regard to hours played and undetectability. However, just because you have the ability to run your bot almost indefinitely and probably get away with it, doesn't mean you should. In regard to responsible use, it's important to not get complacent and believe that you are 100% bulletproof because this is usually when things start to go wrong. We will be creating guidelines surrounding responsible use before release, just like basically every other bot out there.
Weird flex. This is a yikes from me, dawg. Hard pass, and I encourage anybody to use a free touch screen recording app instead of whatever the fuck this is going to turn out to be which even the "developer" lacks knowledge of the basic protocols they're using.
Here's a dude literally bragging about running a fletching bot for 10 days staight that he recorded on mobile with a free app.
07 Mobile afk fletching bot / will work as moneymaker aswell
Cya.