The infamous email shuffle words virus or something

[Dustin]

I don't recall such a distinction. So you concede then that
programmers, rather than coders, don't need to know ASM. Concession
noted. I win that point.

You should re-read some posts then. A programmer is close to a coder,
but lacks the get down dirty in the mud have an intimate discussion
with the hardware skills. Coders *are* very much programmers, but not
all programmers are coders. I don't see what concession you feel I've
made or what point? you're declaring victory on. I didn't make the
mistake of calling you an ass clown before I got to know what your
skillset is. You did that.

No. I rely on my AV suite and firewall to catch and block malware.

Well, alas, I don't. If you want to see something old school I
wrote, you can view this:

http://bughunter.it-mate.co.uk

That program got me a job for (2 years or so) with malwarebytes. Do you
know I essentially did while there? Disected harmful software and wrote
definitions to detect and remove them. I told you from the getgo, you
didn't want to compare skills with me. I'm not God mind you, but I'm
not you either. [g]

 

[Dustin]

These days *WRITING* assembler is a specialty skill that most
programmers will never need.

Hence the difference between your programmers and the rest of us.

 

[Loren Pechtel]

I wouldn't say it's self modifying in the strictest sense, no. The
thing with self altering code vs data re-arrangement tho is that most
resident virus suites/scanners/whatever go ape shit in a hurry now.

The EICAR file is self-modifying as you can't code an Int 21h with the
permitted character set. Thus the Int 21h instruction must be created
mathematically and then written to the code.

It's just supposed to demonstrate what you should see when your
protection of choice actually sees something. It's saddening that it
ever had to be created in the first place, but that's the majority for
you.

The majority?? It's a *TINY* percentage of people that write the
hostile stuff.

Anyway, it's not so much about what you should see as testing that
your protection of choice is actually working. Type it in and it
should get zapped.

 

[Loren Pechtel]

No. I rely on my AV suite and firewall to catch and block malware.

Fine for the average person but someone has to write that AV code.

Someone also has to write the compilers that produce machine code
output.

 

[Loren Pechtel]

Hence the difference between your programmers and the rest of us.

Whatever you call them, writing assembly is now a specialized skill
that few people will ever need.

Reading it is a skill anyone who does it for a living certainly should
have.

 

[Loren Pechtel]

That's true but even if it was intended to be run it's still
irrelevant. Eicar is a 16 bit DOS .com executable not a Win32 or
Win64 PE. This means it doesn't execute instructions directly on the
CPU but in a virtual machine (ntvdm.exe).

But the virtual machine isn't an emulator. The instructions execute
on the raw hardware. It's just the protected instructions are
trapped.

I'm not aware of any precautions regarding caching and self modifying
code. I've examined a lot of it in malware and shellcode and seen no
special steps taken.

http://en.wikipedia.org/wiki/Self-modifying_code#Interaction_of_cache_and_self-modifying_code

It sounds like it isn't an issue at this point. My understanding is
that originally the you got burned if the instruction had already been
loaded into the chip cache.

 

[RayLopez99]

Hence the difference between your programmers and the rest of us.

Whatever. Point being, as a programmer you don't need to write and I
would even say read assembly.

And as for your software, while it was worthy for a few years, it's
now discontinued. As the song says, "Glory days....pass you by" - B.
Springstein

RL

BugHunter is DISCONTINUED SOFTWARE!
Click here to download BugHunter v2.2e updated August 26th, 2008

 

[Loren Pechtel]

I'm sure you're right about the trapping of interrupts, I/O calls and
other privileged instructions but I'm not so sure about emulation for
16 bit. The processor would need to switch modes and looking at the
exports from ntvdm.exe, with function like GetAX, SetAX and similar
routines for all other registers and flags, makes me think there is
emulation.

Emulation runs *MUCH* slower than the raw hardware. The dos box
doesn't. The chip supports 16 bit operation directly, there is no
need of emulation. Only the protected instructions are emulated.

 

[RayLopez99]

