So because I had to know I generated an NTLM rainbow table using the non print character alt 0160 (and non-keyboard represented)0161-0164. The table recognized the non-print character in hex.
The table was able to recognize the non-print character after dumping the hash. (It was a dummy account with a 4 character password for demonstration purposes)
It comes out looking something like:
So although it's not impossible, I didn't have anything in my toolkit that was going to recognize this. Most people with rainbow tables kicking around are either from the community source or have a specific reason for creating them.
I've rarely seen people using these characters, But it makes perfect sense to create a few more tables to include depending on the engagement: £ ¥ ¡ and a few other punctuation marks that are only used in non english languages. Looking on keyboards around the globe for the most common and looking for characters that aren't represented in the US-104 is going to give me a good start. But again, this tableset when made is based on 1 thing: common use. If it's not commonly done, then it probably is easier to find another way to bypass the control.
To speak to a straight up input based brute force, the same thing applies. Anyone that includes it in the character set for input could do it. It just isn't normal to do so.
So in a roundabout sorta way what I'm saying is yes it does make it less susceptible to brute forcing, though not impossible.
-- Edit --
For some real number perspective on table generation:
The basic character set I've got piled up for NTLM fits in a 750Gb drive the numbers I've got on it if I wanted to make a new one: (upper+lower+number+print characters = roughly 96 characters)
Generation time 9 d 22 h (if too high increase number of tables)
Unique chain count 6,094,373,862
Table size 90.81 GiB (97,509,981,789 Bytes)
Total size 726.51 GiB (780,079,854,310 Bytes)
Now this isn't optimal, but for comparison sake the same settings (actually a little kinder settings 8 tables instead of 4 using rtc ) on the full print + non print + non-keyboard ascii set (191 characters) equates to (with compression)
Generation time 395 y (if too high increase number of tables)
Unique chain count 4,823,766,839,375
Table size 57.03 TiB (62,708,968,911,909 Bytes)
Total size 14.20 PiB (15,990,787,072,536,668 Bytes
Essentially 2 orders of magnitude more if you're using the whole ascii character space windows will accept as password input. I'll have to wait a while for that 20 petabyte Seagate before starting down the road to this table. And processors need to speed up if I want the table to finish before 8 generations of me have lived and died.