![]() ![]() Unfortunately the logic of this function is screwed up so this bugfix is only partial and works only with ROCALL (syscall fuzzer mentioned above). They tried to apply fix to that by checking input parameter and then capturing it into safe buffer allocated on service side. Initial problem with this service was absence of input parameter validation, so code was dereferencing invalid pointer resulting in Blue Screen Of Death. This service is a best example of a failed fix. Unfortunately when something more complicated pop ups ReactOS devs gives up. It also got attention from ReactOS developers. The last one ntoskrnl syscall dumb fuzzing bug was in NtUnloadDriver (ROS_NTOS_BSOD_007). Spoiler alert: do not worry this screensaver Easter egg functionality will return (near the epilogue part) □ ![]() Additionally they managed to fix NtCreatePagingFile (ROS_NTOS_BSOD_053) which was a part of BSODScreen screensaver that I exclusively presented to ReactOS. Missing parameters validation added to the NtSetUuidSeed (ROS_NTOS_BSOD_009). They also removed debug breakpoint set into NtRaiseException (ROS_NTOS_BSOD_005) thus resolving another issue. As well as NtDisplayString (ROS_NTOS_BSOD_003). It has been fixed by added missing input parameters validation. The first bug in list at MRGA Part 1 was ntoskrnl.exe (NT core) service NtAllocateUuids (ROS_NTOS_BSOD_004, names are numerological sequence of initial discovery). With some unfortunately fixed in a wrong way□ Note that I tested both 4.12-release and 4.14-dev versions. It is now December 2019 – an year after MRGA Part 1 post and it is time to check results and try to figure out why it is that bad (spoiler alert).Ī little of. It’s decided to wait an year, passing few major releases. Instead of giving them another bunch of their bugs for fix (together with another portion of critics) I decided to wait a little, accommodating their project development timeline, giving them enough time to develop and apply all required fixes. My expectations were exceeded in a bad way and I revised a strategy of my work with such “contingent”. A toxic community of ReactOS current and previous developers/users completely lacking any self-criticism, full of hypocrisy, incompetence embedded into their own virtual world, guys who build their area of significance on others people work they actually stole / borrowed / adapted at the best. Unfortunately (I'm joking, actually I enjoyed it) MRGA post immediately revealed a nature of some people, put their butt-hurt to the incredible level (so some of them even tried to do a spam campaign against MRGA publication). Because obviously if people are talented – when they grown up they are capable of rethinking their past work and capable of self-criticism. But only if you are dumb attention whore of course. So when someone begins to criticize their previous work, entire area of significance shaking as hell too. Or make you top tier security/software engineer from initially been a mediocre level reverser of crackmes. It is like that you have Windows NT operating system clone in your portfolio that should clearly make you an uber expert in OS development. What were expectations from MRGA post? At first, you should understand that several people spent their years of youth involving in this particular project, so they created a virtual area of significance from that fact. I have been planning about 5 or 6 parts of MRGA journey that giving developers of this meme OS more critical system bugs in different areas (discovered by the way in less than two weeks, □). I gave them a dumb simple syscall fuzzer (that they were unable to write for 20 years) and highlighted over 30 critical system bugs discovered with it help. Back to the first MRGA article – it showed overall low quality of the project's code and developers inability to improve it for years due to multiple reasons, dev's team selecting most funny ones as excuses for their failures. ReactOS code and its developing methods is a monument of anti-patterns, and it seems that it exists only for fun and profit of its few developers/project manager. I didn't use “academic project” here, because ReactOS is rather anti-academic than something, that one can study for good. About year ago I’ve published “Making ReactOS great again, part 1” (brief MRGA, posted at ) where described a current state of this meme project (tl dr homemade Windows NT clone with massive masqueraded copy-paste and borrowings from Microsoft OS as results of it reverse-engineering/leaked source usage). ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |