Author Topic: Solution in search of a problem?  (Read 5291 times)

0 Members and 1 Guest are viewing this topic.

hermanm

  • Bull Frog
  • Posts: 282
If you don't know where you are going, you might not get there.
  - L.P. Berra

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: Solution in search of a problem?
« Reply #1 on: September 16, 2012, 03:22:42 PM »
There has been some things like this before ... a self replicating acaddoc.lsp file which copies itself into all folders as and when DWG files are opened is one example. VBA is embeddable into the DWG itself - so simply opening a DWG could have the code run (though by default ACad "should" ask you for a confirmation before running this code).

Obviously if some idiot does want to do this enough, it becomes near impossible to stop. This is one of the reasons many on these forums won't even attempt to use a compiled file (e.g. FAS) - there's no way to see what it's actually doing before running the code. It's sorry that we can't trust each other like this, but until human nature weeds out that particular branch we're stuck with it.
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

BlackBox

  • King Gator
  • Posts: 3745
Re: Solution in search of a problem?
« Reply #2 on: September 16, 2012, 06:39:02 PM »
... there's no way to see what [FAS is] actually doing before running the code. It's sorry that we can't trust each other like this, but until human nature weeds out that particular branch we're stuck with it.

Not necessarily... One of the comments in this thread contains a link to Fas-Interpreter-Beta-08.zip that allowed me to decrypt a virus that cropped up in a handful of our offices across North America enough (not fully), to identify the replication process, and the external objects being invoked, registry keys hit, and even the URL's it (the virus) was attempting to use to 'phone home'.

The trick isn't so much identifying what FAS is doing; it's handling it (an FAS virus) before it loads.

For that, one might register a .NET assembly to auto-[NET]load, which instantiates a Document Event(s) monitor, as this will Initialize() prior to Acad[.lsp [.fas]], and can still be found via FindFile() Method, and renamed or deleted before that step in the startup sequence (when a would-be virus could cause trouble).

Pseudo code:
Code - C#: [Select]
  1. using System;
  2. using Autodesk.AutoCAD.Runtime;
  3.  
  4. [assembly: ExtensionApplication(typeof(TheDoctorSays.BowTiesAreCool))]
  5.  
  6. namespace TheDoctorSays
  7. {
  8.  
  9.     public class BowTiesAreCool : IExtensionApplication
  10.     {
  11.  
  12.         void IExtensionApplication.Initialize()
  13.         {
  14.             Autodesk.AutoCAD.ApplicationServices.Application.
  15.                 DocumentManager.MdiActiveDocument.Editor.WriteMessage(
  16.                 "\n** Bow ties are cool ** "
  17.                 );
  18.         }
  19.  
  20.         void IExtensionApplication.Terminate()
  21.         {
  22.         }
  23.  
  24.     }
  25.  
  26. }
  27.  

Command line output, from Civil 3D 2011:
Code: [Select]
Loading AEC Base...
Loading AEC Base Extended...
Loading AEC Base UI...
Loading AEC Project Base...
Loading AEC Base GUI...
Loading AEC Schedule Data...
Loading AEC Project UI...
Loading AEC Utilities...

Customization file loaded successfully. Customization Group: CIVIL
Customization file loaded successfully. Customization Group: ACAD
Customization file loaded successfully. Customization Group: TOOLBASEDRIBBON
Customization file loaded successfully. Customization Group: TASKBASEDRIBBON
Customization file loaded successfully. Customization Group: AUTODESKSEEK
Customization file loaded successfully. Customization Group: AUTOCADRASTERDESIGN
Customization file loaded successfully. Customization Group: EXPRESS
Customization file loaded successfully. Customization Group: AUTOTURN
Loading AECC Base...

Initializing....
There are no valid MS Jet providers installed......Done.
Loading AECC Land...
Loading AECC Subentity Selection...

Loading Modeler DLLs.
Loading AECC Pipe Part...
Loading AECC QTO......
Loading AECC Pipe Network...
Loading AECC Roadway...
Loading AECC Survey...
Loading AEC Schedule...
Loading AECC Plan Production...
Loading AEC Architectural Base...
Loading AEC Structural Base...
Loading AEC Area Base...
Loading AEC Dimensions Base...
Loading AecCivilBase...
Loading AECC Building Site...
Loading AECC Point Cloud...
Regenerating model.
*Cancel*
Loading AECC Hydrology...
Loading AECC Base UI...
Loading AECC Event Viewer...
Loading AECC Land UI...
Loading AECC QTO UI...
Loading AECC Pipe Network UI...
Loading AECC Roadway UI...
Loading AECC Survey UI...
Loading AECC Plan Production UI...
Loading AECC Publish UI...
Loading AECC AeccUiHydrology...
Loading AECC Mapcheck...
Loading AECC Mapcheck UI...
Loading AECC Building Site UI...
Loading AECC Point Cloud UI...
Loading AECC Management UI...
Loading AECC Model UI...

