Hacking RELEASE Linux udev rule for auto-delivering payloads via fusee-launcher/shofel2

[yesimnathan]

I got tired of having to manually cd to path/to/fusee-launcher, manually run fusee-launcher, and type my password everytime I wanted to fire off a payload to my switch. I wanted my computer to just automatically fire the payload as soon as I plugged my RCM switch in via USB, so I put together a dumb little script & udev rule to do this for me. It has been working great for the last few days. I don't know if this would be terribly useful for many people (maybe some of the raspberry pi projects could use this?) but I figured I'd share anyway!

udev rule
The udev rule lives in /ect/udev/rules.d/10-switch.rules and contains the following:

SUBSYSTEMS=="usb", ATTRS{manufacturer}=="NVIDIA Corp.", ATTRS{product}=="APX", RUN+="/PATH/TO/.switch_payload"

Replace "/PATH/TO" with the absolute path to your .swith_payload script - an example script is below. I just use ~/.switch_payload.

This will only execute the .switch_payload script when the switch is in RCM mode since the manufacturer & product values are different when it isn't in RCM mode.

Once the rule is in place, be sure to reload your udev rules with:

udevadm control --reload-rules

Payload script
I then have a script located at ~/.switch_payload (you can adjust the location of this script by changing the 'RUN' value in the udev rule) with multiple payloads so that I can select which payload gets fired without having to edit the udev rule:

#!/bin/bash

# switchblade
python3 /PATH/TO/fusee-launcher/fusee-launcher.py /PATH/TO/payloads/switchblade_ipl_2018-05-20.bin

# hekate 4.x
# python3 /PATH/TO/fusee-launcher/fusee-launcher.py /PATH/TO/payloads/hekate_ipl_4.x_2018-05-10.bin

# biskeydump
# python3 /PATH/TO/fusee-launcher/fusee-launcher.py /PATH/TO/payloads/biskeydump.bin

# painless-linux
# /PATH/TO/painless-linux/shofel2/shofel2.py /PATH/TO/painless-linux/payloads/cbfs.bin /PATH/TO/painless-linux/payloads/coreboot.rom

Replace "/PATH/TO" with the path to your fusee-launcher, payloads, and painless-linux directories, set the script to be executable (chmod +x .switch_payload), and you're as good as gold! To switch to a different payload, comment the currently active payload (switchblade IPL in the above example) and uncomment a different payload. If you want to temporarily disable this, just comment all of the payloads.

As a note, fusee-launcher.py used to require you to pass the '--relocator' flag with a path to the 'intermezzo.bin' file when executing it from a different working directory. I submitted a PR to fusee-launcher - which was just recently merged, woo! - to look for 'intermezzo.bin' in the same working directory as fusee-launcher.py if the '--relocator' flag is not passed. That can make our fusee-launcher.py commands much shorter!

 

[TheKrane]

Wow that's awesome! I didn't even think about doing that.
Thanks!

 

[yesimnathan]

Wow that's awesome! I didn't even think about doing that.
Thanks!

No problem! =)

 

[Youngsie]

Awesome idea sadly not working for me .

I've followed your instructions to the letter (I believe) and even done some debugging of my own but for some reason udev just wont run the script.

I've put the udev rule in both /etc/udev/rules.d/rules-10-switch.rules and /usr/lib/udev/rules.d/rules-10-switch.rules (I've had problems in the past where udev rules weren't working unless put in /usr/lib so thought i'd try it just to rule it out).

The path to script is ~/.switch_payload and I've made it executable I can confirm the script runs and works fine when manually ran .

lsusb appeared to not show the product name (ie APX) but I've checked with dmesg and it does detect it as APX.
I've also tried changing the ATTRS to idVendor and idProduct but no luck.

I understand this is something you created more for yourself and decided to share and don't expect full support rather just wondered if you had any other ideas as to why it wouldn't be working?

I'm using Arch not that that should be relevant?(i think...)

 

[yesimnathan]

Awesome idea sadly not working for me .

I've followed your instructions to the letter (I believe) and even done some debugging of my own but for some reason udev just wont run the script.

I've put the udev rule in both /etc/udev/rules.d/rules-10-switch.rules and /usr/lib/udev/rules.d/rules-10-switch.rules (I've had problems in the past where udev rules weren't working unless put in /usr/lib so thought i'd try it just to rule it out).

