A Very Dangerous Worm in Windows Metafile Images (WMF)

The Black & Decker one with the 'stiff' tape ?

Graham

Reply to
Pooh Bear
Loading thread data ...

Something like that, yes. It's nice if you want (or need) a totally open source system. For the average PC user it is not usable and non-existent.

--
Thanks, Frank.
(remove 'q' and '.invalid' when replying by email)
Reply to
Frank Bemelman

Respectfully, you may rest your case all the way to a crashed computer with missing and corrupted program and data files!

BTW, ZDNet has come out saying, don't wait for Microsoft, install the patch NOW. "Guilfanov is a big life saver."

formatting link

--
 Thanks,
    - Win
Reply to
Winfield Hill

It would certainly be fewer lines, but not quite that ratio. Assembly has lower density but, more importantly, I comment.

It doesn't really matter a lot. In hard-embedded systems, the time is spent reading dreadful serial DAC datasheets and designing FPGA register layouts and stuff like that, and not coding. We just spent a week characterizing a nonlinearity in an ADC subsystem, and I did a polynomial fix, in assembly, in about 10 minutes...

; OK, WE HAVE THE RESISTANCE IN D3 H:L AS OHMS:FRACTIONAL OHMS. ; BUT THERE'S AN AS-YET UNEXPLAINED ERROR CURVE: HIGHER ; RESISTANCES READ TOO LOW, BY ABOUT 120 PPM AT 1500 OHMS. ; SO LET'S DO AN R^2 KLUGE.

; THIS IS A SMALL TWEAK, SO WE'LL JUST NAB THE INTEGER OHMS, ; SQUARE, SCALE, AND ADD THAT IN.

; 120 PPM OF 1500 OHMS IS 0.18 OHMS, WHICH LOOKS LIKE ; 11,796 IN OUR FORMAT. SO IF X IS THE FUDGEFACTOR,

; 1500^2 * X = 11796 ; ; X = 0.005243 AS AN UNSIGNED FRACTIONAL,

X = 22517998 ; AS A LONG

MOVE.L D3, D5 ; COPY RESISTANCE SWAP.W D5 ; MOVE 'OHMS' PART INTO D5.W MULU.W D5, D5 ; AND SQUARE THAT... LONGWORD NOW. MOVE.L # X, D7 ; NAME THE FUDGE FACTOR MULU.Q D7, D4:D5 ; DO A FRACTIONAL MULTIPLY INTO D4 ADD.L D4, D3 ; AND BLEND IN THE CORRECTION.

Some people like oil, some watercolors, some clay, some stone. It's just a different kind of art.

Tell us something about your software.

John

Reply to
John Larkin

That statement just goes to prove that you have no idea what you are talking about.

Reply to
The Real Andy

But of course. It came with all of the above, BlueTooth, and MSIE which, unfortunately, is presently hung up displaying some kind of .WMF or something...

That's okay--I've still got a plain, old, outdated, old-fashioned 'hammer' to use while I'm holding for tech support on the new one. Oh, and a '486-75 notebook to do real work on. Compact flash harddrives make it dead-silent, with long battery life, and very reliable.

Cheers, James

Reply to
dagmargoodboat

My "print server" at home is an old Mitac 386 laptop, DOS, black&white, with a dimmish electroluminescent backlight. I never could get any version of Windows to drive my NEC wide-carriage fanfold matrix printer, so I network with floppies. It's outlasted four Windows machines so far.

John

Reply to
John Larkin

I use C for embedded systems, with the minimum of assembler required to start up the system and support things like task switching and semaphores. The embedded systems range from simple switched I/O cards, to boards with colour GUI and a touchscreen.

The processors I use for current designs are all ARM7 variants (LPC2000 and LH79520). I never used the 68000 for a commercial project, but I did used to have an Atari ST and have used some 68k derivatives in hobby projects. It *does* have a very nice instruction set, ideal for assembler, so I do sort of know where you are coming from.

In reverse chronological order I have also been using AVR, C167, HC11, and 8048 (gah!).

I also have to do some windows programming, using microsoft visual C++ (more gah!).

One thing I have managed to do in recent years is migrate everything to GNU tools and a common build and version control system. Everything lives in a single tree of source code and I can write a C library for, say, modbus that can be used by several projects using different CPU types. Even low-level bit twiddling can be efficiently abstracted (using C macros), so that the same hardware "driver" code can be used on different projects, even with different microcontroller types.

--

John Devereux
Reply to
John Devereux

Laptops make quite good "servers" in general, for home use anyway.

- Low power, so can be left permanently on without using too much electricity.

- small, so can be hidden out of the way somewhere.

- quiet, important when always-on.

- Built in UPS!

--

John Devereux
Reply to
John Devereux

I wouldn't want to program a RISC machine, or anything from Intel, in assembly. The 68K has a nice highish-level instruction set. I learned to program on the PDP-11, and C is just a sort of PDP-11 assembler... you can see the 11 instruction right through the language.