** Bow ties are cool **

... Acad.lsp loaded.
AutoCAD menu utilities loaded.Regenerating model.

... AcadDoc.lsp loaded.
AutoCAD menu utilities loaded.

... CUix *.mnl files loaded *Cancel*

Command: _RIBBON

Command: COMMANDLINE

HTH
"How we think determines what we do, and what we do determines what we get."

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: Solution in search of a problem?
« Reply #3 on: September 17, 2012, 03:09:50 AM »
Yep, about the FAS disassembler: What RK's mentioned on that page is about what I'd expect. All versions of lisp (at least all that allow byte-code compilation) have a FAS compiling feature. Generally all it does is take the memory snapshot of a loaded LSP file and serialize that into the FAS file. Some have a little bit of optimization of some code as well - which generally changes the "source" into different calls or combines some function calls into one. So using such "decrypter" is a lot like using GDB on a C compiled program, unless you know all the ins-and-outs of the compiler's optimizations you would most probably only be able to see the paths/registry/strings used in the FAS, at best get a general gist of what it's trying to do.

Your idea of a NetDLL used as an ACad AV is good! Could basically be extended to become some sort of heuristic analysis tool warning / stopping "dangerous" code from running. It seems that ADesk is trying to close most of the doors through which some of these viruses might enter, basically doing the opposite of what you're proposing: i.e. disallowing things which heuristically have been found to be this sort of "dangerous" code. Though that is a double-edged sword: it's going to play havoc with some guys' setups.
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

BlackBox

  • King Gator
  • Posts: 3745
Re: Solution in search of a problem?
« Reply #4 on: September 17, 2012, 09:00:02 AM »
Your idea of a NetDLL used as an ACad AV is good!

Why, thank you, Sir.  :angel:

I dubbed my project AcAntiVirus##, where ## represents that database version (i.e., 18, 19, etc.).

The other reason that I like this concept is that, be it a hard-coded List<string>, or stored in separate XML file, one could relatively easily add 'virus definition' updates as needed. Not sure if I'd want the XML file dependency, but still.

One could instead use Acad.rx (as Acad.rx also loads prior to Acad[.lsp [.fas]] in the startup sequence) to auto-[ARX]load an ObjectARX file for same, but I am more adept at .NET than ObjectARX, and that's not saying much.  :lol:

Cheers! :beer:
"How we think determines what we do, and what we do determines what we get."

BlackBox

  • King Gator
  • Posts: 3745
Re: Solution in search of a problem?
« Reply #5 on: September 18, 2012, 12:25:40 PM »
Your idea of a NetDLL used as an ACad AV is good!
I dubbed my project AcAntiVirus##, where ## represents that database version (i.e., 18, 19, etc.).

... Looks like I'm going to get a chance to see if this works as conceptualized; we just found an infected user.

I know first-hand that both the network, and this user's computer were clean as of a specific date, which means it remained clean for a half day+/-.  :lol:
"How we think determines what we do, and what we do determines what we get."

BlackBox

  • King Gator
  • Posts: 3745
Re: Solution in search of a problem?
« Reply #6 on: September 24, 2012, 09:41:00 PM »
Update:

I've made some significant progress on this, and now have working code (thanks greatly to other's help in a couple of other threads here).

I use Civil 3D 2011, 2012 at work, and AutoCAD 2013 at home and was able to rewrite the code from the office in a matter of minutes once I got home.

Now, all I have to do is debug, and make sure that I've cought all of the exceptions that I can, and build in some contingencies for when a renamed file already exists, etc.

I'm doing this in my free time, so hopefully I can wrap this up this week (quite a bit of OT right now for project deadlines).
"How we think determines what we do, and what we do determines what we get."

owenwengerd

  • Bull Frog
  • Posts: 441
Re: Solution in search of a problem?
« Reply #7 on: September 25, 2012, 12:16:41 AM »
...make sure that I've cought all of the exceptions that I can...

You say that as if you think it's a good thing to "catch them all". That's a common novice mistake, so I think it's worth pointing out that you should never catch exceptions unless you know why they're thrown and how to recover safely. Otherwise, catching them will only make your bugs harder to find and fix.

BlackBox

  • King Gator
  • Posts: 3745
