Gibson's Meltdown/Spectre Tester

https://www.grc.com/inspectre.htm

with a warning not to d/l from other sites.
--
Peter.
The gods will stay away
whilst religions hold sway

PeterC wrote:
https://www.grc.com/inspectre.htm

with a warning not to d/l from other sites.

That page says it's "written in assembler" ???
LOL. Maybe he inserted a couple of #pragma and
20 lines of assembler or something. I doubt the
entire program is assembler. Only a kook would
do that (we had such a kook at work).

So the utility did tell me something. I tried a VM first,
and it turns out, VMs don't allow the "true" microcode state
to be seen by the Guest. Good ole VirtualBox tells my
VM the processor is running microcode 18, instead of the 2a
I know it is running.

Since the Host OS was Linux (the only OS which will load
the Jan.8, 2018 microcode for me), I then ran inspectre.exe
under wine.

wine inspectre.exe

And this is the result. Even though it's WINE and runs
the risk of nor handling all OS calls properly, the
green text in the window seems to indicate that Gibson
can see the CPU is running 2a.

https://s18.postimg.org/tv0ythypl/in...under_wine.gif

I don't think WINE has a particularly strong "personality",
and Gibson didn't say it was WinXP or anything. The WINE
registry settings probably don't reflect any of this
current nonsense, so the tool concludes I'm completely
vulnerable.

And if I boot a Windows disk and run the program "native",
I'm not going to get that green text, because Windows won't
load the microcode like Linux is doing at the moment.

My conclusion at the moment is "we can't have nice things" :-)
For some value of green text.

Paul

On Wed, 17 Jan 2018 06:28:20 -0500, Paul wrote:

PeterC wrote:
https://www.grc.com/inspectre.htm

with a warning not to d/l from other sites.

That page says it's "written in assembler" ???
LOL. Maybe he inserted a couple of #pragma and
20 lines of assembler or something. I doubt the
entire program is assembler. Only a kook would
do that (we had such a kook at work).

Steve is exactly that sort of kook, but mostly harmless. He's been
boasting of writing assembly language Windows apps for 25 years or so,
and I've not seen anyone do a disassembly and deny that it's
handcrafted. He is a loon.

Cheers - Jaimie
--
If you mean 'am I serious about what I do', the answer is yes.
If you mean 'am I serious about how I do it', the answer is no.

On 17/01/2018 in message Paul wrote:

PeterC wrote:
https://www.grc.com/inspectre.htm

with a warning not to d/l from other sites.

That page says it's "written in assembler" ???
LOL. Maybe he inserted a couple of #pragma and
20 lines of assembler or something. I doubt the
entire program is assembler. Only a kook would
do that (we had such a kook at work).

He is (or perhaps was) very well known for writing Windows apps in
assembler and offered a complete toolkit free. I had a play with it and it
produced incredibly fast programs.

--
Jeff Gaines Wiltshire UK
If you ever find something you like buy a lifetime supply because they
will stop making it

"PeterC" wrote

| https://www.grc.com/inspectre.htm
|

Thanks. That's a handy little tool. It's nice to
know that Steve Gibson is still kicking. I think of
him as one of the very few people in tech who
just wants to help *and* knows how.

But why did you set responses to block the
Win7 group where you posted?

In article , lid says...

PeterC wrote:
https://www.grc.com/inspectre.htm

with a warning not to d/l from other sites.

That page says it's "written in assembler" ???
LOL. Maybe he inserted a couple of #pragma and
20 lines of assembler or something. I doubt the
entire program is assembler. Only a kook would
do that (we had such a kook at work).


No for years I believe he's written most if not all his apps in
assembler, why they're so small for wehat they do. Least years ago he
did.

So the utility did tell me something. I tried a VM first,
and it turns out, VMs don't allow the "true" microcode state
to be seen by the Guest. Good ole VirtualBox tells my
VM the processor is running microcode 18, instead of the 2a
I know it is running.

Since the Host OS was Linux (the only OS which will load
the Jan.8, 2018 microcode for me), I then ran inspectre.exe
under wine.

wine inspectre.exe

And this is the result. Even though it's WINE and runs
the risk of nor handling all OS calls properly, the
green text in the window seems to indicate that Gibson
can see the CPU is running 2a.

https://s18.postimg.org/tv0ythypl/in...under_wine.gif

I don't think WINE has a particularly strong "personality",
and Gibson didn't say it was WinXP or anything. The WINE
registry settings probably don't reflect any of this
current nonsense, so the tool concludes I'm completely
vulnerable.

