EVE Search - Call to encrypt RPC traffic

All Channels

EVE General Discussion

Call to encrypt RPC traffic

» Click here to find additional results for this topic using Google

Monitor this thread via RSS [?]

Pages: 1 2 3 :: [one page]
Author	Thread Statistics \| Show CCP posts - 0 post(s)
Miilla Minmatar Hulkageddon Orphanage	Posted - 2011.03.27 13:07:00 - [1] In order to prevent external sniffing applications from being used to cheat in eve (Virus scanners etc), I would call that all Traffic is encrypted to some level to prevent this snooping. Please?
yumike	Posted - 2011.03.27 13:14:00 - [2] not all data needs to be encrypted (too much worthless cpu overhead. especially on the server(s)) All sensitive data is already encrypted between the client and server. Don't post for things until you know what your talking about please.
Miilla Minmatar Hulkageddon Orphanage	Posted - 2011.03.27 13:16:00 - [3] Originally by: yumike not all data needs to be encrypted (too much worthless cpu overhead. especially on the server(s)) All sensitive data is already encrypted between the client and server. Don't post for things until you know what your talking about please. Considering they are sniffing out names that are in local via network traffic and having the virus scanners shut down the client. So you propose 2 call streams, one unencrypted and one encrypted or just fudge the data returned in the calls and use non SSL streams? Either way works for me as long as nobody can use external applications to see RPC data and use that to cheat automatically as they are doing today.
Stinky Minky	Posted - 2011.03.27 13:20:00 - [4] Wireshark will set you free
Miilla Minmatar Hulkageddon Orphanage	Posted - 2011.03.27 13:21:00 - [5] Edited by: Miilla on 27/03/2011 13:21:41 Originally by: Stinky Minky Wireshark will set you free Also useless against client server SSL traffic unless ofcourse you happen to run a profiler inproc of eve :)
yumike	Posted - 2011.03.27 13:25:00 - [6] Originally by: Miilla Considering they are sniffing out names that are in local via network traffic and having the virus scanners shut down the client. So you propose 2 call streams, one unencrypted and one encrypted or just fudge the data returned in the calls and use non SSL streams? Either way works for me as long as nobody can use external applications to see RPC data and use that to cheat automatically as they are doing today. Alright, Let's say you did that encrypt local. The key (Dynamic?) would still have to be sent to the client and pass through any virtual network adapter, firewall, virus scanner - bot. ANY peice of software can rebuild the routing table to go through it first. So at most encrypted or not, whatever peice of software between eve and the server would be compromised already. (Since in the case of a bot, it would just need a couple changes to keep working. and then voila it can still sniff network traffic for local.) Encryption in this case is not a viable solution. That's why the current standard for pretty much any mmo i've seen (including eve) is just to XOR encrypt passwords etc. It's easily broken if you have the key which both the client and the server must have.
Miilla Minmatar Hulkageddon Orphanage	Posted - 2011.03.27 13:27:00 - [7] Edited by: Miilla on 27/03/2011 13:28:38 Originally by: yumike Originally by: Miilla Considering they are sniffing out names that are in local via network traffic and having the virus scanners shut down the client. So you propose 2 call streams, one unencrypted and one encrypted or just fudge the data returned in the calls and use non SSL streams? Either way works for me as long as nobody can use external applications to see RPC data and use that to cheat automatically as they are doing today. Alright, Let's say you did that encrypt local. The key (Dynamic?) would still have to be sent to the client and pass through any virtual network adapter, firewall, virus scanner - bot. ANY peice of software can rebuild the routing table to go through it first. So at most encrypted or not, whatever peice of software between eve and the server would be compromised already. (Since in the case of a bot, it would just need a couple changes to keep working. and then voila it can still sniff network traffic for local.) Encryption in this case is not a viable solution. That's why the current standard for pretty much any mmo i've seen (including eve) is just to XOR encrypt passwords etc. It's easily broken if you have the key which both the client and the server must have. You discovered a universal exploit to hack all SSL connections? You should post your whitepaper immediately, the entire banking industry is in chaos and e-commerce is dying.
Karak Terrel As Far As The eYe can see Chained Reactions	Posted - 2011.03.27 13:36:00 - [8] K, i'm confused. What has a Virus Scanner to do with cheating/sniffing? -- please consider to visit our w-space system, cake will be served immediately.
yumike	Posted - 2011.03.27 13:38:00 - [9] Edited by: yumike on 27/03/2011 13:38:03 I wrote out a response but the forum ate it, Can't be buggered to write it again. All i'll say is any time the client or the server is already compromised, It doesn't matter what type of encryption you use as it will be worthless. RSA, AES, SSL and its big brother TLS, it doesnt matter.
Miilla Minmatar Hulkageddon Orphanage	Posted - 2011.03.27 13:38:00 - [10] Originally by: Karak Terrel K, i'm confused. What has a Virus Scanner to do with cheating/sniffing? They use it to search out strings in traffic between applications and if an enemy name appears, they shut down the eve client. In other words, go offline so their bot ratter miner wont get ganked.
Miilla Minmatar Hulkageddon Orphanage	Posted - 2011.03.27 13:40:00 - [11] Originally by: yumike Edited by: yumike on 27/03/2011 13:38:03 I wrote out a response but the forum ate it, Can't be buggered to write it again. All i'll say is any time the client or the server is already compromised, It doesn't matter what type of encryption you use as it will be worthless. RSA, AES, SSL and its big brother TLS, it doesnt matter. Please link me your whitepaper, the entire banking industry and e-commerce vendors will love to see it and probably comment and thus make the internet business safe for all. Thanks in advance for your hard work into this internet security issue. No doubt billions and trillions of banking infrastructure and online businesses will have to spent to fix this. I can see this appearing on slashdot any moment now. CHAOS IN THE INTERNET!
Furb Killer Gallente	Posted - 2011.03.27 13:42:00 - [12] Edited by: Furb Killer on 27/03/2011 13:43:41 Indeed, encryption is kinda useless if the client computer is 'compromised', then you can just read it directly from the memory. Not to mention since bots log for every neutral/red that jumps in that they put 330k char names in their virus definitions, risking pretty much every program randomly shuts down, when you can also read the screen way easier (yes i know miila is just a troll). Encryption is used to make sure you cannot sniff the stuff via routers in the middle, packet sniffers that sniff wireless connections, etc. If your client is compromised you cannot hide your data, it needs to be unencrypted in the memory otherwise the user can never use it.
Miilla Minmatar Hulkageddon Orphanage	Posted - 2011.03.27 13:43:00 - [13] Originally by: yumike not all data needs to be encrypted (too much worthless cpu overhead. especially on the server(s)) Don't post for things until you know what your talking about please. Can you please link me the investigation you did into this issue on the Eve Cluster, I would like to see numbers and some pretty colourful charts graphs, perhaps even a slidedeck too for the audience for peer review.
Kerfira Kerfira Corp	Posted - 2011.03.27 13:44:00 - [14] Originally by: Miilla You discovered a universal exploit to hack all SSL connections? You should post your whitepaper immediately, the entire banking industry is in chaos and e-commerce is dying. You're making a comparison that is not valid. SSL traffic is no more safe than EVE encrypted traffic would be given the same access. SSL is considered secure ONLY in the case where the snooper doesn't have access to either the server or the client. If you have that access, and spend the time reverse engineering that server/client internals to retrieve the encryption codes, then SSL is in no way secure. That is the scenario we have with EVE, since the snooper in this case has FULL access to the client. For the client to decode a coded stream from the server, it has to have to decryption key in memory, and it's a fairly simple (though sometime time consuming) matter of retrieving that key, and then using it in your bot script. Encrypting the streams will make the bot writing a bit more troublesome, but once broken CCP would have to completely re-architect their code to make it resistant again... And they'd have to do it again, and again, and again, and again.... It is not the solution to the problem. Originally by: CCP Wrangler EVE isn't designed to just look like a cold, dark and harsh world, it's designed to be a cold, dark and harsh world.
Karak Terrel As Far As The eYe can see Chained Reactions	Posted - 2011.03.27 13:44:00 - [15] Originally by: Miilla Originally by: Karak Terrel K, i'm confused. What has a Virus Scanner to do with cheating/sniffing? They use it to search out strings in traffic between applications and if an enemy name appears, they shut down the eve client. In other words, go offline so their bot ratter miner wont get ganked. Ah, you mean a compromised virus scanner. If your comp is compromised no encryption will help you. That still such a big problem with all the malware stuff on windows? -- please consider to visit our w-space system, cake will be served immediately.
Miilla Minmatar Hulkageddon Orphanage	Posted - 2011.03.27 13:46:00 - [16] Originally by: Karak Terrel Originally by: Miilla Originally by: Karak Terrel K, i'm confused. What has a Virus Scanner to do with cheating/sniffing? They use it to search out strings in traffic between applications and if an enemy name appears, they shut down the eve client. In other words, go offline so their bot ratter miner wont get ganked. Ah, you mean a compromised virus scanner. If your comp is compromised no encryption will help you. That still such a big problem with all the malware stuff on windows? No, one just with setting to shut down eve traffic if "shield" detects this string. Not compromised at all. Even if your computer is compromised, your client is secured with the server, end to end. Sure you can read memory but that requires attaching an application to read it, which will be detected in future.
Terrolph Trick	Posted - 2011.03.27 13:48:00 - [17] Originally by: Miilla Lalalalalalla Posting in another Miilla thread. How are you feeling today? Nice concepts you have there. I'm not feeling threatened yet, but I'll just prepare my tinfoil hat just in case. If this gets worse I will have to turn off my computer to protect my stuffz against further threats from the internets.
Karak Terrel As Far As The eYe can see Chained Reactions	Posted - 2011.03.27 13:49:00 - [18] and how does it get that setting to search for that string? -- please consider to visit our w-space system, cake will be served immediately.
yumike	Posted - 2011.03.27 13:49:00 - [19] Edited by: yumike on 27/03/2011 13:50:16 I refuse to believe your this lack-of-intelligence. No white paper required, when your client is compromised all your keys are seen and any software-level encryption won't matter. Infact theres half a dozen ways you can even do it at that point! So i'm gonna give you 3/10 for a little bit of effort. Quote: Even if your computer is compromised, your client is secured with the server, end to end. I laughed. Thank you for that.
Badger Molester The Greater Goon Clockwork Pineapple	Posted - 2011.03.27 13:49:00 - [20] Just shut up, you are the worst poster (worse than me).
Miilla Minmatar Hulkageddon Orphanage	Posted - 2011.03.27 13:50:00 - [21] Originally by: yumike I refuse to believe your this lack-of-intelligence. No white paper required, when your client is compromised all your keys are seen and any software-level encryption won't matter. Infact theres half a dozen ways you can even do it at that point! So i'm gonna give you 3/10 for a little bit of effort. Sure it is, you have to back up your statements with facts. Numbers, charts, graphs. Measurements. You said the Eve Cluster cannot handle the load, I would love to see the numbers to back this up. All I am asking is for your numbers, you're the one who made the claims, not me.
yumike	Posted - 2011.03.27 13:56:00 - [22] Originally by: Miilla Sure it is, you have to back up your statements with facts. Numbers, charts, graphs. Measurements. You said the Eve Cluster cannot handle the load, I would love to see the numbers to back this up. All I am asking is for your numbers, you're the one who made the claims, not me. I said it would create overhead thus more stress. Any server can handle it, Don't try to strawman me. However one would have to question the sanity of any developer who would ever think of encrypting every single packet between a client and a server in this sort of situation since as already said, any form of encryption wouldnt really matter as its see-through. You'd effectively be completing extra instructions for no benefit. Way to optimize your code there buddy.
Miilla Minmatar Hulkageddon Orphanage	Posted - 2011.03.27 13:57:00 - [23] Originally by: yumike Originally by: Miilla Sure it is, you have to back up your statements with facts. Numbers, charts, graphs. Measurements. You said the Eve Cluster cannot handle the load, I would love to see the numbers to back this up. All I am asking is for your numbers, you're the one who made the claims, not me. I said it would create overhead thus more stress. Any server can handle it, Don't try to strawman me. However one would have to question the sanity of any developer who would ever think of encrypting every single packet between a client and a server in this sort of situation since as already said, any form of encryption wouldnt really matter as its see-through. You'd effectively be completing extra instructions for no benefit. Way to optimize your code there buddy. So, you don't actually have any measurements do you?
yumike	Posted - 2011.03.27 13:59:00 - [24] Originally by: Miilla Originally by: yumike Originally by: Miilla Sure it is, you have to back up your statements with facts. Numbers, charts, graphs. Measurements. You said the Eve Cluster cannot handle the load, I would love to see the numbers to back this up. All I am asking is for your numbers, you're the one who made the claims, not me. I said it would create overhead thus more stress. Any server can handle it, Don't try to strawman me. However one would have to question the sanity of any developer who would ever think of encrypting every single packet between a client and a server in this sort of situation since as already said, any form of encryption wouldnt really matter as its see-through. You'd effectively be completing extra instructions for no benefit. Way to optimize your code there buddy. So, you don't actually have any measurements do you? 36c
Rakshasa Taisab Caldari Sane Industries Inc. Initiative Mercenaries	Posted - 2011.03.27 13:59:00 - [25] Originally by: yumike not all data needs to be encrypted (too much worthless cpu overhead. especially on the server(s)) All sensitive data is already encrypted between the client and server. Don't post for things until you know what your talking about please. Nor should you... CPU overhead is low for encryption of such low-bandwidth connections, and even if it was a problem adding more servers would be easy.
Miilla Minmatar Hulkageddon Orphanage	Posted - 2011.03.27 14:00:00 - [26] Originally by: yumike Originally by: Miilla Originally by: yumike Originally by: Miilla Sure it is, you have to back up your statements with facts. Numbers, charts, graphs. Measurements. You said the Eve Cluster cannot handle the load, I would love to see the numbers to back this up. All I am asking is for your numbers, you're the one who made the claims, not me. I said it would create overhead thus more stress. Any server can handle it, Don't try to strawman me. However one would have to question the sanity of any developer who would ever think of encrypting every single packet between a client and a server in this sort of situation since as already said, any form of encryption wouldnt really matter as its see-through. You'd effectively be completing extra instructions for no benefit. Way to optimize your code there buddy. So, you don't actually have any measurements do you? 36c Well, I didn't mean your asscup size did I.
Karak Terrel As Far As The eYe can see Chained Reactions	Posted - 2011.03.27 14:03:00 - [27] Originally by: Rakshasa Taisab CPU overhead is low for encryption of such low-bandwidth connections, and even if it was a problem adding more servers would be easy. But it is still the wrong solution because the problem here are people that are just to dump and install every crap on their machines and not a lack of encryption. -- please consider to visit our w-space system, cake will be served immediately.
Badger Molester The Greater Goon Clockwork Pineapple	Posted - 2011.03.27 14:03:00 - [28] Originally by: Miilla Well, I didn't mean your asscup size did I. n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro
yumike	Posted - 2011.03.27 14:03:00 - [29] Originally by: Rakshasa Taisab Originally by: yumike not all data needs to be encrypted (too much worthless cpu overhead. especially on the server(s)) All sensitive data is already encrypted between the client and server. Don't post for things until you know what your talking about please. Nor should you... CPU overhead is low for encryption of such low-bandwidth connections, and even if it was a problem adding more servers would be easy. lol. of course its low. I don't recall saying it would be hefty.. Until you start having 1k people in local and every single packets encrypted like the OP seems to think would be viable. Because you know, the server doesn't lag already or anything. Let's just add in more worthless checks for no benefit.
Rakshasa Taisab Caldari Sane Industries Inc. Initiative Mercenaries	Posted - 2011.03.27 14:17:00 - [30] Originally by: yumike lol. of course its low. I don't recall saying it would be hefty.. Until you start having 1k people in local and every single packets encrypted like the OP seems to think would be viable. Because you know, the server doesn't lag already or anything. Let's just add in more worthless checks for no benefit. Encryption, and even just plain old unencrypted connections, are handled by a front-end load-balancing server. So the 'lag' you're imagining is just in your head, as the sol node won't even know there's encryption involved. Please learn stuff before posting.
yumike	Posted - 2011.03.27 14:23:00 - [31] Originally by: Rakshasa Taisab Originally by: yumike lol. of course its low. I don't recall saying it would be hefty.. Until you start having 1k people in local and every single packets encrypted like the OP seems to think would be viable. Because you know, the server doesn't lag already or anything. Let's just add in more worthless checks for no benefit. Encryption, and even just plain old unencrypted connections, are handled by a front-end load-balancing server. So the 'lag' you're imagining is just in your head, as the sol node won't even know there's encryption involved. Please learn stuff before posting. Uh, No one's talking about lag. Wow are you daft or something? Of course your going to use load balancing, But someone still has to decrypt the packets, That's gonna be the destination server which is gonna waste extra cpu time verifying that its encryption is intact for everysingle incoming packet, game_state change and broadcast for every single individual client. Which is gonna put a little bit more load on the server which then has to respond, rehash then send out that data. Instead of just taking the client at its word, and sending back out plain data. Pleasen learn stuff before posting.
Miilla Minmatar Hulkageddon Orphanage	Posted - 2011.03.27 14:25:00 - [32] Edited by: Miilla on 27/03/2011 14:30:06 Originally by: yumike Originally by: Rakshasa Taisab Originally by: yumike lol. of course its low. I don't recall saying it would be hefty.. Until you start having 1k people in local and every single packets encrypted like the OP seems to think would be viable. Because you know, the server doesn't lag already or anything. Let's just add in more worthless checks for no benefit. Encryption, and even just plain old unencrypted connections, are handled by a front-end load-balancing server. So the 'lag' you're imagining is just in your head, as the sol node won't even know there's encryption involved. Please learn stuff before posting. Uh, No one's talking about lag. Wow are you daft or something? Of course your going to use load balancing, But someone still has to decrypt the packets, That's gonna be the destination server which is gonna waste extra cpu time verifying that its encryption is intact for everysingle incoming packet, game_state change and broadcast for every single individual client. Which is gonna put a little bit more load on the server which then has to respond, rehash then send out that data. Instead of just taking the client at its word, and sending back out plain data. Pleasen learn stuff before posting. Keep digging, soon you may strike oil. SO, your entire argument is "wasting CPU cycles". I always wanted to meet somebody who knew it all. Your replying to my trolls is wasting CPU cycles, how about that? Not very efficient are you? Now I have. scratches that off 1001 things to do before I die
Rakshasa Taisab Caldari Sane Industries Inc. Initiative Mercenaries	Posted - 2011.03.27 14:38:00 - [33] Originally by: yumike Uh, No one's talking about lag. Wow are you daft or something? Of course your going to use load balancing, But someone still has to decrypt the packets, That's gonna be the destination server which is gonna waste extra cpu time verifying that its encryption is intact for everysingle incoming packet, game_state change and broadcast for every single individual client. Which is gonna put a little bit more load on the server which then has to respond, rehash then send out that data. Instead of just taking the client at its word, and sending back out plain data. Pleasen learn stuff before posting. Your post specifically mentions lag when 1k+ people gather in a system... And I am the one who's daft? Also, I just said that the frontend servers would take care of the de/encryption load, not the sol nodes. So there's no 'destination server' who ends up 'wasting cpu time' as you claim, as the destination servers (sol nodes) are behind the frontend servers. And the client has no problem doing decryption as the traffic is so low as to be insignificant in terms of CPU resource usage. You don't know what you're talking about, so stop digging that hole.
yumike	Posted - 2011.03.27 14:39:00 - [34] Edited by: yumike on 27/03/2011 14:46:35 Quote: Keep digging, soon you may strike oil. SO, your entire argument is "wasting CPU cycles". I always wanted to meet somebody who knew it all. Your replying to my trolls is wasting CPU cycles, how about that? Not very efficient are you? Now I have. scratches that off 1001 things to do before I die You had fun, I had fun. No waste in cycles at all ! nn Quote: Your post specifically mentions lag when 1k+ people gather in a system... And I am the one who's daft? Also, I just said that the frontend servers would take care of the de/encryption load, not the sol nodes. So there's no 'destination server' who ends up 'wasting cpu time' as you claim, as the destination servers (sol nodes) are behind the frontend servers. And the client has no problem doing decryption as the traffic is so low as to be insignificant in terms of CPU resource usage. You don't know what you're talking about, so stop digging that hole. you very well could have a system like that in place, you'd have to add an extra value for your internal destination service and another method between zone nodes to do hand offs. i misunderstood you, i thought your reason for trying to load-balance was network throughput not cpu load bearing. also there would be no load-balancing that server since that'd fault so geo and rr are out. that would have to be a pretty beastly box to not only take the entire client base through it, but to be re-encrypting and doing states for all those clients. but im sure you already thought of that right?
Awesome Possum Original Sin. PURPLE HELMETED WARRIORS	Posted - 2011.03.27 14:39:00 - [35] Originally by: Miilla Originally by: yumike not all data needs to be encrypted (too much worthless cpu overhead. especially on the server(s)) All sensitive data is already encrypted between the client and server. Don't post for things until you know what your talking about please. Considering they are sniffing out names that are in local via network traffic and having the virus scanners shut down the client. So you propose 2 call streams, one unencrypted and one encrypted or just fudge the data returned in the calls and use non SSL streams? Either way works for me as long as nobody can use external applications to see RPC data and use that to cheat automatically as they are doing today. I must've missed the devblog/fanfest panel letting us know this was happening. Link? ♥
Miilla Minmatar Hulkageddon Orphanage	Posted - 2011.03.27 14:41:00 - [36] Originally by: Awesome Possum Originally by: Miilla Originally by: yumike not all data needs to be encrypted (too much worthless cpu overhead. especially on the server(s)) All sensitive data is already encrypted between the client and server. Don't post for things until you know what your talking about please. Considering they are sniffing out names that are in local via network traffic and having the virus scanners shut down the client. So you propose 2 call streams, one unencrypted and one encrypted or just fudge the data returned in the calls and use non SSL streams? Either way works for me as long as nobody can use external applications to see RPC data and use that to cheat automatically as they are doing today. I must've missed the devblog/fanfest panel letting us know this was happening. Link? Eve search may have it, it was posted on here from but removed by moderators as the fact they cannot prevent this as it is happening at the Virus scanner and you cannot block them easily without upsetting a LOT of customers. It was on a leak from an Alliance forum, perhaps somebody has it here.
Jaldard	Posted - 2011.03.27 14:49:00 - [37] Originally by: Furb Killer Edited by: Furb Killer on 27/03/2011 13:43:41 Indeed, encryption is kinda useless if the client computer is 'compromised', then you can just read it directly from the memory. Not to mention since bots log for every neutral/red that jumps in that they put 330k char names in their virus definitions, risking pretty much every program randomly shuts down, when you can also read the screen way easier (yes i know miila is just a troll). Encryption is used to make sure you cannot sniff the stuff via routers in the middle, packet sniffers that sniff wireless connections, etc. If your client is compromised you cannot hide your data, it needs to be unencrypted in the memory otherwise the user can never use it. qft
Miilla Minmatar Hulkageddon Orphanage	Posted - 2011.03.27 14:52:00 - [38] Edited by: Miilla on 27/03/2011 14:53:48 Originally by: Jaldard Originally by: Furb Killer Edited by: Furb Killer on 27/03/2011 13:43:41 Encryption is used to make sure you cannot sniff the stuff via routers in the middle, packet sniffers that sniff wireless connections, etc. qft He must have some secret way of sniffing his Browser SSL traffic that we don't know about..
King Aires Privateers Privateer Alliance	Posted - 2011.03.27 15:05:00 - [39] Came here expecting Homage to the great show "Tales from the Crypt" Left with a migrane
Miilla Minmatar Hulkageddon Orphanage	Posted - 2011.03.27 15:07:00 - [40] Originally by: King Aires Came here expecting Homage to the great show "Tales from the Crypt" Left with a migrane Take a chill pill.
Arnakoz	Posted - 2011.03.27 16:09:00 - [41] Edited by: Arnakoz on 27/03/2011 16:14:57 Edited by: Arnakoz on 27/03/2011 16:10:48 i'm not sure what the debate is here. if either the client or server is compromised then they have access to the SSL certs/keys, and can thus decrypt the info readily. period, end of story. the ONLY thing packet encryption is good against is sniffer between you and the server. like a guy in a hotspot/or tunneled into your network, running wireshark. he doesn't have access to the keys that would be used to decrypt the data. while its possible to eventually do so, it would take so long that it would be useless. so the idea that it will stop bots from catching local info is just not plausible - b/c the bot would have access to the client and thus the keys. even if the keys were themselves encrypted they would be static on the client and thus (with some amount of time) be decrypt-able and then usable. so, nuet/red somes into local - sends it encrypted data to the server, the server in turn sends encrypted data to your machine, at which point the bot would be just as capable as the client of decrypting. even if it were possible to do as you're suggesting, bots can still use OCR and color recognition to see the non-blue in local on the screen. so you're talking more overhead for basically no purpose.
Dian'h Might Minmatar Cash and Cargo Liberators Incorporated	Posted - 2011.03.27 16:22:00 - [42] Originally by: Miilla Originally by: Awesome Possum Originally by: Miilla Originally by: yumike not all data needs to be encrypted (too much worthless cpu overhead. especially on the server(s)) All sensitive data is already encrypted between the client and server. Don't post for things until you know what your talking about please. Considering they are sniffing out names that are in local via network traffic and having the virus scanners shut down the client. So you propose 2 call streams, one unencrypted and one encrypted or just fudge the data returned in the calls and use non SSL streams? Either way works for me as long as nobody can use external applications to see RPC data and use that to cheat automatically as they are doing today. I must've missed the devblog/fanfest panel letting us know this was happening. Link? Eve search may have it ... perhaps somebody has it So what you're saying is that you have no documentation to backup your own claims, despite demanding such documentation from anyone who disagrees with you. - - - Dian'h Might - C&Ps resident "internet kleptomaniac"
Julian Assagne	Posted - 2011.03.27 16:28:00 - [43] snooping as usual i see?
Asperath Fernandez	Posted - 2011.03.27 16:36:00 - [44] It totally works that way. X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H* GGGAAAAAAAAAHHHHHHHHHHHHHHHHHH MY BROWSER NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
Lors Dornick Caldari	Posted - 2011.03.27 17:11:00 - [45] 1. Encrypting session traffic using for instance SSL isn't a big issue for the central servers since it could/would be handled by the load balancing proxies and could/would easily be offloaded to cryptographic accelerators. Just as it has for the last 10+ years in any server farm protected by SSL. See Wikipedia for more info on that. (As a side note, I've personally played with such hardware for at least 10 years, still have some early accel boards that I play with now and then). 2. Session encryption using for instance SSL wouldn't put any serious strain on client given that the amount of data transferred is very low compared to all other cpu intensive load that the client will have to deal with anyway. 3. Encrypting traffic to protect against sniffing on any of the end nodes is completely useless and actually silly if either part is compromised and/or and provides free access for the sniffer/analyser software since the private keys will be available to the sniffer/analyser. 4. As with most easy solutions, encrypting the client traffic would only work as a counter against very simple versions of a possible exploit. Any one who's invested time enough to create a nice working bot software wouldn't have to rely on such solution since it would be easy to integrate a sniffer into said software with minimal extra coding. 5. For anyone who's interested in the actual ramifications of the limitations of session encrypting I would recommend pondering the situations of most corporate/campus setups (and many home/small business ones). Where the network owner controls all routing and all nameservers and is able to direct any traffic anywhere and change any forward or reverse nameserver lookups. (How many of you have you own private key to verify the answer from your nameserver?). // Lors
Aeronwen Carys	Posted - 2011.03.27 20:11:00 - [46] Originally by: Miilla In order to prevent external sniffing applications from being used to cheat in eve (Virus scanners etc), I would call that all Traffic is encrypted to some level to prevent this snooping. Please? The keys required for the client to decrypt the traffic will be stored on your PC, this would render most forms of traffic encryption useless. Fail troll is fail.
Miilla Minmatar Hulkageddon Orphanage	Posted - 2011.03.27 20:12:00 - [47] Edited by: Miilla on 27/03/2011 20:13:33 Edited by: Miilla on 27/03/2011 20:12:47 Originally by: Aeronwen Carys Originally by: Miilla In order to prevent external sniffing applications from being used to cheat in eve (Virus scanners etc), I would call that all Traffic is encrypted to some level to prevent this snooping. Please? The keys required for the client to decrypt the traffic will be stored on your PC, this would render most forms of traffic encryption useless. Fail troll is fail. But only the eve client can connect, and attach's can be detected also so no piggybacking eve exe, the key is of no use if you do not know the algorithm, right?
Aeronwen Carys	Posted - 2011.03.27 20:16:00 - [48] Originally by: Miilla Edited by: Miilla on 27/03/2011 20:13:33 Edited by: Miilla on 27/03/2011 20:12:47 Originally by: Aeronwen Carys Originally by: Miilla In order to prevent external sniffing applications from being used to cheat in eve (Virus scanners etc), I would call that all Traffic is encrypted to some level to prevent this snooping. Please? The keys required for the client to decrypt the traffic will be stored on your PC, this would render most forms of traffic encryption useless. Fail troll is fail. But only the eve client can connect, and attach's can be detected also so no piggybacking eve exe, the key is of no use if you do not know the algorithm, right? Clearly you have no idea how much RMT is worth to people and to what lengths they will go to continue earning that money. As long as the keys and algorithms are stored on your PC they will be broken. It is as simple as you are.
Miilla Minmatar Hulkageddon Orphanage	Posted - 2011.03.27 20:19:00 - [49] Originally by: Aeronwen Carys Originally by: Miilla Edited by: Miilla on 27/03/2011 20:13:33 Edited by: Miilla on 27/03/2011 20:12:47 Originally by: Aeronwen Carys Originally by: Miilla In order to prevent external sniffing applications from being used to cheat in eve (Virus scanners etc), I would call that all Traffic is encrypted to some level to prevent this snooping. Please? The keys required for the client to decrypt the traffic will be stored on your PC, this would render most forms of traffic encryption useless. Fail troll is fail. But only the eve client can connect, and attach's can be detected also so no piggybacking eve exe, the key is of no use if you do not know the algorithm, right? Clearly you have no idea how much RMT is worth to people and to what lengths they will go to continue earning that money. As long as the keys and algorithms are stored on your PC they will be broken. It is as simple as you are. Keep raising the bar. Or should we just lay down and admit defeat like you?
Jenna Malone Caldari W-hat LLC	Posted - 2011.03.27 20:21:00 - [50] Posting in a thread with an absolutely clueless OP. Would do again!!!!! A++++++++++
Miilla Minmatar Hulkageddon Orphanage	Posted - 2011.03.27 20:22:00 - [51] Originally by: Jenna Malone Posting in a thread with an absolutely clueless OP. Would do again!!!!! A++++++++++ So, how would you solve this problem then? Suggestions welcome.
Jenna Malone Caldari W-hat LLC	Posted - 2011.03.27 20:25:00 - [52] Make this whole thread disappear as if it never happened. The fanciest doorlocks are ****ing useless, if the thief comes in through the window. Which would be anything using Windows' debugger APIs, in this case.
Ivana Twinkle GoonWaffe Goonswarm Federation	Posted - 2011.03.27 20:25:00 - [53] Originally by: Badger Molester Originally by: Miilla Well, I didn't mean your asscup size did I. n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro n1 bro not emptyquoting ******ed kid brother
Miilla Minmatar Hulkageddon Orphanage	Posted - 2011.03.27 20:26:00 - [54] Originally by: Jenna Malone Make this whole thread disappear as if it never happened. The fanciest doorlocks are ****ing useless, if the thief comes in through the window. Which would be anything using Windows' debugger APIs, in this case. Which are also detectable upon attaching to the process and will shut down the client and/or report the attempt.
Jenna Malone Caldari W-hat LLC	Posted - 2011.03.27 20:28:00 - [55] Edited by: Jenna Malone on 27/03/2011 20:28:08 Because there aren't any kernel debugger interfaces, which an user space process would be none the wiser of, if it was running or not, are there? How do you think crackers break copy protections? They use the same means as people who debug kernel and driver code.
Aeronwen Carys	Posted - 2011.03.27 20:29:00 - [56] Originally by: Miilla Originally by: Aeronwen Carys Clearly you have no idea how much RMT is worth to people and to what lengths they will go to continue earning that money. As long as the keys and algorithms are stored on your PC they will be broken. It is as simple as you are. Keep raising the bar. Or should we just lay down and admit defeat like you? I do not believe at any point I suggested giving up. Merely that your "superb solution" is nothing more than uninformed idiocy, something at which you seem to excel.
Miilla Minmatar Hulkageddon Orphanage	Posted - 2011.03.27 20:29:00 - [57] Originally by: Jenna Malone Edited by: Jenna Malone on 27/03/2011 20:28:08 Because there aren't any kernel debugger interfaces, which an user space process would be none the wiser of, if it was running or not, are there? How do you think crackers break copy protections? They use the same means as people who debug kernel and driver code. Yes and most likely in the new security drive they will block eve from running if a debugger is running, also will **** off Eve API devs in the process.
Terminal Insanity Minmatar Brutor Tribe	Posted - 2011.03.27 20:32:00 - [58] Originally by: Miilla Edited by: Miilla on 27/03/2011 13:28:38 Originally by: yumike Originally by: Miilla Considering they are sniffing out names that are in local via network traffic and having the virus scanners shut down the client. So you propose 2 call streams, one unencrypted and one encrypted or just fudge the data returned in the calls and use non SSL streams? Either way works for me as long as nobody can use external applications to see RPC data and use that to cheat automatically as they are doing today. Alright, Let's say you did that encrypt local. The key (Dynamic?) would still have to be sent to the client and pass through any virtual network adapter, firewall, virus scanner - bot. ANY peice of software can rebuild the routing table to go through it first. So at most encrypted or not, whatever peice of software between eve and the server would be compromised already. (Since in the case of a bot, it would just need a couple changes to keep working. and then voila it can still sniff network traffic for local.) Encryption in this case is not a viable solution. That's why the current standard for pretty much any mmo i've seen (including eve) is just to XOR encrypt passwords etc. It's easily broken if you have the key which both the client and the server must have. You discovered a universal exploit to hack all SSL connections? You should post your whitepaper immediately, the entire banking industry is in chaos and e-commerce is dying. You dont understand what he's saying. SSL exists only to protect you from man-in-the-middle type attacks, or people who are sniffing data remotely. If the hacker has access to ether the server or client, he can see the encryption keys and use them to crack the ssl connection easily. Its not an exploit, its just a fact of how these things work. If your local computer is compromised, no ammount of HTTPS/SSL/SSH is going to keep your private data safe. These methods only protect you against remote attackers.
Jenna Malone Caldari W-hat LLC	Posted - 2011.03.27 20:32:00 - [59] Edited by: Jenna Malone on 27/03/2011 20:33:08 User space processes, like a goddamn game like EVE, will never know whether a kernel debugger or a hack using kernel debugging APIs is running. As such, the game can not kill itself, because it won't notice. Unless it starts scrubbing its memory values every time they're accessed, and like that's not computing and memory intensive. And I don't see what EVE API devs have to do with it. They use web APIs. Stop raising issues around topics you're ****ing clueless about.
me me2	Posted - 2011.03.27 20:34:00 - [60] Originally by: Terminal Insanity Originally by: Miilla Edited by: Miilla on 27/03/2011 13:28:38 Originally by: yumike Originally by: Miilla Considering they are sniffing out names that are in local via network traffic and having the virus scanners shut down the client. So you propose 2 call streams, one unencrypted and one encrypted or just fudge the data returned in the calls and use non SSL streams? Either way works for me as long as nobody can use external applications to see RPC data and use that to cheat automatically as they are doing today. Alright, Let's say you did that encrypt local. The key (Dynamic?) would still have to be sent to the client and pass through any virtual network adapter, firewall, virus scanner - bot. ANY peice of software can rebuild the routing table to go through it first. So at most encrypted or not, whatever peice of software between eve and the server would be compromised already. (Since in the case of a bot, it would just need a couple changes to keep working. and then voila it can still sniff network traffic for local.) Encryption in this case is not a viable solution. That's why the current standard for pretty much any mmo i've seen (including eve) is just to XOR encrypt passwords etc. It's easily broken if you have the key which both the client and the server must have. You discovered a universal exploit to hack all SSL connections? You should post your whitepaper immediately, the entire banking industry is in chaos and e-commerce is dying. You dont understand what he's saying. SSL exists only to protect you from man-in-the-middle type attacks, or people who are sniffing data remotely. If the hacker has access to ether the server or client, he can see the encryption keys and use them to crack the ssl connection easily. Its not an exploit, its just a fact of how these things work. If your local computer is compromised, no ammount of HTTPS/SSL/SSH is going to keep your private data safe. These methods only protect you against remote attackers. Remote being outside of either End boundaries in the End-to-End scenario, end to end being the application (client) and the destination (server).
Aeronwen Carys	Posted - 2011.03.27 20:35:00 - [61] Originally by: Miilla Originally by: Jenna Malone Edited by: Jenna Malone on 27/03/2011 20:28:08 Because there aren't any kernel debugger interfaces, which an user space process would be none the wiser of, if it was running or not, are there? How do you think crackers break copy protections? They use the same means as people who debug kernel and driver code. Yes and most likely in the new security drive they will block eve from running if a debugger is running, also will **** off Eve API devs in the process. Assumption, as they say is the mother of all mess ups, again something you seem to excel at. CCP stated during the fanfest that they will only be "watching" the EVE.exe process and will NOT be watching any other process on your machine, most likely because to do so without permission would be the companies death knoll, and no-one is going to give a company permission to spy on their system 23/7. In short, at the moment there is no fool proof way to detect when someone is spying on either the network traffic coming in to the client or in the actual client itself. With any luck CCP will be able to work something out to kill of these bot users, but I highly doubt they will be coming to you for advice.
Jenna Malone Caldari W-hat LLC	Posted - 2011.03.27 20:39:00 - [62] Originally by: Aeronwen Carys Assumption, as they say is the mother of all mess ups, again something you seem to excel at. CCP stated during the fanfest that they will only be "watching" the EVE.exe process and will NOT be watching any other process on your machine, most likely because to do so without permission would be the companies death knoll, and no-one is going to give a company permission to spy on their system 23/7. The respective hack would just need to run at elevated priviledges while EVE continues to run as normal user as it does right now, to be hidden from the process list that EVE can retrieve. You don't get insight in the system wide process list as normal user. Same reason why task manager asks for admin rights, if you want to see everything.
Aeronwen Carys	Posted - 2011.03.27 20:42:00 - [63] Originally by: Jenna Malone Originally by: Aeronwen Carys Assumption, as they say is the mother of all mess ups, again something you seem to excel at. CCP stated during the fanfest that they will only be "watching" the EVE.exe process and will NOT be watching any other process on your machine, most likely because to do so without permission would be the companies death knoll, and no-one is going to give a company permission to spy on their system 23/7. The respective hack would just need to run at elevated privileges while EVE continues to run as normal user as it does right now, to be hidden from the process list that EVE can retrieve. You don't get insight in the system wide process list as normal user. Same reason why task manager asks for admin rights, if you want to see everything. Thank you for putting that in to slightly more technical terms for me
me me2	Posted - 2011.03.27 20:44:00 - [64] Originally by: Aeronwen Carys Originally by: Jenna Malone Originally by: Aeronwen Carys Assumption, as they say is the mother of all mess ups, again something you seem to excel at. CCP stated during the fanfest that they will only be "watching" the EVE.exe process and will NOT be watching any other process on your machine, most likely because to do so without permission would be the companies death knoll, and no-one is going to give a company permission to spy on their system 23/7. The respective hack would just need to run at elevated privileges while EVE continues to run as normal user as it does right now, to be hidden from the process list that EVE can retrieve. You don't get insight in the system wide process list as normal user. Same reason why task manager asks for admin rights, if you want to see everything. Thank you for putting that in to slightly more technical terms for me They are using GameGuard nProtect to do this. It runs as a rootkit.
Aeronwen Carys	Posted - 2011.03.27 20:45:00 - [65] Originally by: me me2 Originally by: Aeronwen Carys Originally by: Jenna Malone Originally by: Aeronwen Carys Assumption, as they say is the mother of all mess ups, again something you seem to excel at. CCP stated during the fanfest that they will only be "watching" the EVE.exe process and will NOT be watching any other process on your machine, most likely because to do so without permission would be the companies death knoll, and no-one is going to give a company permission to spy on their system 23/7. The respective hack would just need to run at elevated privileges while EVE continues to run as normal user as it does right now, to be hidden from the process list that EVE can retrieve. You don't get insight in the system wide process list as normal user. Same reason why task manager asks for admin rights, if you want to see everything. Thank you for putting that in to slightly more technical terms for me They are using GameGuard nProtect to do this. It runs as a rootkit. I wondered how long it would take for you to bring your alt in as support miilla. You are still a fail troll.
me me2	Posted - 2011.03.27 20:47:00 - [66] Sorry to burst your bubble but I just read it in the forum here. Hope it's not true.
Aeronwen Carys	Posted - 2011.03.27 20:48:00 - [67] Originally by: me me2 Sorry to burst your bubble but I just read it in the forum here. Hope it's not true. Yes of course.
Barakkus	Posted - 2011.03.27 20:48:00 - [68] Originally by: Jenna Malone Originally by: Aeronwen Carys Assumption, as they say is the mother of all mess ups, again something you seem to excel at. CCP stated during the fanfest that they will only be "watching" the EVE.exe process and will NOT be watching any other process on your machine, most likely because to do so without permission would be the companies death knoll, and no-one is going to give a company permission to spy on their system 23/7. The respective hack would just need to run at elevated priviledges while EVE continues to run as normal user as it does right now, to be hidden from the process list that EVE can retrieve. You don't get insight in the system wide process list as normal user. Same reason why task manager asks for admin rights, if you want to see everything. Um, no. You can get pretty much any process info you want without regard to privilege. If you want to hook a process you will need elevated privileges, but to simply enumerate them, you don't need elevated privileges. The reason the task manager requires admin is because you can do more with it than simply enumerating processes. I have designed into some software at work to grab every running process that has a window handle, visible or not in order to get system info when something goes wrong with one of our applications. You'd be surprised at what is actually running on your machine that even the task manager doesn't tell you, and it with simple user privileges. - - [SERVICE] Corp Standings For POS anchoring
Terminal Insanity Minmatar Brutor Tribe	Posted - 2011.03.27 20:51:00 - [69] Unfortunately, there is really no way to stop this type of cheating. There are so many numerous ways to figure out when a hostile has entered the system. Some dont even require encryption or modifying any sort of data. They just take a screenshot, and if theres a little red box, close the window. Poof. You could encrypt every piece of data with 10 types of encryption, and this method would still be unaffected. Solutions would include activly monitoring people's disconnects, and looking for players who frequently disconnect within a second of a hostile entering the system on a consistant basis. This type of monitoring could work, and is why i've never understood CCP's and other MMO companies reasoning for allowing their players to mirror their clicks across clients. Mirrored clicking would have been an awesome way to detect macrominers. Simply watch for several clients on the same IP who send the exact same command at the exact same time. Another solution would be to extend the ammount of time your ship is left in space after you disconnect. Perhaps extend the 15 minute timer to when you've engaged NPC's as well. This would certainly stop this!
Miilla Minmatar Hulkageddon Orphanage	Posted - 2011.03.27 20:53:00 - [70] Originally by: Terminal Insanity Unfortunately, there is really no way to stop this type of cheating. There are so many numerous ways to figure out when a hostile has entered the system. Some dont even require encryption or modifying any sort of data. They just take a screenshot, and if theres a little red box, close the window. Poof. You could encrypt every piece of data with 10 types of encryption, and this method would still be unaffected. Solutions would include activly monitoring people's disconnects, and looking for players who frequently disconnect within a second of a hostile entering the system on a consistant basis. This type of monitoring could work, and is why i've never understood CCP's and other MMO companies reasoning for allowing their players to mirror their clicks across clients. Mirrored clicking would have been an awesome way to detect macrominers. Simply watch for several clients on the same IP who send the exact same command at the exact same time. Another solution would be to extend the ammount of time your ship is left in space after you disconnect. Perhaps extend the 15 minute timer to when you've engaged NPC's as well. This would certainly stop this! . Perhaps extend the 15 minute timer to when you've engaged NPC's as well. This would certainly stop this! NO NO NO, i have been in a mission in a 2b ship and i DC'd on entering, came back with 30% hull!!! do not EXTEND this timer! Hell no! Dont even go there lol.
yumike	Posted - 2011.03.27 20:57:00 - [71] Saying your gonna watch the process is fine, but there's nothing too hard about getting around that either. to be completely honest it doesn't matter what kind of security measures the client side has - as the person who gets to tailor the software specific to your medium will always have the upper hand since your showing all your cards. - sniff network traffic - read memory - force a page file and read that instead - so long as client passes crc/patching (might require some packet mangling depending how rigorous the check is) you could effectively op out of all the security running in the client hell you could even setup a proxy that would be able to do it. have client connect to proxy. report bad checksum, proxy cleans the packet ships it off to server and sends the client back an 'ok go ahead and connect as normal' I actually threw something like this together for a certain workaround about ten years ago took all of two days. The only solution to the issue is a real gameplay change.. no amount of software level cleverness will really matter.
Terminal Insanity Minmatar Brutor Tribe	Posted - 2011.03.27 21:00:00 - [72] Originally by: Miilla NO NO NO, i have been in a mission in a 2b ship and i DC'd on entering, came back with 30% hull!!! do not EXTEND this timer! Hell no! Dont even go there lol. Your ship could warp away still. and remain at that 1au safespot for 15 minutes (allowing players time to probe and kill you) I think this would be the best solution. People already risk much more then 2b to this game mechanic during pvp. Extending it to pve isnt a bad idea if it cuts down on macro ***s.
Miilla Minmatar Hulkageddon Orphanage	Posted - 2011.03.27 21:03:00 - [73] Edited by: Miilla on 27/03/2011 21:03:29 Originally by: Terminal Insanity Originally by: Miilla NO NO NO, i have been in a mission in a 2b ship and i DC'd on entering, came back with 30% hull!!! do not EXTEND this timer! Hell no! Dont even go there lol. Your ship could warp away still. and remain at that 1au safespot for 15 minutes (allowing players time to probe and kill you) I think this would be the best solution. People already risk much more then 2b to this game mechanic during pvp. Extending it to pve isnt a bad idea if it cuts down on macro ***s. You think I wasnt clicking WARP? I tried but it was lagged due to the DC, not responding. Once you are locked, you cannot warp on disconnect for 15 minutes jesus do not extend that lol.
Aeronwen Carys	Posted - 2011.03.27 21:07:00 - [74] Originally by: Miilla Edited by: Miilla on 27/03/2011 21:03:29 Originally by: Terminal Insanity Originally by: Miilla NO NO NO, i have been in a mission in a 2b ship and i DC'd on entering, came back with 30% hull!!! do not EXTEND this timer! Hell no! Dont even go there lol. Your ship could warp away still. and remain at that 1au safespot for 15 minutes (allowing players time to probe and kill you) I think this would be the best solution. People already risk much more then 2b to this game mechanic during pvp. Extending it to pve isnt a bad idea if it cuts down on macro ***s. You think I wasnt clicking WARP? I tried but it was lagged due to the DC, not responding. Once you are locked, you cannot warp on disconnect for 15 minutes jesus do not extend that lol. Given up on the fail troll and switching subjects already miilla? I am disappoint. Though not surprised.
yumike	Posted - 2011.03.27 21:09:00 - [75] Originally by: Miilla You think I wasnt clicking WARP? I tried but it was lagged due to the DC, not responding. Once you are locked, you cannot warp on disconnect for 15 minutes jesus do not extend that lol. It doesn't matter if your client is locked up, as soon as the server sees the client isnt there, if it can you enter emergency warp. That is from my understanding Does this player have GCC? - if so they stay in space for 15 minutes. Is this player warp scrambled - y/n with obvious effect. He's not saying you wouldnt ewarp on a DC for example. Just that your ship would be in space for 15 minutes as if you had just ganked someone on a gate.
Miilla Minmatar Hulkageddon Orphanage	Posted - 2011.03.27 21:13:00 - [76] Originally by: yumike Originally by: Miilla You think I wasnt clicking WARP? I tried but it was lagged due to the DC, not responding. Once you are locked, you cannot warp on disconnect for 15 minutes jesus do not extend that lol. It doesn't matter if your client is locked up, as soon as the server sees the client isnt there, if it can you enter emergency warp. That is from my understanding Does this player have GCC? - if so they stay in space for 15 minutes. Is this player warp scrambled - y/n with obvious effect. He's not saying you wouldnt ewarp on a DC for example. Just that your ship would be in space for 15 minutes as if you had just ganked someone on a gate. You cannot warp on logoff if you are agressed, that takes 15 minutes. No GCC no scrambled. Just agressed. That is enough to cause the 15 warp delay timer. This was a change they did a few patches ago.
yumike	Posted - 2011.03.27 21:17:00 - [77] Originally by: Miilla You cannot warp on logoff if you are agressed, that takes 15 minutes. No GCC no scrambled. Just agressed. That is enough to cause the 15 warp delay timer. This was a change they did a few patches ago. I haven't played a ton since tyrannis, so any new lowsec mechanics are beyond me. But if that's really the case, if a workaround was implemented as a feature it might be a step in the right direction. Though the in-game work around will just be effected by another in-game work around (cloak).
Erichk Knaar Caldari Noir. Noir. Mercenary Group	Posted - 2011.03.27 21:23:00 - [78] ITT: People who don't pvp much. The 15 minute aggression timer goes into effect if you are engaged or engage another player. This is different to GCC, which will stack on top of the aggression timer, this gets applied for criminal acts. The GCC means gate/station guns and Concord (if in hisec) will engage you. Under the effects of the aggression timer, you still ewarp if you quit (or DC) if it is possible to do so (not tackled). I fully support adding this for pve, the bot problem would end p. quickly, as they would be decimated and it would likely become very un-profitable. I don't see it happening though, because the whining would be epic.
Barakkus	Posted - 2011.03.27 21:34:00 - [79] Originally by: me me2 They are using GameGuard nProtect to do this. It runs as a rootkit. And you can hide any hack you want pretty easily, Gameguard won't do **** for custom written stuff. If someone wants to write their own bot or hack there's nothing Gameguard will do to detect it since it relies on signatures. Here's a good example of something someone could use to hook EVE's process or hide a hack in a legitimate system process: http://help.madshi.net/madCodeHook.htm - - [SERVICE] Corp Standings For POS anchoring
Miilla Minmatar Hulkageddon Orphanage	Posted - 2011.03.27 21:36:00 - [80] Edited by: Miilla on 27/03/2011 21:37:06 Originally by: Erichk Knaar ITT: People who don't pvp much. The 15 minute aggression timer goes into effect if you are engaged or engage another player. This is different to GCC, which will stack on top of the aggression timer, this gets applied for criminal acts. The GCC means gate/station guns and Concord (if in hisec) will engage you. Under the effects of the aggression timer, you still ewarp if you quit (or DC) if it is possible to do so (not tackled). I fully support adding this for pve, the bot problem would end p. quickly, as they would be decimated and it would likely become very un-profitable. I don't see it happening though, because the whining would be epic. So why wasnt i ewarping? I wasnt scrammed, perhaps it thought I was still online but no modules active but I was effectively disconnected, well the client was running but not responding due to no internet traffic. Perhaps the best thing to do there is to actually kill eve? I suspect that wont fix that problem either on ISP disconnect, I use mobile connections sometimes. Perhaps the ewarp only works if the server Kills the socket.
Erichk Knaar Caldari Noir. Noir. Mercenary Group	Posted - 2011.03.27 21:37:00 - [81] Edited by: Erichk Knaar on 27/03/2011 21:38:51 Train better navigation skills. Actually, yes, the server has to realize you are DCed before you ewarp. This generally doesn't take very long.
Miilla Minmatar Hulkageddon Orphanage	Posted - 2011.03.27 21:39:00 - [82] Originally by: Erichk Knaar Train better navigation skills. I was aligned and my skills are high already.
Erichk Knaar Caldari Noir. Noir. Mercenary Group	Posted - 2011.03.27 21:43:00 - [83] Doesn't change the mechanics. Maybe CCP was trolling you by having the rats bump you.
Terminal Insanity Minmatar Brutor Tribe	Posted - 2011.03.27 21:45:00 - [84] Originally by: Miilla bleh obviously you do not understand how the timers work. When you are disconnected, your ship will automatically warp 1au away to a random safespot and remain there untill its timer is over. Unless, of course, you are warp disrupted/scrammed, in which case your ship will remain in its original location until the timer causes the ship to disappear, or you are blown up, or the scram is disrupted somehow. Considering these are just obvious troll posts i dont think its any use arguing about this anymore, since i've put a nail in your argument and now you're resorting to arguing with complete ignorance of the subject. Enjoy your ban or gag whenever ccp looks away from re-touching the turret models =P btw, i cant wait for the new backdrops! ****ing about time!
Hieronimus Rex Minmatar Infinitus Sapientia New Eden Research.	Posted - 2011.03.27 21:45:00 - [85] EASY SOLUTION: put a hostile cloaker alt in every bot system.
Miilla Minmatar Hulkageddon Orphanage	Posted - 2011.03.27 21:54:00 - [86] Originally by: Hieronimus Rex EASY SOLUTION: put a hostile cloaker alt in every bot system. I like this idea! AFK Cloaker in every nullsec system!
Dr BattleSmith PAX Interstellar Services	Posted - 2011.03.27 22:23:00 - [87] Edited by: Dr BattleSmith on 27/03/2011 22:26:15 Originally by: Miilla You discovered a universal exploit to hack all SSL connections? You should post your whitepaper immediately, the entire banking industry is in chaos and e-commerce is dying. Sounds like he's talking about ARP DNS cache poisoning. It's possible to insert yourself in the middle of a route and become the new certificate authority. Done poorly the user is warned that the cert is incorrect. Done in combination with a remote exploit and it's undetectable. Never leave your internet banking session logged in, always hit the logout button the moment you have finished. Never use Wifi for internet banking. Originally by: Miilla SO, your entire argument is "wasting CPU cycles". Individual users wouldn't notice the waste. CCP would have to put a wall of high end encyption machines into the infrustucure to deal with the massive amounts of CPU needed to decrypt that volume of traffic. "lots"

Pages: 1 2 3 :: [one page]

COPYRIGHT NOTICE
EVE Online, the EVE logo, EVE and all associated logos and designs are the intellectual property of CCP hf. All artwork, screenshots, characters, vehicles, storylines, world facts or other recognizable features of the intellectual property relating to these trademarks are likewise the intellectual property of CCP hf. EVE Online and the EVE logo are the registered trademarks of CCP hf. All rights are reserved worldwide. All other trademarks are the property of their respective owners. CCP hf. has granted permission to EVE-Search.com to use EVE Online and all associated logos and designs for promotional and information purposes on its website but does not endorse, and is not in any way affiliated with, EVE-Search.com. CCP is in no way responsible for the content on or functioning of this website, nor can it be liable for any damage arising from the use of this website.