soviras

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 123 total)
  • Author
    Posts
  • in reply to: Everyone Okay? #38162
    soviras
    soviras
    Participant
    3+

    I heard about the bombing in your city when I checked the news just now… I came here to see any news from your end. I’m so glad that you are alright.
    Stay safe.

    in reply to: Temporary Alternatives? #36761
    soviras
    soviras
    Participant
    0

    As far as I am aware, discussing alternatives, besides cursory mentions that they exist, or perhaps that there’s features you’d like in Miqo too, is against the rules.
    That said, there aren’t any alternatives that are on par with Miqo.

    in reply to: Miqobot (unofficial) status FAQ #36750
    soviras
    soviras
    Participant
    0

    That all being said, please note that the devs has never asked for donations or support. In these hard of times, of you have ever used the Miqobot, and as me has enjoyed the features, go ahead and extend your time. It will support the devs no matter what they say. God bless you all, may we have peace in all off europe sooner rather than later.

    They actually don’t want donations, the opposite rather. They want us to look out for ourselves first.

    in reply to: Miqobot (unofficial) status FAQ #36744
    soviras
    soviras
    Participant
    1+

    Wow. Since when did this place turn into Twitter? So many offended people getting offended on someone else’s behalf.

    People can unsubscribe if they wish. People can be unhappy if they wish.
    Calm down and vent on Twitter.

    If it is a troll… Congratulations on taking the bait and doing what they wanted. Congrats.

    It’s very Narcissistic to preach how you’re a good person by giving money for a product and expecting people to do the same while you praise yourself.

    I’m all subbed for a year. Give me a damn medal and please tell me if you aren’t so I can lord it over you.

    Now, back to the actual topic.

    I’m happy that everyone is safe for now. no rush for me on getting it working. I’m just happy for the potential that it’ll be working again.

    I think you missed the point. People weren’t upset that they didn’t want to keep paying, but that they were essentially saying that the devs should spend their time on fixing it right now, as if that is the top priority.

    I do agree though, back to the main topic.

    What’s most important is that the devs are safe and sound. It doesn’t matter how long they take.

    in reply to: Miqobot (unofficial) status FAQ #36663
    soviras
    soviras
    Participant
    3+

    Please take as much time as you like, we are not in a hurry. It is great to hear from you guys. Stay safe!

    We are indeed not in a hurry. The only reason I wanted to make a temporary fix for everyone was so that the team could rely on the income during this horrible time.

    in reply to: Miqobot (unofficial) status FAQ #36652
    soviras
    soviras
    Participant
    0

    Hi guys,

    Let me know if I can be of any assistance.
    I’m not great at dynamic memory patching (it’s been a while), but I’ve made some trainers pointing to dynamic addresses and have some (probably basic) knowledge of CheatEngine.

    Considering you have some experience, your help would be more than welcome.

    in reply to: Miqobot (unofficial) status FAQ #36647
    soviras
    soviras
    Participant
    1+

    I made a discord server for the preservation effort. I would like to ask permission from our resident moderator, @arkheat before I post it here.

    • This reply was modified 2 years, 1 month ago by soviras soviras.
    in reply to: Miqobot (unofficial) status FAQ #36646
    soviras
    soviras
    Participant
    0

    We don’t know anything. All we can do is wait.

    in reply to: Miqobot (unofficial) status FAQ #36621
    soviras
    soviras
    Participant
    0

    I think if it’s in arc’s power this is a very solid idea that would not hurt the MiqoTeam in this specific, VERY exceptional, setting.

    Good shout boys.

    If anything I would think it would help the miqo team as people would still be paying for sub if they know they can keep using it. A few of us may sub regardless sure but the vast majority of users aren’t really paying attention to what’s going on so they may wander off if they can’t use it.
    My hope is that this mess will be over soon but it doesn’t look likely and not having heard from them makes me worry for their safety.

    Short of a coup in Russia (which is getting increasingly likely), or Putin and his allies dying due to food poisoning, I don’t see it ending anytime soon…

    in reply to: Miqobot (unofficial) status FAQ #36608
    soviras
    soviras
    Participant
    0

    According to my knowledge Miqobot has some form of Anti-Cheat implemented.
    There have been several occasions of people complaining on the forums about getting their license key revoked, their money refunded and their IP banned, only to result in Miqobot clearing that up, that those people have been attempting to reverse-engineer the bot and got auto-banned from the server.

    This is also the reason why there is no more free trial of Miqobot. Too many people have attempted to reverse-engineer the trial version to cheat themselves out of the monthly sub.

    Something to keep in mind.

    There is, but not on every part. I know the extent of their protection, and would advice people to not tamper with it without knowing what you’re doing. That’s also why it’s done in this exact way, no alterations until after you cleared the authentication process.

    I’ve modified Miqo for months now, not in any bad way though. I pay for it, just add features that I want or fix broken parts earlier. Would love to have a full programmable interface, more advanced than scenario, in the future, where we could code things and then share it the same way as we do for other things. One example is fixing the crafting calculations. Miqo is community driven, and letting the community do more direct programming could take a significant burden off of Miqos dev team in the long run.

    I haven’t personally messed around with your method, and I could be wrong, but from my own knowledge of reversing this is POSSIBLE to turned into a patch for everyone. It’s a matter of finding the assembly instruction(s) that are responsible for allocating + placing the MAR value in memory, no? If the value(s) in question are implemented directly in Miqobot source code, and you say that the location changes from machine to machine depending on where the memory is allocated, then I can’t help but think the address is encoded directly into an assembly instruction, such as mov [SomeDynamicLocation], 0x123456789 and then referenced from there. If not that, then the value lives as hex bytes inside a module, which gets mapped dynamically into memory at runtime and would be referenced like mov rax, [SomeConstantAddress]/mov rax, [SomeModule.123456789]/mov rax, [SomeDynamicAddress + SomeConstantAddress].

    I have no formal training in this so again I could be totally wrong, but those are patterns I see a lot when I do this kind of thing.

    You are correct, but, due to how miqo does things, the memory structure is not exactly consistent across different devices. Finding the place the address is stored that works on all devices is the hard part as a result.

    I honestly would love to talk more in depth about this, maybe even try to find a solution, just don’t want to discuss potentially sensitive info on Miqobot’s inner workings on a public forum…

    Agreed. If we could bundle resources in a non public setting, we can try to fix something up, maybe…

    in reply to: Miqobot (unofficial) status FAQ #36586
    soviras
    soviras
    Participant
    1+

    Last hour before the hotfix potentially breaks miqo indefinitely…

    in reply to: Miqobot (unofficial) status FAQ #36579
    soviras
    soviras
    Participant
    0

    I just hope the devs are alright tbh… We haven’t heard from them in a bit, and that is very worrying. The person I contacted in the past has long since left the country.

    in reply to: Miqobot (unofficial) status FAQ #36577
    soviras
    soviras
    Participant
    0

    According to my knowledge Miqobot has some form of Anti-Cheat implemented.
    There have been several occasions of people complaining on the forums about getting their license key revoked, their money refunded and their IP banned, only to result in Miqobot clearing that up, that those people have been attempting to reverse-engineer the bot and got auto-banned from the server.

    This is also the reason why there is no more free trial of Miqobot. Too many people have attempted to reverse-engineer the trial version to cheat themselves out of the monthly sub.

    Something to keep in mind.

    There is, but not on every part. I know the extent of their protection, and would advice people to not tamper with it without knowing what you’re doing. That’s also why it’s done in this exact way, no alterations until after you cleared the authentication process.

    I’ve modified Miqo for months now, not in any bad way though. I pay for it, just add features that I want or fix broken parts earlier. Would love to have a full programmable interface, more advanced than scenario, in the future, where we could code things and then share it the same way as we do for other things. One example is fixing the crafting calculations. Miqo is community driven, and letting the community do more direct programming could take a significant burden off of Miqos dev team in the long run.

    I haven’t personally messed around with your method, and I could be wrong, but from my own knowledge of reversing this is POSSIBLE to turned into a patch for everyone. It’s a matter of finding the assembly instruction(s) that are responsible for allocating + placing the MAR value in memory, no? If the value(s) in question are implemented directly in Miqobot source code, and you say that the location changes from machine to machine depending on where the memory is allocated, then I can’t help but think the address is encoded directly into an assembly instruction, such as mov [SomeDynamicLocation], 0x123456789 and then referenced from there. If not that, then the value lives as hex bytes inside a module, which gets mapped dynamically into memory at runtime and would be referenced like mov rax, [SomeConstantAddress]/mov rax, [SomeModule.123456789]/mov rax, [SomeDynamicAddress + SomeConstantAddress].

    I have no formal training in this so again I could be totally wrong, but those are patterns I see a lot when I do this kind of thing.

    You are correct, but, due to how miqo does things, the memory structure is not exactly consistent across different devices. Finding the place the address is stored that works on all devices is the hard part as a result.

    in reply to: Miqobot (unofficial) status FAQ #36572
    soviras
    soviras
    Participant
    0

    the main issue being finding the new addresses, and finding a method to consistently locate where the memory values miqo uses are stored within miqo after it loads the module, because that is all over the place… Different machines produce slightly different results, so making it work for others is the biggest hurdle.

    In other words doing all the work Miqo team has been doing for every patch.

    Yup! With a few extra steps because I don’t have the source code!

    Is this something you could make a guide for so that others can do it? Instead of making a patch that works for everyone might be easier to make make a guide for each person to do themselves.

    I could, but most people wouldn’t be able to even with a step by step guide, as it requires knowledge about assembly language and memory interpretation to understand what you’re looking for. In the end, someone still has to go through the steps, and do it for everyone…
    Steps that are required are as follows:
    1. Start Miqo.
    2. Use any software that lets you browse, search, and edit memory. Cheat engine is one I would recommend as it’s easy to set up, and free. Hook it up to Miqo.
    3. Activate any module within Miqo (including the base module, which hooks it to the game).
    4. Trace what addresses are altered within memory upon activating the module. The address reference you need is in that.
    5. Find the memory address reference (MAR) that miqo reads data from within that.
    6. Find a way to locate the MAR consistently using memory that’s around the region (this is the hard part due to how different CPUs and operating systems create different patterns in memory with how miqo loads in stuff).
    6b. Find where the values are in memory in the new version of FF14. (Miqo team does this normally, and then just rewrites the source code)
    7. Create a routine that rewrites the MAR to the new address. Cheat engine lets you do this with a simple on/off toggle if you know how to do that. (miqo just edits in the source code, much easier version of the step)
    8. Test it on various pc builds.

    The only time I will release something is if:
    A. Miqo team is still missing.
    B. I have the time to go through this process.
    C. It isn’t impossible to make something that’s easy to use for random people that doesn’t expose miqos inner workings.

    • This reply was modified 2 years, 1 month ago by soviras soviras.
    in reply to: Miqobot (unofficial) status FAQ #36567
    soviras
    soviras
    Participant
    0

    Out of curiosity, is there a scenario where a moderator team could be equipped to take the reins for an extended period of time?

    For the forums, yes. For the bot, no.
    If it comes down to it, I will assist as much as I can, and try to create a hacky solution for the bot to keep working, but as nobody but the miqo team has access to the source code, its gonna be a lot of work to do that. The best I could do is find the new memory layout, and then try to hook into miqo to overwrite where it’s looking in the games memory, but that could very well take months to do.
    The mods are just volunteers, and I’m not even a mod…

    By the dev team’s own admission, Miqobot downloads her modules from a server at runtime in an attempt to discourage reverse engineering. I theorize that creating any sort of “patch” would involve 1. extracting these modules from memory, 2. do enough reverse engineering to locate the data we are interested in, 3. create some sort of wrapper that can identify and patch the data at runtime without causing any other issues. Additionally, this method assumes that Miqobot has no innate “anti-cheat” so to speak, and that the modules are downloaded in their entirety & Miqobot does not need to fetch any server-side information “on demand” that’s critical to our goal.

    A memory patch will suffice, overwriting the memory addresses where miqo looks at in runtime… Doing this with something like cheat engine is possible, the main issue being finding the new addresses, and finding a method to consistently locate where the memory values miqo uses are stored within miqo after it loads the module, because that is all over the place… Different machines produce slightly different results, so making it work for others is the biggest hurdle. I got a patch for the crafting stuff in much the same manner, but it’s specific to one device… Once the memory addresses are loaded in, which miqo has to do to find the values it needs, the modification can’t be prevented by any anti tamper. The process would be something like:
    Start game.
    Start Miqo.
    Start Cheat engine with custom table.
    Activate base module entry, miqo now hooks to game.
    Activate combat assist in miqo.
    Activate combat module entry, miqo can now read combat related data.
    Disable combat module entry (or miqo will crash).
    Disable combat assist in miqo.
    Getting it to work on one device is easy, getting it to work for everyone is what takes time, and as I’m jobhunting, I am low on time.

Viewing 15 posts - 1 through 15 (of 123 total)