Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by chain
  1. chain


    Version 1.0.0


    International Weather script for Eggdrop, Based on Lilys Simple Weather. Users can now set/save multiple weather locations! Script does the current weather conditions, a 1 to 7 day forecast, world time, and more from the www.apixu.com API page. Displays in both F/C and MPH/KPH.
  2. SEGA announced its very own mini console - the Mega Drive Mini - at FES 2018 to celebrate the 30th anniversary of the original console. After being delayed in September last year, the classic console is finally back on track and is set to be released on September 19 this year according to an announcement made by SEGA on Twitter earlier today. The Mega Drive Mini will be sold under the name Genesis Mini in certain regions, similar to the original console which was known as Genesis in some countries and Mega Drive in others. SEGA has yet to reveal what the console will be called in different regions.
  3. chain

    Updating Multi_Conn

    still working on it Top I will let you know when its ready for release
  4. chain

    Updating Multi_Conn

    I have done a few tune ups to Multi_Conn next is the dialogs ive been playing with them & hopefully Nicklist.
  5. Over the last few weeks, there have been lots of leaks around Microsoft's new Chromium-based Edge browser. First, we reported on screenshots that were leaked, then there were support documents, an extensions page, and even an installer that didn't work. But now, the full browser has leaked for anyone to try out. Spotted by Aggiornamenti Lumia, the PCBeta forum has a link to a ZIP file with the browser. If you run the Setup.exe file that's included, the browser will install. Naturally, we've installed it, and we'll have a hands-on video later on today. The browsing experience is exactly the same as in Chrome, but with a layer of Microsoft on top of it. You can choose to install extensions from either the Microsoft Store or the Google Store, and you'll want to sign in with your Microsoft account. Note that if you install this app, you're doing it at your own risk. Obviously, it's coming from a third-party, so you should always be skeptical of executable files from untrusted sources. There are still bits of Edge that are missing, such as the ability to write on webpages. Clearly, this isn't done, and Microsoft still has a long way to do. A public preview should be coming soon though.
  6. Microsoft has released a new Insider extension for the Edge Chromium browser that anyone can install from the app store using the leaked Chromium-based version of the browser that became available over the weekend. The extension appears to be a way for Microsoft to remotely set tasks for Insiders to try out known issues or other features that the company wants to test. The store page states that the extension is available to Insider build channels "canary", "dev", and "beta" only, which at least confirms it will have a similar development roadmap to Google's Chrome browser, of which anyone can opt in or out of each channel. The extension even installs on the 'old Edge', although doing that won't display the current version number, allow you to change channel, or obviously test any of the tasks that appear within it in relation to the Chromium version. It's possible that a future version of the extension will be blocked from installing in the older version of Edge, but that's just a reasoned guess. For those that haven't checked out Edgium Chrodge Edge on Chromium, you can get the download link here, or check out our hands-on video. Although Microsoft has not yet commented when the browser will become widely available, the leaks and Insider extension seem to suggest it isn't far off.
  7. A graphical pacman game online for mIRC. https://gitlab.com/Ouims/Pacman
  8. chain

    Tat\'s Trivia Bot

    Added WPM questions.WPM*HoTMaiLWPM*The quick brown fox jumps over the lazy dogWPM*What a todo to die today at a minute or two to twoWPM*The world beyond the stars is full of stumps.WPM*The night is long and full of terrorsWPM*Winter is comingWhat is the chemical symbol for gold=*AuFixed /ask command. It was wonky and I never realized till I tried to use it to test /ask WPM: This is a test of the trivia bot.The added = formatting indicates that it should use exact mode. Which uses neither fix nor case insensitivity. This is also used for WPM questions Where failing to capitalize the letters results in a fail.Added /openquestions as a secret command that opens the question file. https://www.mediafire.com/?lf27b3zy29idj
  9. Part 1 - Preface Before I start, I would like to explain the purpose of this tutorial. This tutorial will deal with destructive floods targetted at channels and ways to detect and/or stop them. I specifically will not deal with what I refer to as "annoyance" kicks such as swearing, repeating (not in excess - repeating will earn bans with my methods anyway unless you specifically prevent it), color abuse, etc. My goals are accuracy and speed - I want to react to valid threats as rapidly as possible, and to avoid kicking users who are not valid threats. A valid threat constitutes a flood that has the potential to disrupt a channel by disconnecting users or otherwise making the channel unusable (due to lots of text, etc). I want to teach you how to make a flood protection script that does its job, and does it well. I will not directly address personal flood protection, although it can be handled in a similar fashion. Bear in mind that bots that are used for user-access (i.e. op ops, keep bans, etc) must of necessity 'listen' to incoming privmsg or notice commands -- the best thing for a channel flood protection bot, however, is to run with SILENCE +!@* thus avoiding personal floods altogether. The /ignore command will not keep you from being disconnected with private messages/notices/etc. SILENCE, however, stops text on the server before it's even sent to you. That all said, the rest of the tutorial will be in two main sections -- the first will describe two types of floods and explain why they work, and the second will discuss my own ideas about how to detect and deal with them. I will also discuss some IRC concepts that affect this subject (mostly to the detriment of effective flood protection =/) so familiarity with the IRC protocol is useful. Lastly, the majority of my experience is with the DALnet network and Bahamut IRCD. Please inform me of any differences, changes, or incorrect statements I make concerning other IRCDs (or even Bahamut for that matter). Part 2 - Floods: How They Work There are two main ways to cause a user to be disconnected from IRC. Trojans and backdoors aside, one of these involves exploiting script triggers and their responses, and the other is based on brute force -- large amounts of data at high speed. The former method is easiest to exploit but, with the exception of 'standard' triggers such as !list, requires that the attacker know more about the target than the latter. *** User has quit IRC (Excess Flood) This message is caused when a client sends so much data to the server that the server disconnects the client. There are some things to know about how this works that also pertain to limits on what flooders themselves can do. On an IRC server, there is a Send Queue and a Receive Queue for each client. The Send Queue (or SendQ) is used to store data that is waiting to be sent from the server to the client. The Receive Queue (RecvQ) is used to hold data that was received from the client for processing. Excess Flood is caused when the Receive Queue is full and the server reads data from the client. There are a few things that govern the way the Receive Queue works. When the IRC server reads data from the client, the data goes into the RecvQ. The server will process the data a line at a time as commands. The server also keeps a variable associated with each client. This variable (dubbed 'since') will be less than or equal to the server's current time value while the client is idle. Each time the server reads and processes a command line from the RecvQ, it increments this value by 2 seconds. If the line is particularly long, the variable is also increased by $int($calc($len($1-) / 120)), where $1- is the line that was read. This is to say, for each multiple of 120 the length of the line is, an additional 1 second is added to the 'since' variable. When the server reads a command from your RecvQ, it skips processing that command if the 'since' variable is more than 10 seconds ahead of the current time. In simpler terms, if you pasted 10 lines to a channel, 5 of them would show to everyone right away, and the other 5 would come through every two seconds or so. Also, I'd like to note briefly that upon connecting to an IRC server (or at least a Bahamut one) you already have a few seconds against you -- where you might be able to fire off 5 commands instantly after being idle, immediately after connecting you can only send 3 or 4. This helps to limit what automatic flooders can do, and is worth keeping in mind. Additionally, some specific commands increase the 'since' value, though this may depend on the IRCD. So. If you send stuff too fast (or too long, or both), it doesn't 'go through' right away. This means that your Receive Queue fills up FAST, since it isn't being emptied. If you have a script with a trigger (such as !list in some poorly written file servers) that doesn't have any form of flood protection, you are an easy target. All someone has to do is send !list a bunch of times to a channel you are in, and your script sends plenty of nice long notice lines in return -- to users who probably aren't even online anymore -- thus filling up its RecvQ. What happens when your RecvQ is full? You quit IRC with the message: Excess Flood. *** User has quit IRC (SendQ Exceeded) This is the harder of the two flood types to achieve. Your Send Queue works like your Receive Queue without the extra flood code written in. The server has a queue of data it is waiting to send you, and when it fills up, you get disconnected. Having a fast connection helps avoid this, but you could have an OC3 and still be vulnerable. Your download speed isn't the only factor -- the IRC server's send speed is too. And the IRC server has a whole lot more to do than you do. The IRC server has to loop through all its clients' Send Queues. It sends one line per client, then moves on. As well, server connections take precedence and are sent all the data in their queue regardless of how many lines. So, a server with lots of clients can't always keep up -- either in processing time or in upload speed (although servers generally have plenty of both). In addition, if a channel is being flooded, the server has to send all the data that is coming through to all the clients on each channel, not just one person. Therefore, it's not as hard as you might think to flood a user, or a channel, off IRC this way. One thing that gives a flooder a major leg up in this type of attack is control codes. Control codes alone won't do the trick, but control codes applied to text will -- you are probably familiar with the 'screen lag' that can be generated by gobs of bold characters alternated with text. If not, try this sometime in mIRC: //var %t = $ticks + 4000 | while (%t > $ticks) { echo -a $str($+($chr(2),$chr(35)),400) | dec %i } Likely you'll notice how the text display becomes noticeably slower. While mIRC is spending CPU time updating your screen, it's spending less time reading from the socket. This only helps your SendQ to fill up faster. What happens when your SendQ is full? You quit IRC with the message: SendQ Exceeded. You may have seen prefab combination floods, which use preset triggers in combination with long lines and control codes, like this: <lamer13245> !list File Servers Online Ping Me flo0dflo0dflo0dflo0d... These tend to work well versus poorly coded scripts that reply to any or all of the triggers, and with enough clones or enough time running rampant through the channel will disconnect people for SendQ as well. One of the worst things is that often flood protection scripts, when faced with a large enough flood, will Excess Flood sending MODE commands (bans, channel locks..)! I've seen this happen in some well-known and recommended scripts, so don't think you're safe just because someone popular wrote the one you use Anyhow, that about sums up this section... on to the next! Part 2.5 - Keeping Your Bot Online I know I said I wasn't going to talk about personal protection. I lied, a little Your bot/script doesn't do anyone any good if it is offline or deopped. I'll leave it to you to code things to get it opped and in the right channels. I will offer some suggestions on keeping it online. If your server offers SILENCE, use it. Silence !@* if you can, or !@* if you need to "hear" notices from say, ChanServ. Dalnet offers usermode +R, use it. Remember, /ignore doesn't help -- the most it can do is keep mIRC from spending CPU time updating your screen, but you are still going to be sent the data. Blocking data at the server, before it gets sent, is very useful for avoiding private floods. Get a bounce on a shell with lots of bandwidth, and one that will DO something if somebody tries to "packet" you. ("Packeting" = Denial of Service or Distributed Denial of Service attacks that consume large amounts of bandwidth -- often via botnets, attacks such as smurf or bang, or both.) If a flooder can't get your channel because your script prevents them from getting a satisfying flood in, he may try to "packet" your script/bot offline in order to flood the channel. Use some sort of buffering/queueing on ANY command that is triggered by user action. This includes bans from floods as well as !list or !op style triggers, it also includes CTCPs if the IRC server you use has no built in CTCP flood protection. Prioritized queues are best -- you want to be able to force channel locks to be sent before bans, bans before kicks, kicks before anything "non-essential". Somewhat along the lines of the previous paragraph, use MODE queues to combine modes. Send six bans with each command, not one. You have room for four bans along with a channel lock such as +mi, but don't "wait around" to get four hosts to ban. Also, regarding mode locks -- make absolutely sure that your script does not send say, five MODE commands full of bans and THEN try to lock. That's an extra 2 seconds you may not have. The best case scenario is for your script to lock the channel before setting any bans (if you decide to use bans?) at all. Don't unlock the channel until everything else has been taken care of and you've had a chance to return to "idle" state. If a botnet is still going strong trying to flood you, you had better be ready to take another flood the moment your channel becomes unlocked. Along these lines, coordinate with other ops so that nobody's scripts conflict with each other -- someone unsetting a +i lock while your script is still in the middle of setting bans can be bad news for all of you. Strip codes from incoming text anywhere, at least when there are lots of them -- don't use themes that use gobs of codes. Keep in mind that ctrl-k (color) does almost no damage. In order of seriousness, the control codes go about like this: bold, underline, reverse, color, reset. Bold and Underline are the critical ones, don't let your script display text containing lots of these. Keep to a minimum number of channels. Each extra channel your script or bot is in gives a flooder another advantage over you. They can flood all your channels at once without much performance decrease, but you can't protect all of those channels as easily. These are some things to keep in mind while designing your flood protection script. I thought I'd get them out of the way before I get into the guts of this tutorial so that they are already in mind when we come across places some of these ideas could be used. Part 3 - Reaction Reaction time is everything. Reaction depends on how well you can detect floods and discriminate between floods and regular channel text. What I'm going to teach you here is aimed to increase reaction times and maintain the ability to discriminate. There are two things you are likely to see with floods. There is the single-host flood, where a single client (often with a couple clones on the same host) joins your channel and floods. It may or may not disconnect and repeat... if it doesn't disconnect, it will be even more ineffective of a flood than it already is This type of flood only really has a hope of causing someone to Excess Flood via trigger abuse, and is easy enough to catch. Your script should not cause a channel lock for this type of flood, all it needs to do is ban the flooder. On some networks, there is a feature called "bquiet" which will make a banned user unable to talk on the channel. This is useful... if your server doesn't have this, you will want to arrange a swift kick for the offender and any clones. Speaking of kicks, for the most part you can delay your kicks until well after everything else is taken care of. Almost any automated flood will cause the flooding users to leave or quit repeatedly, and a ban in place will keep them from coming back (except in some instances with lag involved -- more later). Having a separate bot set to filter-kick users on bans is an excellent setup. If a flood isn't generated from a single host with a script, it is likely a botnet or proxy flood. These can have large numbers of clones and need to be dealt with very rapidly. Bots in a botnet can be used for proxies, but there are also lists of various types of proxies all over the web. Proxy floods offer the flooder more control, but he needs to know what he is doing to make them effective. Botnet floods are often automated, which makes the impact less as the bots tend not to all begin their flood (or maintain it) at the same time / speed. With these things in mind, my preferred action is to set a single ban on single-host floods, but to lock the channel if two or more hosts are involved. The channel lock should be sent before any bans that have been accumulated -- reaction time, as I've said, is critical. I try to always be on servers with low lag to my client. 200ms is decent, but I prefer 100 or less. In flood circumstances, the server has a LOT to do, therefore even if I were to send the command MODE #chan +mi the INSTANT the first clone joined, it could take much more than 200ms for the command to be enacted. Here is a real-world example from a log from an older version of my bot: (09:36.28) 0 *** Channel being locked!! (09:36.33) 0 *** ComputerEyes sets mode: +mi It took five seconds from the time my bot sent the MODE command until the mode change was enacted. The bot's lag to the server was about 400ms at the time. In that time, a total of 93 bots joined and flooded the channel. To put this in perspective -- my bot sent the MODE lock after the 4th line of flood text. (Reaction times were improved later The bot set two bans before the mode lock -- one flood bot flooded way before the others and was banned singly. Hopefully these kinds of circumstances are rare, but when you are imagining the scope of things, keep in mind that any decent botnet has well more than enough bots to fill your channel's ban list and still flood you pretty hard with the ones you can't ban. I've seen lists of 200-300 connectable proxies on Dalnet, although Dalnet now scans all the common proxy ports, and I've seen or heard of botnets with populations in the thousands. And of course, botnets can be used as undetectable proxies. Now, most people won't ever have to deal with floods of this magnitude, and the largest botnets are often used for "packeting" rather than flooding, but the same principles that I am about to outline apply for 50 bots or 5000. Part 3.1 -- Detection and Discrimination How is all that for preliminary rambling? Now we get into the good stuff! By now you should have an idea of: how floods do damage, some ways you can protect yourself, and why reaction time is important. Now I'm going to go into how you can protect others too. How do you go about discriminating between valid text and "dangerous" text? You look at characteristics. The only way for a flood not to be caught is to imitate "regular" text to such a degree that it no longer becomes "dangerous" to users. This more or less defeats the purpose of flooding, except to preserve it as an annoyance. Annoyances are easy to deal with manually or with other scripts -- mass floods more or less require script intervention. "Regular text" in social channels generally is short, relatively free of codes, not often repeated (except sometimes with things like 'lol') between multiple people, and generally has reasonable delays between typed lines. People do not often speak immediately after joining a channel. "Regular text" in some other channels, such as file serving channels, may have text repeated at long intervals, contain long lines and lots of colors, but relatively few other codes, many lines will be similar but not identical. Most scripts do not advertise immediately upon joining, but some will. Some people will also have more than one script responding. (I've seen file servers advertise twice, I let them get banned rather than change thresholds to suit users who can't even get their own script under control.) I've also seen fileserver ad floods, so don't be too lenient on these guys. "Flooder text", in the context of this document, generally follow a very similar pattern: a flood host will join the channel, immediately send its flood text (often 1-3 lines, usually 2), and then part, quit, or close the socket (generating a quit). Flood text can be sent in privmsg, notice, ctcp, etc. There are various ways to optimize the result of this phase, and I will deliberately avoid going into them; I don't believe the small benefit of this knowledge would help enough to justify making it easily publicly available. Notable differences: flood text will usually begin immediately after joins, will be repeated many many times between multiple hosts, and will often evidence many other tipoffs, such as large control code content, long text length, multiple triggers (sometimes), and repeated text within the string (flo0dflo0dflo0d). I have some code that will check for the last, which I will include near the end of this tutorial. I do not advocate punishing a user for any one of these things alone, but all of them combined will almost guarantee you a flooder. Some exceptions to watch out for include file server triggers and many scripts which seem to like to advertise themselves immediately upon joining a channel with plenty of color codes and whatnot (I'm using Al-Hasif Script). Flood text CAN be short, such as that in CTCP floods. While I'm on the topic of CTCP floods, I'd like to point something out in the versions.txt file for mIRC 6.0. Previous to mIRC 6.0, some problems were evident in mIRC (which I discovered, and know of at least one other person who has as well). 187.$chan is now filled for the on ctcpreply event if it was a channel ctcp message. The on ctcpreply event did not fill the $chan identifier. Although CTCP replies never have a good reason to be sent to a channel, one of the prime sources for exploits and other malicious things comes from assumptions in programming. No mIRC script could properly respond to a user CTCP Reply flooding a channel because none of them would associate the flood with the channel. $target was the giveaway but I don't know of anybody who made use of it. 188.Ctcp messages that use an invalid format are now treated as plain text, and will trigger script events. Before mIRC 6.0, there were also ways of misformating CTCP messages so that mIRC did not display them at all, and therefore could not react to them either. Both of these problems are now fixed, and I recommend that you use mIRC 6.0 at least to avoid being vulnerable because of either of these things. In addition, any script you write should have flood protection on every single event that generates a response from your script due to outside user input, especially if there's no reason for anyone to provide said input. Many, many scripts are vulnerable to CTCP reply floods, especially CTCP PING reply floods, because of autopingers. I can't remember the last time I saw a well-written autopinger, and they all blithely reply with a wonderfully long notice to a very short command. Autopings are one of the easiest triggers to exploit with the exception of !list. Be sure to write in CTCP Reply flood protection towards channels and users just as you might write in "regular" text flood protection. CTCP Replies are no different than any other text. Part 3.2 - Where's the Code? Rather than present you with my (admittedly ugly) bot code, I am going to instead describe exactly how it works, with code samples that hopefully don't look too much like an alien language. The first generation of my flood protection bot, ComputerEyes, was pretty much a test of a concept. I wanted to see if my ideas regarding flood detection were any good. So, it started out small, clean, and simple -- and it worked great. I wrote two things: A JOIN flood detector A repeat flood detector I made use of the inc -z command all over the place, and pestered Khaled to add an hinc so that I could clean up the ugly variables and $+'s. inc -z increases a variable, and tells mIRC to decrease that variable once every second until it reaches zero, then unset that variable. I'm going to go ahead and recreate the basic form of my bot here: on @*:join:%protect_chans:{ inc -z %protect.j. $+ $chan $+ . $+ $site 7 if (%protect.j. [ $+ [ $chan ] $+ . $+ [ $site ] ] > 13) kickban $chan $nick } ctcp *:*:#:{ haltdef protect_check $1- } on *:text:*:%protect_chans:{ haltdef if ($me !isop $chan) return protect_check $1- } on *:notice:*:%protect_chans:{ haltdef if ($me !isop $chan) || (. isin $nick) || (($network == dalnet) && (ChanServ == $nick)) return protect_check $1- } on *:action:*:%protect_chans:{ haltdef if ($me !isop $chan) return protect_check $1- } ;call this alias for text in PART and QUIT messages too alias protect_check { ;so chan staff doesn't get mad at me for kickbanning them :) if ($nick isop %c) || ($nick isvo %c) return ;i use a hash of the text to find repeats -- strip the text of codes, ;make it all lowercase, and truncate to 400 chars; this helps to ensure ;that cosmetic variations in flood lines are minimized. var %h = $hash($lower($strip($left($1-,400))),32) ;keeps the repeat variable from getting ridiculously high as it is wont in large floods ;the cap on this value will play a useful role in the more "complicated" version of my ;script -- as it decreases once per second, the higher it is allowed to get, the longer ;it is before saying text that generates this same "fingerprint" will be safe, i.e. not ;cause a ban. ;lastly, this variable stores global repeats -- anybody saying this text will inrease it if (%protect.r. [ $+ [ $chan ] $+ . $+ [ %h ] ] < 70) inc -z %protect.r. $+ $chan $+ . $+ %h 2 ;now for the client-specific flood variable ;first, we increase it by the global repeat value (which gets bigger with each repeat) inc -z %protect.r. $+ $chan $+ . $+ $site $+ . $+ %h %protect.r. [ $+ [ $chan ] $+ . $+ [ %h ] ] ;also, we increase it by the client-specific join-flood value -- if the client just joined ;it will take a big hit to its flood numbers: inc -z %protect.r. $+ $chan $+ . $+ $site $+ . $+ %h %protect.j. [ $+ [ $chan ] $+ . $+ [ $site ] ] ;there are other factors i ended up adding here; they will be discussed later but i'm ;leaving them out of the code ;client specific flood value too high? get rid of them! if (%protect.r. [ $+ [ $chan ] $+ . $+ [ $site ] $+ . $+ [ %h ] ] > 19) kickban $chan $nick ;pseudo-code to follow: ;if (lock condition) && (lock variable unset) { lock channel | set lock variable } ;i won't go into this because then i'd have to also write in my ban and kick queues, channel ;flood value stuff, and more } The preceding code may or may not work, it's taken from my bot and drastically simplified. I do not remember why I used an if line rather than on @*:text:etc, so don't ask me about it It's just there to give you an idea of what's going on. I had an alias to do the job of inc -z and the [ $+ ] stuff, but found it more cryptic to read than just writing out the code itself. Okay, what is all that garbage!? Basically, I keep a few variables for things. These variables are constantly shrinking automatically, so over time they will empty themselves. But, when things keep happening that increase them, they are eventually pushed over a threshold. When this happens, the script reacts. For example, in the JOIN flood code, the threshold is 13. Each time a user joins, the variable associated with joins for a given $site value is increased by 7. Two joins within less than a second will cause the value to pass the threshold. Three joins within 7 seconds will do the same, as will four joins in 14 seconds, etc. The join value directly affects the flood value of a line of text. Each time text with a certain hash is said, the corresponding channel variable is increased. This indirectly affects the flood value of a line of text. Continuing to repeat a certain text phrase (more often than once every two seconds) will cause a client's flood value to rise exponentially. Text within 7 seconds of a join also takes a minor to major hit, depending on how soon after it was said. When a client's flood repeat value is over the threshold, that client is kickbanned. Any other clients saying the same text will also be kickbanned in short order. In the actual bot I have, I make protect_check take a channel as a parameter. This is so that I can call it from the on quit event for text in quit messages. I also call it from on part. I modified that in the example code to help improve its already dubious clarity Because this script has evolved far from its starting point, the basis of the code that controls when a channel is locked is in the ban queue code. Using a similar inc -z method, I keep a value for the number of bans queued in a channel. When the number of bans becomes large enough, the channel is locked. I keep a variable set after sending a channel lock so that my bot does not attempt to send the lock more than once. When certain modes (in this case, +i) are unset, the variable is too. What are these complexities you speak of? Well, in addition to increasing the client flood value based on channel repeats and the join value, I added in the following factors: Text length Repeated text content (Left-to-right) Repeated text content (Right-to-left) Control codes Any of these can affect the increase of the client flood value by a limited number. The maximum increase varies per item, and would make a nice option if it was adjustable. At the moment, the only way to adjust my bot's settings, however, is to edit the code. Text length is fairly straightforward, depending on how much weight you want that to carry, an easy formula to use is $int($calc($len(text) / N)). I used N = 100, so 450 characters would make for an increase of 4. Repeated text content refers to things such as 'flo0dflo0dflo0d'. That string would contain 3 repeats from either direction. Right-to-left is the most important, because of floods that include text triggers and such at the start, but then have repeated text afterwards. I added the Left-to-right checking upon seeing a flood that did this in reverse. This is the code I used to check for that: alias rchk { var %t = $strip($1-), %a = $right(%t,1), %i = $calc($len(%t) - 2), %b while (%i) { if ($mid(%t,%i,1) == %a) goto rc2 | dec %i } return 0 :rc2 | inc %i | %b = $mid(%t,%i) | return $pos(%t,%b,0) } The copy of mIRC running my bot does not strip control codes automatically. I use custom echos in a sort of "theme" to include debug information, and to allow my script the ability to count how many and what kind of control codes are present, rather than have mIRC strip them out before I get a chance to see. The identifier I made to return a value for control code content is somewhat abstract: alias cchk return $int($calc((1 - $len($strip($1-,bur)) / $len($1-)) * $len($strip($1-)) / 2)) I hardly remember why I did that anymore, but it appears to take into account both the percentage of the text containing codes and the length of that text without codes. Keep in mind that control codes are useless if they have no text to apply themselves to. There are other planned additions that I never got around to, these include $site blacklists for repeat offenders (especially useful to keep track of hosts that are involved in mass floods, can lead to an early channel lockdown) and a text blacklist, where the hash of a certain text string that is used in separate floods leads to more likely bans or channel locks. You'd have to be careful with that last, anyone who understood how it worked could flood with things like 'lol' and cause undesired results. Hopefully all of that isn't too hard to understand. Please leave me feedback and suggestions on how to make it more easily accessible -- which parts to change, leave out, explanations to add, etc. Part 3.3 - How to React What you do about what you see is important too. Obviously you want to ban offenders and lock the channel when necessary. But often people don't put enough thought into even simple things like this. As I said before, I recommend locking if you have to ban more than one client for the same flood, and don't send more than one or two MODE lines before you do so, if you're going to. If you're not sure, wait a little and see. Appropriate mode locks -- Dalnet has modes +M and +R. +M allows only registered and identified users to talk on the channel, and +R allows only registered and identified users to join the channel. I do not recommend using either of these. As I mentioned earlier, assumptions lead to exploitability: you don't see any registered-nick floods now, but what's to say there can't be any? I can see no reason to assume that. In my opinion, nothing can beat +mi. Nobody talks, nobody joins. Simple and effective. Your users aren't going to be talking much in the middle of a flood anyway, so they aren't losing much. Now, I'd like to address something here that I haven't yet, and that is network lag. Some flooders will purposefully choose to connect their bots to laggy servers -- or even chose a server and attack it with DoS or DDoS attacks to make it laggy -- so that their floods are more effective. Here's what happens. When you set mode +mi, it takes effect on your server (the sooner the better), but it also has to send the MODE command out to the other servers, so that it is the same everywhere. This doesn't always happen instantly, to my great annoyance, and the result is that flooding hosts can still join and part the channel, even after the modes +mi have been set. This is because the +i mode hasn't made its way to the server the flood bots are connected to. I can think of no easy way around this except to make sure your protection bot is located near the center of the network, or to locate more than one bot on different servers at opposing servers. Although the local server cannot deny JOIN commands issued from other servers, it CAN refuse to broadcast PRIVMSG and NOTICE commands. This means that the +m will keep the flooders silent, at least on any servers which the mode lock has propagated to so far. What does this mean? Mode +m is important. It should remain until flood bots are no longer joining your channel. After this happens, it is ok to remove the +m mode so that users already in the channel can talk, however it is usually a good idea to leave the channel +i for a while. How long is up to you, I recommend making it at least 10 seconds after finishing all other commands (such as bans and/or kicks). I use a progression whereby the channel mode goes like this: +mi -m +R-i -R What you use is up to you, but don't make any assumptions I considered writing a script to find common masks between multiple hosts (for bots with nicks that all contain a certain word or phrase), but decided it wasn't worth it. It is, however an available option. Combining modes -- this is important for your bot. Do you want to ban every user in a large flood? If so, you're going to want to be setting 6 bans per MODE command or it will take a long time. $modespl in mIRC will tell you how many modes you can set per line, if the server provides that information. It occurs to me that banning hosts only serves to slow the largest floods, but it's probably worth it anyway. Small floods will be entirely blocked, large ones will at least not be able to join their strongest/fastest flood bots. My own bot did not bother unsetting its own bans - it relied on ops or other bots to do that job. That decision is up to you. An eggdrop bot that filter-kicked bans and unset bans after a time, as well as does user access and is configured to op the flood protection bot on join would make a nice complimentary combination with the kind of bot I'm describing. I won't give you any code for command queuing and combining modes -- this tutorial is long enough already. In addition, the code I've been using is lacking and I have a better system in mind but incomplete. Sorted @windows would probably be a good resource, with the first token being a number to affect priority. Part 4 - 'Lines per Second' Rant I have a very low opinion of this method of 'flood protection'. Even when written correctly, it is generally configured incorrectly, and it's the users who suffer. Some of the ops don't even care. Partly, this is because people lose sight of the goal. What is a flood? Is it three lines in five seconds? No. That's not even an annoyance, unless the text is really obnoxious. Is it pasting text from somewhere else? No. That can be an annoyance with enough data, but there's an easy fix - kick them once, and they won't rejoin until they are done pasting. All the PRIVMSG commands have to go through before the JOIN does. 4 lines within 1 second should be sufficient to detect this, and it's one of the few uses I can think of for this method. So you have a script you like, and it uses lines per second to detect floods. How do you configure it? A high number of lines in a low number of seconds. Why would you ever want the number of lines to be LESS than the alotted time? Is someone typing rapidly going to cause people to be disconnected? Is it doing any damage to your channel? Probably not. Is a real flood going to be so slow that you have to configure your settings like that? Probably not. Keeping in mind what I said about how many commands you can send before the server stops you, 2-3 lines in 1 second is likely to be a good setup. Flooders aren't going to wait a second per line. Unfortunately you can't factor joins, parts, or quits into this equation. For a flood worthy of locking the channel, I'd say that 10 lines in 2-3 seconds is sufficient. If your channel has a lot of stuff going on, that may need adjusting, but the important thing is many lines, few seconds. Heavy floods can easily achieve that. The more lines you use, the longer before your script reacts, so the higher the number, the more accuracy, and the slower the response. If you've got it the other way around, do some thinking. Part 5 - Summary Hopefully I've managed to impart to you through the course of this document an understanding of how and why floods work, the knowledge that there are better ways to do flood protection than simply "lines per second", some ideas on how you can discriminate between real users and flood clones. I hope that you will use this as a stepping stone, and put a little effort into making a script that is above par. Realize that flood protection isn't the only thing you can do this with.
  10. chain

    nScreenShot 1.0

    Version 1.0.0


    Χ Screenshot This command takes a simple screenshot of your computer and saves it to your computer. USE: $dll(path\nScreenShot.dll,Screenshot,<path_to_file>) EXAMPLE: //echo -a $dll(path\nScreenShot.dll,Screenshot,c:\mirc\screenshot.jpg) Χ Convert This function converts an image from one file to another. USE: $dll(path\nScreenShot.dll,Convert,<path_to_input_file>?<path_to_output_file>) EXAMPLE: //echo -a $dll(path\nScreenShot.dll,Screenshot,c:\mirc\screenshot.jpg?c:\mirc\screenshot.png) ========================== Notes ========================== The return values will either be S_OK or E_* where * is descriptive of the error. Supported formats, the R column is read, and the W column is write: RW Extention xx .tiff xx .jpg xx .bmp xx .png xx .tga x- .wbmp x- .pbm x- .ppm x- .pgm x- .pcx x- .ico x- .mng x- .psd x- .jng x- .koa x- .pcd x- .ras x- .cut x- .iff x- .lbm NOTE: alternate extentions work as well.. like jpeg and jpg. .pbm .ppm .pgm and .wbmp are supported by the lib to
  11. Don't you just hate them when you give 'em voice, and then you receive automsg.. this one kikcks their asses :D
  12. Ho ho ho... ever seen one of these ?? Well, if you are able to unban yourself from that chan, (meaning that you have access there) just paste this baby in your remotes... Usage : auto
  13. Snippet that simply repeats last X lines (the name is quite self explanatory, isn't it ?) of conversation in active window/to target. Usage : /last <X> [target] <X> represents number of lines that you want to repeat. [target] (optional) if you enter target, then last X lines from active window will be sent to target. If not, they will be repeated to $active window.
  14. Weekend PC Game Deals is where the hottest gaming deals are amassed into an easy to follow format, every week, from all over the internet. So kick back, relax, and hold on to your wallets. Another two weeks have gone past since Epic Games Store's last giveaway and while taking a break from all the exclusive grabs, it has had a new game jump into its freebie slot. Night School Studio's supernatural adventure game Oxenfree can now be added to your Epic Store library for free. The 2.5D title will be free on the store until April 4, and the next two-week giveaway to begin on that day is for the puzzle game The Witness. Humble Store has also jumped in on the action this weekend by offering up a freebie of its own. You can now grab a copy of the exploration title Tacoma for free. This is a DRM-free giveaway though, so there isn't a Steam key or anything of the sort attached to it. You can download the game through a direct link or via a torrent. This giveaway doesn't have that long to go, however, with it only available until 10am PT tomorrow, March 22. Free Events If you're into turn-based strategy games, then XCOM 2's new free weekend is not something you want to miss out on. The Firaxis-developed title has you rebuilding XCOM and going up against the Earth occupying alien forces again with plenty of new opportunities to miss 99% chance to hit shots. Meanwhile, City building fans also have something to try out, with Paradox's Cities: Skylines having a free weekend for its base game. Be sure to try out some of the mods available as well, which can add in quite a bit to the game. Big DealsUbisoft is still going strong in its franchise sales, which have now spread onto even more stores, including Steam. Fanatical spring sale code FANATICAL10 is still applicable on the store's wares as well, bringing down prices by a further 10%. Here's our list of this weekend's big deals for your perusing: Call of Cthulhu – $30.14 on SteamDestiny 2: Forsaken expansion – $25.99 on Battle.netShadow of the Tomb Raider – $24.99 on DLGamerPillars of Eternity II: Deadfire – $24.75 on FanaticalSquad - Early Access – $23.99 on Humble StoreAssassin's Creed Odyssey – $23.99 on SteamFar Cry New Dawn – $19.99 on SteamFar Cry 5 – $19.79 on SteamShenmue I & II – $18.89 on FanaticalXCOM 2: War of the Chosen expansion – $18.00 on GreenManGamingAssassin's Creed Origins – $17.99 on SteamGhost Recon Wildlands – $17.49 on SteamGrand Theft Auto Collection – $14.99 on Humble StoreNBA 2K Playgrounds 2 – $14.99 on Humble StoreSteel Division: Normandy 44 – $13.59 on FanaticalDark Souls III – $13.49 on DLGamerBioShock: The Collection – $12.49 on WinGameStoreRise of the Tomb Raider – $11.99 on SteamStar Trek: Bridge Crew – $11.99 on SteamWatch_Dogs 1 and 2 Bundle – $10.78 on SteamTom Clancy’s Splinter Cell Blacklist – $10.19 on SteamCall of Duty: Modern Warfare 2 – $9.99 on FanaticalXCOM 2 – $8.90 on WinGameStoreWorms W.M.D – $8.67 on GreenManGamingFictorum – $7.99 on SteamGrim Dawn – $7.49 on Humble StoreRedout – $6.99 on Humble StoreGhost Recon: Future Soldier – $6.79 on SteamBanished* – $6.79 on Humble StoreState of Decay: Year One Survival Edition – $6.50 on GamesPlanetCities: Skylines – $5.99 on WinGameStoreSouth Park: The Stick of Truth – $5.99 on SteamMax Payne 3 – $5.99 on WinGameStoreStyx: Master of Shadows – $5.75 on GamesPlanetBully: Scholarship Edition – $5.24 on Humble StoreSimplePlanes – $5.19 on SteamChild of Light – $5.09 on SteamVampire: The Masquerade - Bloodlines – $4.99 on Humble StoreEuro Truck Simulator 2 – $4.80 on GreenManGamingAmerican Truck Simulator – $4.80 on GreenManGamingSleeping Dogs: Definitive Edition – $4.49 on SteamLife is Strange Complete Season – $3.99 on SteamPrince of Persia: The Sands of Time – $3.39 on SteamDeus Ex: Human Revolution - Director's Cut – $2.99 on SteamJust Cause 3 – $2.99 on SteamDeus Ex: Human Revolution - Director's Cut – $2.99 on SteamTrine 2: Complete Story* – $2.99 on Humble StoreSupreme Commander: Forged Alliance – $2.59 on SteamWorms Armageddon – $2.55 on GreenManGamingTrine Enchanted Edition* – $2.24 on Humble Store100% Orange Juice – $1.74 on SteamTomb Raider: Anniversary – $0.98 on SteamOxenfree – $0 on The Epic Store*DRM-free version also included DRM-free GoodnessThe GOG store's spring sale is now up and running with over 600 DRM-free specials available to grab. There are even flash deals to catch on the front page. Here are some highlights from the sale to get your feet wet: Darksiders III - $41.99 on GOGPathfinder: Kingmaker - $29.99 on GOGThronebreaker: The Witcher Tales - $22.49 on GOGTorment: Tides of Numenera - $22.49 on GOGMegaquarium - $17.49 on GOGThe Witcher 3: Wild Hunt GOTY - $14.99 on GOGHellblade: Senua's Sacrifice - $14.99 on GOGBaldur's Gate: Enhanced Edition - $9.99 on GOGXCOM: Enemy Unknown Complete Pack - $9.99 on GOGDragon's Dogma: Dark Arisen - $8.99 on GOGMetro: Last Light Redux - $6.79 on GOGSWAT 4: Gold Edition - $4.99 on GOGCrysis - $4.99 on GOGCrysis Warhead - $4.99 on GOGZork: Grand Inquisitor - $3.89 on GOGHeroes of Might and Magic - $2.49 on GOGBrothers in Arms: Hell's Highway - $2.49 on GOGSteel Rats - $1.99 on GOGRune Classic - $1.99 on GOGMemoria - $1.99 on GOGPopulous: The Beginning - $1.49 on GOGMagic Carpet Plus - $1.49 on GOGSyndicate Wars - $1.49 on GOGAlone in the Dark: The Trilogy 1+2+3 - $1.49 on GOGWing Commander 1+2 - $1.49 on GOGWing Commander: Privateer - $1.49 on GOGX-COM: Terror from the Deep - $1.49 on GOGX-Com: Apocalypse - $1.49 on GOGX-Com: UFO Defense - $1.49 on GOGTacoma - $0 on Humble StoreKeep in mind that availability and pricing for some deals may vary depending on the region you're in. And that is it for our pick of this weekend's PC game deals folks, and hopefully, some of you have enough self-restraint not to break your bank accounts adding new games to your growing backlogs. Of course, there is an enormous amount of other deals ready and waiting all over the internet if you comb through it hard enough, so keep your eyes open for those, and have a wonderful weekend.
  15. By now, you might be familiar with Nintendo's Direct and Nindies Showcase streams, where the company highlights some of the games which are making their way to the Switch, with the latter of the two being focused on games from independent developers. Now, both Sony and Microsoft seem to be taking some inspiration from the Japanese rival, as both companies have announced their own streams dedicated to highlighting new and upcoming titles. Hot on the heels of this week's presentation from Nintendo, Microsoft has announced its own indie-focused presentation called ID@Xbox Game Pass. As you can probably infer from the name, this stream isn't just focused on indie games for Microsoft's console; it's specifically for those that are coming to Xbox Game Pass, the company's subscription service for games. It's also clearly a part of Microsoft's ID@Xbox program, which has been helping indie developers get their games on the platform for quite some time now. The first episode of ID@Xbox Game Pass will air on March 26 at 9AM Pacific Time, and it will focus on titles including Afterparty, Void Bastards, Supermarket Shriek, and more. Many of these were previously showcased at events like E3 or X018, so the presentation isn't as focused on new announcements as Nintendo's variant. Instead, it will offer more of a deep dive into those games, and it will also feature talks with the studios behind the games, including a visit to the studio behind Afterparty. Sony, on the other hand, is starting a more broad gaming series called State of Play, which will highlight upcoming titles for the PlayStation 4 and PlayStation VR. The company didn't reveal details about what will be in its own presentation, but it will be taking place on Monday, March 25, at 2PM Pacific Time. State of Play will be the stage for new trailer and gameplay footage, as well as announcements for new games, according to Sony. Nintendo has been using its Direct presentations - and with the Switch, variants such as the Nindies Showcase - since 2011, when it hosted the first stream dedicated to Nintendo 3DS software. After almost eight years, it's certainly interesting to see its rivals take a similar approach to game announcements.
  16. Microsoft keeps making more and more minor improvements to Skype in an attempt to win back the love of its users, who were unhappy with the release of Skype v8. Today, the messaging app is getting a couple of new additions to calls if you're an Insider, with the highlight being the ability to mute incoming audio from someone on a call. The new mute button is available both in group calls, so you can mute specific people, and one-on-one calls. Muting incoming audio might seem somewhat counter-intuitive when you're on a call, but there might be scenarios where it's a welcome temporary solution. The feature joins the ability to disable incoming video, which has been part of Skype for some time now. Another addition to calls is a "View Profile" option during calls, which, as you might have guessed, lets you view the profile of someone you're on a call with. This should make it easier to engage privately with someone you might be meeting for the first time on a group call. The two new features are available with this week's Insider update to the Skype apps on Windows. If you're using the desktop app, it'll be on version, and those using the Microsoft Store app will want to look for version Earlier this week, Microsoft added previews for files you're about to send.
  17. Welcome to [ D-BoT Scripting ] 2.0 Hi there, long time no see! After being gone for a long time, [D-BoT] is back as an English bot and now supports the international versions (.com and .dm) next to the .nl version of Omerta. On this website you will find all the basic information about [D-BoT] you need, for example the commands, some handy information about IRC, some basic statistics of the game and information on how to contact us. https://www.d-bot.net
  18. chain

    Mass Popups

    Version 1.0.0


    Use the popups to do mass commands such as op/deop, help/dehelp, voice/devoice, kick/kickban/ban
  19. Version 1.0.0


    This addon allows you to perform some basic actions on connect. Features included : - Nickserv Identification - Memoserv Listing - Joining certain channels (up to 8 #channels)
  20. Version 1.0.0


    The simplest NickServ identifier. It has the option of choosing the way you communicate with NickServ, using "/ns". or "/msg nickserv".
  21. Folks using healthcare-related Android apps: after you've handed over your private details to that software, do you know where it is sending your data? If you don't, nobody should blame you. It turns out it can be a complicated and obfuscated affair. So much so, eggheads probing the data-sharing practices of mobile health applications have urged software developers to be more transparent regarding how they're handling people's personal info, after observing all sorts of records being passed on to third parties. Parent companies, adverting networks, analytics platforms, data brokers, and more, are seemingly getting their hands on at least some part of the pile, directly or indirectly. And while the studied applications could well be above board, at least within their fine print and terms of use, and sharing data carefully and with consent, the lack of transparency and the large emission of information may deal a blow to any trust you may have in them. Furthermore, even if the information is anonymized prior to sharing, the data tends to flow through the usual few suspects – Google, Facebook, etc – which could, in theory, piece together the identity of individual netizens using these apps, seeing as they capture so many data points. Report Academics hailing from universities in Canada, Australia, and the US, together studied 24 popular Android health and medicine-related apps, and found that nearly 80 per cent were passing on at least some of their users' data to third parties. Their findings were published this week in the British Medical Journal. Check it out for the full details; we'll summarize them here. "Sharing of user data is routine, yet far from transparent," the group concluded in their paper. "Clinicians should be conscious of privacy risks in their own use of apps and, when recommending apps, explain the potential for loss of privacy as part of informed consent. Privacy regulation should emphasise the accountabilities of those who control and process user data. Developers should disclose all data sharing practices and allow users to choose precisely what data are shared and with whom." We're told that 38 per cent of the studied apps shared browser activities, such as medicines looked up and pharmacy websites visited, with third parties; the same again passed on users' email addresses; 25 per cent handed over the list of drugs people are taking; 21 per cent the users' first and last names; 17 per cent the users' medical conditions; and so on. These stats were produced by studying the network traffic of the applications, which range in install bases of 500 devices to 10 million and are among the top 100 most-used in their sector. "Although most (20/24, 83%) appeared free to download, 30% (6/20) of the 'free' apps offered in-app purchases, and 30% (6/20) contained advertising as identified in the Google Play store," the academics noted. "Of the for-profit companies (n=19), 13 had a Crunchbase profile (68%)." https://www.theregister.co.uk/2019/03/21/medical_apps_personal_data/
  22. Facebook revealed to have stored the passwords of hundreds of millions of users in plain text, including passwords of Facebook Lite, Facebook, and Instagram users. “As part of a routine security review in January, we found that some user passwords were being stored in a readable format within our internal data storage systems.” reads the announcement published by Facebook. “This caught our attention because our login systems are designed to mask passwords using techniques that make them unreadable.” The disconcerting discovery was made in January by Facebook IT staff as part of a routine security review. The passwords were stored in plain text on internal data storage systems, this means that they were accessible only by employees. Facebook quickly fixed the issue and plans to notify the affected users. Facebook estimated that hundreds of millions of people using Facebook Lite, tens of millions of other Facebook users, and tens of thousands of Instagram users are impacted. “To be clear, these passwords were never visible to anyone outside of Facebook and we have found no evidence to date that anyone internally abused or improperly accessed them,” continues Facebook. “In the course of our review, we have been looking at the ways we store certain other categories of information — like access tokens — and have fixed problems as we’ve discovered them,” According to the popular investigator Brian Krebs that is investigating the incident, hundreds of millions of Facebook users had their account passwords stored in plain text and searchable by thousands of Facebook employees. Krebs date some cases back to 2012, anyway he did not find an indication that employees have abused access to this data. Krebs believes that the passwords of between 200 million and 600 million Facebook users may have been stored in plain text, and that over 20,000 Facebook employees may have been able to search those passwords. Krebs cited a senior Facebook employee, who is familiar with the investigation and who spoke on condition of anonymity, that revealed the company is currently investigating a series of incidents regarding employees who built applications that logged unencrypted password data for Facebook users and stored it in plain text on internal company servers. https://securityaffairs.co/wordpress/82728/social-networks/facebook-passwords-plain-text.html
  23. According to the media, 1600 motel guests between November 24 and March 2 were spied by the indicted individuals that now face up to five years in prison, as well as a ₩30 million fine along with a ₩10 million penalty for porn distribution. The group wireless micro IP cameras hidden in motel rooms at 30 motels in 10 cities in the North and South Gyeongsang and Chungcheong Provinces. The cameras with 1-millimeter lenses were planted in TV media boxes and power sockets. Image source: Yonhap News AgencyThe group transmitted the videos via a streaming website that was using servers abroad. According to the investigators the site had 4099 registered users, the gang sold 803 videos and earned $6,200. “The site had more than 4,000 members, 97 of whom paid a $44.95 monthly fee to access extra features, such as the ability to replay certain live streams. Between November 2018 and this month, police said, the service brought in upward of $6,000.” reported the CNN. The South Korean authorities confirmed that other similar cases have happened in the past. “There was a similar case in the past where illegal cameras were (secretly installed) and were consistently and secretly watched, but this is the first time the police caught where videos were broadcast live on the internet,” police said. South Korea authorities confirmed that spy-cam sites and revenge porn are common crimes in the country, as reported in a press release published by the Copyright Protection Division of South Korea’s Ministry of Culture, Sports and Tourism. “The police agency strictly deals with criminals who post and share illegal videos as they severely harm human dignity,” reads a statement issued by the Seoul Metropolitan Police Agency. It is quite easy to buy spy cam detectors in South Korea, The KoreaTimes revealed that the sales of these devices have a spike in March 2019 after media reported the case of a South Korean singer who secretly recorded videos of his partners and shared them with friends. In September 2018, the South Korean government carried out a campaign that led to the inspection of thousands of public toilets for hidden cams The fight against this kind of crime included doubled prison sentences for people involved in such kind of illegal activities.

Copywrite © 2020 ChainScriptz

  • Create New...