FARR v2 - Official Bug Tracking and Feature Request Thread

[aloishammer]

welcome aloishammer 

i'm afraid i'm totally ignorant about ASLR and Perma-DEP.  could you point me to something gentle i could read and maybe elaborate a little on why you think this would be useful?

-mouser (August 20, 2010, 06:34 PM)

I don't know what you'd consider "gentle".  Microsoft seems to have gone out of their way to confuse anyone attempting to use either CPU-based or compiler-based software protection techniques. 

There's an MSDN article here that explains some of the code protection techniques MSVC offers.  Unfortunately, Microsoft can't decide whether it's Address Space Layout Randomization (ASLR) or "dynamic base" or "image randomization".  Also, while they differentiate between the NX execute-protection CPU instruction and "SafeSEH" in the article, Windows does not.  Windows offers "Data Execution Prevention", occasionally calls it NX (as in the NT6 bootloader), and combines both NX and "SafeSEH" for anything selected for protection with "DEP".

Wikipedia may actually be a considerably better reference:
http://en.wikipedia....Execution_Prevention
http://en.wikipedia....on#Microsoft_Windows

The extremely short version I can offer: the NX instruction is used to mark memory ranges as non-executable; if someone successfully inserts malicious instructions into an NX-marked data (non-code) area and successfully sets the instruction pointer there, the CPU should throw an exception and refuse to execute the non-code.

SafeSEH is next to worthless, but very good at breaking applications that weren't compiled for it.  This is why "DEP" was introduced in WinXPSP2, but Win7 still doesn't enable it by default, and I assume 7SP1 won't, either.

