Jimmy Bergmark has reported a particularly unpleasant piece of malware, so please check it out. The Autodesk Knowledge Base item can be found here.
Tag Archives: Virus
Partial fix for language pack problem
The Civil 3D group within Autodesk has moved impressively quickly in providing a partial solution to the language pack problem I described earlier. What has been provided so far is a set of patches for Civil 3D 2009, 2010 and 2011 that allow Civil 3D users to remove the spurious language pack flag by opening and re-saving the affected drawings. I have not yet tested this, but I am informed that it works.
What’s left to do? Obviously, not all recipients of these drawings are going to have Civil 3D. In fact, prior to isolating Civil 3D as one definite source of the problem, I had spent a lot of time helping out AutoCAD users clean up language-pack-infected drawings, using awkward and dangerous copy-and-paste methods. So Autodesk has AutoCAD and all its vertical variants to work through yet as far as a cleanup mechanism goes. Also, the problem needs resolving at the source end. All “infected” templates (in Civil 3D and any other verticals that may have the problem) need fixing and distributing to users as quickly and effectively as possible, in order to reduce the number of drawings being created with the problem. I know individual users can do this for themselves, but large numbers of users won’t do so if left to their own devices, causing problems for everyone else. As the originator of the problem, Autodesk has a duty to do its very best to resolve it.
Thanks, Autodesk, for quickly getting started on fixing the problem and providing a partial solution in a timely manner. I hope you can provide the rest of the solution equally efficiently.
Civil 3D 2011 ANZ comes complete with “virus”
If you install Civil 3D 2011 using the ANZ (Australia/New Zealand) profile, when you start it up for the first time, you will see a large warning indicating that the drawing requires an Asian language pack to be installed. It also warns that this is a symptom of the acad.vlx virus:
Now I know that in this case it’s not an actual virus causing the problem, but rather the ANZ template drawing being “infected” with this Language Pack requirement. I have had to deal with quite a few incoming drawings in this state, and that’s painful enough without Autodesk also infecting every Australasian Civil 3D drawing with the problem. Other profiles may be similarly infected, but at the moment I don’t know. Edit: Matt Anderson reports that the problem occurs on US systems too.
Autodesk, I suggest that as a matter of great urgency you create a clean ANZ template file, post it as a hotfix and warn all your Civil 3D customers of the SNAFU. Neither “install the language pack” nor “turn off the warning” are adequate workarounds. Your customers do not want to send out or receive any drawings in this state.
Beyond the immediate issue of Autodesk shipping software that on first use warns the user that they may have a virus (and encourages the creation of drawings that spread that warning far and wide), I would appreciate some assistance in dealing with “infected” drawings, whether in Civil 3D or plain AutoCAD.
First, I need to be able to detect such drawings using LISP so I ensure they are rejected rather than allowed into our drawing management system, and this detection will need to work in releases at least as far back as AutoCAD 2004.
Second, I need a mechanism of cleaning up such drawings. The only thing I have discovered that works so far is the manual, time-consuming and dangerous process of recreating the drawings by starting from scratch and Copy/Paste in each layout. With big jobs using nested xrefs, this is fraught. I need to be able to provide a LISP-based cleanup mechanism that I can set up to work in batch mode on a set of drawings.
I would be grateful for any clues anyone might have about the above detect & cleanup needs.
Edit: see the comments for further important information.
AutoCAD virus protection update
As I mentioned in my last post, I had some reservations about the code provided by Autodesk to deal with suspect acad.vlx and logo.gif files. Based on a suggestion from Jimmy Bergmark, I have written my own, safer version which you can download here: clean_virus_safe.lsp.
The comments at the top of the clean_virus_safe.lsp file explain what to do with it, but I will reproduce some of the relevant points here.
- Purpose: Checks for existence of acad.vlx and logo.gif files, which are associated with virus AL/Logo-A, also known as ACAD/Unexplode, ACAD/Agent.A or ACM_UNEXPLODE.B. Written as a safer alternative to Autodesk’s code which deletes suspect files without prior warning. This code renames the files instead.
- Legal: Provided as-is with no warranty whatsoever, use at own risk. May be distributed freely.
- Usage: Append the contents of this file into a startup LISP file (e.g. acaddoc.lsp in your search path – create such a file if it does not exist). Autodesk’s suggestion to modify the acad20xx.lsp file should not be followed: this is bad practice. The acad20xx.lsp file is Autodesk’s file and any modifications you make to it are likely to be lost when updates and patches are applied.
- Effects: Any and all files named acad.vlx and logo.gif and located in AutoCAD’s search path will be renamed, e.g. “acad.vlx” will become “[Suspected Virus] acad.vlx0”. The name will end in a number starting with 0. If other suspect files are later found in the same location, those files will be renamed to end with 1, 2, 3 and so on.
I don’t have a copy of the actual virus, and would like to get hold of one with a view to possibly improving this code. If you have a copy, I would be grateful if you could contact me so I can dissect it.
Another AutoCAD malware warning
Shaan Hurley has posted some useful information about another AutoCAD-based virus that is doing the rounds, and I strongly suggest you read it. However, I have some reservations about the solution that is posted there and in the Autodesk knowledgebase.
The LISP code suggested will delete any files called acad.vlx or logo.gif that are located in the current user’s current AutoCAD search path. There are a couple of problems with that.
- The search path will change depending on the user, the profile, the startup folder and the drawing folder. That means you can’t just use the code once and expect the problem to go away; the code will need to remain in place permanently to ensure it does not recur. That may not be a huge problem, although it will have a performance penalty (particularly where the search path is long and/or includes network paths) and it is one more thing to remember to carry over to future releases.
- More importantly, the code has no idea if the files it is deleting are legitimate or not. It is quite possible for a custom environment or third-party utility to make use of a file called acad.vlx, and there are all sorts of reasons you may have a logo.gif file floating around. The Autodesk code will just erase such files without prior warning, which is a bit naughty.
I commend Shaan and Autodesk for posting this information and proposed solution. However, I recommend caution before using this code as suggested. Check with your CAD Manager (if you have one) first to ensure there are no legitimate acad.vlx files in your environment. Do a search for these files yourself and see if there is a legitimate reason for them being where they are.
As with most malware attacks, taking care with incoming files is a very important part of the solution. Don’t just blindly use the contents of a zip file full of drawings, even from a trusted source. If somebody sends you a zip file containing an acad.vlx file, let the sender know about the problem and ask for an uninfected set of files.
AutoCAD malware warning
There is a piece of malware out there written as an ObjectARX application, i.e. it will only affect AutoCAD users. It’s a China-based adware client, which Andrew Brandt at the Webroot threat blog has named Trojan-Pigrig. For full details, see here. Also, see here for AutoCAD-specific advice from the AutoCAD support team at the Without a Net blog.