_mat_

I would not count on that at all. AMD CPUs are using their LAPIC timer for the System Clock Interrupt in Windows 8+. That timer completely depends on the ref clock. The same goes for the TSC on AMD, it's basically the same timer source as the LAPIC timer. So if there is any possibility to change the ref clock, it will result in skewed benchmark results.

The vulnerability has been fixed now and will be released with BenchMate 0.9. I can't say the same for all other benchmarks that either enforce HPET (GPUPI, x265) or just use QPC with "useplatformclock" enabled (Geekbench for example). I don't have the time right now, but my best guess is that even kernel tick related timer functions can be tricked with this as well. That would include 90% of all benchmarks here on HWBOT. 0.0 did this with very little programming experience and he used a third party driver, so he didn't need kernel driver or reverse engineering skills. @GeorgeStorm What is HWBOT going to do about that?

Hey, thanks for the report. I can't see anything wrong in the logs. What do you do to get the error? Is it reproducible?

Thanks for pointing this out, I've simply overlooked it. It's certainly an interesting attack vector, that is sadly allowed by the specs of HPET made by Intel and Microsoft. It's also NOT a BenchMate specific problem, all benchmarks relying on HPET will be vulnerable by this. And to put this in the right perspective: A driver needs to be written, that has low-level access to HPET. So this is not everybody's cheat, some big hurdles need to be overcome to do this. I'm in contact with 0.0 and we are working on a solution.

If you upload the OS image I can take a proper look. Never tested it with a bootable stick.

That should work then because the result is fetched from the integrated IE browser window. The problem with the tryout version is that it directly opens the default browser with the already uploaded online result. The new version fixes that by setting its hooks deeper into the benchmark. I sadly can't disclose it because everything that's done is actually a vulnerability of the existing benchmark. And thanks for your Patreon donation! You are officially the first person on this earth that donated to BenchMate. I love it, thank you very much!

This is a feature request for the HWBOT submission API. BenchMate can make use of it, if it's there. Another great feature would be to add the submission comment to the API as well. @Devroush @Leeghoofd

Holy shit, those photos! Get well soon!

Short update: In the last two days I rewrote the Geekbench support to include tryout versions as well. This was for sure a motherfucker, but it's even more stable than ever and independent of any GUI activity. On a more important note: I've also encountered a problem with ensuring reliable time measurement and upholding the unified security standard on Geekbench. As there is an inner benchmark executable it is not correctly set up yet to support the whole range of security vulnerabilities. I'm in the process of fixing this to make it completely compliant to BenchMate's standards. My recommendation is that Geekbench results made with all currently available versions of BenchMate should have their points disabled and remain as test results. Sorry folks, but that's why we needed this test competition!

There is an internal bug report tool, people! Please use it! The error message is far from enough to take a look at this!

Nice one, about time the Titan V is pwnd! What's going on with the hardware shaming here?

Will look into it, thanks. I kind of doubt that the old minimizing trick will have an impact on the score for CPUs with at least two physical cores enabled.

Please report it as false positive. It certainly is. The bit.ly-URL is btw just a download for 0.8.1, so no new version for now.

@tyger81 Please submit a Bug Report (executable right next to BenchMate's) so I can have a closer look! Regarding the other reports: Thank you, I will have a look!

Will be fixed soon, please be patient.

I'm pretty sure that the old driver was still loaded without reboot and that's why the service failed to handle new requests. I will write an updater next that will take care of properly reloading everything without a reboot. It will be necessary anyways. I guess it's the same there. The problem is that I need some entry point to know when a run has been started and ends. That's easy for most benchmarks, but CINEBENCH has a custom UI so I can't capture any WIN32 API function from button inputs and the likes. We'll find a way.

The service is needed to guard a 32 bit benchmark from a 64 bit environment. I can't overcome the WOW barrier without it, so if the service is not working, 32 bit applications will not start. The "BenchMate Security Service" can be found in the service list (type services.msc in the taskbar's search field). It should be running while BenchMate is active. A Bug Report (from the menu) would be nice after you tried to start a 32 bit application and it's not working. Otherwise it's hard for me to determine what is happening here.

Thanks! BenchMate 0.8.2 will follow in the next few days. Will add some love for Windows 7, fixes Geekbench 3.1.5 and allows submission with Geekbench 4 Trail version. There is also a bug currently with Cinebench. If you run it minimized it can't capture the score. Same thing happens if you use a very high priority class on CB, the system will be so swamped that I don't receive a notification for the start and/or the end of the run. Please be aware that this could happen. There are also no bugs currently that invalidate a verified run. That's a good thing.

Thanks, I will have a look at it. SLI/Crossfire information is determined by using the native driver libraries NVAPI (for NVIDIA) and AGS (for AMD). A bug report via the integrated "Bug Report" functionality (in the menu) might come handy to be able to see what is going on here.