I'm sure you're right about the trapping of interrupts, I/O calls and
other privileged instructions but I'm not so sure about emulation for
16 bit. The processor would need to switch modes and looking at the
exports from ntvdm.exe, with function like GetAX, SetAX and similar
routines for all other registers and flags, makes me think there is
emulation.

Ant, you can fool a lot of people talking like that, but you can't
fool me. You sound pretty foolish in fact. "makes me think" LOL
that's a good B.S. catchall phrase, as you can always back out and say
"it looked that way". As for virtual machine, why don't you use
Google? http://en.wikipedia.org/wiki/Virtual_machine and see below.
In short, here is the killer sentence that refutes your position: "The
standard x86 processor architecture as used in modern PCs does not
actually meet the Popek and Goldberg virtualization requirements.
Notably, there is no execution mode where all sensitive machine
instructions always trap, which would allow per-instruction
virtualization."

Just like Loren Pechtel said.

RL

http://en.wikipedia.org/wiki/Virtua...nderlying_raw_hardware_.28native_execution.29

Emulation of the underlying raw hardware (native execution)

This approach is described as full virtualization of the hardware, and
can be implemented using a Type 1 or Type 2 hypervisor. (A Type 1
hypervisor runs directly on the hardware; a Type 2 hypervisor runs on
another operating system, such as Linux). Each virtual machine can run
any operating system supported by the underlying hardware. Users can
thus run two or more different "guest" operating systems
simultaneously, in separate "private" virtual computers.


The standard x86 processor architecture as used in modern PCs does not
actually meet the Popek and Goldberg virtualization requirements.
Notably, there is no execution mode where all sensitive machine
instructions always trap, which would allow per-instruction
virtualization.

Despite these limitations, several software packages have managed to
provide virtualization on the x86 architecture, even though dynamic
recompilation of privileged code, as first implemented by VMware,
incurs some performance overhead as compared to a VM running on a
natively virtualizable architecture such as the IBM System/370 or
Motorola MC68020. By now, several other software packages such as
Virtual PC, VirtualBox, Parallels Workstation and Virtual Iron manage
to implement virtualization on x86 hardware.

Intel and AMD have introduced features to their x86 processors to
enable virtualization in hardware.

 

[Dustin]

I'm sure you're right about the trapping of interrupts, I/O calls and
other privileged instructions but I'm not so sure about emulation for
16 bit. The processor would need to switch modes and looking at the
exports from ntvdm.exe, with function like GetAX, SetAX and similar
routines for all other registers and flags, makes me think there is
emulation.

Under an NT based OS, it's completely emulated. 16bit apps are NOT
directly talking to the hardware; Windows is the phonebank.

 

[Dustin]

The majority?? It's a *TINY* percentage of people that write the
hostile stuff.

The majority as I intended was the lamer end users, not the malware guys.
I'm aware of the percentage and a considerable amount more with regard to
the malware scene. I was er, one of them once...

Anyway, it's not so much about what you should see as testing that
your protection of choice is actually working. Type it in and it
should get zapped.

I shouldn't have to "test" my protection. [g]

 

[Dustin]

Whatever. Point being, as a programmer you don't need to write and
I would even say read assembly.

As a malware researcher tho, assembly is required. Atleast, for me.

And as for your software, while it was worthy for a few years, it's
now discontinued. As the song says, "Glory days....pass you by" -
B. Springstein

I discontinued BugHunter because I went to work for malwarebytes, I
couldn't continue updating both apps. One was a paying gig, the other
was free.

 

[FromTheRafters]

The majority?? It's a *TINY* percentage of people that write the
hostile stuff.

The majority as I intended was the lamer end users, not the malware guys.
I'm aware of the percentage and a considerable amount more with regard to
the malware scene. I was er, one of them once...

Anyway, it's not so much about what you should see as testing that
your protection of choice is actually working. Type it in and it
should get zapped.

I shouldn't have to "test" my protection. [g]

I never really considered it a test of anything. I only recommended it
to people so that they could see what an alert looks like coming from
their "protection" program. They would be less likely to fall for some
fake-AV script telling them "Blah AV has found suspicious activity and
will scan your system [OK(okay)|X(still ok)]" if they knew what a real
alert looks like.