The path to script is ~/.switch_payload and I've made it executable I can confirm the script runs and works fine when manually ran .

lsusb appeared to not show the product name (ie APX) but I've checked with dmesg and it does detect it as APX.
I've also tried changing the ATTRS to idVendor and idProduct but no luck.

I understand this is something you created more for yourself and decided to share and don't expect full support rather just wondered if you had any other ideas as to why it wouldn't be working?

I'm using Arch not that that should be relevant?(i think...)

I had typed out some troubleshooting stuff but after re-reading my initial post, I realized that I forgot to put the command to reload udev in there

Try running this once the udev rule is in place:

udevadm control --reload-rules

I'm on arch too. I put my udev file in /etc/udev/rules.d and it seems to work

Let me know if that doesn't work & we can try some more troubleshooting!

 

[Youngsie]

Sorry I forgot to mention that I'd tried reloading the rules and I did this last night so the reboot in-between should've reloaded the rules.

Just tried again and still not luck.

could I get the permissions for your rules files and the script its self? (Maybe it's a permissions issue) Does udev require the user to be in a group of any kind or anything?

Sorry i'm not very familiar with udev.

editapologies meant to make this a reply to your reply but first day on gbatemp)

 

[zerotri]

Sorry I forgot to mention that I'd tried reloading the rules and I did this last night so the reboot in-between should've reloaded the rules.

Just tried again and still not luck.

could I get the permissions for your rules files and the script its self? (Maybe it's a permissions issue) Does udev require the user to be in a group of any kind or anything?

Sorry i'm not very familiar with udev.

editapologies meant to make this a reply to your reply but first day on gbatemp)

Udev scripts like this don’t generally run under your user, so if you’re referencing the script as literally ~/.switch_payload, it is going to be looking in /root/.switch_payload

You should make sure the udev rules use the absolute path to the script. Even better would be to put it somewhere accessible to other users like /usr/local/bin and set the ownership to root:root or something equivalent. Permissions for that likely should be 755, unless you want to specifically restrict execution access.

 

[yesimnathan]

Udev scripts like this don’t generally run under your user, so if you’re referencing the script as literally ~/.switch_payload, it is going to be looking in /root/.switch_payload

You should make sure the udev rules use the absolute path to the script. Even better would be to put it somewhere accessible to other users like /usr/local/bin and set the ownership to root:root or something equivalent. Permissions for that likely should be 755, unless you want to specifically restrict execution access.

Sorry for my late reply - This is a good point. In my rules file, I'm referencing an absolute path (/home/username/) rather than ~. Permissions on the rules file shouldn't matter too much since udevd runs as root but my permissions are 0644 root:root

 

[Youngsie]

Sorry I should've stated that I had the absolute path in my rules and it still didn't work.

However... I decided to start over from fresh following both your suggestions i put the script inside /usr/local/bin set the permissions to 755 and copy pasted the rule from op (changed perms to 0644 just for good measure ) and im happy to report it works now.
.
Sadly can't tell what exactly was causing the issue as i started from fresh but it works flawlessly now so thank you both!

 

[yesimnathan]

Sorry I should've stated that I had the absolute path in my rules and it still didn't work.

However... I decided to start over from fresh following both your suggestions i put the script inside /usr/local/bin set the permissions to 755 and copy pasted the rule from op (changed perms to 0644 just for good measure ) and im happy to report it works now.
.
Sadly can't tell what exactly was causing the issue as i started from fresh but it works flawlessly now so thank you both!

Glad you got it working! It's quite handy. I was getting super tired of having to manually run the command & type my password everytime lol

 

[RHOPKINS13]

This sounds awesome! I just need something similar to this that I can use in Windows.

 

[Youngsie]

This sounds awesome! I just need something similar to this that I can use in Windows.

There are several solutions that allow this. The most popular being TegraRcmGui you can minimise it to system tray and it will send a payload when RCM is detected .

*Edit to correct name of program

 

[RHOPKINS13]

There are several solutions that allow this. The most popular being TegraRcmGui you can minimise it to system tray and it will send a payload when RCM is detected .

That's nice, didn't realize TegraRcmGUI had that feature. I'd love it if there was a method that worked by hooking into something like the Windows Registry, so that you didn't need a separate program running in the background for it to work.

This method of using a udev rule in Linux is awesome, but I don't think there's a perfect alternative for it on Windows.