You need the latest version to be able to upload the files correctly. Please download 0.8.1 from here: https://www.overclockers.at/news/benchmate-beta-tester-gesucht It's in German but the download links are right under the first image. @Leeghoofd The news on the main page link to the download of version 0.8 directly. I strongly encourage to use the latest version of BenchMate, it fixes many bugs. Maybe redirect it to the site above as well? I'm working on a microsite for BenchMate that will soon be ready and in English of course.

Then I would need the client.log in the logs directory please. Please send it to matthias at hwbot.org!

Hey, Bruno! You need to press the "Save Result" button to take a proper, BenchMate verified screenshot. It will show the full run statistics and the score. Afterwards it can be uploaded to the temporary BenchMate category for Geekbench 3 by pressing "Submit to HWBOT" (or right click on the result in the result list, you can also view your screenshot there).

BenchMate shouldn't have a different rule set, I agree. It's here to make life easier for everybody (except me). That's why it should need NO rules at all. Just run your benchmarks with it and you are fine. That's by the way exactly what you always wanted, Leeghoofd ... "Just click the damn run button!" The question is what do we need to do to get there in the eyes of the HWBOT moderation team. @Leeghoofd I will add texture file hashing for CB in the next minor version, 0.8.2. When a new benchmark pops up, it should never be added without knowing what it does, which vulnerabilities it has and how reliable it is. Otherwise things can go south quickly, results have to be removed, maybe the whole benchmark. I've seen this happening too often and it leads to a lot of bad blood. So we should work together on ensuring to avoid that at any cost. When adding new benchmarks to BenchMate I ensure that they are in fact validatable. If they are not, we can contact the author and talk about the necessary changes. That's an important communication and verification process that HWBOT misses right now. Also important to note here is what happens when a benchmark is added to BenchMate. As soon as it's in a lot of well-known vulnerabilities are already handled. Timer troubles are gone instantely and results can be submitted to HWBOT without any additional work for integration. Do you see how easy things could be? About XTU, please post a screen to clarify this. @cbjaust I guess you are talking about all the information that's shown on results like this: https://valid.x86.fr/2xfi08 BenchMate is currently designed to detect everything that's necessary for benchmarking. Complete system analysis will be added further down the road by adding more and more information as needed.

Guess it's just another upload of the same result. The debug version can do that to make my life easier when testing.

You really need to think different here. One of the main goals of BenchMate is to be able to make bench life easier by unwinding the rules and removing everything that is no longer necessary. That's easily possible in this case. So the important questions here are: Do we need to see the Cinebench rendering? No, we actually don't and this shouldn't be the way to moderate Cinebench anyways! There are multiple ways to show a fullscreen image instead of the real benchmark window and desktop. This could be an application that does this or just a desktop wallpaper to trick the screenshot. It's impossible to verify such a cheat and even if I would try, it would turn into a cat and mouse game. But we don't have to go down that road because there are other, much better solutions to check that everything has been rendered correctly. We can check the file hashes of the textures and even better every other file that CB uses for the run. Additionally we can upload a second screenshot that shows the window buffer of the CB window. That's also not the prefered method because it's easy to write into that buffer at any time, but that won't be as easy as a fake wallpaper and if used additionally to the file hash check it adds protection and a nice way (for fellow benchers as well) to inspect only the benchmark window if it's overlapped by anything. This would completely remove the many problems we have with overlapped benchmark windows. We would end up with less rules for the screenshot, less to moderate and more valid results. Do we need the CPU-Z windows? As you can see for yourself on this screen they have to be placed very carefully so they don't overlap anything important. You have to play around with the window's order to get it right. Not to mention that it takes time to open two to three CPU-Z windows and fiddle around. I think this was fine when we had no alternative, but we have the possibility to improve the process right now, so why don't we use it? So the question to ask here is, what information do those CPU-Z windows offer that BenchMate doesn't have already. First of all the information on CPU-Z is captured at the time the screenshot was made and not during the benchmark run itself. The CPU can be downclocked manually after the run or as it often happens with air and water results it has to downclock because either the CPU gets too hot there was an AVX negative ratio applied and the benchmark used AVX. Same goes for voltages of course, they can differ greatly due to loadline calibration settings, dynamic voltage options and the likes. So the information is outdated and not very reliable. But there are also things it does offer, that are not implemented in BenchMate. Three things actually: Bus frequency and ratio (can be added easily to BenchMate) A second level of CPU name detection by checking the CPUID family, model and stepping ID (can be done as well in BenchMate, but will take more time) The memory's Command Rate (currently not part of the HWiNFO SDK, but I'm sure it can be enabled) These are the things that need to be discussed here to make our lifes better. Shrinking the BenchMate window to a stoplight is definitely not what I had in mind for creating a new standard of benchmark validation and that's why I'm not going to do that, especially for wrong reasons.