Jump to content
UBot Underground

clkmnky

Members
  • Content Count

    21
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by clkmnky

  1. Hi Nick,

     

    Thank you so much for taking the time to reply. Sometimes it's useful to get someone else's perspective on how to potentially obtain a solution.

     

    Oddly enough, neither Aymen's File Management plugin nor the Heopas plugin contain Functions or Parameters that would appear to produce a file size. For example, the "$file info" parameter within Aymen's File Functions plugin provides these options:

    -Get Creation Time
    -Get Last Write Time
    -Get Last Access Time

     

    (They're phenomenal plugins, I should add, and appreciate you bringing them to my attention!)

     

    It occurred to me there might be away to obtain file size information by leveraging UBot Studio's built-in support for Python.

     

    Sure enough, this actually produced a measurable number:

    download file("http://www.ubotstudio.com/resources","{$special folder("Desktop")}/page.html")
    
    set(#FileInformation,$python result("FileSize","import os
    
    os.path.getsize(\'{$special folder("Desktop")}\\page.html\')"),"Global")
    

    (This wouldn't have been achievable absent your reply, which kinda triggered more thinking on my part.)

     

    You mentioned something intriguing:

     

     

     

    You could download the scripts and images contained in the HTML as well if you needed to see how much data that takes up as well.

     

     

     

    My original vision was to block the loading of images so as to remove this as a potential variable associated with attempting to measure the amount of bandwidth that could potentially be consumed. However, considering that various tracking pixels are, to the best of my knowledge, image files, it might be shortsighted to block images.

     

    Would you propose scouring the code of the page being loaded for any HTML "img" tags and then subsequently downloading those files as well so that they can be measured for size?

     

    (The rationale for wanting to measure all of this file size information stems from having to calculate potential paid proxy bandwidth costs.)

     

    Any additional insights or perspectives you might have are appreciated, as always.

     

    ^Stephen

  2. Hi! Question:

     

    1) You navigate to a webpage using the UScript "navigate" command.

    2) Now you want to determine the kilobyte/megabyte size of the data contained on the webpage.

     

    Any thoughts or perspectives on whether or not this can be accomplished with either native UScript code or alternatively via a plugin?

     

    Thanks in advance for any insights.

  3. Hello!

     

    What's the name of the specific font whose bold version you'd like to use? I might be able to provide you with a specific code example.

     

    I genuinely couldn't figure out how to specifically use the built-in image functions, so I waded into ImageMagick command line instructions that oddly made more sense to me. I'm able to trigger bold face versions of fonts (even custom created fonts) directly via ImageMagick.

  4. UPDATE: I re-discovered a circa 2010 "EeePC" that I had stashed away which happens to be loaded with the Windows 7 Starter edition operating system, an Intel Atom N450 processor, and 2 gigabytes of RAM. I was successfully able to load UBot Studio v5.9.55 and once again have access to the native FTP functionality that no longer exists when using UBot Studio in Windows 10. I'm familiar with the shell/batch file workaround that others have pointed out that can be used to perform FTP commands from UBot Studio within a Windows 10 working environment. I can confirm the workaround works. However, for reasons that are beyond the scope of this post, I'm genuinely interested in having the built-in FTP functionality work again -- and I can confirm that within a Windows 7 operating system environment, at least with UBot Studio 5.9.55, FTP "works" again as intended. I realize that Windows 7 is fast approaching EOL status at Microsoft, but I have a few ideas to potentially extend the usefulness of Windows 7, specifically as it relates to hosting 24/7 apps created with UBot Studio. More on that in another post, at another time.

  5. I'm not experiencing this issue, but I read the information contained in the link that Pash shared, and the only potential thing that jumped out was this line:

     

     


    Note: A 32-bit process running on a 64-bit OS can address 4GB of user-mode memory, and a 64-bit process running on a 64-bit OS can address 8TB of user-mode memory, so an OOM on a 64-bit OS isn’t likely. It is possible to experience an OOM in a 32-bit process running on a 64-bit OS, but it usually doesn’t occur until the process is using close to 3GB of private bytes.

     

    Based on the fact db00 mentions having 70 gigs of RAM, 30 of which are usually always available, that strongly suggests that a 64bit version of Windows 7 is being used (assuming the information in db00's profile is accurate, wherein it mentions the OS being used as Windows 7).

     

    To the best of my knowledge, UBot Studio is a 32 bit program/process. That means, based on what Microsoft published, that an OOM (out of memory error) can potentially be thrown if close to 3 gigabytes of RAM is being utilized within a 64bit operating system environment by a 32bit program/process.

     

    It seems unlikely, but is it possible that loading UBot Studio with multiple high performance plugins could conceivably push the total amount of RAM memory being consumed to over 3 gigabytes?

     

    Interestingly, I have always assumed that the rigors of compilation are carried by the external remote "compilation server" that our local UBot Studio software connects to. In other words, when we "compile" something, we are merely transmitting our code to the external/remote compilation server, the program gets compiled there, and we get an EXE file in return that's then placed on our machine in the directory we specify when compiling.

     

    If that's the case, it's plausible that UBot Studio is coded in a way that any errors experienced by the compilation server are displayed to the user whose code was being compiled. If the OOM error is being triggered by system environmental factors on the remote server, then that may be less directly under our control. (Meaning, we could have terabytes of RAM, exabytes of data, hundreds of cores, but it ultimately doesn't matter given that the system variables that directly impact compilation reside on a remote/external UBot Studio server that could be taken offline at anytime.)

  6. Hi!

     

    If you happen to be running the Windows 7 operating system (regardless of edition), and are also running UBot Studio, could you please take a moment to kindly comment on whether or not the FTP functionality that's built into UBot Studio works for you? This is primarily in reference to Bug # 1217 wherein FTP stopped working. I think I recall some individuals mentioning that they weren't experiencing this bug, and the primary variable seemed to be the operating system being used.

     

    Thanks in advance for any thoughts or comments.

  7. Hello All it was so difficult but finally I am able to fix VIRUS TOTAL FALSE POSITIVE upto 99% which means almost 99% antivirus will not detect the software as false positive now ;) have a look here https://www.virustotal.com/#/file/20842697fced7d3c6cbd93b30bee84d4f1cfda0ce0eb9706d16c2e2b8af9b2a6/detection

     

    And thank you clkmnky your post gave me courage to fix it I put almost 12 hours of My time and drank 13 cups of coffee lol to fix it :D

     

    Download here : https://aiarticlespinner.com/go/ai

     

    **STANDING OVATION!**

     

    That. Is. AMAZING!

     

    I'm extremely impressed with your dedication and determination to achieve a practically clean VT result on the UBot Studio compiled executable itself.

     

    Like, really... WOW!

     

    The biggest variable that jumps out at me is what VT reports as the file sizes.

     

    The first iteration of AIAS is reported by VT to be 19.48 MB. The second iteration of AIAS (the one that is practically 100% clean) is reported by VT to be 21.07 MB in size.

     

    There seems to be widespread consensus that the #1 reason all these false positives occur is because there's a mechanism within the UBot Studio compiled executable that will check to see if the necessary files needed to successfully run a UBot Studio executable are in the machine's "roaming" folder, and if they're not, then they will be downloaded directly from the UBot Studio server. I don't know if this is true, but I see it being mentioned a lot.

     

    Given that you've included all the necessary files in your installer, there's no need for the UBot Studio executable to download support files from the UBot Studio server. However, the mechanism to check if the support files exist is likely still in the executable file, as well as the mechanism to download the support files if necessary.

     

    I'm guessing one of two things have occurred:

     

    Either:

     

    1) You have managed to somehow "crack" the UBot Studio compiled executable so that it no longer contains the code that checks for support files on the local machine (and downloads them directly from the UBot Studio server if they're not on the local machine), or

     

    2) You have added "padding" to the UBot Studio executable so that it somehow changes the way it's perceived by AV systems, and it's no longer being flagged. In other words, the UBot Studio compiled executable still contains the built-in support file check/download functions, but by adding additional data to the finished file, it somehow changes the entire way in which AV's see the finished file.

     

    OR....

     

    Something else. Some other mechanism through which you've managed to get the final compiled UBot Studio executable to be seen as clean.

     

    You're a genius. :)

     

    EDITED TO ADD: You're a genius, or... that's some really good coffee! Haha. Great job!

  8. Just putting it out there..... since most av's tag ubot with a false positive, and in doing so will often delete or otherwise make the file/exe unavailable to the user, it seems to me that any steps you can take to prevent the actual scam-ware (antivirus) from falsly flagging you is a good thing and should be embraced.

     

    I agree 100% with this.

     

    Once the installer unpacks/installs the UBot Studio compiled executable for AI Article Spinner, it resides here (at least on my machine):

     

    C:\Program Files (x86)\AI Article Spinner\AI Article Spinner\AIArticleSpinner.exe

     

    To the extent a particular AV that's installed on an end-users machine is flagging a UBot Studio compiled executable as a virus, and then deleting it or making it unavailable to the user, then the method Romeo has suggested will not ultimately solve the problem. The reason why is because the AV system installed on the end-users machine will invariably notice the UBot Studio compiled executable when it gets run. It has to be run for the software to actually work.

     

    Romeo's method definitely *does* help when an end-user initially downloads the installer and decides to scan the installer on something like VirusTotal. It'll show a clean result.

     

    But once the installer has been executed, and AI Article Spinner is installed, the UBot Studio compiled executable is vulnerable to whatever AV an end-user might have installed on their machine.

     

    I'm not sure there's a one-size-fits-all answer to this. And a lot depends on who the end-users (generally speaking) happen to be.

     

    I just rather be on offense and wrap my arms around the proverbial virus "boogie man" and straight up tell people that my software is getting some false positives.

     

    The good news is that, according to VT, highly respected AV's like McAfee, Kaspersky, Symantec, and Microsoft all rate AI Article Spinner as being "clean."

     

    There are no easy answers and I definitely respect and agree with the need to minimize this being an issue at all.

    • Like 1
  9. OP Says:: "I just fixed the FALSE POSITIVE VIRUS DETECTION"

     

    What did you do to fix it?

     

     

    It appears to be a situation in which the installer/wrapper turns up a clean VT test result, but the enclosed UBot Studio compiled executable (which shares the same name as the installer/wrapper) turns up as virus infected malware:

     

    https://www.virustotal.com/#/file/adb82e49091fd8d4efb68f08cd017cec38133b0f716693f65cc3a68f44a92e6f/detection

     

    It's definitely a clever work-around that relies on the idea that someone might scan/check the installation executable file with something like VT, but not necessarily check the enclosed files.

     

    My preference is to still be upfront about it, as described in detail here: (http://network.ubotstudio.com/forum/index.php/topic/22224-antivirus-issue-getting-worse/?p=136066).

     

    Imagine having to do damage control when someone scans the installer and sees it's clean, but then discovers the enclosed executable is getting flagged as virus infected malware.

     

    I just ran the above paragraph through the software, and here is the result:

     

    # # #

     

    It looks a situation where the installer/wrapper arises a clean VT check result, however the enclosed UBot Studio compiled executable (which shares the same name while the installer/wrapper) arises while virus infected malware:

     

    https://www.virustotal.com/#/file/adb82e49091fd8d4efb68f08cd017cec38133b0f716693f65cc3a68f44a92e6f/detection

     

    It's definitely a clever work-around that depends on the idea that somebody might scan/check the set up executable document with something similar to VT, however, not necessarily check the enclosed documents.

     

    My preference is usually to be upfront about it, as described at length here: (http://network.ubotstudio.com/forum/index.php/topic/22224-antivirus-issue-getting-worse/?p=136066).

     

    Imagine needing to do harm control when somebody scans the installer and sees it's clean, but discovers the enclosed executable gets flagged while virus infected malware.

     

    # # #

  10. All --

     

    Nobody wants to download and use software that appears to be virus infected malware.

     

    So when I share a link to this VirusTotal detection report...

     

    https://www.virustotal.com/#/file/41fdbe471f168cb82a2931dcb009ca236dc8280c808f29f415dde3a86939d4b4/detection

     

    ...and you see that 30 out of 68 anti-virus/malware programs classify it as dangerous (at least as of the time I'm sharing the report link)...

     

    You're likely to conclude there's no way anyone would ever download and use the software.

     

    And that's what I'd initially assume, too.

     

    But thousands, if not tens-of-thousands of people use this software every day.

     

    (I'm running multiple instances of this software as I type this message.)

     

    Two things make the difference.

     

    1) A rational upfront explanation of why the software may be showing up as malware.

     

    From the sales thread of the software whose VirusTotal report I'm highlighting...

     

     

     

    Windows 10 Defender recognizes miner as a virus, some antiviruses do the same. Miner is not a virus, add it to Defender exceptions.
    I write miners since 2014. Most of them are recognized as viruses by some paranoid antiviruses, perhaps because I pack my miners to protect them from disassembling, perhaps because some people include them into their botnets, or perhaps these antiviruses are not good, I don't know. For these years, a lot of people used my miners and nobody confirmed that my miner stole anything or did something bad.
    Note that I can guarantee clean binaries only for official links in my posts on this forum (bitcointalk). If you downloaded miner from some other link - it really can be a virus.
    However, my miners are closed-source so I cannot prove that they are not viruses. If you think that I write viruses instead of good miners - do not use this miner, or at least use it on systems without any valuable data.

     

    2) Social proof confirming that the software works and doesn't do any harm.

     

    In this case, the software is posted for download on a forum where people can reply and post questions, comments, or concerns.

     

    You can see the thread for yourself: https://bitcointalk.org/index.php?topic=1433925.0

     

    The original post gets updated whenever a new version of the software is released.

     

    But you can see the first reply to the original post specifically mentions the malware issue:

     

    - - - -

    My antivirus removed the file as soon as it was available.
    So ill keep off until some more comments are available.

    - - - -

     

    It starts becoming a non-issue once the software author replies with...

     

    - - - -

    I pack my miners to prevent disassembling. Some paranoid antiviruses treats any packer as a virus. I'm trying to fix it, but not sure that it is possible for all antiviruses.
    If you think that I write viruses - do not use this miner.

    - - - -

     

    ...and it snowballs as more social proof rolls in throughout the forum thread.

     

    The Solution

     

    In a perfect world, no app/bot created with UBot Studio would get flagged as virus infected malware.

     

    But it happens.

     

    Trying to get some random AV company to whitelist one's software is tricky at best, impossible at worst.

     

    Pleading with the UBot Studio development team to fix the problem is understandable, but the issue has been addressed in the past:

     

    http://network.ubotstudio.com/blog/why-your-bot-is-showing-up-as-a-virus-and-what-to-do-about-it/

     

    I've only used one part of the formula (a rational upfront explanation of why the software may be showing up as malware) and haven't had any real issues.

     

    Here's what I say, feel free to borrow or modify it:

     

    ========

    Hi, it's %%YOUR-FIRST-NAME%%. I'm the creator of %%NAME-OF-SOFTWARE%%.
     

    Before you download %%NAME-OF-SOFTWARE%%, I just want to take a moment to personally thank you for expressing an interest in this amazing software.
     

    I also want to take a moment to proactively bring some very weird and bizarre information to your attention.
     

    The overwhelming majority of anti-virus systems correctly classify %%NAME-OF-SOFTWARE%% as being completely clean and safe to download and install. That's why I'm bewildered to have to tell you that a small minority anti-virus systems are erroneously classifying %%NAME-OF-SOFTWARE%% as being virus infected malware.
     

    You can see the independently generated 'Virus Total' results for the %%NAME-OF-SOFTWARE%% executable (EXE) file here: [LINK-TO-VIRUS-TOTAL-REPORT]. Verify the SHA-256 hash listed on the 'Virus Total' page with the code below.

    %%NAME-OF-SOFTWARE%%.exe :: [the-sha256-hash-for-your-ubot-exe-file]

    After speaking to several other independent software developers and reaching out to a software security consultant, I discovered that a lot of legitimate software gets erroneously flagged as virus infected malware from time to time.

    In conclusion, if you download %%NAME-OF-SOFTWARE%% directly from this website ("YourDomainName.com") and not from some random "warez" site, I'm 100% certain that everything will be fine. I use %%NAME-OF-SOFTWARE%% every day.
     

    Thank you for your support,
    %%YOUR-FIRST-NAME%%

    ========

     

    Now imagine if in addition to that upfront transparency, there were at least 80 "replies" with various messages that join the conversation already going on in the mind of the individual who might be interested in the software.

     

    "Yeah, my AV flagged it, but I whitelisted and there are no problems."

     

    "No problems installing it on my system."

     

    "Works fine."

     

    "The file is clean."

     

    I'm just saying, we as a community don't have to let this AV issue hold us back or hold us down.

    • Like 1
  11. ALso FTR Ive got the latest VC++ runtime distributable + .Net 4.7.2

     

    I'm not using 6.01 or 6.02 at the moment, but during my failed attempt to get 6.01 to work in a manner that reasonably resembled the functionality of 5.9.55, I noticed the following bullet point in the release notes for 6.01:

     

    *** Note: The new internal browser requires the .net framework version 4.5.2. Please make sure this is installed on your system ***

     

    The only reason I bring this to your attention is that there's a slight chance that having -any- version of the .NET framework that's inconsistent with what's emphatically listed in the release notes (including versions below or above 4.5.2) may cause unexpected issues to arise, such as the license validation problem that is being discussed in this thread.

     

    I didn't experience the license validation problem. I don't have any evidence to support that the reason I didn't experience the license validation problem being discussed in this thread was my strict adherence to the .NET framework requirement listed in the 6.10 release notes. However, it may not hurt to attempt to configure one's system to the precise specifications being mentioned. If nothing else, it removes the version of the .NET framework installed on one's system as a potential reason why your license validation problems are occurring.

     

    [sidenote: I attempted to update my forum profile to reflect my use of the v4.5+ framework, but the forum software reverted to the "unsure" option every time I attempted to save my change. I only mention this to disambiguate what I'm saying in this post with the .NET framework information that will appear on my profile at the time I'm posting this.]

  12. I'm genuinely grateful for HelloInsomnia's step-by-step suggestions regarding creating a backup directory prior to upgrading. (link: http://network.ubotstudio.com/forum/index.php/topic/22154-read-this-before-you-update/)

     

    This made it dramatically less challenging to completely remove 6.01 from my machine after experiencing Bug 1276, Bug 1272, and several others, and to remain with 5.9.55 for the time being.

     

    I'm convinced that the machines being used to develop and test 6.01 are different than my machine, and the machines of others.

     

    My rationale for saying this is that it's hard to imagine that 6.01 would have been pushed out had the development team experienced these bugs themselves.

     

    I'm sympathetic to the development team because software development is an incredibly challenging and unpredictable undertaking. This is especially true when there's so much variability with the respect to the machines that might ultimately run the software being developed.

     

    It's also totally understandable that some would feel the blood drain from their heads as they upgrade to 6.01 without a backup of 5.9.55 and discover that "nothing works" (which is a mischaracterization, but an understandable one given the frustration some have voiced.)

     

    Two bugs that seem unsolvable are Bug 1210 (circa April 2017) and Bug 1271 (circa September 2018). Both bug reports involve the 13 built-in FTP commands and 4 built-in FTP functions no longer working. These commands and functions are incredibly useful. There is a clumsy workaround involving the use of a batch file, but it's baffling that FTP would be inoperable for so long.

     

    That said, I'm 100% convinced that 6+ will eventually be a phenomenal leap forward. Updates genuinely *do* move UBot Studio forward, not backward. And in time, 6+ will move UBot Studio further forward.

     

    [Minor typographical edit.]

    • Like 6
  13. do they at least match all of exbrowsers abilities?

     

    I'm not sure that there necessarily has to be a feature-for-feature "match" with ExBrowser for the multi-browser functionality being announced to be useful.

     

    But as I alluded to previously, I'm cautiously optimistic that the multi-browser functionality described in the announcement will extend to apps/bots that are compiled with UBot Studio.

     

    To the extent this newly announced functionality is relegated to only being operational from within UBot Studio itself, and cannot be extended to compiled apps/bots, it leaves ExBrowser with a competitive advantage.

     

    I guess we'll find out soon enough, but does anyone already know if the multi-browser functionality will extend to compiled apps/bots?

  14. [...] I would prefer that all of that stuff was built in and standard with ubot.

     

    +1

     

    I'm cautiously optimistic that the functionality described in the announcement will extend to apps/bots that are compiled with UBot Studio. To the extent this newly announced functionality is relegated to only being operational from within UBot Studio itself, and cannot be extended to compiled apps/bots, it leaves ExBrowser with a competitive advantage as it relates to compiled apps/bots (reference link).

  15. bestmacros:

     

     

    It is not good for the new users also, because you need to buy Ubot license (not cheap) and also buy several must have plugins (not cheap) and all this just to be able to automate some websites.

    Thanks for clarifying. In the ideal scenario, it sounds like the optimal outcome would be a UBot Studio that can automate all major popular websites (defined as perhaps the top 50 traffic-getting websites in the world), right out-of-the-box. No need for special plugins or third-party accessories.

     

    You had previously mentioned ..."naked out-of-the box ubot is not usable on most popular websites because of internal browser"... which got me thinking. I'm very much still a UBot "newbie" in the sense that I don't know everything about the tool. If, for example, the UBot internal browser (currently Chrome 49 at the time I'm writing this, if I'm not mistaken), were updated to Chrome 67 (which happens to currently be the so-called 'stable' release), would that solve the problem?

     

    If so, I wonder if an immediate work-around would be to use the 'set header' command to essentially spoof the user agent? For example:

     

    navigate("http://www.ipchicken.com","Wait") 
    comment("This will mention Chrome 49 in the 'browser' portion of the website.")
    wait(5)
    set header("User-Agent","Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36")
    navigate("http://www.ipchicken.com","Wait")
    comment("Now the 'browser' section mentions Chrome 67.")
    
    You had also previously mentioned ..."http request automation using build-in commands is also problematic - you need external plugins for that"... which I have to admit, I don't have the technical understanding to comprehend. Help me understand what that means, if you wouldn't mind. I just want to better understand some of this terminology. Or better yet, what UBot plugin solves this problem? I can then read more about the problem and the solution on the plugin website.

     

    . . .

     

    More broadly speaking, I find myself increasingly using UBot Studio as a versatile general purpose programming language with the ability to create standalone EXE files.

  16. Hi!

     

    whoami:

    Is UBot dying?

     

    I'm cautiously optimistic UBot isn't dying. I genuinely like the tool, and what can be done with it. The challenge with software that conditions usage on username and password credentials being verified on an external server is that if the software vendor goes out of business or pulls the plug on the project, the availability of the external server can become jeopardized. To the extent the external server is offline and can no longer provide credential validation (or compilation services, as in the case for developer edition license holders), the entire ecosystem that has evolved around the tool will evaporate rather quickly. The same is true for this forum.

     

    bestmacros:

    ubot nowadays is little bit outdated, so I guess not many new users are joining

    What would be considered a more up-to-date tool that new users might be choosing to use instead of UBot? (I'm mainly asking to get a better understanding of what tool you're referring to.)

  17. Hi uBotters!

    Updating this thread seemed liked the "right thing" to do given it's practically the ONLY thread that comes up in Google when someone searches for more information after seeing something like this when they try to load a compiled bot:


    http://content.screencast.com/users/datapile/folders/Snagit/media/df8538b4-d5b6-4529-a920-ca050b678f7f/09.30.2014-13.55.png

    The user "gabel" mentions:
     

    you could put the files in an installer and when that's ran it will automatically add those so the end user won't have to download anything

    As of uBotStudio v5+ it appears there is a built-in installer (at least for the developer edition) wherein all the necessary support files can be included.

    Here's a link with more information:

    http://wiki.ubotstudio.com/wiki/Compiling_in_the_Developer_Edition


    (Scroll all the way down on the aforementioned link/page, and pay special attention to the "AppData" portion of the instructions.)
     

    ===

    EDIT: The specific folder cited in the Wiki page appears to relate to uBotStudio v5.0.4 (at least as of the time this post is being made) ... try loading this directory first (see below) and then click into whatever the most up-to-date uBotStudio directory you have (which appears to be in the form of a version number):

     

    C:\Users\YOUR-WINDOWS-USERNAME-HERE\AppData\Roaming\UBot Studio\Browser\

     

    Mine looks like this (at the time this post is being made):

     

    C:\Users\thnksrvr\AppData\Roaming\UBot Studio\Browser\5.0.13

    ===

    To the extent your "AppData" folder appears to be inaccessible, here is a quick YouTube tutorial randomly discovered on the 'net that demonstrates how to make that folder accessible:

    https://www.youtube.com/watch?v=RoSWTDoWldI

    Hopefully this provides a useful path forward for anyone who stumbles upon this thread who is attempting to resolve the issue(s) posed by the "Please wait while we download the necessary support files" message, and/or the slightly ominous "The remote name could not be resolved: 'www.ubotstudio.com' message!

     

    Kind regards,

    Stephen

×
×
  • Create New...