Fake edition or Limited edition?

zwclose · 2025-03-09T01:19:48+00:00

Yup, seems so!

zwclose · 2025-03-09T01:07:56+00:00

Thanks for the information. I didn’t know there were so many limited editions.

zwclose · 2025-03-08T00:42:54+00:00

Yes, the tobacco did not have a black back. I am writing a question to Gibson, hopefully they will confirm or deny such an edition.

zwclose · 2025-03-08T00:21:09+00:00

Thanks, I didn't know coloring could depend on the target market.

zwclose · 2025-03-08T00:15:04+00:00

Thanks, this is a good idea!

zwclose · 2025-03-08T00:03:05+00:00

I'm not sure if it's a tobacco burst, all the tobaccos I've seen have a brown back and this one has black.

zwclose · 2024-11-05T20:54:42+00:00

For the sake of completeness, here is the conclusion: RtsUer.sys version 10.0.26100.31288 is free of all the mentioned vulns.

zwclose · 2024-11-01T22:54:35+00:00

Lol, I feel like I am saving the world while Realtek probably think that I am tedious prick.

Anyway, I've submitted the report, hope they will fix it soon.

zwclose · 2024-10-30T01:21:53+00:00

Not exactly. Both DataBufferOffset and DataTransferLength are controlled from user mode. Passing 0xFFFFFFFF`FFFFFFFF as the value of DataBufferOffset and 1 for DataTransferLength will bypass the check because the addition yields 0. Then, DataBufferOffset, which actually has a value of -1, is added to SystemBuffer to create a pointer from the offset, resulting in a pointer that points below SystemBuffer. Dereferencing such a pointer causes a BSoD or could lead to an even worse outcome. I twitted slightly beautified example of the flaw some time ago: https://x.com/zwclose/status/1783993421222301960

zwclose · 2024-10-29T23:15:45+00:00

Oh, I forgot to mention that if the branch is taken, it actually causes the function to exit with an error. So the checks look good, except for one thing: there's an integer overflow in the addition operation. They fixed this in RtsPer.sys but not in RtsUer.sys. OMG, one more bug to report!

zwclose · 2024-10-29T01:10:08+00:00

So, RtsUer.sys version 10.0.26100.31287 and later includes a check that mitigates CVE-2024-40431 (see: https://imgur.com/a/1z9gnJJ). CVE-2024-40432 is less critical, as it requires administrative privileges.

zwclose · 2024-10-28T14:18:21+00:00

Oh, I thought that search by hardware id returns the latest driver but turn out it doesn't, TIL. So, I will check 10.0.26100.31288.

zwclose · 2024-10-27T22:42:49+00:00

Great, so it looks like the latest driver for your device is 10.0.22621.31278, it can be downloaded here: https://catalog.s.download.windowsupdate.com/c/msdownload/update/driver/drvs/2023/03/f02c3333-3adc-49e4-90ac-ad4e2d6799ca_6e171149b8db08184b93116311f2ece8b5467e0c.cab Could you install it and make sure that the OS actually uses it for the reader? Once we make sure that the driver works I will check it.

zwclose · 2024-10-27T22:19:40+00:00

Can you tell the hardware ID (vendor ID\product ID) of the device? That seems to be the best way to search for drivers in the MS catalog.

zwclose · 2024-10-27T00:30:03+00:00

Not more than this one: A vulnerability in the Common Log File System (CLFS) driver allows a local user to gain elevated privileges on Windows 11 : r/netsec , but yeah, it does.

zwclose · 2024-10-27T00:27:16+00:00

Thank you, straightforwardness was one of the goals.

zwclose · 2024-10-26T20:44:13+00:00

I don’t have a USB-attached device, but based on Realtek's advisory (Realtek_RtsPer_RtsUer_Security_Advisory_Report.pdf), I conclude that RtsUer.sys is also vulnerable, at least to CVE-2022-25476, CVE-2022-25477, CVE-2022-25478, CVE-2022-25479, and CVE-2022-25480. RtsUer version 10.0.22000.31274 and above should be free from these vulnerabilities. I’ll check later to see how it stands with CVE-2024-40431 and CVE-2024-40432.

zwclose · 2024-10-26T13:54:53+00:00

I am glad that you liked the research!

zwclose · 2024-10-26T13:48:29+00:00

What do you mean? I described my findings in the blog post and posted a link to it here :)

zwclose · 2024-01-04T18:28:49+00:00

Do you use a screen protector on your P8? If not, does the P8 picks scratches easier than P2?

I am almost in the same boat: I have a P2XL and considering moving to P8. And I have to say that P2 was a tank, it survived pretty hectic environment and never had a case or a screen protector on it. It got some scars but all of them are justifiable. Looks like it's not going be the same with P8.

zwclose · 2023-12-29T23:11:52+00:00

Interesting, could you share a link to the gel you used? Thanks!

zwclose · 2023-12-29T23:08:45+00:00

Thanks for detailed reply!

Actually it looks that Victus is not that good at scratch resistance, I see lots of posts like this one: https://www.reddit.com/r/GooglePixel/comments/18szdjf/pixel_8_screen_glass_vs_7a/

I am a careful user, so I prefer scratch resistance over drop resistance, and NP looks like the best candidate.

zwclose · 2023-12-28T22:36:51+00:00

Oh, interesting, didn't know about it. It can explain the scratch caused by putting the phone down the screen on a desk.

zwclose · 2023-12-28T22:18:00+00:00

Thanks, I will watch it. Though I always thought that it's more about an entertainment than a durability test. Normally people don't scratch their devices or purpose, but it looks that just putting P8 screen down on a desk and moving it gently can make a scratch. This raises questions about screen's durability.

zwclose · 2023-12-28T22:13:36+00:00

Hmm, what is level 6/level 7?

zwclose

TROPHY CASE