gah!

I recently did a tcp/ip app for Windows, using PowerBasic. It talks binary packets to a Lantronix Xport thingie in an embedded laser modulator (48 of which fire NIF). The PB program is neat: the tcp/ip stuff is simple and the result is a single, small exe file. They also have a window builder, sort of like VisualBasic but again makes a small, fast exe.

I do all my engineering apps in PowerBasic.

I just don't like abstraction... that's just me. A programming language is just an interface between your mind and the hardware, so different people will have different preferences.

I'm not a programmer by profession, so I don't care what's trendy or what's on my resume. I just want to get beautiful products out, and the sooner I finish a program the sooner I can wrap it up and start designing more hardware. A professional programmer knows that, when this program is finished, there's a lifetime of more programming ahead; that's a different attitide.

John

Reply to
John Larkin

I can wait until 10 january. There are other and more exciting things in my life than a SETABORTPROC problem. I don't fall for language usage such as "when the WMF file hits the hard drive...".

WMF is a handy format. JL does not understand why an image file wants to execute something, because he has no imagination at all. Then everybody gets excited because the extension does not safely indentify a file for certain purposes. Everybody knows that file extenstions were a bad idea in the first place, simply because there are so many different file formats that we have ran out of meaningful extensions. Internal header are *the* place to indentify a file. Nothing to get excited about.

There is no problem in the WMF file design itself. Windows will be fixed again, and we can continue to use WMF files. JL does not need to understand why WMF files have a place and why they execute things. He is too narrow minded to grasp such concepts.

--
Thanks, Frank.
(remove 'q' and '.invalid' when replying by email)
Reply to
Frank Bemelman

I guess I'm not a "professional" programmer either in that sense, and I never had a resume! I do hardware design & pcb layout too. I just spent the last few days designing a photodiode amplifier. (Well, more like fiddling with Phil Hobbs' one).

But. The cost of the hardware part of my projects is going down and down, and the microcontrollers are getting more and more powerful. My $6 ARM jellybean is 50 times as fast as your $100k PDP11. What I can do with the software is limited by my programming abilities, not by the hardware. So it makes sense to me to use higher level languages to organize the complexity, just so I can keep things straight in my head.

--

John Devereux
Reply to
John Devereux

We're working on one too. We'd like to speed up this receiver...

formatting link

which uses a fairly klunky silicon pin diode. I did this one, with the pin just feeding a current-mode opamp as a transimpedance thing, about

180 MHz bandwidth. Next gen, we'll add a common-base stage to reduce the capacitance that the opamp sees and, more importantly, increase the voltage across the pin diode, which in addition to reducing junction capacitance seems to sweep the carriers out faster. 350 MHz, 1 ns risetime, would be nice if we can push it that far.

John

Reply to
John Larkin

Kinda makes me think of "Maximum Overdrive". :-) (and, of course, the Terminator. :-) )

Cheers! Rich

Reply to
Rich Grise

In article , John Devereux wrote: [...]

A few years back, I wrote something in ASM51 that had to be duplicated on a PC. The PC version was written in C and then later converted to C++. At each step, it got longer.

R1 = 45; ACC = *DPTR; ACC *= B; ... etc ...

Neither C nor C++ allow multiple entry points.

--
--
kensmith@rahul.net   forging knowledge
Reply to
Ken Smith

How did you count lines? E.g., does "y=sin(x)" count as one line in C? How many in assembly? Does one count the lines of library code?

What was the "conversion" to C++? With a _very_ small number of exceptions, C code compiles just fine in C++ compilers.

You mean something like:

PrintSpace: mov r16,#32 PrintChar: (print whatever's in r16)

???

C or C++ with any decent optimizer will takes two functions such as "PrintSpace" and "PrintChar" and produce exactly the same code.

I might buy the idea that there are somehow mores lines of code "overall" in higher level languages, but there are certainly fewer and fewer lines _manually entered_ by a human.

---Joel Kolstad

Reply to
Joel Kolstad

So does Irfanview.

It does not. That's a lot of what this worm is about... executing WMF files that are misnamed .jpg, .gif, .bmp. No warning, it just runs the worm code.

John

Reply to
John Larkin

WMF files are very useful. They can invoke your browser and load popup ads. They can search your disk and tell Microsoft what apps you have installed. They can ensure that the contents of the document will be unusable after June 12, 2002. They're not just pretty pictures, they can do *anything*.

John

Reply to
John Larkin

Yeah, fun subroutines have multiple entry and multiple exit points. And call their own tails as subroutines.

John

Reply to
John Larkin

There's a plausible argument that many of the buffer overflow vulnerabilities in Windows are deliberate backdoors, their advantage being that they're not visible even in the source code.

Or maybe they're just stupid.

John

Reply to
John Larkin

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.