| 00:53.10 | *** part/#bzflag apeman1 (~Victor@222-155-41-238.jetstream.xtra.co.nz) |
| 01:39.42 | *** join/#bzflag Patlabor221 (~JeffM@2605:e000:7d02:c700:70cd:a69f:6f1:453e) |
| 01:41.20 | *** join/#bzflag Patlabor (~JeffM@2605:e000:7d02:c700:70cd:a69f:6f1:453e) |
| 02:02.36 | *** join/#bzflag zlsa (~zlsa@static-205-157-147-198.ded.unwiredbb.net) |
| 02:46.51 | *** join/#bzflag noyb (~noyb@cpe-172-248-224-184.socal.res.rr.com) |
| 02:50.14 | *** join/#bzflag mlilenium_ (~mlilenium@178.251.136.142) |
| 02:50.24 | *** part/#bzflag mlilenium_ (~mlilenium@178.251.136.142) |
| 03:39.52 | *** join/#bzflag noyb (~noyb@cpe-172-248-224-184.socal.res.rr.com) |
| 04:00.14 | *** join/#bzflag noyb (~noyb@cpe-172-248-224-184.socal.res.rr.com) |
| 04:15.42 | *** join/#bzflag blast007 (~blast007@bzexcess.com) |
| 04:15.48 | *** join/#bzflag blast007 (~blast007@bzflag/developer/Blast) |
| 12:17.33 | *** join/#bzflag grrrrrit (~nomad7@ppp121-45-218-29.lns20.cbr1.internode.on.net) |
| 12:19.14 | *** part/#bzflag grrrrrit (~nomad7@ppp121-45-218-29.lns20.cbr1.internode.on.net) |
| 13:04.32 | *** join/#bzflag nitroxis (~n@wtwrp.de) |
| 13:05.03 | *** join/#bzflag thot (~t@wtwrp.de) |
| 13:36.24 | *** join/#bzflag mahem1 (42377386@gateway/web/freenode/ip.66.55.115.134) |
| 14:00.05 | *** join/#bzflag spldart (ac380e3a@bzflag/contributor/spldart) |
| 14:00.05 | *** mode/#bzflag [+v spldart] by ChanServ |
| 14:12.23 | *** part/#bzflag spldart (ac380e3a@bzflag/contributor/spldart) |
| 14:28.19 | *** join/#bzflag zlsa (~zlsa@static-205-157-147-198.ded.unwiredbb.net) |
| 14:43.03 | *** join/#bzflag TimRiker (~TimRiker@bzflag/projectlead/TimRiker) |
| 14:43.03 | *** mode/#bzflag [+o TimRiker] by ChanServ |
| 15:02.25 | *** join/#bzflag cd101 (ceb061c3@gateway/web/freenode/ip.206.176.97.195) |
| 16:06.32 | *** join/#bzflag Patlabor221 (~JeffM@2605:e000:7d02:c700:bc8c:d73d:47e:1841) |
| 16:24.16 | *** mode/#bzflag [+o JBdiGriz] by ChanServ |
| 16:39.16 | *** join/#bzflag Patlabor221 (~JeffM@107-209-61-105.lightspeed.irvnca.sbcglobal.net) |
| 17:29.24 | *** join/#bzflag Patlabor (~JeffM@76-218-80-21.lightspeed.irvnca.sbcglobal.net) |
| 17:29.45 | Patlabor221 | bad laptop.. no IRC for you! |
| 17:38.30 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 19:44.44 | WarPig | blast007: This DR hacker is pervasive. Would it be fruitless to go after him through his ISP's TOS? |
| 19:44.49 | *** join/#bzflag apeman1 (~Victor@222-155-41-238.jetstream.xtra.co.nz) |
| 19:45.00 | blast007 | *shrug* |
| 19:45.10 | blast007 | or the FBI ;) |
| 19:45.48 | WarPig | We would need some dates/times and IP addresses, at the very least |
| 19:46.02 | blast007 | "Someone in the Dominican Republic is DoSing a game server named Planet Mofo! HALP!" |
| 19:46.20 | WarPig | Even those of him connecting to ##planetmofo to brag of his exploits |
| 19:46.37 | apeman1 | Someone told me a few months ago the Dominican Cheater was using an exploit that crashed servers by filling them up with joins. Did this ever get addressed? |
| 19:46.57 | blast007 | people confuse the terms "crash" and "hack" |
| 19:47.07 | blast007 | he didn't crash them, he just filled them up so nobody could join |
| 19:47.47 | WarPig | So, again, would it likely be fruitless (or pointless) to pursue? |
| 19:48.33 | blast007 | the crashes he triggered were in once case due to triggering out of bound array values in MsgTeleport (though that was just a client crash, which we have since fixed in both the client and server - the client won't crash when the server sends invalid indexes, and the server won't send invalid indexes) |
| 19:48.39 | blast007 | one case* |
| 19:48.54 | blast007 | WarPig: depends how responsive his ISP is to abuse complains |
| 19:49.29 | apeman1 | did he simply get bored of using the exploit blocking joins? |
| 19:49.57 | WarPig | I imagine the FBI would make it a pretty low priority, what with the elections and republican smearing they have in the queue. |
| 19:51.24 | WarPig | ...but yeah, his ISP might be helpful if someone with some reason to be angry (like a server owner, or the bzflag developers) gathered some evidence to help them track this guy down. |
| 19:52.15 | Patlabor221 | what part of his TOS is he breaking? |
| 19:52.17 | blast007 | apeman1: well, connection limits at the firewall made that harder for him |
| 19:53.14 | zlsa | urban jungle just either went down or was shut off by the owner |
| 19:53.42 | blast007 | http://www.tricom.net/media/Pol%C3%ADtica-de-Uso-Aceptable-del-Servicio-Internet-de-TRICOM.pdf |
| 19:53.45 | WarPig | I havent read his TOS, but I would imagine there would be some verbiage in there regarding hacking passwords and running a DoS campaign. |
| 19:54.01 | blast007 | when did he hack passwords? |
| 19:54.40 | Patlabor221 | WarPig, how do you even know his ISP or what is TOS is? |
| 19:54.43 | WarPig | He was bragging about gaining admin perms via an exploit.... Does that not count |
| 19:54.51 | WarPig | ? |
| 19:54.59 | Patlabor221 | depends on his TOS |
| 19:55.07 | WarPig | I know his ISP because I have his IP address |
| 19:55.24 | Patlabor221 | you have AN ip address, can you prove it is his? |
| 19:55.32 | thrakt | WarPig : which one? |
| 19:55.36 | blast007 | Patlabor221: because he regularly joins with the same ISP with varying addresses in those ranges |
| 19:55.43 | Patlabor221 | ahh |
| 19:55.54 | Patlabor221 | the odds are the ISP won't respond |
| 19:56.04 | Patlabor221 | they have no legal reason to do so |
| 19:56.05 | blast007 | they have an abuse address in their TOS |
| 19:56.16 | Patlabor221 | then fire it off and see what happens |
| 19:56.24 | blast007 | I don't speak spanish ;) |
| 19:56.28 | Patlabor221 | but I'd have the owner of a server who was abbused do it |
| 19:56.40 | blast007 | mine was, mofo's was |
| 19:56.41 | thrakt | blast007 : kierra does. |
| 19:56.59 | thrakt | if a letter is written, she could translate and we can send both. |
| 19:57.12 | Patlabor221 | send it in english, they will probably be able to translate, if not they will respond with a request for more info |
| 19:57.19 | Patlabor221 | then get it translated |
| 19:58.42 | Patlabor221 | keep it simple |
| 19:58.46 | blast007 | their TOS does cover attacks including unauthorized access, trying to overcome security measures, and port scans, along with pinging, flooding, mailbombing, and DoS |
| 19:59.05 | WarPig | I was just reading that too. |
| 19:59.28 | Patlabor221 | then fire them off an email |
| 19:59.35 | Patlabor221 | worst they can do is ignore you :) |
| 20:00.12 | WarPig | IP addresses and exact dates/times must accompany the letter. |
| 20:00.26 | blast007 | and times should be in UTC |
| 20:01.38 | WarPig | IRC logs would be helpful too. |
| 20:02.07 | Patlabor221 | WarPig, why? do you run the IRC sever he abbused? |
| 20:02.22 | blast007 | no, but he bragged and described the attacks there |
| 20:02.32 | WarPig | He did not abuse an IRC server, to my knowledge. |
| 20:02.34 | blast007 | from his home ISP ;) |
| 20:02.39 | Patlabor221 | can you link his IRC username to the IP? |
| 20:02.47 | blast007 | yes |
| 20:02.49 | Patlabor221 | k |
| 20:02.54 | WarPig | ...what blast007 said. :D |
| 20:03.06 | blast007 | well, kinda.. the attacks have been from proxies mostly, which makes it slightly more complicated |
| 20:03.21 | Patlabor221 | yeah... that's kicker |
| 20:03.34 | Patlabor221 | you need to clearly show him using those IPs for the attacks |
| 20:03.36 | WarPig | ...because his real IPs have been firewalled |
| 20:03.44 | Patlabor221 | against services you own/controll |
| 20:04.28 | Patlabor221 | IRC threats probably don't violate the TOC, they are simply him saying things |
| 20:04.40 | Patlabor221 | you have to SHOW exactly how he violated the TOC |
| 20:05.22 | WarPig | They can catch him in the act, if they're interested to do so. |
| 20:05.27 | Patlabor221 | and it has to be clear and irrifutable to someone who has NO knowledge of history of the person |
| 20:05.47 | Patlabor221 | they CAN do many things, the question is WHY would they do it |
| 20:05.58 | WarPig | ...he continues to run his DoS, even now. |
| 20:06.00 | Patlabor221 | you need to show them WHY they want to monitor his trafic |
| 20:06.03 | blast007 | monitoring his proxy use would be a pain... |
| 20:06.06 | blast007 | even for an ISP |
| 20:06.16 | Patlabor221 | yeah, it's not like they have people with nothing to do :) |
| 20:06.28 | Patlabor221 | they don't exist to serve us, they exist to serve him |
| 20:06.52 | WarPig | You're right, if it's an SSL proxy, which it probably is. |
| 20:07.03 | blast007 | no, it probably isn't |
| 20:07.13 | blast007 | but are they going to inspect EVERY packet he sends? probably not |
| 20:07.23 | Patlabor221 | if the attacks came from one of his IPs, that's an attack against the TOS. if the attacks came from other IPs, you may not have much of a case |
| 20:07.41 | Patlabor221 | did he ever attack a server from his IP directly? |
| 20:07.47 | WarPig | yes |
| 20:08.25 | Patlabor221 | and you have system level logs that show that? |
| 20:08.52 | WarPig | that's the question. I don't run a server, so I have no logs. |
| 20:09.36 | Patlabor221 | then you should not be involved in the report |
| 20:09.50 | WarPig | I don't need to be. |
| 20:10.02 | WarPig | I'm just trying to come up with a solution. |
| 20:10.04 | Patlabor221 | if you have no logs, how do you know he attacked a server from his IP? |
| 20:10.08 | Patlabor221 | there is no solution |
| 20:10.10 | Patlabor221 | fix the game |
| 20:10.34 | WarPig | Because I know people... |
| 20:10.39 | Patlabor221 | you are sugesting a highly improbable last ditch effort |
| 20:10.49 | Patlabor221 | so you have hearsay, that isn't quite evedence. |
| 20:11.00 | Patlabor221 | I'd get the logs before you say what he has and has not done |
| 20:11.02 | WarPig | hence my original inquiry. |
| 20:11.11 | WarPig | 'would it be pointless'? |
| 20:11.33 | Patlabor221 | it has a high likelyhood of being ignored, specially if it does not include hard evidence. |
| 20:12.06 | WarPig | Yes... I know. |
| 20:12.45 | WarPig | .... which is why I asked blast007, who has a server that was attacked using his ISP and IP. |
| 20:13.01 | Patlabor221 | he said proxy servers attacked his server |
| 20:13.03 | Patlabor221 | not his IP |
| 20:13.26 | WarPig | He began using proxy servers when his IP was firewalled. |
| 20:13.26 | Patlabor221 | you have to be VERY clear in these things :) |
| 20:13.33 | WarPig | I know. |
| 20:13.56 | Patlabor221 | was he just cheating when he was using his IP, or was he doing DOS attacks form his IP? |
| 20:14.14 | Patlabor221 | usualy you use a range of proxies to get a DOS going so you get more bandwith |
| 20:14.23 | WarPig | He is attacking servers NOW using his IP. Server owners could collect data NOW to present to his ISP. |
| 20:14.36 | Patlabor221 | how is he attacking? |
| 20:14.45 | Patlabor221 | DOS? or just cheating? |
| 20:14.53 | WarPig | DoS |
| 20:15.12 | Patlabor221 | he must have one hell of an upstream pipe then, are you sure? |
| 20:15.26 | Patlabor221 | last I heard the DOSs were from HTTP based DDOS proxy systems |
| 20:15.34 | WarPig | He says he's using a DoS tool he downloaded. |
| 20:15.47 | Patlabor221 | again that'd be a very large upstream pipe |
| 20:15.58 | Patlabor221 | so it's probably doubtful |
| 20:16.09 | Patlabor221 | the tool probably contacts a botnet |
| 20:16.21 | WarPig | likely |
| 20:16.32 | Patlabor221 | so the attacks are NOT coming from his IP in that case |
| 20:17.56 | WarPig | hard for me to say, I'm not running a server. |
| 20:18.05 | Patlabor221 | but you know people ;) |
| 20:18.14 | WarPig | yes I do. |
| 20:18.49 | Patlabor221 | still sounds like you have some less then solid info |
| 20:19.40 | WarPig | I have no info at all. I know how this has played out over the last several months, and I know ho the players are. You and I are not those players. |
| 20:20.14 | WarPig | ...in fact, I think it was my original ban of him that cause him to go off teh deep end. |
| 20:20.23 | Patlabor221 | in reality there is very little you can do to stop him with out just fixing the software, or making there not be a reason for him to continue |
| 20:20.54 | Patlabor221 | I'd just ignore him, if he stops getting off on it, he'll have no reason to continue |
| 20:21.30 | WarPig | I know that. If we can send some heat his way in teh form of threats of disconnection form his ISP, that'll give him some incentive to stop. |
| 20:22.00 | Patlabor221 | I don't think this single incident would generate "heat" |
| 20:22.07 | WarPig | ...a long shot I knoe. |
| 20:22.10 | Patlabor221 | it's a silly online game :) |
| 20:22.10 | WarPig | know* |
| 20:22.30 | Patlabor221 | now if blast were to say he worked at a bank.... |
| 20:23.04 | WarPig | It, in principal, is the same. |
| 20:23.22 | Patlabor221 | when has principal ever mattered in the real world? |
| 20:23.39 | apeman1 | i havent seen any evidence that these attacks are actually high bandwidth |
| 20:24.07 | WarPig | nor have I |
| 20:24.22 | Patlabor221 | then are the hosts for the games that slow that they can't weed out the traffic? |
| 20:24.35 | Patlabor221 | or is he sending HTTP requests and making the server eat cycles? |
| 20:24.47 | apeman1 | so while it is bringing servers down, its really just a cheat rather than something his provider would care about |
| 20:25.12 | Patlabor221 | oh is he just crashing instances of bzfs? |
| 20:25.16 | WarPig | he called it "01THE DoS Http Tool that i downloaded from Google01" |
| 20:25.37 | WarPig | (could you read that copy/paste?) |
| 20:25.38 | apeman1 | thats probably just a mock insult |
| 20:25.40 | Patlabor221 | assume everything he says is a lie |
| 20:26.39 | Patlabor221 | if you don't run any HTTP plugins then bzfs should ignore HTTP trafic |
| 20:26.49 | blast007 | WarPig: black text on black background ;) |
| 20:27.08 | WarPig | stealthy.... the way I like it. |
| 20:27.28 | WarPig | ....though not conducive to intellegent discourse. |
| 20:28.51 | Patlabor221 | is he flooding out connections or hitting a bug in BZFS? |
| 20:29.25 | blast007 | heh, think I just firewalled 127.0.0.1 from my test game server :P |
| 20:29.33 | WarPig | oops |
| 20:29.45 | apeman1 | probably a bug. BZFS is still sending/receiving TCP in a timely manner |
| 20:30.14 | blast007 | Patlabor221: one odd thing I noticed during one of his attacks was that everyone had the same (high) lag value |
| 20:30.20 | apeman1 | so he may be sending data in a way that tricks BZFS into dropping UDP packets |
| 20:30.41 | apeman1 | or not "dropping", but deciding not to send them |
| 20:30.57 | Patlabor221 | UDP packets are dropped all the time |
| 20:31.01 | Patlabor221 | it's the nature of UDP |
| 20:31.16 | Patlabor221 | blast007, so he could be causing the bzfs loop to spin on some data for some fixed time |
| 20:31.21 | apeman1 | 80% drop rate? |
| 20:31.29 | Patlabor221 | apeman1, depends on network conditions |
| 20:31.38 | Patlabor221 | UDP is connectionless and can be dropped at any time |
| 20:31.43 | apeman1 | 80% drop rate when there are 4 players on a server? |
| 20:31.43 | blast007 | bzfs tries to process UDP data for up to 250ms per server loop |
| 20:31.45 | Patlabor221 | he could be filling the system network buffer |
| 20:32.02 | Patlabor221 | or he could be filling one of our buffers |
| 20:32.09 | blast007 | and the lag value I was seeing almost everyone at in one instance wa 292ms, with varying three digit jitter |
| 20:32.16 | Patlabor221 | or he could be flooding out the connection so nothing can get out |
| 20:32.17 | blast007 | was* |
| 20:32.31 | Patlabor221 | then yeah he's probalby spinning bzfs |
| 20:32.39 | blast007 | and there was a lot of MsgUDPLinkEstablished messages being sent, like 200/second |
| 20:32.40 | Patlabor221 | could be in the HTTP code too |
| 20:32.51 | Patlabor221 | ok then it's a lot of UDP packets |
| 20:32.54 | Patlabor221 | probably with a large size |
| 20:32.55 | blast007 | (rough estimate based only on log output) |
| 20:33.06 | blast007 | that message *is* sent over TCP though |
| 20:33.16 | Patlabor221 | after connect too |
| 20:33.26 | blast007 | had a blank callsign though |
| 20:33.43 | Patlabor221 | could drop a connection if it tries UDP before auth |
| 20:33.51 | Patlabor221 | coudl also log out the packet size |
| 20:34.05 | Patlabor221 | he could be sending us large packet sizes and making us spin on decoding them |
| 20:34.16 | blast007 | and I never run debug logging on my servers |
| 20:34.29 | blast007 | (only the logDetail output) |
| 20:35.06 | Patlabor221 | The server won't even receive a world update message, could try auto closing any connection that sends a BZ message over 128bytes or something |
| 20:35.36 | apeman1 | i would take a bet that the exploit relates to poorly coded static variables :P |
| 20:35.49 | Patlabor221 | could you possibly be more generic? |
| 20:35.53 | Patlabor221 | or vauge |
| 20:36.11 | apeman1 | yes |
| 20:36.15 | Patlabor221 | IIRC we don't use a static network buffer, every player has it's own |
| 20:36.43 | Patlabor221 | there could be something in the single UDP message section, since UDP is connectionless we don't know what player it's from untill we decode it. |
| 20:37.01 | apeman1 | i would take a bet that the exploit relates to a static bool variable that has something to do with "should we process this soon" |
| 20:37.06 | Patlabor221 | but we know the max size of any inbound message, so it'd be super easy to ignore large ones. |
| 20:37.17 | Patlabor221 | apeman1, and this is based on what? |
| 20:37.19 | Patlabor221 | a guess? |
| 20:37.27 | apeman1 | yes |
| 20:37.34 | Patlabor221 | I do not recall any boolean like that |
| 20:37.35 | apeman1 | i would take a bet |
| 20:37.46 | apeman1 | ive seen one already |
| 20:37.54 | Patlabor221 | then be specific |
| 20:38.07 | Patlabor221 | are you talking about the loop timer? |
| 20:39.04 | Patlabor221 | There is a variable timer to determine the frame time on the server |
| 20:39.19 | Patlabor221 | then we see if there are any message to process and process what we can up to 250ms of time |
| 20:39.30 | Patlabor221 | then it's another wait |
| 20:41.13 | apeman1 | i cant be specific because i dont know the exploit. its just what i do a quick check of first |
| 20:41.39 | Patlabor221 | huh? |
| 20:42.03 | Patlabor221 | what section of the code do you think it's in? |
| 20:42.46 | apeman1 | he posted an exploit before, http://pastebin.com/bmUj6jbA which takes advantage of bzfs.cxx: |
| 20:42.46 | apeman1 | static bool spawnSoon = false; |
| 20:43.07 | Patlabor221 | that's spawn code, that has nothing to do with networking |
| 20:43.20 | Patlabor221 | and yeah we have to time out our spawns |
| 20:44.01 | Patlabor221 | that looks like an old thing where we used to accept spawns before identify |
| 20:44.01 | apeman1 | what kind of networking problem do you think the exploit could be then? |
| 20:44.05 | Patlabor221 | I belive that has been fixed |
| 20:44.18 | apeman1 | he used that exploit yesterday and i tesetd it too |
| 20:44.36 | Patlabor221 | I don't know, I'd need to know what type of data he is sending |
| 20:44.42 | Patlabor221 | on a recently updated server? |
| 20:44.46 | apeman1 | yes |
| 20:44.48 | Patlabor221 | or some old 2.4.2 thing? |
| 20:44.56 | apeman1 | updated to say 3 weeks ago |
| 20:44.58 | Patlabor221 | because that'd be super easy to fix |
| 20:45.55 | Patlabor221 | that's a single message on conenct |
| 20:46.01 | Patlabor221 | find out what it is and block it untill after join |
| 20:49.23 | Patlabor221 | looks like he's sending 00al |
| 20:49.52 | Patlabor221 | and that's pure TCP |
| 20:49.55 | Patlabor221 | no UDP |
| 20:51.39 | apeman1 | yes, he sends a MsgAlive |
| 20:51.52 | apeman1 | then everyone who joins spawns instantly |
| 20:53.36 | Patlabor221 | that should be ignored handleCommand checks to see if the player is completely added |
| 20:53.43 | Patlabor221 | it's possible that we don't clear a buffer |
| 20:54.17 | Patlabor221 | it should never even get to the spawn code |
| 20:55.05 | apeman1 | it does not enter handleCommand()'s switch statement, but it still gets to the other one |
| 20:55.13 | Patlabor221 | what other one? |
| 20:56.02 | apeman1 | it still triggers the second "case MsgAlive" in handleCommand() |
| 20:56.10 | apeman1 | and goes to playerData->player.queueSpawn(); |
| 20:56.15 | Patlabor221 | then the playerID is not being matched |
| 20:56.24 | Patlabor221 | he's spoofing the ID of a valid player |
| 20:57.10 | Patlabor221 | stupid solobots..... |
| 20:57.48 | apeman1 | i dont understand |
| 20:58.10 | apeman1 | handleCommand's int t argument is as normal |
| 20:58.26 | Patlabor221 | but where does it get T from? |
| 20:59.33 | apeman1 | i presume because he was made a player after sending the BZ_CONNECT_HEADER |
| 21:00.04 | Patlabor221 | being made a player doesn't make you pass the IsFullyConnected |
| 21:00.10 | Patlabor221 | so he can't be using his own playerID |
| 21:00.14 | Patlabor221 | if what you say is true |
| 21:00.14 | apeman1 | isCompletelyAdded? |
| 21:00.17 | Patlabor221 | yeah |
| 21:00.28 | Patlabor221 | it's the only way he could hit the second switch and not the first |
| 21:00.47 | apeman1 | well i used his script in order, the playerID the server thinks he is is normal like he is a real player |
| 21:00.56 | apeman1 | in different orders* |
| 21:01.09 | Patlabor221 | then why did isComplelyAdded allow it to pass? |
| 21:02.12 | apeman1 | are yous aying that MakePlayer( is not sufficient to add him completely? |
| 21:02.29 | Patlabor221 | no you need to send a callsign |
| 21:02.55 | blast007 | I don't know if that spawnSoon thing was fixed |
| 21:03.50 | blast007 | but that just triggered an auto-spawn glitch for your own client so you could evade the _waitTime (or whatever the var was) after a rejoin |
| 21:04.06 | blast007 | not exactly earth shattering |
| 21:04.07 | Patlabor221 | I'm diggging |
| 21:04.19 | apeman1 | i will check again |
| 21:06.19 | apeman1 | it definitely reaches that second MsgAlive |
| 21:07.35 | blast007 | we could fix a lot of this in 2.6 if we got motivated enough to put time into it ;) |
| 21:08.20 | blast007 | the handshake is a bunch of cobbled together stuff (well, much like most everything else) |
| 21:11.46 | Patlabor221 | I see how to fix it |
| 21:13.29 | Patlabor221 | the spawn boolean is lame, but it is not involved in the exploit |
| 21:13.36 | Patlabor221 | it's just a bug in bzfs message processing |
| 21:13.54 | Patlabor221 | you can't send alive untill after an enter |
| 21:17.30 | apeman1 | *facepalm*, also the first MsgAlive doesnt prevent it from being processed |
| 21:17.40 | Patlabor221 | yeah |
| 21:17.43 | Patlabor221 | I have a fix |
| 21:17.55 | Patlabor221 | I have sent it to a reputable server owner for testing |
| 21:18.02 | Patlabor221 | we'll see if he cares enough to build it :) |
| 21:18.23 | apeman1 | i can test it right now |
| 21:19.21 | Patlabor221 | it'll prevent a number of messages from being processed untill after an enter |
| 21:39.57 | blast007 | should be live on bzexcess |
| 21:41.52 | Patlabor221 | that'll block chat untill you have a name too |
| 21:42.10 | *** join/#bzflag gnu-sense (~gnu-sense@c-98-223-179-205.hsd1.in.comcast.net) |
| 21:43.17 | *** join/#bzflag Not-c98d (~notifico@198.199.82.216) |
| 21:43.17 | Not-c98d | [02bzflag-import-3] 07JeffM2501 pushed 031 commit to 03v2_4_x [+0/-0/±3] 13http://git.io/uES2-Q |
| 21:43.18 | Not-c98d | [02bzflag-import-3] 07JeffM2501 036eeb795 - filter messages before enter |
| 21:44.11 | Patlabor221 | that dosn't do the stupid string compare every message :) |
| 21:44.18 | blast007 | ah |
| 21:44.45 | Patlabor221 | and removes the map messages since they are needed |
| 21:51.52 | blast007 | that version is live now ;) |
| 21:53.36 | blast007 | hmm, or maybe not... |
| 21:55.11 | blast007 | ah, that was your fork, Patlabor221 - was that your intention? |
| 21:57.26 | *** join/#bzflag MonsieurApple (~MonsieurA@unaffiliated/mrapple) |
| 22:13.59 | *** join/#bzflag Snakissssh12534 (329c524c@gateway/web/cgi-irc/kiwiirc.com/ip.50.156.82.76) |
| 22:36.46 | Patlabor221 | goddmanit! |
| 22:36.52 | Patlabor221 | how do I push it back? |
| 22:37.38 | Patlabor221 | pull request maybe? |
| 22:37.47 | blast007 | that's one way |
| 22:38.05 | Patlabor221 | I have too many things in my project list that say "Bzflag" |
| 22:38.11 | blast007 | ;D |
| 22:38.34 | blast007 | I have a crap ton of local repos for BZFlag right now.. |
| 22:38.39 | Patlabor221 | how do you generate a pull request? |
| 22:38.45 | blast007 | first, you get a goat.. |
| 22:39.45 | Not-c98d | [02bzflag-import-3] 07JeffM2501 pushed 032 commits to 03v2_4_x [+0/-0/±6] 13http://git.io/elUL7w |
| 22:39.48 | Not-c98d | [02bzflag-import-3] 07JeffM2501 036eeb795 - filter messages before enter |
| 22:39.48 | Not-c98d | [02bzflag-import-3] 07JeffM2501 03fc578ad - Merge pull request #5 from JeffM2501/v2_4_x filter messages before enter |
| 22:39.54 | Patlabor221 | did that do it right? |
| 22:42.30 | blast007 | yeah, that looks right |
| 22:42.49 | blast007 | or at least it was one way of doing it ;) |
| 22:44.01 | blast007 | think that's how it works for pull requests. you can 'rebase' in other cases so that it bases your commits on the latest changeset and then it doesn't look like a merge but instead just a commit (or set of commits) after the latest |
| 22:44.27 | Patlabor221 | yeah it was just an odd interface to get to it |
| 22:44.37 | Patlabor221 | compounded by the fact that our "master" branch is useles |
| 22:44.46 | blast007 | but that's all still a bit confusing for me.. I tend to screw up my local repos often enough that I tend to back them up before any "fun" operation |
| 22:45.20 | Patlabor221 | I've done some rebases with other projects ok |
| 22:57.59 | Snakissssh12534 | was khonkhortisan here the past 7 days on #bzflag? |
| 23:09.01 | Patlabor221 | you can check the loggs |
| 23:28.20 | *** join/#bzflag PrezKennedy (~DarkCalf@2002:40b9:e85a::40b9:e85a) |
| 23:28.33 | *** join/#bzflag DTRemenak|RDP (~DTRemenak@76-227-151-154.lightspeed.irvnca.sbcglobal.net) |
| 23:28.35 | *** join/#bzflag DTRemenak|RDP (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 23:28.35 | *** mode/#bzflag [+v DTRemenak|RDP] by ChanServ |
| 23:50.50 | *** join/#bzflag Patlabor221 (~JeffM@70-240-33-134.lightspeed.irvnca.sbcglobal.net) |