PoC source code can be found here: https://github.com/kite03/echoac-poc.
- Number: CVE-2023-38817
- Vendor: Inspect Element Ltd (13017981), trading as Echo.
- Affected Products: echo.ac AntiCheat scanner tool.
- Affected Versions: echo.ac - <126.96.36.199, echo_driver.sys - All shipped versions.
- Affected operating systems: 64Bit versions of Windows from; Windows 7 to Windows 11.
- Mitigation: Do not use the software, and add driver signatures to blacklist.
- Protocol (Whanos): GitHub Link - Initial discovery, first contact with echo.ac, and exploit development.
- kite03: GitHub Link - Exploit development, and writing.
- Lemon (Wishes to stay anonymous): - Exploit development and assistance.
echo.ac is a commercial "screensharing tool", marketed and developed mostly for the Minecraft PvP community, but also used by some other game communities - such as Rust. A "screensharing tool" is a program developed to "assist" server admins in identifying if someone's using cheats or similar banned external tools in-game, effectively a single-run Anticheat scanner.
As such - these programs execute numerous intrusive scans on a users computer, while being deliberately very vague of what they data collect and why.
Additionally, as these programs are for (terrible) Admins to "check if a user is cheating", they are given to the user under duress - as users will be threatened with a permanent ban from the server they were playing on if they refuse.
Furthermore, these users are usually quite young and do not understand the issue of running random executables on their personal computer (see the current plague of malware on Discord presently).
When this point was brought up to them, they reacted aggressively and attacked us for criticising this practice. We think that it is unfair that users can be banned for not wanting to run this invasive software.
I (Whanos/protocol) also attempted to disclose this exploit to the CEO in private before disclosing it publicly - to allow ample time for the developers to patch it, but they brushed me off, saying that it's not a bug - and then banning me from their discord server.
Our interactions with echo are documented in this blog post, after the bug
Thanks for reading!
echo-free.exe - their client app, deploys a Kernel driver named
echo_driver.sys to a newly generated folder in
%TEMP%. This driver appears to be used mostly to scan and copy target processes memory so it can be analysed later to "check for cheats" (glorified string-searching tool...)
Unfortunately, this gaping security hole of a driver has no access controls on what programs can access it, making it trivial to abuse for all manners of exploits on the system.
Simply by using the following series of IOCTL codes, a local attacker can control the driver to Read and Write memory on the system. We abuse this in our PoC to read the Kernel's EPROCESS/KPROCESS block in memory, and then perform Access Token Theft using the driver - copying it into a newly spawned shell of ours, which immediately escalates it's privileges to
nt authority\system (Highest system permissions).
- Firstly, create the service and start the driver using
sc create EchoDrv binpath=C:\PathToDriver.sys type= kernel && sc start EchoDrv.
- Next, get a handle to the driver, which uses device path
- Now execute IOCTL code
0x9e6a0594to bypass an internal check - shown later.
- Set the PID to the exploiting program by using IOCTL code
0xe6224248, this returns a HANDLE to your provided PID.
- Finally - you can use IOCTL code
0x60a26124to make the driver execute
MmCopyVirtualMemorywith your given arguments, allowing the arbitrary Memory Read/Write.
One thing to note is that the driver does not have a "write" function, but you can simply flip the
from address parameters to "read" your data buffer into another program just fine.
- Stop and remove the driver from your system by executing
sc stop EchoDrv && sc delete EchoDrv.
Why This Works
The first IOCTL calls this function, which we seems to sets the output buffer for some internal BCrypt operations we frankly do not care about. Without this call the driver does not listen our commands.
The next IOCTL looks up the PEPROCESS data of our given process' PID and stores it internally - then returns a HANDLE which much be provided in all subsequent requests. This appears to be the driver's "Access Control" - which is frankly, awful.
Finally, we can use the driver's Copy Memory IOCTL to do whatever we want with memory. Our parameters are directly fed into a CopyMemory function - which basically is just a wrapper for MmCopyVirtualMemory.
Specifically, MmCopyVirtualMemory is an undocumented Windows API function which allows a Driver to copy the Virtual memory of a given process.
Also, the function is being executed at Kernel level - indicated by parameter
0 in the call above - which is
In short, this means our exploit allows direct access to a Kernel mode memory context via simple IO requests from user-mode.
As you can see, the complete lack of access control or validation causes this driver to become effectively - A "Security-Hole As A Service".
Extra Driver Info
- The driver was built on June 18th 2021, so we can presume that all client program versions from that point onwards are vulnerable.
- The vulnerable driver's SHA256 hash is
- The vulnerable driver's MD5 hash is
There are several uses for this exploit - having Kernel level memory access to anything on the system is very dangerous and abusable!
For our example, we perform a privilege escalation attack using it.
In the GitHub repository there is a working Privilege Escalation attack which allows an attacking process to make any process run with
nt authority\system privileges.
This is dangerous because this has more permissions than any other user on the system, which could be easily used by malware to cause much more damage!
Additionally, this exploit can be (and has been) extensively used for Cheating in video games - it turns out that this driver was seemingly whitelisted by Easy Anti Cheat (EAC) - one of the most popular commercial Anticheat providers - allowing cheaters to trivially cheat in games protected by it!
This is due to the fact that back in ~May 2022, hundreds of echo's own users were banned by EAC in series of large ban waves - due to echo's methodology of mass-memory scanning all programs on a user's computer (a really big no-no for all Anticheats!).
Somehow, echo managed to convince EAC to unban all the users affected by this - and seemingly whitelist their driver from being detected - all the whilst not patching the arbitrary memory Read/Write exploit described above!
In fact, after speaking with some cheater developers about this - some were abusing this to cheat in games such as Rust for almost a year prior to this writeup!
- Program protector (PPL stripper/adder) by sam: https://www.youtube.com/watch?v=TOVb-lyBNBY
That's the end of the exploit writeup!
Thank you very much for reading.
The following section documents our conversations with the echo team and CEO, for clarity.
First and foremost: Please do not harass anyone mentioned in this document. While some people might've gone too far in some aspects - harassment is not okay. Do not stoop to that level - thanks.
Echo and Data
Echo.ac is pretty quiet about the data it collects and why. Their own ToS on their website and scanning app does not tell us what data is scanned and what exactly they will do with it.
ToS archived as of writing (~29th of June 2023):
There are only 2 hints we get as to the data that they collect.
First are the result pages people publicly share in their discord. An example of which can be found here.
Not much information can really be extrapolated from here, unfortunately.
(Screenshots, in case they delete this scan):
Second, the policy that they publish.
This policy is supposed to provide some transparency as to what data echo collects. It is assumed that, for ethical reasons if nothing else - a rough outline to the methods used to collect data are stated. Unfortunately, this policy is not trustworthy.
This is because Echo has changed is policy regarding what they collect after the following interactions.
Note that they still collect this data, they just don't tell their users anymore.
They aren't being open as to what information they collect, and are clearly happy to hide things from their policy if it helps them evade criticism!
Consider the following tweet.
Since Bulbasaur's tweet was posted, they removed the line in their website about storing the memory of processes on the computer, but yet they still do it!
After that tweet, they updated their "What do we log" FAQ:
My Initial Contact
On the 24th of May 2023, I (protocol/Whanos) published a tweet to my personal Twitter account (@WindowsKernel) - sharing my concerns with Echo.AC, as well as sharing a tria.ge link, which reported suspicious behaviour from the Echo.AC client.
My tweet - albeit being a bit debatably sensationalised - didn't contain anything untrue, and was more of a general warning to not execute applications random server Admins want you to run on your PC.
At the time, my tweet only had interactions from my own followers - as I mostly post about cybersecurity to a relatively small audience.
However - shortly after it was posted, the CEO of the company behind Echo.AC - Josh, and some developers and associates of Echo.AC responded with what could frankly only be described as hate-mail and bullying.
Most of these replies are still viewable on the original tweet, but as a precaution I screenshotted them for posterity.
Firstly, I received this DM from Josh, the CEO.
I also received a frankly asinine amount of hate-mail replies from users that never followed me beforehand!, meaning that they were sent to my tweet by other users.
One of them even called me the r-slur (Censored here). Great.
After this, I was blocked by the company's official Twitter account. Great response!
The Disclosure Attempt
Steeled by this insane series of interactions, my friends and I (credited at the top) started digging into their driver to look for vulnerabilities.
Unsurprisingly, it was trivial to discover the exploit, considering the visible lack of Kernel driver knowledge. It's basically just a copy-pasted Cheat Driver.
After we found the bug, we started preparing this writeup - and in the meantime I wanted to responsibly let the CEO know about the bug, so they can fix it before we release the writeup.
Shockingly, they brushed it off as it not being an vulnerability, and passive-aggressively mocked me, before banning me. Lovely!
My conversation with the CEO follows, dated the 29th of June, 2023.
After this, I was banned from their Discord for the crime of attempting to responsibly report a vulnerability... lol?
Overall, this entire situation is very damaging to your reputation.
How would your users feel if they realise that actual real issues in your own product is met with abuse and ignorance? - you should know better, Josh, especially as you are the CEO of an Anticheat company - which requires the trust of your users to exist!
Fin - Thanks for reading!
Contact me here.