And if I boot a Windows disk and run the program "native",
I'm not going to get that green text, because Windows won't
load the microcode like Linux is doing at the moment.

My conclusion at the moment is "we can't have nice things" :-)
For some value of green text.

Paul

On Wed, 17 Jan 2018 06:28:20 -0500, Paul
wrote:

PeterC wrote:
https://www.grc.com/inspectre.htm

with a warning not to d/l from other sites.

That page says it's "written in assembler" ???
LOL. Maybe he inserted a couple of #pragma and
20 lines of assembler or something. I doubt the
entire program is assembler. Only a kook would
do that (we had such a kook at work).
Gibson does write in assembler. I think, however, that
he uses a macro assembler.

I went to grad school in the 1960s. Peter B. Olson
was an undergraduate at the same school who wrote
IBM 360 code in assembler, including a spool program,
and a job submittal program that ran from APL so that
people no longer needed to use card decks.

For a couple of years he did not use macros, which
he as able to do since he know all of the SVC calling
sequences the he used by heart. Yes, he could
write programs using the console data switches in addition
to merely debugging at the console.

I don't remember why he didn't use macros; perhaps it
was because he thought it took too long for the assembler
to process them on our 360/50. However, he switched to using
macros, for the SVC's at least, when IBM changed the way
that one or more SVC's worked and he had go through all of
his code to fix the calls that had to change.

(I think this is the same Peter B. Olson who worked at
the Free Software Foundation and who died in April 2017.)

So the utility did tell me something. I tried a VM first,
and it turns out, VMs don't allow the "true" microcode state
to be seen by the Guest. Good ole VirtualBox tells my
VM the processor is running microcode 18, instead of the 2a
I know it is running.

Since the Host OS was Linux (the only OS which will load
the Jan.8, 2018 microcode for me), I then ran inspectre.exe
under wine.

wine inspectre.exe

And this is the result. Even though it's WINE and runs
the risk of nor handling all OS calls properly, the
green text in the window seems to indicate that Gibson
can see the CPU is running 2a.

https://s18.postimg.org/tv0ythypl/in...under_wine.gif

I don't think WINE has a particularly strong "personality",
and Gibson didn't say it was WinXP or anything. The WINE
registry settings probably don't reflect any of this
current nonsense, so the tool concludes I'm completely
vulnerable.

And if I boot a Windows disk and run the program "native",
I'm not going to get that green text, because Windows won't
load the microcode like Linux is doing at the moment.

My conclusion at the moment is "we can't have nice things" :-)
For some value of green text.

Paul

On Wed, 17 Jan 2018 13:24:40 +0000, Jaimie Vandenbergh wrote:

On Wed, 17 Jan 2018 06:28:20 -0500, Paul wrote:

PeterC wrote:
https://www.grc.com/inspectre.htm

with a warning not to d/l from other sites.

That page says it's "written in assembler" ??? LOL. Maybe he inserted a
couple of #pragma and 20 lines of assembler or something. I doubt the
entire program is assembler. Only a kook would do that (we had such a
kook at work).

Steve is exactly that sort of kook, but mostly harmless. He's been
boasting of writing assembly language Windows apps for 25 years or so,
and I've not seen anyone do a disassembly and deny that it's
handcrafted. He is a loon.

Cheers - Jaimie

When you look at a program in memory you will see a sequence of one's and
zeroes. The software you might use to examine this mess kindly arranges
the output to be more understandable by humans, generally by translating
into assembly language or maybe something else. I don't know how one
could determine in what language the author wrote the program, but
whatever it was, it simply translated into assembly language which in
turn generated a bunch of one's and zeroes.
We used to have guys who would analyze memory dumps generated by a user
after some sort of program crash. These guys had the patience of Job, but
the key to navigation was looking at system calls. It ain't easy.
By the way, what's wrong with assembly language. It's not that bad and
people that do it on a regular basis keep a copy of commonly used
routines like generating output so they don't have to re-invent the wheel
each time.
I use a very powerful text editor - Vedit, which supposedly was first
written in assembly language prior to windows. Not sure what they use for
the windows version but it's very powerful and fast. I started using it
years ago when brief and others were around, Vedit outlives them all.
I wonder what language was used for emacs, that's been around forever
also.

In article , says...

On Wed, 17 Jan 2018 13:24:40 +0000, Jaimie Vandenbergh wrote:

On Wed, 17 Jan 2018 06:28:20 -0500, Paul wrote:

PeterC wrote:
https://www.grc.com/inspectre.htm

with a warning not to d/l from other sites.

