Hi, can you provide a windows app.

[vanopy]

I need a windows app because I don't like to use MSI gaming app, but i want to control the rgb light.

Thank you.

[nagisa]

Providing an app for Windows would involve writing a kernel driver (as far as I can tell), getting the driver signed (something I have no idea how to do), and figuring out how to make Windows load the driver.

I cannot dedicate time for all the effort needed to release a Windows application myself, but if you, or anybody else, wants to help, I’ll gladly accept it.

[vanopy]

Thank you for you reply, i found a project which can control the msi card without gaming app: https://github.com/Vipeax/MSI-LED-Tool.

Is there any way to make a new tool like this project?

[nagisa]

The tool you’ve linked to still uses the libraries from the gaming app to implement the functionality, so it is not truly “without gaming app”.

[vanopy]

is there anyway to make a tool with the libraries ?

[nagisa]

Sure.

[stbatuhan]

So somehow can you use that to manipulate for motherboard on Windows? I tried with ubuntu on windows 10 but not worked of course :( And standart system of MSI for leds is not enough. I purchased 5050 leds and nzxt hue+ set. Hue+ is great but on MSI side not fancy things like that :(

[nagisa]

This cannot be used on windows yet. I still haven't seen a standalone ISA bus driver.

On Jul 10, 2017 11:15 AM, "stbatuhan" notifications@github.com wrote:

So somehow can you use that to manipulate for motherboard on Windows? I tried with ubuntu on windows 10 but not worked of course :( And standart system of MSI for leds is not enough. I purchased 5050 leds and nzxt hue+ set. Hue+ is great but on MSI side not fancy things like that :(

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/nagisa/msi-rgb/issues/3#issuecomment-314036824, or mute the thread https://github.com/notifications/unsubscribe-auth/AApc0hYGqwD96jn8v2eorYrP88ubsCSGks5sMd2ogaJpZM4NMm9F .

[stbatuhan]

Well is there a way to contribute? I'm a programmer also but not interested on hardware programming and drivers on the kernel for now. Also i hate when i get home after work :) Bec all my day passes on the programming. So i spent only almost an hour @last-friday

[nagisa]

You could try to write an utility that uses MSI's own drivers, but I would personally avoid them because of them enabling trivial vulnerabilities.

On Jul 10, 2017 11:34 AM, "stbatuhan" notifications@github.com wrote:

Well is there a way to contribute? I'm a programmer also but not interested on hardware programming and drivers on the kernel for now. Also i hate when i get home after work :) Bec all my day passes on the programming. So i spent only almost an hour @last-Friday https://github.com/last-friday

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/nagisa/msi-rgb/issues/3#issuecomment-314041228, or mute the thread https://github.com/notifications/unsubscribe-auth/AApc0qt9pu4RVo9baB-ZSJPfTT5oIS5aks5sMeIigaJpZM4NMm9F .

[dcerisano]

Looks like you might be able to build msi-rgb on Windows 10. I am not going down this path, but Windows Subsystem for Linux provides a user-mode Linux kernel.

Instead, I shall continue trying to get RUSTUP to build msi-rgb using the MSVC tool chain.

For this I installed MSVC Build Tools and then RUSTC in Windows 10.

• I have msi-rgb compiling on Windows 10, but it complains about the /dev/ports access.
• Looking for a cross-platform mechanism for accessing hardware registers.

[nagisa]

You cannot as WSL does not give access to ISA ports.

On Sep 16, 2017 05:28, "Dominic Cerisano" notifications@github.com wrote:

Looks like you can run msi-rgb on Windows.

https://msdn.microsoft.com/en-us/commandline/wsl/install_guide

I have not tried it, but this is a full blown user-mode version of Ubuntu from Canonical allowing bash.

Personally I think it is cheating, so I will continue trying to get RUSTUP to compile msi-rgb using the MSVC tool chain.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/nagisa/msi-rgb/issues/3#issuecomment-329939245, or mute the thread https://github.com/notifications/unsubscribe-auth/AApc0jNG2E_o-AhUjpp5pogijzaoDtYkks5sizJdgaJpZM4NMm9F .

[dcerisano]

Looks like WSL Insider Preview might get ISA port access 'soon' .. it just got serial port access.

On the native tool chain side, have you looked at the x86(amd64) crate I mentioned? The documentation is a little sparse ..

[dcerisano]

This looks to be the missing piece of the puzzle. There are no crates available for it, but it allows user mode port access in Windows.

[Arlodotexe]

I just want to report that I installed the Linux Subsystem for Windows, Ubuntu flavor, and was able to successfully build the project. However, it chokes up with the error:

error: could not open /dev/port; try sudo?
   caused by: No such file or directory (os error 2)

I am interested in helping to port this to Windows, but I have hardly worked with hardware development or Windows software development. I've been a JS developer for a few years and am trying to get my foot in the door to building these kinds of apps. If I can be of any help, I will gladly contribute!

[nagisa]

The missing piece as pointed by the Dominic seems right. Porting the app should be just changing the program to load the linked driver and use functions provided by it on windows rather than the inb and outb functions called currently.

On Nov 20, 2017 06:03, "Arlo" notifications@github.com wrote:

I just want to point out that I installed the Linux Subsystem for Windows, Ubuntu flavor, and successfully built the project. However, it chokes up with the error:

error: could not open /dev/port; try sudo? caused by: No such file or directory (os error 2)

I am interested in helping to port this to Windows, but I have hardly worked with hardware development or Windows software development. I've been a JS developer for a few years and am trying to get my foot in the door to building these kinds of apps. If I can be of any help, I will gladly contribute!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/nagisa/msi-rgb/issues/3#issuecomment-345586210, or mute the thread https://github.com/notifications/unsubscribe-auth/AApc0o98c_Zr4m0GyGQkyL7cSSWdRNLnks5s4PotgaJpZM4NMm9F .

[dcerisano]

Ports are protected in Windows and require signed drivers. The windows port driver I mentioned is signed.

The interface is standard in/outb for ports. But every SIO chip will have different bytecode protocols.

I have since moved onto usb adressable RGBs, which do not require leaping through such fiery hoops, Also they are addressable.

[dcerisano]

RWeverything is a little more up-to-date and supports both command line and gui. http://rweverything.com I have not installed it, but I suspect it contains the driver mentioned above, since signing authority is hard to come by.

[ixjf]

I have 'ported' msi-rgb to Windows. See here.

It's not exactly a port.

For one, it's not written in Rust. I didn't add support for Windows to this project. It was a possibility, and I do find Rust attractive, but 1) Rust is a bit too verbose 2) There are no idiomatic Win32 wrappers and it lacks other little niceties that make C++ far more convenient to get things done quickly 3) I barely have any experience with Rust (that's not to say I didn't try to port it in Rust, I did and I gave up when I realized the amount of verbose code I'd have to write and the amount of time I'd have to spend to write code to make calls to Win32).

For another, while I ported over most of the functions from here, my goal was to do it differently. I.e. reverse engineering Mystic Light to figure out how to do it right, rather than try to guess from trial and error. @nagisa did get it pretty much right - but I couldn't have known.

Also, reverse engineering Mystic Light allowed me to understand a couple of things: Mystic Light-supported MBs use either NCT6797(D), NCT6795(D), NCT5567, or NCT5565. Some have specialized LED controllers, which means they work in a completely different way. Others also work differently though they use these same chips (they're categorized differently in the program). However, IO to all 4 chips works exactly the same. They're always found at 0x4E. Functionality is not chip-dependent, but motherboard-dependent. So there are going to be motherboards not compatible with msi-rgb even though they use an NCT6795(D) chip. Also it seems to me that LED control on these motherboards affects all built-in MB LED hardware (including headers)? It looked to me like it, but I don't have a motherboard to test it to make sure I'm not missing anything.

[dcerisano]

That is excellent work @ixjf. Did you explore the possibility of using this signed library that can access ports without admin or kernel privileges?

Also does your solution work even from cold boot (power off/on)? Our experience is that MSI GAMINGAPP has to be run first to initialise the SIO rgb header.

You can reset the SIO chip to factory by holding down your PC start button for 10 seconds while it is unplugged.

[ixjf]

That is exactly the one I'm using. I just scrapped all the user mode code and wrote my own to avoid a DLL dependency and because I already had code to talk to a driver that was cleaner and simpler (I only needed specific code to load the x64 driver as well). The driver is also embedded in the program and is extracted to the process' current path before loading, and then deleted afterwards on unloading, so it's really all just one 300kb EXE.

I don't think it's possible to load a kernel driver without admin privileges, though.

[dcerisano]

It is not a kernel driver, it is a signed library. Signing authority allows access to protected memory like IO ports. All you really need to do is replace your port register call with the InpOut32 call. You should be able to statically link it into your executable? The upside is no admin privilege required to run it.

[ixjf]

No, it uses a kernel driver. There is a kernel mode and user mode to it: the DLL, which applications load and call functions from, and the kernel mode (the .sys), where the magic happens. It's exactly because of that kernel driver that it needs to be signed. Only signed drivers can be loaded by Windows. Only drivers can access the hardware at that level. You see only a DLL because the .sys file is embedded in the DLL.

Also, no, it doesn't. Coincidentally, I was trying to figure that out just now. I had fully turned off my PC and then turned it back on and I realized the LEDs weren't working. So far, nothing.

Edit: To clarify, it's the kernel driver that is signed, the DLL doesn't need to be.

[dcerisano]

The point being (is-a and has-a aside) that it allows user level port access.

To re-initialise your rgb header, just launch MSI GAMING APP and set your leds to white (or any colour). Only have to do this once per cold boot (after unplugged).

You might want to use RWEverything to sniff the ports while MSI GAMING APP runs for the first time. This should contain the rgb header init port register sequences, which you could add to your code.

[ixjf]

Yes, I know, but I want to figure out why it doesn't work at all now. I followed all the main calls in Mystic Light and I don't seem to be missing anything from there, so there must be something else initializing the chip.

[dcerisano]

It is obviously something that MSI GAMING APP is doing, strongly suspect it is just a sequence of bytes sent to some bank of port registers on first run. Sniff the ports!

[ixjf]

Yes, but I mean there are multiple DLLs. The DLL I've been looking at had all the logic for dealing with the chip, but maybe there's something else. Or I'm just overlooking something important.

Also, no, statically linking won't help. That's not the problem. It's the call to CreateService that fails if the process doesn't have admin rights. It doesn't matter how the code is loaded.

[dcerisano]

The DLLs don't matter - the port registry bytes are what initialise the SIO. It does not matter which DLL sends them, just the order they are sent. The init codes should be the first ones sent to the RGB bank on cold start.

You would have to first uninstall MSI apps, cold boot, run RWEverything and then reinstall and run the MSI apps. Instead of RWEverything you might get away with just tracing the DLLs after uninstall, cold boot, reinstall. I would guess the MSI DLLs only send the init codes once ever per cold boot (possibly why you have not seen them yet).

You should be able to create a service with user privilege (it seems - not that familiar with WIN10 service security model).

But why don't you just install it as a persistent System Tray app? Do you need the service model for something?

[ixjf]

The DLLs DO matter, because that's where I get the information from. I'm reverse engineering them, not doing trial and error with RWeverything.

Also, no, you can't. Especially not a kernel driver. You need sudo on Linux too, don't you?

[dcerisano]

No DLLs don't matter - only the init codes to the SIO. You should be able to get them from tracing the MSI DLLs from cold boot (or RWEverything). I would use both at the same time.

On Linux yes, only root or groups like dailout can access serial ports. I just set the sticky bit on the msi-rgb binary (sudo chmod u+s msi-rgb). Ownership and group must be set to root.

Are you saying only admin can install a signed driver? That would make sense. Obviously I have not gone done this road on WIN10. Port access requires superuser to install on both WIN and LINUX, but should only require user-level access to run an msi-rgb-enabled app.

In fact I gave up on msi-rgb and found that building my own rgb chips out of $1.00 ATTiny chips allowed HID-USB access rather than SIO access (which does not require superuser access or even mobo rgb). Now I have nearly unlimited (matrix and strip size only limited by power supply) 60fps addressable rgb lighting everywhere (mobo agnostic - as long as there is a usb port).

I have argued with @nagisa that the only function of msi-rgb should be to disable mobo rgb. That way it wont interfere with custom case lighting solutions like mine.

[ixjf]

I think you don't understand what I'm saying. I'm NOT doing trial and error with RWeverything. That can tell me what is happening, but not how and why. I'm reverse engineering Mystic Light - disassembling the code and seeing what it does.

Also, no. Signing is not what allows user level access to hardware. Signing provides a way for both Windows and the user to know that some executable comes from the author it says it does. That's about it. It's like a real life signature. It doesn't even have anything to do with drivers. You can sign any executable. In order to access the hardware, you need to run in kernel space. Hence, you need a kernel driver. The reason Windows only allows signed kernel drivers is because those drivers can do pretty much anything, especially without being detected, so it's best only those from reliable sources be installed. Moreover, it's not the InpOut32 DLL that is signed - it's the kernel driver that the DLL loads.

And yes, only an administrator can install a driver. The reason you don't see Mystic Light asking for permissions every time you run it is because when you installed Mystic Light, or the Gaming App, the setup asked you for them. When it installed the program, it installed the services (including the driver service) as well and allowed anyone to run it afterwards. If you look at LEDKeeper.exe in Mystic Light's directory, you'll see a small blue and yellow icon on the side that shows that the executable requires admin rights.

[dcerisano]

I don't see why you would want to reverse engineer SIO port protocols without the aid of a port sniffer. That seems unnecessarily difficult. It is how @nasiga got this far in the first place.

Also reverse engineering proprietary OEM apps seems extraordinarily laborious given they change the apps every time they release a new SIO chip, mobo design, BIOS version, etc (which is the core point of not doing it, and of course it is intentional).

[ixjf]

It's actually quite simple. Half of the DLLs are in C#, which means they can be disassembled very easily and keep all the names. The other half isn't, but it exports the important functions, so all I need to do is follow the program logic.

[dcerisano]

But you will have to do it all over again every time MSI sneezes! Not to mention there are whacks of other OEM SIO chips that msi-rgb does NOT handle.

It is a combinatorial explosion!

[ixjf]

Also, it's highly unlikely the program logic is going to change that much from version to version.

[dcerisano]

It's not the progam logic, it's the proprietary SIO protocols that are subject to extreme variance from OEM to OEM and even BIOS to BIOS version.

[ixjf]

msi-rgb does handle them. That's the thing that nagisa got wrong. As I had already said above, functionality is mostly motherboard-dependent, not chip-dependent. There are probably half of the motherboards that Mystic Light supports that should work with msi-rgb. The other half could be easily implemented as well with this knowledge now.

[dcerisano]

Got your LEDs working yet? Lol. But seriously ...

Great work so far, but I think you underestimate the amount of maintenance your solution would require to support even a handful of mobos from the same OEM. And of course the SIO protocols are SIO dependent. Also you will have to keep tracing every new version of the MSI apps. Not to mention cross-platform issues if you want to support Linux, Mac, Android, iOS, etc ... (oh yes mobile is going rgb too ...)

BTW my addressable rgb controller already works with mobile USB-OTG, of course because it is just another HID device.

[ixjf]

Mystic Light-supported MBs all use the same 6 chips, which function in exactly the same way. They just have different functionality enabled. There are only a few MBs with different, Renesas chips.

[dcerisano]

Case in point - let's see how long it takes you to solve the initialisation problem (and test on all supported mobos). That is point where I gave up on this approach, and found it easier to invent my own driverless addressable rgb controller chip as a USB HID device.

Note that any manufacturer could also do this - but they won't because they want to lock you into their ecosystem. That is why the issues I mentioned with your approach are not going to go away, and likely just get worse.

Also doesn't the Mystic Light EULA contain a non-reverse-engineering clause? The issues could be more than just technical.

[ixjf]

Yes, if this were to become very popular, there could be. But I doubt most people will ever hear about it, so MSI won't care. Plus, it's not like they're losing any money if someone doesn't use Mystic Light. If anything, it might make more people buy their boards.

[ixjf]

Also, testing on all supported mobos is unfair. Did you test msi-rgb on all boards with an NCT6795 chip?

[dcerisano]

I would have agreed with you up until now, but apparently some smart guy just opensourced a Windows version of msi-rgb. The space-time continuum has been altered!

You have listed a bunch of supported mobos on your repo, so yeah gotta test them or remove them. I only had to test msi-rgb on one board to know it was a rabbit hole approach.

[ixjf]

Doubt it. I posted it on Reddit and no one batted an eye. Think I'll be fine. Especially if no one makes a GUI for it. N00bs.

[dcerisano]

It may take a while for people to grasp the full extent of this. Then you could have techtubers hounding you for interviews.

RGB is a marketing phenomenon. Little blinky lights have a strange effect on people, and you just released into the biggest and strangest OS.

Ever thought of working for MSI? If not, you could have a go at implementing my Linux msi-rgb apps on Windows!

[nagisa]

@ixjf

Yes, I know, but I want to figure out why it doesn't work at all now. I followed all the main calls in Mystic Light and I don't seem to be missing anything from there, so there must be something else initializing the chip.

We had the same problem with msi-rgb. This is the code that "enables" the advanced mode that makes RGB work. Make sure that you have all steps of initialization in your code as well.

[nagisa]

As I had already said above, functionality is mostly motherboard-dependent, not chip-dependent. There are probably half of the motherboards that Mystic Light supports that should work with msi-rgb.

This makes me suspect that

1) Either RGB control is not implemented in the SIO (similar to ASUS’ Aura, which possibly has a separate chip on the ISA bus) and either (a) SIO chip is not related to RGB at all; or (b) SIO is passing the configuration to the actual RGB control chip; or (c) something else entirely; 2) SIO chip is separately programmable/configurable (maybe reads its firmware from the flash which happens to store BIOS), but this would only make sense if the configuration would turn-on and turn-off certain functionality, rather than cause fundamental interface differences to occur.

[nagisa]

Also doesn't the Mystic Light EULA contain a non-reverse-engineering clause? The issues could be more than just technical.

Reverse engineering prohibitions are not enforceable in many jurisdictions as reverse engineering is considered fair use. That clause should not be valid anywhere in the US and EU (Disclaimer: IANAL, not legal advice, check with your local lawyer).

[ixjf]

Regarding the advanced mode, yes - I know about that. It's actually called extended mode. All it does, as far as I can tell from datasheets of similar chips, is enter configuration mode. I have all the instruction codes you have, and it's the same thing the app does.

Also, RGB control is implemented in the SIO (or at least, the SIO controls it) in all of the motherboards listed on my MSIRGB's README (and some others as well). A few motherboards use some Renesas chips instead, but the motherboards that we've been testing with don't. I'm just missing some initialization code, for sure.

@dcerisano, the list of boards in my README is not random. I put them there as a "should work on" because from looking at Mystic Light they seem to work the same way, at least for the most part.

[ixjf]

I'm pretty sure I just got it. Am gonna test it further but I think I figured out how to initialize the chip properly.

[ixjf]

@nagisa What kind of weird fade-in behaviour are you referring to when you talk about the 'fff' bits in bank 12h cell 0xFF?