To really test an AV you need a wide variety of confirmed real malware
to throw at it.

 

[Dustin]

Apparently not (on x86).

As I've learned. Thanks for the educational update. [g]

True.

It's a nice emulation effect tho. A cmos view/dump/backup/restore util
I wrote years ago seems to perform it's functions, but the amusing
kicker is the changes are in that ntvdm.exe session only. If I open
another console and run another copy, it doesn't know anything about
any changes and shows me the old cmos before I edited it. Saving my
results is shown to work, but only for as long as the session is open.
The second I close that console; the "change" is lost.

Interestingly enough, int13 appears to actually work on floppy
diskettes. The changes persist, they are actually written over to the
floppy. heh.

 

[Dustin]

The majority?? It's a *TINY* percentage of people that write the
hostile stuff.

The majority as I intended was the lamer end users, not the malware
guys. I'm aware of the percentage and a considerable amount more
with regard to the malware scene. I was er, one of them once...

Anyway, it's not so much about what you should see as testing that
your protection of choice is actually working. Type it in and it
should get zapped.

I shouldn't have to "test" my protection. [g]

I never really considered it a test of anything. I only recommended
it to people so that they could see what an alert looks like coming
from their "protection" program. They would be less likely to fall
for some fake-AV script telling them "Blah AV has found suspicious
activity and will scan your system [OK(okay)|X(still ok)]" if they
knew what a real alert looks like.

That's my point, I think. I just didn't consider that people would need
to see the alarm going off to know it was... Stupid move on my part, I
suppose.

Was the test file planned prior to Doren Rosenthals shareware virus?

 

[FromTheRafters]

The majority?? It's a *TINY* percentage of people that write the
hostile stuff.

The majority as I intended was the lamer end users, not the malware
guys. I'm aware of the percentage and a considerable amount more
with regard to the malware scene. I was er, one of them once...

Anyway, it's not so much about what you should see as testing that
your protection of choice is actually working. Type it in and it
should get zapped.

I shouldn't have to "test" my protection. [g]

I never really considered it a test of anything. I only recommended
it to people so that they could see what an alert looks like coming
from their "protection" program. They would be less likely to fall
for some fake-AV script telling them "Blah AV has found suspicious
activity and will scan your system [OK(okay)|X(still ok)]" if they
knew what a real alert looks like.

That's my point, I think. I just didn't consider that people would need
to see the alarm going off to know it was... Stupid move on my part, I
suppose.

Was the test file planned prior to Doren Rosenthals shareware virus?

I don't know. Probably because of them/it. I don't think people were as
likely to ever see a real bona fide alert back then, and they *did* want
to be reassured that the "protection" was doing *something* besides
costing them money. )

 

[Loren Pechtel]

I've learnt something by your challenging my preconceptions.
Apparently mode switching is not the problem I thought it would be.

It's not cheap but it's an awful lot cheaper than emulating everything
would. I've hit one case where it was really bad--graphics.

I was using VMWare which for most purposes is excellent. (As I write
this I'm in a VMWare machine, in fact. All web access that I can is
isolated in the VM, it's much easier to restore than a whole machine
would be.) It can't do graphics, though--under normal conditions you
install a supplied video driver that works fine for anything other
than gaming. This only works inside Windows, though--dos boxes are
another matter. Trying to run ordinary 25x80 text mode was slow
enough to really bug me when typing. Trying to run a program that
used 800x600x256 graphics mode was out of the question.

Microsoft's Virtual PC performed better in this situation but it was
still ugly.

Note that this was some time ago, it might work better on modern
hardware but the need to run the legacy app is now gone, I haven't
tried it.

 

[Loren Pechtel]

Under an NT based OS, it's completely emulated. 16bit apps are NOT
directly talking to the hardware; Windows is the phonebank.

The hardware access is fully emulated but most everything else
executes on the chip directly.

 

[Loren Pechtel]

That's my point, I think. I just didn't consider that people would need
to see the alarm going off to know it was... Stupid move on my part, I
suppose.

It could be useful if it wasn't your own box. It lets you test the AV
setup on any box you're using.