Re: Solution in search of a problem?
« Reply #8 on: September 25, 2012, 11:19:06 AM »
...make sure that I've cought all of the exceptions that I can...

You say that as if you think it's a good thing to "catch them all". That's a common novice mistake, so I think it's worth pointing out that you should never catch exceptions unless you know why they're thrown and how to recover safely. Otherwise, catching them will only make your bugs harder to find and fix.

Owen,

I've only interacted with you on occasion, but your reputation for excellence precedes you.

I accept your criticism, as I am a novice... At .NET development, Visual LISP, even development concepts and programming altogether. It is only through the feedback and guidance of others, such as yourself, that I have been able to achieve the level of development acumen that I currently have (no matter how insufficient that may be).

To clarify my statement, I do not intend on writing a catch block for each and every exception possible for the various Methods being invoked (System.IO.File.Move(), or this thread, as a couple of examples). Instead, I am attempting to (albeit perhaps insufficiently) avoid many possible exceptions through test expressions where possible.

But there are those, as in the latter example linked above, and in System.IO.File.Move() such as UnauthorizedAccessException that I simply cannot (or at least do not know how to) mitigate without catching, reporting to the user, and throwing.

Acknowledging that I have much to learn, doesn't quite make the point adequately.
"How we think determines what we do, and what we do determines what we get."

owenwengerd

  • Bull Frog
  • Posts: 441
Re: Solution in search of a problem?
« Reply #9 on: September 25, 2012, 11:45:21 AM »
I think it's a bad design to throw exceptions willy nilly when there are other perfectly un-exceptional ways to signal normal things like a file not found. You are rightly puzzled about the behavior you mentioned in the other thread. Unfortunately, if the API function you're calling uses exceptions in that way, then your client code has to be written accordingly. The main point I wanted to make in this thread is simply that catching exceptions is bad unless you know why they are thrown and how to safely recover. If you can safely recover, then catching exceptions is good (but slower than detecting and preventing the exception in the first place).

dgorsman

  • Water Moccasin
  • Posts: 2423
Re: Solution in search of a problem?
« Reply #10 on: September 25, 2012, 12:59:01 PM »
I've seen both ways used, with critcisms for each e.g. additional logic for conventional if/then testing which can hide problems vs. straight-through processing and catching any errors (programming by exception); or trying to suss out all applicable catch'es needed vs. simple logic tests to avoid the error in the first place.  A lot of it seems to be based on programming style and what is being designed e.g. a sealed (figuratively, not keyword) box of tools will likely take the exception route because a some severe problems cannot be anticpated.  Alot of it comes from "pure" programmers rather than hobbyists and considers conventional logic tests as uniformed/haven't learned exception programming, less streamlined, "hacks", etc.

I fall somewhere between the two extremes.  The common duh-simple problems get a "normal" logic test while problems which probably won't happen, but are end-of-the-world in consequences get try/catched just in case.   Consistent handling, I think, is the key - don't be returning a null in some places (which then needs checking) and throwing exceptions in others. For example I try to avoid returning nulls as it requires (or seems to...) constant testing of "Hey, is this a valid value?".  I also universally throw exceptions in cases where something (e.g. an argument value) is so wrong there's no point in proceeding further.
If you are going to fly by the seat of your pants, expect friction burns.

try {GreatPower;}
   catch (notResponsible)
      {NextTime(PlanAhead);}
   finally
      {MasterBasics;}

BlackBox

  • King Gator
  • Posts: 3745
Re: Solution in search of a problem?
« Reply #11 on: October 02, 2012, 05:41:51 PM »
I've been using a draft version of this AcAntiVirus (one where the known virus definitions are hard-coded, rather than looked up from XML - An enhancement forthcoming)... More importantly, I've been using the DocumentActivated Event to invoke the Method responsible for looking for these known virus files.

Giving this more thought, would it perhaps be better (by means of performance, overhead, etc.) to register a FileSystemWatcher for DWGPREFIX for each document added to the DocumentCollection, rather than to search for a virus file using HostApplicationServices.Current.Findfile() and looping again until none are found (where there's one instance of a self-replicating virus, there's usually more).

While it is possible for malicious code to accidentally be copied to a location in our SFSP (not just in a project directory), it is much more unlikely. Most users do not even have permission to these locations, and we internally add them to our standard profiles.

I've also thought of incorporating a SystemVariableChanged event handler to monitor the ACADLSPASDOC System Variable.

Just trying to cover the basics, to ensure that this is a well rounded (perhaps not an all inclusive) application plug-in.

TIA
"How we think determines what we do, and what we do determines what we get."