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 wasn’t 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.

It’s disappointing. I almost didn’t upload the notice, hoping that if we all ignored the cretins they’d go away. But I know they won’t. And in the meantime a lot of innocents would get hurt.

I find it frustrating that our computers and the networks we’ve built to link the country together (nets made both of silicon and of flesh) must be fouled by this pestilence. I wish they’d take their paint cans and spray their crud somewhere else.

Strike that. No, I don’t. I don’t want to wish them on anyone else. I want them gone, permanently and irrevocably. But how??

From: Jmoreno

Re: Submenus

I’m 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, I’m going crazy (there are those who say I’ve BEEN crazy for years now but ignore them).

From: Jumpcut

Re: Submenus

Can’t you use the SetItemCmd call? Just wait for an activate event in your event loop and switch between the two menus as needed. (You’ll have to load them both from the resource file when you start.)

From: Jmoreno

Re: Submenus

I’d thought of tha; the problem is my app doesn’t limit the number of windows, and I’d like for each window/file to have it’s own menu, so how do I get a menuID for each that’s in the proper range, and don’t I have to worry about DA’s 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 I’d 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, I’d 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.) Don’t 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; don’t imbed a constant for the ROM address). finally, to really get some speed, don’t 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 that’s 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 don’t 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. I’m 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, I’m using LightSpeed 4.0 with a MacIIcx, color. But, I’m 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. Doesn’t 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 you’re 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++

I’ve been experimenting with Apple’s 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, it’s the first implementation of C++ on the Mac, and it IS the full release 2.0 from AT&T. In many respects it’s quite satisfactory for a beta compiler: it’s pretty stable as far as I can tell (despite warnings to the contrary in the release notes), and I’ve yet to encounter a case where it produces incorrect code that causes a runtime error (as opposed to something the C compiler can’t swallow). The code isn’t always the most efficient, but hey, it’s still early.

I’m sad to report that there’s a real downside to this product, however. In a word, it’s slow. Even on a Mac II with plenty of memory for Multifinder and a large MPW partition. I can’t say they didn’t 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”. That’s only about one-third of the problem, however. The real slowdown comes from the fact that you can’t precompile and load header files. No #pragma dump and load as in MPW C 3.0. That’s 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 it’s just inexcusable, in my humble opinion. Apple admits and even draws attention to the problem in the documentation for the preliminary MacApp headers. But what’s their solution? Compile all your source files at one shot using #include directives so the header files are only read in once. That’s fine once your code is debugged and you’re 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 doesn’t usually add significant features after a product enters the beta stage, and if something like that was in the works you’d 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...

I’ve been using the List Manager with Prototyper, and I never realized that the List Manager doesn’t handle scrolling all by itself. I’ll have to look into that!. By the way, List Manager seems to be very sensitive to memory allocation problems associated with ThC. Haven’t 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 I’m wrong, but the List Manager does handle scrolling all by itself. Check IM 4 p. 273 - LClick takes control when there’s a mousedown in the list or scrollbars. Maybe Prototyper isn’t using the actual list manager but some nasty imitation...You’ll have to be more specific on the problems you’re having.

From: Romeom

Re: Patching Traps

The October’89 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 don’t 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 FCB’s” 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 DA’s with submenus that work or don’t 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 haven’t 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, it’s 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? I’d 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

I’m looking for an Init to allow Tear Off Menu’s. I know MacTutor had an article on programming them some time ago, but I don’t 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 can’t 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!