安装 Steam
登录
|
语言
繁體中文（繁体中文）
日本語（日语）
한국어（韩语）
ไทย（泰语）
български（保加利亚语）
Čeština（捷克语）
Dansk（丹麦语）
Deutsch（德语）
English（英语）
Español-España（西班牙语 - 西班牙）
Español - Latinoamérica（西班牙语 - 拉丁美洲）
Ελληνικά（希腊语）
Français（法语）
Italiano（意大利语）
Bahasa Indonesia（印度尼西亚语）
Magyar（匈牙利语）
Nederlands（荷兰语）
Norsk（挪威语）
Polski（波兰语）
Português（葡萄牙语 - 葡萄牙）
Português-Brasil（葡萄牙语 - 巴西）
Română（罗马尼亚语）
Русский（俄语）
Suomi（芬兰语）
Svenska（瑞典语）
Türkçe（土耳其语）
Tiếng Việt（越南语）
Українська（乌克兰语）
报告翻译问题
此主题已被锁定 
讨论规则及指引
举报此帖
SMBIOS didn't work, still got kicked by VAC. :/
If I change my CPU fingerprint to one that does not have VT-d with the coresponding cpu features, VAC might not bother doing any checking for virtualisation.
I refuse to believe VAC is doing timing attacks and checking hypercalls...
VAC is attempting to detect malicious actors. You can bet it's checking hypercalls, doing timing attacks, and everything else in the book to detect Hypervisors. You will be able to get Windows to stop being able to detect it but not VAC.
4. ONLINE CONDUCT, CHEATING AND ILLEGAL BEHAVIOR
You agree that you will not directly or indirectly disable, circumvent, or otherwise interfere with the operation of software designed to prevent or report the use of Cheats.
I know it has been posted in the thread previously, but there it is again.
Technically they'd just being fixing a vac error, not evading a ban since you need to be cheating in the first place in order to be intentionally cicrumvating or interfereing with it. No where in the SSA does it say you can't fix a vac authentication error, nor that you can't use a hypervisor
I respect your opinion and post, though. Thanks.
The problem is that they never specified that using a hypervisor is against the rules. According to him they only said if he wanted play without errors he'd have to disable it.
Since there is no specification that he's not allowed to solve this issue in other ways that don't directly touch vac, or that using the hypervisor itself counts as circumventing vac, then there isn't anything illegal being done. Just a grey area :p
Not sure why you mention "intentionally" or why you consider this a "grey area"
The registrant agrees not to:
"INDIRECTLY CIRCUMVENT OR OTHERWISE INTERFERE WITH OPERATION" of VAC
Just "how" this happens does not need to be specified. it's a blanket clause which I fail to see how anybody could not understanbd covers any situation in which VAC operation is interefered with by any means.
It is similar in some ways to the blanket definition of "cheat" agreede to within the same contract. There are many who may argue that in their opinion and ideal/cultural experience, what constitutes a 'cheat' may not necessarily involve more stringent criteria than the catch-all generalised definition thus agreed - this does not in anyway, however, affect the status of the agreement or VAC's operation, and nor does it (nor even should it) affect Valve's policy.
This shouldn't be an issue. At no point was HV ever mentioned on the list of required specification for the product.
Why does it not need to be specified? Do we just legally declare vague things without specifying now?
How is it circumventing vac if it's not defined as such? The only information they gave was that it was causing an error with vac and can be fixed by disabling it. Nothing is said about how using a hypervisor or modyfying it counts as tampering directly or indirectly with vac. That's like saying if i modified how ccleaner works because I was getting an authentication error, I'd be messing with vac. I'd just be fixing the error as far as I'm concerned
I guess, first of all I should clarify what the specific platform setup is (I think most of the people just citing the SSA don't know anything about the tech) and why I use it. 2 years ago I had 2 computers below my desk (one older, SFF-styleLinux-machine and a cheap Windows-gaming-rig), with the Linux machine becoming quite sluggish even on day-to-day tasks and also quite uncomfortable to use with my new display (which needed HDMI 1.4 or DP, neither of which was cost effective to add with a new GPU). As my financial budget (and the "need" for a better gaming system) did not allow to just get 2 nice and shiny machines, I decided to give the VFIO-passtrough a try and ordered a R9 390 for my new Linux machine to passthrough to a Windows 10 VM. This worked flawlessly and now I'm able to concurrently use both Windows and Linux (which is "necessary", as I'm a student and in a little bit downtime on a gaming session I still can access my fully operational working environment) with the ability to shift around resources in a blink, fully utilising my system for whatever application I run, effectively saving me around 600€ (cost of i7+Board+Case+PSU+some disks+RAM) and yielding me a quite well-specced system (e.g. 24GB of RAM, which I can flexibly share between both systems with minimal downtime).
Now, as you know how and why I use it, I think it's time to look into the VAC issue with running in a VM from a basic point of view. Most people here argue that there is the possibility to tamper with the running system (as it's just virtualized, and all resources are managed by the host OS, e.g Linux) from the outside, thus allowing nearly undetectable cheats. This is clearly true, although I guess for it to work with the VFIO-subsystem (which depends hard on some sort of HW-managed isolation (VT-D)) you really have to put a lot (and I mean A LOT, if it's even possible) of effort into rewriting the software, which means you probably could just make enormously more money by just putting your evil hacking skills into getting out of your AWS-instance (which is probably at least as satisfying). IMHO this is just so highly unlikely that one uber-cheater on some-thousands of legit users (I guess the setup is indeed getting traction) is just not worth defending against it by non-obvious-measures, after all it's just a game (e.g. if you want to defend against it, just detect the VM and shut down, dozens of people "getting leaved" at 13:12 probably do harm the experience at least as much as a 1 in a million cheater...). Besides that, I think the people having the resources to do such attacks could also just drop into Intel-ME and then the HV-discussion doesn't matter anymore - it's just the same play of rewriting your HV all over again in another environment (same strings attached...).
For me, the whole thing which bugs me about this, is the complete ignorance of Valve on this issue. Apparently they don't do, what they rightly are allowed to do (still, whether this is justified or not is up to debate imo) and just tell you upon starting CS in a VM that you are not eligible to play (as some people mentioned, it's quite hard to fully stop even Windows from more or less directly recognising it's running in a VM). Instead they let you get into the game, just to kick you after some rounds, leaving you with a cryptic message, which (given by the nature of the problem) doesn't help you in debugging the problem, and additionally ruining the fun for the remaining 9 people in the game. If you complain/ask others and explain your problem, the customer support "monkey"/average forum guy probably googles QEMU/KVM and then echoes "hypervisor" not really appreciating the circumstances. Those are definitely more of a problem with the HV-configuration, in turn nothing else than a bug in the UEFI if you want a bare-metal analogy (I hope, all of you also come around in those discussions and tell them that they should just get the "supported" Steam-Box configuration) and can and should be fixed. If not by Valve, then at least by the users themselves by fiddling with configuration options and helping each other in forums as these (and seriously, if you can't add anything besides some basic pseudo-law-bs, just spare your time and don't crush any technical discussion in its infancy...)
Overall this discussion is quite ironic as it clearly shows how much the company - whose founder loudly argued against the walled-garden (with the hidden lock of TPM (though I guess, a proper chain of trust from the host TPM into the VM with a verified UEFI image could be a way to remedy this situation)) nature of modern windows operating systems - is itself interested in enabling people to play the games they want the way they want.
P.S: this started on the first of march, I was still happily playing, till I finally installed Windows 10 1607 around a week ago...
Firstly if VAC detected the VM immediately and aborted the game immediately this would provide cheaters with much faster turn-around times to check whether or not VAC can detect their current hypervisor cheat setup.
VAC has been explicitly designed to provide as little feedback as possible to cheaters. One of the ways it does this is delaying things it uses delayed bans, the VAC system only kicks you out of a game after a random interval once it knows that it is unable to detect what is going on, etc.
This is all standard procedure when you don't want to make it easy to reverse engineer what you are doing, and making it possible for cheaters to create undetectable cheats more quickly.
Secondly yes it's "just a game" and yet cheating is big business, there are websites that offer premium cheats with monthly subscriptions that cost more than a VAC protected game every month, and people actually buy these subscriptions and use those cheats to cheat for as long as possible ruining the fun of as many people as possible. Valve takes a hard-line on such things and as a result a number of things are not allowed (although they won't say exactly what is and what is not because as specified already VAC is designed to provide as little feedback as possible to prevent reverse engineering better cheats).
You can run most VAC secured games with VAC disabled (this will also allow you to run under a hypervisor), and there will almost always be servers available. Unfortunately they will be inhabited by all those people who have used cheats and have been banned by VAC. They are probably still using cheat, but "it's just a game" right? So I would naturally assume you won't have any problem playing with them (after all that is the kind of server you want the rest of us to play in if we weakened VACs protection).
All you need to do is put the -insecure flag on your executable. That's it. You'll be good to go to play inside your hypervisor.
From the opening post....
Support clearly told the OP to disable the software. Problem solved.
Any amount of time spent in this forum, and one can easiy see that there is no limit to what some will go through to cheat. We have seen cases where users have many accounts previously VAC banned, and there are players out there that will spend any amount of money seemingly on buying "undetectable" cheats.
For some, cheating is an addiction. When it comes to addictions, money means nothing. They will steal it if they have to, in order to support that very addiction.
You can play using the hypervisor. You simply have to use the -insecure flag and join in on a server that is insecure, as the good Darren said above.
In this case, there is absolutely nothing "cryptic" about it. The message seems very clear to me.....
In many cases, yes, the user has to do some troubleshooting to find the cause of the VAC authentication error. But in this case, that is not the case. Support already told the OP the issue. No special troubleshooting is needed. Just get rid of the hypervisor. Problem solved.
Cheaters also want to play the games "the way they want to play". VAC cannot tell the difference between the good player that does not want to cheat using the hypervisor and the ones that will cheat using it. So, it is not allowed. Simple.
1. We agreed not to interfere with how VAC does it's thing. I'm sure that at least we're all agreed on that.
2. We don't know how VAC actually works - we're all just guessing and only Valve know the actual details. This puts us in a position where all statements saying that hypervisors don't interfere with VAC must be taken as false based purely on the strength of Valve's own statements on the subject. This is simple logic. However, we can glean one bit of info from the SSA which actually makes this point completely irrelevant.
3. We agreed to let VAC scan everything on the physical host machine. Yes, we did - go read clause 4 of the SSA thoroughly if you don't believe me. As I (apparently) don't understand the tech at all, can someone please explain to me how you scan the underlying host from inside a virtualized environment?
ESXi 5.x, 6.x and KVM.
But I think the issue is CSGO specific. I tested TF2 in a ESXi 6.x VM, no bios passthrough, VMtools installed, in no way "hiding" the fact that the VM is a VM. And I had no issues.
I did another test using Workstation 12.5, again no "hiding" the fact that its a VM, using NAT for networking. And again in TF2, no issues.
I dont see anyone mention testing other VAC secured games.
But to me the bottom line is, VAC does not strictly forbid hypervisors or virtualized environments. CSGO may do so, and I would assume with a reason.
If you can setup a KVM system, you should also be able to see why VAC and virtualization COULD be an issue and how it could be abused.
To your comments:
Darren: I understand how this system is intended to work, but if I run a setup where even task-manager says "Virtual Machine: yes" I think that one could cut the BS and just hold onto the facts... If I had setup some elaborate configuration to mimic real hardware, I would not complain about this behavior, but this is like going to the club, waving with your pills, still getting waved through, just for security to turn up at 3:30 and pull you out of a pile of drunkards for being drugged. It's utterly stupid and schizophrenic, just ruining the thing for a lot of people (I don't think that the 4 people playing with me, were very happy about their teammate leaving 2/3s into the game...).
Concerning the "hypervisors enable cheating" argument, that's just pure paranoia at the moment, no one has done it so far (?) and while it's still very well possible to do this, I think at this point you should then also wonder about all the nice gadgetry in your firmware and chipsets you use being able to do exactly the same things (or some DMA devices happily reading out your memory), a hypervisor can do – if you think this to the end, you end up with a sealed CS:GO-box, you can then send in every-year for integrity assurance. A great triple "hooray" to Saint Gaben!
The Giving One: the support fix is no fix, because it basically tells you to throw your PC away. Additionally I can't disable a HV, because it's the software running the software and I still don't get, how the support and think to "fix" this by disabling the software, as it's not possible... If Valve does not want you to run in a virtual environment, they can just say so, consult my reply to Darren for why this is stupid in the current state;
if the problem relates not to the HV per se, but only to the specific behavior of the "virtual system" (as I see it), this thread should not be filled with you repeating yourself, but with constructive configurations tips (I'd say play with the timers, but don't thinks it's worth my time...).
Considering the "insatiable cheaters": I doubt that there is a lot of people, who really want to buy a ~600€ computer and then have the technical knowledge and patience to install and maintain the contraption (I guess, this setup is not good for much else then) of "cheat-enabled-VFIO-gaming-rig" – even given the availabilty of a patched version of the HV which someone wants to sell in a source code bundle (because I doubt that a precompiled run-everywhere package for this kind of thing is really feasible).
Brugeira: I guess, you don't get the point that apparently Valve is not banning the VM, but it's behavior. And just as I hope you don't tell people to remove every software listed on the VAC-page for forever and don't think that working around it (w/o modyfing Valve's software) is... a "crime" (?!), let people do this. As you were so kind and provided numbered bullet points:
1) how do I interfere with VAC if I change the timer settings of my HV – VAC can still do, whatever it wants....
2) yeah, we guess, and if we guess right and this solves the problem, this is totally ok. Your understanding about the whole thing is quite interesting if you tell me that the hypervisor is "interfering" with the VAC software. Does it modify the binary or it's runtime environment!? - No. So does it interfere!? No, VAC can run and still do all its rootkit stuff (as it does).
3) I read it. It does not say so. There is a lot of talk how I should not modify their software but none that gives them power to do whatever they want (e.g. "scan everything", which is basically rootkit behavior and I would really love some people bring such clauses in front of an european court :)) or somehow limits me in my choice of software I run besides it. It just says: don't modify the sw and that they can cancel the contract whenever they want (like with every free "proprietary" software).
So in the end: bye Valve, hello GoG and Humble-DRM-free-sales.
budozero: ack. Still no problem to think about fixes ;).