coming to you every hour on the hour.
Time for some revelations
It's been quiet for too long once again so let's jump into it, shall we.
A quick recap and refresher: I've initially started serving the root domain vigem.org with WordPress back in the days to get something started and a blog with some small CMS aspects to it made the most sense to me. And it served well, don't get me wrong, but maintaining it became such a burden that every time I wanted to spew out some wisdom I first had to install some plugin or theme updates and beg that the site would still operate afterwards. Now this isn't a unique problem only WordPress suffers from, but I think their plugin ecosystem is drenched with an unhealthy amount of really terrible code, especially those who "enhance" the content syntax. Here on NodeBB there's Markdown and that's it. By limiting myself to a small set of formatting options I get less distracted and focus more on the text content than its presentation. Not a win for everybody but hey, I guess more frequent updates are preferred over less polished ones Comment if I'm totally wrong
Right, the dreaded feedback option is back No, seriously, be my guest to engage in civilized discussion and/or criticism. A forum inherently enables the possibility on giving instant feedback, previously blog posts had a weird disconnect, it happened very rarely that they got discussed on Discord and that's a shame. Let's see where this takes us
Yeah, the placeholder ist still there and redirecting to this category. I have nothing to show yet, only an idea that I want to build a simple and informative landing page, describing the projects and probably the people involved if they want
I'm not a web developer so I'll stick to
stealing getting inspired by existing solutions We'll see about that.
I have to admit, I've underestimated the powers of good forum software for quite a while but I've learned my lesson. No more wasted time running a dedicated blog, no more Discord-only; Discord is still great but for some topics it is too volatile (and the search is questionable at best ). I want to let the public know what I'm up to and I think this platform can help me with that.
I'd like to emphasize that everything presented under *.vigem.org domains is run by yours truly and served by dedicated rented virtual machines in a data center in the European Union. For over 10 years now you still won't find any ads on anything I host as I don't believe in them and it would be quite hypocritical if I'd force some down your throats. I also try to keep the resources loaded from 3rd party CDNs and tracking crap to an absolute minimum (as far as the software I use allows it) because again; I myself hate this crept-in trend of
stealing collecting and selling everybody's data in the back while smiling a fake smile in the front Needles to say but I'll do anyway: your mail addresses and credit card numbers are save with me Thanks for your trust.
Docu... what? No, seriously, I know the situation is still terrible. I've launched docs.vigem.org a few months back with the idea of having a central location for guides and documentation rather than having to maintain countless GitHub READMEs and Wiki instances. I got inspired by sites like these which look cool and are rich in content but have to be maintained as well Also a lesson learned: less infrastructure experiments, more content. I'll try to improve the situation here as well, pinky promise
Despite the statement on the official repository I still get inquiries about it, mainly support requests. I politely ask you to stop that, it is not maintained anymore and mails or Discord DMs won't change that. What I can give you though is an explanation on why I pulled the plug in the first place. The topic deserves an entire dedicated article but I digress, here we go.
The ScpToolkit is not a device driver. I know it get called that all the time - even by myself - but it isn't. It's a giant C# program that does many... things. It forces a generic USB driver (WinUSB by Microsoft) onto DualShock 3 and 4 devices and directly communicates with them, all done in user-land C#, not a driver. Same goes for the Bluetooth dongle, the actual "driver" is WinUSB, not SCP. WinUSB has no idea about what a DualShock or Bluetooth host is, and it doesn't have to as its purpose is to be as generic as possible. SCPs core handles that, it even contains an entire Bluetooth software stack, also entirely implemented in C#. It's pure madness. Then there's code which talks to the ScpVBus who's only responsibility is to spawn and feed a virtual Xbox 360 Controller. This is the only real custom driver in the entire SCP package, designed and written by an unknown entity only known by the pseudonym Scarlet.Crush. This driver has some dangerous flaws and shouldn't be used anymore. I've attempted to fix them in custom builds but those aren't signed properly and won't get loaded by every Windows version's kernel.
In mid-2016 I published the last attempt of turning SCP into something great. But at the same time I realized, that a more drastic approach was necessary. Drivers should do driver tasks, not .NET applications. The monolith had grown to a massive blob, that was riddled wit hacks and workarounds desperately trying to please everybody, especially the users of the dreaded "fake" DualShock 3 devices ("PANHAI"). So instead of feeding into this machine of madness I decided to pull the plug and follow the route of Shaul Eizikovich and write the ScpVBus kernel driver from scratch. This was the birth of ViGEm
Let me tell you one thing right away: developing Windows kernel drivers is hell. And I love it. It's a hostile yet powerful realm and it took me many months, if not years to prove myself worthy of these cursed lands. You don't just code for the kernel, you need knowledge of cryptographic signing, deal with the Microsoft Partner Portal, fight off the untruths that lurk in the web and last but not least invest quite a bit of money I have done all these trials and oh boy, was it a bumpy road to where we are now but it was worth it. The knowledge and experience I've gained is unparalleled to anything I've yet experienced in IT and I plan on descending even further until I might shake hands with the devil himself.
The last official stable release of the ViGEm Bus Driver was exactly one year ago. Quite some time. It has received some critical fixes and even new features during 2018, but due to certain circumstances I'll describe in greater detail later and the introduction of WHQL testing it was put on hold. If certain things have cleared up until the end of January I might be able to craft a new release. Will keep you posted.
I've published some experimental stuff over the last two years attempting to replace at least parts of the ScpToolkit. Some of them include:
A dedicated kernel-mode USB function driver that transparently presents the DS3 as a HID-compliant device to the system and therefore requires no additional application. Unfortunately I goofed this up in the past. FireShock Generation 1 was a very poorly designed USB lower filter driver (to my defense: I was still very inexperienced with kernel driver when I first published it). It worked somewhat but had memory leaks (yikes), no support for rumble and wasn't properly signed.
Then Generation 2 hit the deck, this is the one currently published on GitHub. It's my first driver using the User Mode Driver Framework 2, quite stable but requires a companion user-mode application similar to SCP, which was fine for research and development but would lead to a similar strange construct that SCP became, so once again, not satisfied.
Meet Generation 3, it has 3 in it so it has to be good Seriously though: this is the ducks guts. A kernel-mode HID-minidriver which properly exposes the DS3/Nav/Move as a HID-compliant device and exposes the rumble motors as Force Feedback effects! This means no more custom builds of e.g. the LilyPad plugin for PCSX2, you can just configure FFB effects as rumble instructions! This is huge and so poorly documented that it took a few people to come up with a solution, including countless hours of research and reverse engineering. Unfortunately Generation 3 isn't production ready yet, but very close. This time I went a different route and continued development in a private Git repository to minimize the confusion that alpha releases suffer from.
Riding on the wave of creativity I ported the entire Bluetooth stack from SCP/C# into its own UMDF2 driver and named it AirBender. Because... Air... Bluetooth... Wireless, ya know Using UMDF allowed for rapid development and testing but again required help from said companion user-mode application, not the final solution I was envisioning.
But the work and time that went AirBender wasn't wasted; by having a driver I could litter with diagnostics I stumbled upon the solution for a major showstopper that was dragged along in SCP all this time: the support for wireless connection of the fake PANHAI DualShocks!
Turns out that the Stack used in SCP (which I didn't invent, I documented and refurbished it at best) was wrong all along; it happened to work with the original genuine DS3s but it didn't operate like the PS3s Bluetooth stack Time for another rewrite!
Meet another secret project: WireShock! Because... Wireless... and DualShock... makes Wire... shut up! I'm not creative with names, ok
Bad naming aside, here is where things got really spicy! Once again pure kernel-mode, custom written Bluetooth stack but now not inspired by the flawed implementation in SCP but by code from Linux/Arduino! And this time: raging success! The fake ones connect as well! And stay connected We're really close now, the next step is to once again throw everything over again and solve one last big issue: how to maintain compatibility with existing Bluetooth devices. As SCP users might now, in order to use the controllers wireless, you have to sacrifice an entire dedicated Bluetooth dongle for this setup to work. That's going to change! You can follow the spectacle right here!
... isn't dead, just postponed. A quick rundown of a similar formula.
This is the version that's currently floating around the web and causes troubles. It was a proof-of-concept and I made the mistake of publishing it. Shouldn't have done that. But yet again; now I know way more than two years ago, so I'm gonna rectify this. Later.
HidGuardian wen't through at least three complete design iterations and partial rewrites because I totally underestimated creating an input device firewall so the current development is once again happening in secret on private Git repositories and will be released when considered really stable. It's too dangerous to throw out flawed kernel drivers, I've learned that as well.
Until the end of January I'm quite busy with a few personal challenges which might eventually get resolved. Sorry to be so cryptic, more info to come.
Thanks for listening to my ramblings, this got quite unstructured once again, apologies