The thought of viruses in dgns and mdls have been swimming around in the
back of my head for more that a year or so. I really don't think the
anti-virus people care about (read scan) .dgn or .ma files at all.
>How do I know this binary isn't a Trojan without opening it?
because there is no provision in ustn to autoexecute code that might be
embedding in a dgn. And there is no way with the standard package to embed
any type of user command, macro or mdl in a dgn file. It's quite possible
for a virus to be in there and have a mdl or something unravel it onto the
disk and then run it; but where would you get such an mdl, and why would it
even be configured as a MS_DGNAPP?? And if it was a virus mdl, why would it
wait for a companion file. I mean, just go ahead and start trashing your
system as soon as you download it and pop it into uStn to see what kind of
goodie you just d/l 'ed.
It could however contain a startup element. This will instruct uStn to load
an mdl when loading the file, but the mdl has to be on the system or
network. So if a stranger gives you an .ma and a .dgn together, I might be
suspicious, but these could be found using EDG they would by type 66 (level
10? or 20? I forget?)
I going to go out on a limb here; and i'm sure that if I'm wrong or have
overlooked something Chris Z or Mark H. or somebody (BSI) will hopefully
chime in; but let's go ahead and estabish this. It is 100% safe to open any
alleged microstation design file with EDG. and if that file has no startup
elements in it, and there are no ~unknown~ mdl apps loaded as MS_DGNAPPS or
ucms configure to run ( MS_INIT) then it's 100% save to open it with uStn.
And if that file contains engineering links, I wouldn't follow them .
it used to be that code was code and data was data and the o/s would only
run code, ~not~ data. Therefore there was ~no~ way to get a virus by having
a program look at any data. This was repeated often by McAffee and others
during the "Goodtimes" virus scares. But then VBA and startup Macros matured
and now data and code ~can~ exist in the same file and M$ office products
will run the code, and depending on your M$ office configuration, sometimes
without even asking!
I saw a "goodtimes" variant going around a couple of months ago! Still alive
after all these years!
regards
tom m
--
Regards
Sam
"tom.mooney" <cl...@surveyor.com> wrote in message
news:IcZS4.78361$MB.16...@news6.giganews.com...
Sam,
Does Axiom still have that license term stating one cannot use File
Fixer to fix anyone else's files? I always got a kick out of that.
Lets see. He gave you a copy, so its yours to fix. Now you give him
back a copy of the fixed file. Sounds ok to me. Say a client gives you
a file, parts of which you must copy into your work. These parts also
happen to be corrupted. So you fix the corrupted parts now incorporated
into your file. Ok so far but now what? You cannot sell your product
back to the client because it contains copies of the client's elements
fixed by you?
Allan
>Say a client gives you<
> a file, parts of which you must copy into your work. These parts also<
> happen to be corrupted. So you fix the corrupted parts now incorporated<
> into your file. Ok so far but now what? You cannot sell your product<
> back to the client because it contains copies of the client's elements
> fixed by you?<
I don't have any clients that send me DGN files, it's the other way around.
My clients don't have CAD and don't wish to employ someone to start a design
office. So they simply contract the work to me and I give them production
drawings they don't give a hoot what system they were done in as long as
they get accurate drawings. I used Axiom File Fixer extensively until quite
recently when it sunk in at Bentley that they were lots of corrupt files
around and they have improved the quality. I find it very useful on old
files that require modification e.g. V4 into /J and they seem to be the
worst for problems. Also the odd AutoCAD translation, it soon sorts out the
problems that arise. We also have a vectorising bureau and they are they are
by far the worst for corruption but a couple of swings through File Fixer
and they are as *clean as a whistle*.
>You cannot sell your product<
> back to the client because it contains copies of the client's elements
> fixed by you?<
I'd sell my mother-in-law if she was marketable!.
CAD for me is simply a tool to make money, I have no interest in the system
itself or the operating system. I do get uptight when the CAD I am using
hinders my endeavours to make lots of greenbacks.
--
Regards
Sam
"AKSeidel" <akse...@swbell.net> wrote in message
news:391D6C86...@swbell.net...
> *********************************************************************
> New posting to comp.cad.microstation news group.
> Provided by the newsgroup-microstation "Majordomo" List Server
> *********************************************************************
> *********************************************************************
> To Un/Subscribe your self to any Bentley System, Inc. "Majordomo" list:
> via web : http://majordomo.bentley.com
> *********************************************************************
>I going to go out on a limb here; and i'm sure that if I'm wrong or have
>overlooked something Chris Z or Mark H. or somebody (BSI) will hopefully
Yes... but the probability of this happening in uStn is nil (zero).
Actually, data files (any data files) can turn into executable program.
The trick is to create a _corrupted_ data file which may trigger a bug in
processing application (most likely buffer overrun). When this happens,
malicious data (containing code) is overwriting parts of application's
own code and is executed. Normally OS (like NT) will prevent this, throwing
an exception (0xc00000005). But this is valid only for true, native code.
MicroStation is an OS in itself, and is executing p-code files (MDL), and these
are regarded being a data files by NT. In this case, no exception will be raised,
and, in theory, a DGN file may _modify_ MDL program in any fashion.
But we are talking rocket science here, and uStn is not even remotely
close to be regarded worth such attempt. But with regard to MS Explorer,
it is a whole another story...
--
Best Regards,
/Chris Zakrewsky
tom.mooney wrote in message ...
Chris Zakrewsky wrote in message ...
>Hi Tom (& thanks for confidence),
>
>>I going to go out on a limb here; and i'm sure that if I'm wrong or have
>>overlooked something Chris Z or Mark H. or somebody (BSI) will hopefully
>
>Yes... but the probability of this happening in uStn is nil (zero).
Thanks for the affirmation.
>Actually, data files (any data files) can turn into executable program.
>The trick is to create a _corrupted_ data file which may trigger a bug in
>processing application (most likely buffer overrun). When this happens,
>malicious data (containing code) is overwriting parts of application's
>own code and is executed. Normally OS (like NT) will prevent this, throwing
>an exception (0xc00000005). But this is valid only for true, native code.
yeah. ok, i see you point . but since most buffers are dynamic assigned at
run time it would seem that this would be a completely ramdom event that a
virus designer could never could on. I think there is a ~much~ better
chances of winning the lottery!
>But we are talking rocket science here, and uStn is not even remotely
>close to be regarded worth such attempt. But with regard to MS Explorer,
>it is a whole another story...
True, nobody would attempt to use uStn as a vehicle to bring world wide
e-mail servers to a crawl. Ustn just isn't out there on enough desktops. The
only reason I can think of why anybody would waste their time with a uStn
type of virus is for , industrial espionage / sabotage. Ok maybe I ~have~
seen one too many james bond movie or entertained one too may cia conspiracy
theories ! :~) But I really don't think the current crop of anti-virus
software will ~ever~ protect us from anything that could be lurking!
regards
tom m