That page says it's "written in assembler" ??? LOL. Maybe he inserted a
couple of #pragma and 20 lines of assembler or something. I doubt the
entire program is assembler. Only a kook would do that (we had such a
kook at work).

Steve is exactly that sort of kook, but mostly harmless. He's been
boasting of writing assembly language Windows apps for 25 years or so,
and I've not seen anyone do a disassembly and deny that it's
handcrafted. He is a loon.

Cheers - Jaimie

When you look at a program in memory you will see a sequence of one's and
zeroes. The software you might use to examine this mess kindly arranges
the output to be more understandable by humans, generally by translating
into assembly language or maybe something else. I don't know how one
could determine in what language the author wrote the program, but
whatever it was, it simply translated into assembly language which in
turn generated a bunch of one's and zeroes.
We used to have guys who would analyze memory dumps generated by a user
after some sort of program crash. These guys had the patience of Job, but
the key to navigation was looking at system calls. It ain't easy.
By the way, what's wrong with assembly language. It's not that bad and
people that do it on a regular basis keep a copy of commonly used
routines like generating output so they don't have to re-invent the wheel
each time.
I use a very powerful text editor - Vedit, which supposedly was first
written in assembly language prior to windows. Not sure what they use for
the windows version but it's very powerful and fast. I started using it
years ago when brief and others were around, Vedit outlives them all.
I wonder what language was used for emacs, that's been around forever
also.

When I programmed for a living I used assembler for a number of various
cpu's not all of them Intel. Mind you the programs tended to be small
usually less than 8Kb or so (embedded chip stuff) but I always liked the
"control" one had over basically everything. C/C++ and Pascal/Delphi is
also used a lot and I have to say I preferred Pascal way more than C. In
fact first 100,000 soucre code lines of code I wrote for Windows was in
straight Pascal without using any libraries, instead making all calls to
Win API's directly. That was very satisfying. I stopped prgramming about
time all this "new crap" starting appearing, e.g. Net, C#, Perl, Java
etc. and to be truthfull glad I did as I hate the thought of having to
write anything uses the web (too used to writing own code to
commmunicate directly me thinks .

Jaimie Vandenbergh wrote:

On Wed, 17 Jan 2018 06:28:20 -0500, Paul wrote:

PeterC wrote:
https://www.grc.com/inspectre.htm

with a warning not to d/l from other sites.

That page says it's "written in assembler" ???
LOL. Maybe he inserted a couple of #pragma and
20 lines of assembler or something. I doubt the
entire program is assembler. Only a kook would
do that (we had such a kook at work).

Steve is exactly that sort of kook, but mostly harmless. He's been
boasting of writing assembly language Windows apps for 25 years or so,
and I've not seen anyone do a disassembly and deny that it's
handcrafted. He is a loon.

Cheers - Jaimie

From a very quick glance using a hex editor, my guess is there is some
code for the GUI portion of his "program" but the program that is what
is actually getting delivered to do the testing is in assembler. Gibson
has been coding in assembler for something like 30+ years.

About the only assembly that I do anymore is inline C. Way back 30
years ago, yeah, I did assembler, too, on mainframes where I can to know
the instruction set and which fields changed position, got extended, or
supplanted depending on the instruction. Gladly I moved on to higher
languages because I did not have to test, debug, and workaround at that
low level anymore.

On Wed, 17 Jan 2018 06:28:20 -0500, Paul
wrote:

PeterC wrote:
https://www.grc.com/inspectre.htm

with a warning not to d/l from other sites.

That page says it's "written in assembler" ???
LOL. Maybe he inserted a couple of #pragma and
20 lines of assembler or something. I doubt the
entire program is assembler. Only a kook would
do that (we had such a kook at work).

Hardly. He is simply someone who makes different trade-offs in
his programming.

If you work with Assembly language a lot and have a good
Assembler, it would hardly be impossible to do.

[snip]

Sincerely,

Gene Wirchenko

In message , Dave
writes:
On Wed, 17 Jan 2018 13:24:40 +0000, Jaimie Vandenbergh wrote:

On Wed, 17 Jan 2018 06:28:20 -0500, Paul wrote:

PeterC wrote:
https://www.grc.com/inspectre.htm

with a warning not to d/l from other sites.

That page says it's "written in assembler" ??? LOL. Maybe he inserted a
couple of #pragma and 20 lines of assembler or something. I doubt the
entire program is assembler. Only a kook would do that (we had such a
kook at work).

Steve is exactly that sort of kook, but mostly harmless. He's been
boasting of writing assembly language Windows apps for 25 years or so,
and I've not seen anyone do a disassembly and deny that it's
handcrafted. He is a loon.

Cheers - Jaimie

When you look at a program in memory you will see a sequence of one's and
zeroes. The software you might use to examine this mess kindly arranges
the output to be more understandable by humans, generally by translating
into assembly language or maybe something else. I don't know how one
could determine in what language the author wrote the program, but
whatever it was, it simply translated into assembly language which in
turn generated a bunch of one's and zeroes.

On the whole, a person moderately experienced in examining .exe files
can usually tell at least whether they were written in high-level
language or lower, unless there has been a deliberate attempt at
obfuscation. A skilled such person can often make a fairly good guess
_which_ high-level language - C, etcetera.

We used to have guys who would analyze memory dumps generated by a user
after some sort of program crash. These guys had the patience of Job, but
the key to navigation was looking at system calls. It ain't easy.

Probably based on knowledge of how the software in use used memory (or
at least how it created these "memory dumps").

By the way, what's wrong with assembly language. It's not that bad and
people that do it on a regular basis keep a copy of commonly used
routines like generating output so they don't have to re-invent the wheel
each time.

Nothing at all: it produces the smallest, fastest, code. The only
disadvantage is that coding can be more of an effort (and that can be a
significant disadvantage), especially if the code has to work in
assorted environments.
[]
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

"This situation absolutely requires a really futile and stoopid gesture be done
on somebody's part." "We're just the guys to do it." Eric "Otter" Stratton (Tim
Matheson) and John "Bluto" Blutarsky (John Belushi) - N. L's Animal House
(1978)