ASLR, depending on exact implementation (Windows' is partial for performance reasons), can place various code *and* data into totally random memory address ranges.  This way, anyone successfully injecting malicious code into the in-RAM, executing image of your app will either be unable to reliably predict where the malicious code went, and thus be unable to set the instruction pointer to it, or will have to work considerably harder to locate and execute it.

These are the two big ones: the MSDN article mentions one or two other code protection techniques (mostly free just by enabling switches in MSVC), but most focus ends up on "DEP", NX, ASLR.

Major caveat: ASLR on Win32 gives you only a 3.2-3.5GB address space to search, so it's very close to not worth doing.  This is part of the reason I'm asking for a native Win64 build.

Wrap-up: assuming you're using MSVC, and at least 2005SP1, or that you can/could build with MSVC Express (free), NX, ASLR, and the other techniques mentioned in the MSDN article are effectively free; it should be a matter of switching on flags when building your project.

Postscript: From my testing, I don't think you'd need any recoding.  I've been experimenting with Microsoft's EMET 2.0 release: FARR2 and DCU are reported as running with full EMET-enforced protections and display no abnormalities.

[tleforge]

Feature Request:  When highlighting an app to run, the ability to highlight multiple apps (maybe with a shift key) to run all highlighted.

Knowing you guys, I'm sure this is already in the program somehow and I've just missed it.

[mouser]

i'm afraid you can't multiple select in the program list but you can use Ctrl+# to launch an item and stay open (you can change the effect of keyboard modifiers on the Keyboard Interface tab of options); so if you want to launch programs listed as items 1,2,3 you would hold Ctrl and hit 1 2 3.

[aloishammer]

One more security note: everyone in the wider security community has "binary planting" on their minds just now.  I can't even begin to guess where FARR2 might need/want changes, but this new research seems extremely pertinent to FARR2, whose entire purpose is to create new processes...

http://blog.acrossec...anting-goes-exe.html

[pattu]

When plugging and unplugging monitors FARR gets lost off screen...

I am using v2.90.02 and am really quite addicted.  Unfortunately, I work between home and work a lot and change between multiple and single monitors on my notebook, only using suspend, not rebooting.  When  I change configs, FARR often ends up appearing off screen.  I used to use ALT-SPACE as my hotkey, but I have changed away from that, because I need to use this to move the FARR window back on screen.  FARR should I guess check the resolution of the current monitor every time.  Drives me a little crazy, but I still use FARR a *lot*.

[mouser]

Yes, i will add this.  it's a very good point.

May i suggest that you may want to install a program to handle this case of applications off screen if you frequently  unplug monitors.  In the past i've used i tiny old freeware called "Discover" but i can't locate it anymore.  It stays in tray and you double click it and it moves any windows that are currently offscreen back on screen.  there are surely other tools to do this -- probably one or two written by dc members that i'm not recalling at the moment 

[lordmuzer]

Hi,

I have 2 small problems
Here is a screenshot:
http://dl.dropbox.co...93394/FARR_bug_2.png

1. FARR get icon direct from .exe file, not .lnk. But if .exe has no icon and .lnk has it, can FARR take it from .lnk? on screenshot "windows update.lnk" has icon, but FARR does not show it

2. After first 9 item in history list with predicate with "* - ", other items has strange space before.

and last, i confirm that

3. When a list of results is displayed, right-click an item and click Properties. Result: nothing happens. No error, no message, just nothing  The Shell Context Menu command works, though.

reproduce in windows 7 x64

sorry for my bad english, its not my native lang

thanks

[mouser]

hi lordmuzer, welcome to the site!

thank you for your bug reports -- they are all very clear.  i am going to try to fix them.  i think bugs 1+3 are also happening on my other program (LaunchBar Commander) so it is important that i get them fixed as soon as possible.

[chok]

I know some discussion about launching 64-bit programs has taken place.  I don't see any discussion about finding and launching 64-bit programs in the system32 directory.  As you know, a 32-bit program sees the sysWOW64 directory as the system32 directory.  I first noticed this problem when launching cmd.exe from FARR.  It finds the 32-bit cmd.exe in the sysWOW64 directory and runs it.  Then when I type something like nbtstat in that command prompt window, it cannot find it, because there is not a 32-bit nbtstat.exe in the sysWOW64 directory, only a 64-bit one in the real system32 directory.  I think what we need is a 64-bit build of FARR.

[mouser]

this is an interesting issue.

FARR should not actually have any trouble finding or launching 64 bit programs.. the problem is well described by you -- it seems to be finding+launching the 32bit version of cmd.exe and then what you see from that is not what you want.

It seems like a good workaround for now would be to create your own alias to launch the 64bit command.com  Can you test and see if that works?

[chok]

I cannot add an alias, because the 32-bit FARR cannot find the 64-bit cmd.exe.  When it looks at system32, it is actually seeing the sysWOW64 directory instead.

I can copy the 64-bit cmd.exe to another directory and FARR can find it and run it just fine.  But there are quite a few programs that are missing.  Defrag, dnscmd, mrt, msconfig, telnet, and tftp are a few that I have noticed.  Also, most of these have some language-specific files in %windir%\system32\en-US (on my machine), which have to be copied to a corresponding subdirectory of wherever the executable is.

There is also just a philosophical issue of running the 32-bit versions of everything instead of the new 64-bit versions.  Practically, though, it probably makes no difference.

It is much easier just to work around this issue by launching cmd with the Windows key.

I do think that sooner or later you will be wanting to start offering a 64-bit build.  It will probably be a long time before 32-bit support is phased out, but 16-bit programs stopped working with the first 64-bit Windows (http://support.microsoft.com/kb/896458).

[mouser]

Interesting.. That is a bit troublesome isn't it.. Let me think a little on this, and if anyone has any other ideas please post.

[lordmuzer]

yes, i can confirm.
i type in FARR "C:\Windows\System32\regedit.exe", but instead "C:\Windows\SysWOW64\regedit.exe"  will start.
my os is windows 7 x64

Microsoft say at http://msdn.microsof...384187(v=VS.85).aspx:

Applications can control the WOW64 file system redirector using the Wow64DisableWow64FsRedirection, Wow64EnableWow64FsRedirection, and Wow64RevertWow64FsRedirection functions. Disabling file system redirection affects all file operations performed by the calling thread, so it should be disabled only when necessary for a single CreateFile call and re-enabled again immediately after the function returns. Disabling file system redirection for longer periods can prevent 32-bit applications from loading system DLLs, causing the applications to fail.

and as temporary fix:

32-bit applications can access the native system directory by substituting %windir%\Sysnative for %windir%\System32. WOW64 recognizes Sysnative as a special alias used to indicate that the file system should not redirect the access. This mechanism is flexible and easy to use, therefore, it is the recommended mechanism to bypass file system redirection. Note that 64-bit applications cannot use the Sysnative alias as it is a virtual directory not a real one.

[mouser]

great tips lordmuzer! 

[chok]

I think lordmuzer should get a gold star on his chart for today!  Wow!  I just added %windir%\sysnative to my search folders and unchecked %windir%\system32 and I can launch all these neat 64-bit programs instead of the 32-bit versions.  I think this is just a good as a 64-bit FARR.  Thanks lordmuzer.

[lordmuzer]

but another problem: on x64 OS FARR cannot start any .lnk (from %MYSTARTMENU%|%COMMONSTARTMENU%)
for build-in/system Windows application from "%windir%\System32\" that doesnt have corresponding x32 analog in "%windir%\SysWOW64\"

on windows 7 x64 you cannot execute:
"Sound Recorder", "Snipping Tool" and other.

maybe FARR, when resolve *.lnk target to %windir%\system32\* can try to find it in %windir%\sysnative too ?

[chok]

Well, bummer.  As long as I find the file and launch it and don't use any shortcuts that have system32 in them, I'll be OK.  Although it may be a lot of work, I still think a 64-bit FARR would solve all of this.

[lordmuzer]

and the last problem with "Program Files"|"Program Files (x86)" folders:

by default windows 7 x64 has 2 shortcut for Internet Explorer:
"Internet Explorer.lnk" = "C:\Program Files (x86)\Internet Explorer\iexplore.exe"
"Internet Explorer (64-bit).lnk" = "C:\Program Files\Internet Explorer\iexplore.exe"

but FARR always execute "C:\Program Files (x86)\Internet Explorer\iexplore.exe"

[justauser]

I have a feature request.  I'd like to be able to have a command that is composed of other aliases.  For example, I have an alias for opening site 1 and an alias for site 2.  I'd like to have an alias that open site 1 and site 2.  I can do this by entering the URLs, but not the aliases, as far as I can tell.

[Armando]

Farr updates seems to break the Timer plugin (czb) settings, or the timer doesn't like updates...
I've had problems with the last 2 updates. It might not be the direct cause, but there seem to be a link.

I got this error a while ago :



Last week, I tracked down the problem to the farr's ini file.

Half an hour ago, I got fed up with the JSON.parse error and not being able to use the Timer plugin , so I decided to solve it. Turned out that something messed up my findandrunrobot.ini file and the json there was all messed up. I corrected the code there, and all is fine now.
[...]

-Armando (November 19, 2010, 04:58 PM)

So... JSON syntax was wrong so I corrected it and all went well.

Today I install farr update, and I get the JSON parsing error message again. Of course I'm going to try to see what's wrong with the Timer's JSON stuff, but it's weird...

Any ideas ?

[Armando]

here's what happens to the code (put in red what's wrong, use (...) to indicate cuts ):

(...) {"datetimer = []>n>timer = [{"date":1290617048468,"text":"éteindre lampe"}]>n>settings.sound = C:\WINDOWS\Media\notify.wav>n>settings.alert = true>n>settings.pre_voice = Warning! Warning!>  (...)
etc.

And how I need to correct it

(...) {"date":1290615468906,"text":" éteindre lampe"}]>n>timer = []>n>settings.sound = C:\WINDOWS\Media\notify.wav>n>settings.alert = true>n>settings.pre_voice = Warning! Warning!>
(...)

[risingeil]

Feature Request:

I would like to be able to use the %appdrive% variable in External Tools  My apologies if you already do this, please show me an example, maybe I"m doing something wrong.

thanks

[dnknitro]

Sometimes I receive "FindAndRunRobot - No Disk" and FARR renders unusable for some time. Even program restart doesn't work! This is very frustrating because other then this error the program is very good.

I am using v2.93.01 on Windows 7 Enterprise (However I experience the same error @ Windows 7 Ultimate).

I am sure it happens when I connect my Android phone for charging only, so the phone doesn't expose itself as USB removable disk, but Windows 7 OS still starts to show that there is a new Removable disk connected, but it is inaccessible. When I switch the phone to the USB removable disk mode - FARR start working fine.

I guess the problem is with FARR's handling of disks which are inaccessible for some reasons. Can you please fix it?


One more issue - is there a possibility to ultimately disable FARR's search through the all disks in the system? I would like to make FARR search _only_ within folders, defined in the Program Options->Lists->Search Folders?

And one more - when I pass command line parameters to some program (e.g. "cmd.exe ++SomeCommand"), it looks like FARR makes all parameters lowercase, so the command will be run as "cmd.exe ++somecommand". Can this be fixed also?

[mouser]

thanks for the bug reports dnknitro, all seem reasonable and accurate.

the only one that i think is not a bug is:

One more issue - is there a possibility to ultimately disable FARR's search through the all disks in the system? I would like to make FARR search _only_ within folders, defined in the Program Options->Lists->Search Folders?

farr will only search those folders.. something else must be happening if it is searching elsewhere.. maybe because of an item in your history.

after new year i will release some substantial farr updates, so hang on until then!

[relipse]

Feature Request:

Voice Recognition Addon With FARR

FARR
say "FAR Robot" to open
start talking
it "types" what you say into the text box

Jim