Apr 90 Mousehole
Volume Number: | | 6
|
Issue Number: | | 4
|
Column Tag: | | Mousehole Report
|
Trojan Horses
By Larry Nedry, Mousehole BBS
From : Arlen
Re: Trojan Horse Alert!
We have detected a new (to us) Macintosh trojan at the University of Alberta. Two different strains have been identified. Both are dangerous.
The first strain is embedded in a program called Mosaic, type=APPL and Creator=????. When launched, it immediately destroys the directories of all available physically unlocked hard and floppy disks, including the one it resides on. The attacked disks are renamed Gotcha!.
Unmounted but available SCSI hard disks are mounted and destroyed by the trojan. The files of hard disks are usually recoverable with one of the available commercial file utility programs, but often the data file names are lost. Files on floppy diskettes usually lose their Type and Creator codes as well, making recovery a non-trivial procedure.
The second strain was detected in a Public Domain program called FontFinder, Type=APPL and Creator=BNBW. It has a trigger date of 10 Feb 90. Before that date, the application simply displays a list of the fonts and point sizes in the system file.
On or after the trigger date, the trojan is invoked and disks are attacked as for the first strain. The trojan can be triggered by setting forward the Mac system clock.
Because the second strain has a latency period during which it is nondestructive, it is much more likely,to be widespread. Both trojans were originally downloaded from a local Macintosh BBS here in Edmonton. The second version was part of a Stuffit! archive named FontFinder.sit that also contained documentation and the source code for the FontFinder application. The source code does NOT contain the source code for the trojan.
A quick and dirty search string for VirusDetective (v/3.01 or later) has been developed that appears to detect the trojan engine in both strains. It is:
Resource CODE & ID = 1 & Data 44656174685472616B
Note that this will detect the currently known versions, but may or may not detect mutated versions of this trojan.
There is some evidence that these trojans are related based on preliminary investigation of the code. It has been speculated that the second is an improved version of the first (more sophisticated), or that the two versions were developed by two individual perpetrators working with the same trojan engine. There easily could be more versions either circulating or being developed.
This appears to be the first deliberately destructive malicious code that targets on the Macintosh. There is some suspicion that one or both have been developed locally. There is also the possibility that one or both were uploaded from a BBS in the Seattle, Washington area.
Our investigation is far from complete, but it is continuing. Please warn your Mac users to make proper back-ups on a regular basis, be suspicious of all software not received from a trusted source until tested, and generally, to practice safe computing.
There was also a third trojan, less destructive than the other two called Virus Info, which is an application (this should make one suspicious immediately), that was supposed to give information on several of the recent viruses, including samples of code used in these viruses. Instead as soon as you run the application it trashes your Finder, and then quits causing a crash because there is no Finder to exit to. There was no other apparent damage done by this trojan
I wasnt sure if any one here had seen this note. I figured on a board this populated somebody would post it before I got around to it, but I decided to err on the side of redundancy. It seems the vandals are catching up with the Mac.
Its disappointing. I almost didnt upload the notice, hoping that if we all ignored the cretins theyd go away. But I know they wont. And in the meantime a lot of innocents would get hurt.
I find it frustrating that our computers and the networks weve built to link the country together (nets made both of silicon and of flesh) must be fouled by this pestilence. I wish theyd take their paint cans and spray their crud somewhere else.
Strike that. No, I dont. I dont want to wish them on anyone else. I want them gone, permanently and irrevocably. But how??
From: Jmoreno
Re: Submenus
Im writing a program where sub-menu needs to change depending on the top-most window. How can I switch the sub-menu back and forth when ever there is a activate event? Any and all suggestion would be GREATLY suggested, Im going crazy (there are those who say Ive BEEN crazy for years now but ignore them).
From: Jumpcut
Re: Submenus
Cant you use the SetItemCmd call? Just wait for an activate event in your event loop and switch between the two menus as needed. (Youll have to load them both from the resource file when you start.)
From: Jmoreno
Re: Submenus
Id thought of tha; the problem is my app doesnt limit the number of windows, and Id like for each window/file to have its own menu, so how do I get a menuID for each thats in the proper range, and dont I have to worry about DAs adding their own submenus? Can I have more than one menu with the same ID if I set the menuID directly, or is this a big no-no that will cause it to blow up in my face?
From: Jmoreno
Re: Submenus
Just thought Id let you know what was stumping me. GetMenu was returning a handle to the first menu allocated using it, so instead of a menuhandle for each window I had a menuhandle for ALL windows, so I changed to NewMenu which works just fine. I do a DeleteMenu(SubID); InsertMenu(MyWndRec^.MenuHan,-1), and every thing is fine.
From: Jersquare
Re: Floating Windows
This is my first time that I have needed to add Floating Windows in an Application that I am building. I have it down mostly, except for dragging the windows that are beneath the topmost window.
What I have been doing is calling DragGrayRgn to move my window, BUT this draws the Gray Rectangle over my topmost window; it is a small problem I admit, but it is something I would like to get rid of. I know it can be done as if you hold the command key down when you drag a window in the Finder it moves behind and the DragWindow has the same option if you hold the command key in a drag.
What am I doing (or not doing) that Apple is not??
Thanks for any help you can offer.
From: Rastamon
Re: Floating Windows
Here is a code fragment that does the clipping necessary to make the window outline appear beneath the other windows when you call DragGrayRgn.
{1}
...
GetPort(SavePort);
GetWMgrPort(wMgrPort);
SetPort(GrafPtr(wMgrPort));
wMgrClip:=NewRgn; {should check for failure here!!}
DragRgn := NewRgn; {should check for failure here!!}
GetClip(wMgrClip);
SetClip(GetGrayRgn);
ClipAbove(theWindow);
CopyRgn(WindowPeek(theWindow)^.strucRgn,DragRgn);
Final := DragGrayRgn(DragRgn, globalMouse, boundsRect, boundsRect,
noConstraint, NIL);
SetClip(wMgrClip);
DisposeRgn(DragRgn);
DisposeRgn(wMgrClip);
SetPort(SavePort);
...
From: Tomt
Re: Pascal externals
In January MacTutor there was an example of a way to invoke external code resources from C. Does anyone have a similar fragment for use in Pascal? Invoking a code resource is doable, but I wonder about how I can pass a parameter to the code segment. While I could write it into a resource, Id prefer to use something simpler.
From: Romeom
Re: Pascal externals
Read the letter by Richard Siegel in the July 1988 MacTutor. Given a handle to the code, you can call the code and pass arguments to it by the procedure:
{2}
procedure CallCode(arg1,arg2,...,argN,codeHandle);
inline $205F,$2050,$4E90;
From: Walrus
Re: A New Book on the Market
Dan Allen has a book out called On Macintosh Programming:Advanced Techniques. It is a brief (460 pages) treatment of Mac programming, discussing some of the stuff in IM, but, in a more general view, although he does delve into some detailed areas (like, what exactly goes on between the time you turn on the Mac and it is ready to do something useful). It contains programming examples in Pascal, C, assembly lang., and Hypertalk; with almost no parallel listings (i.e. both C and Pascal programs that do the same things). The examples themselves are usually various types of utilities and tools. He covers MPW as well as Pascal and C programming, plus Hypercard (Allen works at Apple and says Winkler Mr. Hypertalk is writing a book about that language and says that when that becomes available, it should be THE reference). The Advanced Techniques in the title does not refer to getting into the minutiae of the Mac, he covers just too much area in one volume, but it is very useful, especially to those who are multi-lingual. The best feature of the book, I thought, was a lot of what he added because of his association with Apple. In discussing Mac software -- the Toolbox, MPW, ResEdit, etc., he tells the reader who worked on it. Andy Hertzfeld appears a lot of course, but I was not aware of how much Larry Kenyon had done on the software. It also contains some of the Mac curiosities like the MonkeyLives variable in low memory and the Mac SE slide show.
All in all, it is a book worth checking out. Even if you know IM by heart, this book probably contains little gems of trivia that you did not know.
From: Carless
Re: Quick CopyBits
I am having difficulty making CopyBits work quickly on my Mac II. Rewriting the stdBits routine will be a real pain. Is there a way to speed it up without rewriting stdBits?
From: Nicks
Re: Quick CopyBits
You can get some minor speed improvements by making sure your bitmaps are always word-aligned or especially long-word aligned (horiz. pos and width of bitmap in bytes is evenly divisible by four. Also, always copy maps of the same depth (e.g. use 4 bit deep maps with a 4-bit screen, etc.) Dont use 8-bit depths unless you just _must_ have 256 colors visible. Just using only 4-bit depth speeds up transfers by a factor of 2 over 8-bit transfers.
You can get about a 5% speedup when repeated copying small maps by bypassing the trap dispatcher and calling the ROM code directly (warning: use NGetTrap to obtain the address at run time; dont imbed a constant for the ROM address). finally, to really get some speed, dont rewrite the stdBits routine. A more direct way is to handle all the memory moves yourself in assembly. e.g.: to move a an 8-bit deep pixmap thats 16 pix wide and 16 high, just find the base address of each area and the rowbytes, then move 4 long words 16 times. Make sure your bitmaps dont need to be clipped, or strange and wonderful things will occur.
From: Ronyd
Re: Using Copybits()
I seem to have a basic misunderstanding on how the CopyBits() function is used. Im trying to blit a PICT resource onto the screen. I created the a widget using SuperPaint, copied this widget to Scrapbook, and used ResEdit to read it from Scrapbook, creating a PICT resource of my own. If I use DrawPicture(), the widget is reproduced. But, using CopyBits() produces an unrecognizable image. I then tried to blit an icon of a known size (32x32). This worked great!!
My conclusion is that I may not be setting up the BitMap struct properly, or the rectangle parameters correctly with an image of an irregular shape (ie., 50x120).
Can someone point me in the right direction? By the way, Im using LightSpeed 4.0 with a MacIIcx, color. But, Im dealing strictly with black and white images.
From: Ellsworth
Re: Tickcount accuracy for stopwatch routine
I am writing an application to emulate a stopwatch for doing race results. The accuracy needs to be in hundredths of a second. Tickcount would be great if I just divide by 60. The problem is that when testing the application the time gets longer when testing against a real stopwatch - about 2 seconds for every 10 minutes of race duration. Doesnt seem to matter which Mac I use or how abbreviated I make the program. I have read all the usual stuff about retrace and have even considered setting up a VBL task to update the timer but that is what tickcount is... Using the system clock works but only to 1 second accuracy. Please help!!!
From: Btoback
Re: Tickcount accuracy for stopwatch routine
The Mac vertical interrupt is 60.15Hz, rather than 60Hz. Divide TickCount by 60.15 rather than 60 and you should get more accurate results. But if youre going to time very long races, you should sample a number of Macs at a number of temperatures to see how stable and how repeatable the timebase is.
From: Atom
Re: C++
Ive been experimenting with Apples MPW C++ v3.1b1 now for about a month and a half, and have come away with a very mixed impression. I started out very hopefully. I wanted to like this compiler. After all, its the first implementation of C++ on the Mac, and it IS the full release 2.0 from AT&T. In many respects its quite satisfactory for a beta compiler: its pretty stable as far as I can tell (despite warnings to the contrary in the release notes), and Ive yet to encounter a case where it produces incorrect code that causes a runtime error (as opposed to something the C compiler cant swallow). The code isnt always the most efficient, but hey, its still early.
Im sad to report that theres a real downside to this product, however. In a word, its slow. Even on a Mac II with plenty of memory for Multifinder and a large MPW partition. I cant say they didnt warn me: the Fall 1989 APDAlog clearly states that the extra step of compiling before translating results in significantly longer compile times than those of other languages. Thats only about one-third of the problem, however. The real slowdown comes from the fact that you cant precompile and load header files. No #pragma dump and load as in MPW C 3.0. Thats a serious drawback to any Macintosh compiler considering the number and length of the Mac interface headers, but for a compiler specifically intended for MacApp users its just inexcusable, in my humble opinion. Apple admits and even draws attention to the problem in the documentation for the preliminary MacApp headers. But whats their solution? Compile all your source files at one shot using #include directives so the header files are only read in once. Thats fine once your code is debugged and youre just interested in building the application. But having to wait two minutes (only a slight exaggeration) every time I forget a semicolon in one source file is enough to drive me nuts.
Maybe the final release will fix this problem, but I rather doubt it. Apple doesnt usually add significant features after a product enters the beta stage, and if something like that was in the works youd think they would mention it somewhere. Common sense would indicate that there has to be a good reason for this omission, since Apple uses C++ quite a bit internally. No explanation whatever, though, in the release notes.
From: Jholder
Re: Help!
Well, I found out how to force a FDHD disk to be initialized. Just use the same csParam number as you would a 400k disk! If an FDHD disk is in the drive it will be initialized properly...
From: Mward
Re: List Manager problem...
Ive been using the List Manager with Prototyper, and I never realized that the List Manager doesnt handle scrolling all by itself. Ill have to look into that!. By the way, List Manager seems to be very sensitive to memory allocation problems associated with ThC. Havent got it worked out yet, but if I put too much into the MacHeaders, List Manager starts returning some really bizzzarre errors.
From: Jumpcut
Re: List Manager problem...
Um, correct me if Im wrong, but the List Manager does handle scrolling all by itself. Check IM 4 p. 273 - LClick takes control when theres a mousedown in the list or scrollbars. Maybe Prototyper isnt using the actual list manager but some nasty imitation...Youll have to be more specific on the problems youre having.
From: Romeom
Re: Patching Traps
The October89 MacTutor gave me help on writing INITs. But is there an equivalent in Pascal to the C procedure, CallPascal? It would come in handy to call the old trap from within our trap. The Pascal article in October 89 unfortunately did not give an example of patching traps in Pascal.
From: Tiger
Re: Patching traps
I need to patch all the standard file traps at once (I really just need to have my init called when a program calls SFGET, SFPUT, SFPPUT, SFPGET, etc., and I need to save some info, then call the proper function SFGET, etc. and need to do some processing after the call. I have found these routines to all be called by PACK3; so if anyone could help me out and tell me how to perform pre/post processing on these calls I would appreciate it. I tried trapping Pack3 with my init but I dont know enough about what it is doing to get it to work properly. Anyone know how I can patch these four routines?
From: Mward
Re: More Open Files
How does one go about increasing the number of open files allowed beyond the normal limit? (is it 40?)
From: Mrteague
Re: More Open Files
The only example I have seen of increasing the number of open files, is an INIT called Up Your FCBs by someone at Apple - I believe it allows the FCB queue to increase dynamically. Short of that, you *could* try changing the No. of open Files field in the boot blocks of your boot drive, using something like FEdit.
From: Wolfhound
Re: DA conflict with 32 bit Quickdraw
Recently I released a DA as shareware and I have found it has a bug, When the persons system has 32 bit color Quickdraw installed the sub menus of the DA do not work. The system does not pass anything in the ParamBlock. More specifically, nothing in cntrlParam->csParam[0]. Does anybody know anything about this? It works fine in all other cases returning the sub menus ID number. Does anybody with 32 bit color on their machine have other DAs with submenus that work or dont work? Does Apple know anything? Any help advice etc. anyone can give would be most greatly appreciated!
From: Jmoreno
Re: CursorWrap Init
The problem you are having is NOT with a boolean expression. Apple defined a keymap, i.e. theMap as an array of boolean, THINK defines it as a array [0..3] OF LONGINT, so instead of if themap[58] then you need to do a bittst(@themap,58) which if I havent messed up the params will work.
From: Chucks
Re: dimming text problem
Trying to dim text in home-grown buttons (using OOP objects) but Think Pascal 2.02 is being weird on me. I draw the button title, set up a rect containing it, PenMode(patBic), PenPat(gray), Paint(therect) which has the right effect. But when I run it, its sporadic--sometimes graying the text, sometimes not. The rest of my routine just calculates where to draw, sets the origin there (after saving the whole drawing environment), draws, tries to dim, restores the environment. Any ideas, flaws, better approaches? Thanks.
From: Carlm
Re: Color Think
Does anyone know where I can get interfaces for Think Pascal to handle the new 32 bit color calls? Id sure appreciate a lead. We will try to rewrite the MPW interfaces, but it would be a whole lot easier not to have to.
From: Philk
Re: Want Tear Off Menu Init
Im looking for an Init to allow Tear Off Menus. I know MacTutor had an article on programming them some time ago, but I dont remember when. I also seem to remember there were some problems with the programming techniques used that were brought out in letters sent in later. Is there a commercial or preferably shareware Init available?
From: Mikec
Re: Application Window
Does anyone know how to move the HyperCard application window? On startup, I would like to use an XCMD to reposition the window (on MacII machines) so that my dialogs and card fields are in alignment. I know I saw it in a mag. once and cant for the life of me remember which one.
From: Tata
Re: Dialog from scratch...
Has anyone any solutions how to build up in memory a DITL list? This particular dialog I am working on is running in a XCMD under HyperCard. I tried to declare a button in a record, and then send the handle of the record to the NewDialog, but somehow I can not get the button appear in the screen! The rectangle of the button is however there somewhere because when you click to the place where it should appear in the dialog, modalDialog does exit from it correctly. HELP!