Paul news Jan 2018 11:28:20 GMT in alt.windows7.general, wrote:

PeterC wrote:
https://www.grc.com/inspectre.htm

with a warning not to d/l from other sites.

That page says it's "written in assembler" ???
LOL. Maybe he inserted a couple of #pragma and
20 lines of assembler or something. I doubt the
entire program is assembler. Only a kook would
do that (we had such a kook at work).

Actually, he's known for writing entire apps in pure assembler.
Spinrite is another such beast.



--
To prevent yourself from being a victim of cyber
stalking, it's highly recommended you visit he
https://tekrider.net/pages/david-brooks-stalker.php
================================================== =
Steal this tagline and I'll tie-dye your cat!

"J. P. Gilliver (John)" wrote

| On the whole, a person moderately experienced in examining .exe files
| can usually tell at least whether they were written in high-level
| language or lower, unless there has been a deliberate attempt at
| obfuscation. A skilled such person can often make a fairly good guess
| _which_ high-level language - C, etcetera.
|

That would depend. A basic compiled executable
(as opposed to .Net, Java, scripting, etc) is compiled
to native or machine code -- the actual CPU operations.
Assembly is just closer to that than higher-level
languages. But I don't see any reason to expect it
would make radically different native code. Maybe
a very sophisticated expert could make some
assessment by studying the native code,
but in general I think the only way you'd know
would be from things like the string table, import
table, etc. For instance, if it has a dependency on
msvcrt.dll then it's probably written in VC++6.
Similarly, each version of Visual C++ has its own
runtime. But in general it's not obvious.

Looking at inspectre.exe, it contains a digital
signature and it's marked as compressed with UPX.
Decompressing and reading the bytes indicates
that there's embedded RTF text that gets loaded
into a RichEdit window. Not likely to be done with
assembly. Even if it's possible it wouldn't make
sense.

Looking at it in Depends shows a lot of calls
to high-level API functions. (That' a handy
program that may be available in the Win SDK.
Depends shows, to some extent, the libraries
and functions used by an EXE.)

Either way, I trust that Steve Gibson knows
what he's doing.

In article , says...

Paul news Jan 2018 11:28:20 GMT in alt.windows7.general, wrote:

PeterC wrote:
https://www.grc.com/inspectre.htm

with a warning not to d/l from other sites.

That page says it's "written in assembler" ???
LOL. Maybe he inserted a couple of #pragma and
20 lines of assembler or something. I doubt the
entire program is assembler. Only a kook would
do that (we had such a kook at work).

Actually, he's known for writing entire apps in pure assembler.
Spinrite is another such beast.


Yea, Spinrite worked fine and was all assembler.

I'm surprised people find assembler something they don't expect to be
used anymore. I would suspect that an assembler level programmer would
build up a toolbox of canned routines used over and over again no
different than people constantly using any language. Even in
C/C++/Pascal & Delphi (geez even dBase in it's day) I had a library of
"utility" routines I constantly used.