Gibson's Meltdown/Spectre Tester

Gene Wirchenko 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).

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

If you did that and didn't tell your employer, you'd
probably be fired.

Because by not using a HLL, you're wasting company time.

You "break into assembler" for:

1) Short data-intensive routines needing absolutely
top-flight efficiency (copy look in FP register,
SSE instructions, AVX512). This also includes writing 20
copies of the same routine, so it runs fast on an
AthlonXP and on an Itanic. As you go through all the
generations of Core processors, your copy loop could
use different/better instructions or register sets.

2) The possibility of emitting the 70% of instructions
that HLL don't generate. In the case of the above application,
he could be emitting privileged CPUID instructions to
get back the CPU revision number. But you only need
a short stanza of inline assembler to do that.

In Windows now, you can make a pretty decent skeleton
for the GUI portion of the program, in less than a page
of code. At one time, in the old days, it took about
12 pages of code, before you could even printf(HelloWorld).
That was a disincentive to using the provided tools.


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

For a system at work, approximately 120KB of assembler were
written and paged into some cheesy 8 bit processor. It took
two guys around a year to do that. Gibsons code is around
that size (even though it runs on a 32 bit processor).

There is the potential to waste a lot of time, "being efficient"
when "being efficient" is not needed.

This is why, as a hardware guy, I used to be an evangelist
for the Profiler our kernel guy wrote. It would detect
hot spots in code, and tell you whether all the time
in your program, was being wasted in three lines of code.

One day, when I promoted the Profiler to one of our software
guys (someone writing some sort of package for some GPID
thing), he came running back to me a couple hours
later and said "I found some code that got copy/pasted
into the source by accident, and was wasting 25% of my
performance". So that's what you do, besides Lint and
Code Review. Pop a good sized project into a profiler
and see whether the hot spots you detect, actually
seem reasonable. Then decide whether you need to
do something about it or not.

I was in the Assembler camp at one time too, but
that was more for the experience, than with any
kook-driven conviction. Our management, claimed
that our HLL was within 10% of the speed of
writing the equivalent function in assembler,
and at the time, that seemed a reasonable metric.
You could strip line numbers and symbols before
shipping the code, so there wasn't a lot of extra
overhead. A peephole optimizer blended the individual
HLL chunks emitted, to remove the "inefficiency".

In Windows, like Visual Studio, symbols are stored
in a separate .pdb file, and normally only the
developer needs those.

Paul

On Wed, 17 Jan 2018 09:21:55 -0500, Mayayana wrote:

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

Ah, um, cock-up? I 'thought' that I'd set the follow-up. Oh well.
--
Peter.
The gods will stay away
whilst religions hold sway

On 17/01/2018 09:26, PeterC wrote:
https://www.grc.com/inspectre.htm

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


https://i.imgur.com/sfixhnh.png https://i.imgur.com/sfixhnh.png

--
With over 600 million devices now running Windows 10, customer
satisfaction is higher than any previous version of windows.

Paul wrote:

Gene Wirchenko wrote:

Paul wrote:

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 did that and didn't tell your employer, you'd probably be
fired.

Um, Steve is employed by ... wait for it ... Steve.

http://www.hoovers.com/company-infor...fd43d c1.html
Number of employees: 9

Steve owns the company. He does employee others for sales.

He has been on Leo LaPorte's Twit.TV (https://twit.tv/) many times. He
has has own "Security Now" segment (Records live every Tuesday at 4:30pm
Eastern / 1:30pm Pacific / 21:30 UTC). Maybe he gets paid for those
appearances but they cannot dictate how he codes his own programs
distributed by his company that he owns.

In message , Mayayana
writes:
"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

From what I've seen, C (for example) produces a lot of inefficient code,
which on the whole I'd say I could recognise.
[]
signature and it's marked as compressed with UPX.
Decompressing and reading the bytes indicates

Not through compression, of course.
[]
Either way, I trust that Steve Gibson knows
what he's doing.

Indeed!

--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

A clean, neat and orderly desk is a sign of a sick mind. (G6JPG's mind is
clearly extremely healthy ...)

In message , pjp
writes:
[]
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.

I was somewhat startled in discussion with a youngish computing graduate
- I think in the last ten years, but probably not much more recent than
that - to discover he'd never done any assembler. But IT is so big these
days that there will indeed be room for people at all levels. And, sad
though it may be for some of us oldies, modern processing power (and
storage, both RAM and disc) are such that it really isn't necessary to
write compact code (unless you're writing for microcontrollers - and
even those have huge amounts compared to what I grew up with).

Though I still have great respect for those who _do_ produce compact
code: the Gibson example that started this discussion, and e. g.
IrfanView. (And I can't help _feeling_ - though would be hard pushed to
prove it - that such code is less likely to go wrong. [And there's no
doubt it _does_ run faster, but probably not significant on modern
hardware and OSs where the OS gets in the way.])
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

A clean, neat and orderly desk is a sign of a sick mind. (G6JPG's mind is
clearly extremely healthy ...)

J. P. Gilliver (John) wrote:


From what I've seen, C (for example) produces a lot of inefficient
code, which on the whole I'd say I could recognise.

In the hands of the wrong individual, yes.

*******

You can compile to .s format, which is assembler metainstructions,
and see what the code quality looks like. The example at the
top of this page, is a particularly poor choice for an
efficiency explanation. What I want to point out in this link,
is you can generate a .s file using GCC, then examine it in comfort.
You don't have to use a hex editor on the object code, to review
what it's doing.

https://stackoverflow.com/questions/...nerated-by-gcc

Try some arithmetic statements in your test.c,
then tell me how efficient the test.s is, and how much wonky
overhead there was.

If you really need efficiency, you don't have to drop to
assembler and do the whole thing there. You can simply review
the .s and hand-optimize your source as desired.

That only works if you have the #pragma to generate whizzy
instructions. For example, you might have to do something
special to have an instruction sequence emitted as AVX512 say.
You should have no problem generating ADD,SUB,MUL,DIV with
a little (integer) test program.

You can also experiment with compiler optization,
like -o, -o2 and so on, and see what effect that has,
Maybe some assembler is moved out-of-order, for better performance.
Initially, you'll want to test with no -o at all.

If you don't think the game is honest, there's at least
one free disassembler for x86 you can get. And you can
review the code after object is generated.

Paul

NOTE: Followup-To by OP was ignored. If a newsgroup is not an
appropriate newsgroup for continued discussion then don't post there!
Don't be rude by yanking the discussion away from the audience YOU
choose. The OP's post was read in Windows 7 and it will be there that I
include my reply.

PeterC wrote:

https://www.grc.com/inspectre.htm
with a warning not to d/l from other sites.

https://www.youtube.com/watch?v=Lh6Es_ucAZ8
(1 hour 33 minutes)
It's an audio aka radio show (with video recording) so topics bounce
around. They are geared toward responding to their subscribers. They
are sponsored (so they can afford to be on the air) so there are ads
interspersed in the recording, too.

The scare stories have been effective because they omit a very important
and devastating crush to their sca these are POCs (Proof of Concepts)
that have not been encountered in malware in the wild in over 23 YEARS!
The published documentation is what spurred the fixes. What was hidden
was never abused but what is now public *could* (not necessarily will)
be abused. Being vulnerable does NOT equate to guaranteed attack.

Gibson also touches on Intel's AMT which stupidly has a default password
(not really their fault but the fault of the sysadmins or IT folks
distributing the hosts without changing the username and password).
This is like the default username and password on routers for which you
can find lists of what routers use what default login credentials. Yet
few users (who are placing themselves in the sysadmin role) ever change
their router's login credentials. That means intruders can get into
their router from outside to change its settings.

How many users reconfigure their web browser to mandate ALL content
delivered from an HTTPS web site is actually delivered using HTTPS
instead of HTTP? Few. Most users have a clue what is HTTPS or that
connecting via HTTPS to get the secure icon in their web browser may not
be true because some of that page's content may come from an HTTP
source. Mixed content (HTTP delivered from an HTTPS page) is a setting
that users have to change in every web browser. Why do web browsers all
mixed content? Because blocking mixed content breaks too many sites.
Aw, gee, because the site doesn't regulate its off-domain content (e.g.,
ads and 3rd party tracking) means we users, by default, should endure
"secure" web pages that are insecure. Either a web page's content is
secure or it is not secure. Anything between is not secure.

When you start looking into security, there are TONS of recommendations
for locking down your computer. I remember using a tweaker that made
many suggestions (maybe it was Belarc Advisor) where it recommended
switching from SSL to FIPS for greater security ... except connecting a
web browser to any HTTPS site would thereafter fail. More security
means less ease of use. They are the antithesis of each other. There
are those who are super paranoid and run multiple active anti-virus or
anti-malware programs but don't realize the impact on their system until
one day they decide to ease up on the security. You could replace the
exterior doors of your house with non-windowed steel security doors that
have multiple locks including bolts that extends from all edges but then
that door is still only nailed to 2x4's in the opening frame in the wall
plus there are still all those "knockouts" (burglar slang for all your
windows). That Meltdown and Spectre have the fascination of the press
just means that type of press doesn't have much else to glom upon.

For a personal PC, I'm not wasting my time on POCs. See timemark
1:31:45 in the Gibson radio video. Any in-the-wild implementations that
show up later will still require a payload to deliver the invader.
Seems heuristics in AVs or anti-exploitware could catch the use of the
system calls (timemark 48:22) for the branching trick on return in
attempting to probe memory outside its process' constraints as suspect
behavior. Besides the AVs looking for the malicious behavior, the OS
gets patches to mitigate the attacks. Only time will tell if Microsoft
will use the patches to leverage their customerbase in pushing them to
Windows 10 by not providing the updates to prior versions of Windows.

https://blog.malwarebytes.com/securi...-need-to-know/
"Because the Meltdown and Spectre variants are hardware vulnerabilities,
deploying security programs or adopting safer surfing habits will do
little to protect against potential attack."

So Malwarebytes claims [for now] that security software cannot catch the
POCs. They run at kernel mode so they can certainly inspect the order
of system calls to the OS along with a sequence of assembly instructions
for the perpetration. They may simply figure they don't have to do
anything since the OS makers are patching their OSes (with a boost from
Google) and Intel updating their firmware. Yet, just think for a
moment: how long before you get the OS update, and if you're not on
Windows 10, and just how is Intel going to deliver a firmware update to
burn new code into your CPU, and how many smartphone users NEVER see an
update for the Android OS on their phone (because they have a locked or
unrooted phone are at the whim of the cellular provider who doesn't want
to change their products which means more support).

It is not just a fix in the firmware that resolves the problem.
Programs have to get recompiled to be Spectre constrained. Google
already provided the solution and it's open source. gcc has already
been updated. VC has its /qspectre switch (which should be established
a default in the command line). So what we're really waiting for is for
app authors to recompile their programs to provide a new version that is
Spectre constrained. Well, some authors are quick, some are very slow,
and too many have abandoned their project yet users still employ those
apps.

Be interesting to see how long it takes for KeePass to update. See
https://sourceforge.net/p/keepass/di...read/4ae796cf/.
Despite storing the keys in memory in encrypted form, the crypto keys
can also be captured so the encryption can be undone. So they still
need to harden their program. That's just one example. It will be
interesting to see when the wave starts of authors that are actively
supporting their programs to get them updated.

At 1:14:13, Gibson starts to talk about the microcode update. I keep
reading articles that talk about updating the CPU and yet I've not seen
any pins on one that puts it into a burn mode as with, for example,
EEPROMs that have an input to enable higher voltage to write new code.
I kept thinking it was a BIOS update because that is in EEPROM and users
have long had available .bin downloads along with a "burner" program
that puts the EEPROM into high-voltage mode to then write in the .bin
file. Unfortunately, I've not heard that this "microcode update" which
is really a BIOS update lets the user save the current code in EEPROM
into a backup .bin file. I have seen where a new .bin is bad (has its
own problems in the new code) so I had to go back to the old .bin code
(as long as the new .bin code was still capable of booting the machine
so I could load the .bin writer program). So the CPU's microcode
(instruction set) is not getting altered. The BIOS code is getting
updated to *mask* the vulnerabilities in the CPU. Alternatively, the
"CPU microcode" is a patch to the *operating system* (not a microcode
write to the CPU) to also *mask* the vulnerabilities in the CPU. All
this "CPU microcode update" is a hoax. It is mask code (aka dynamic
code overlaid in system RAM) loaded by the BIOS or OS. The microcode
(firmware) within the CPU has *not* changed so the vulnerabilities
remain in the hardware. Well, we have to see when Intel, AMD, Qualcomm,
and other processor makers actually come out with later versions of
their hardware that directly eliminate the vulnerabilities instead of
having the BIOS or OS mitigate them.

I found it funny at the end (timemark 1:30:30) that Gibson remarked that
a major portion of his 125KB program is for the 93KB "ghost" icon
because of a Windows 10 requirement on the graphical element. Maybe he
should get rid of the icon. I was wondering why he needed 122KB (in the
current release) for what his program does in assembly (which is very
compact code written using the instruction set of the processor). So
his program is really only about 30KB in size.

I noticed the sideways vertical stack of Byte magazines on the shelf
behind him. He does the radio shows from his home. Byte stopped print
publication back in 1998, but he still kept them.

On 17-Jan-18 9:28 PM, Paul wrote:




For a system at work, approximately 120KB of assembler were
written and paged into some cheesy 8 bit processor. It took
two guys around a year to do that. Gibsons code is around
that size (even though it runs on a 32 bit processor).


You're not wrong, when I was reading the thread and looking at Gibson's
page I idly wondered how long it would take me to write a typical 120KB
program in assembler, a ****ing long time is the conclusion I came to.

pjp
Wed, 17
Jan 2018 20:28:04 GMT in alt.windows7.general, wrote:

In article ,
says...

Paul news 17 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.


Yep. I've done that since I was a kiddo with various programming
languages. Why reinvent the wheel?


--
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
================================================== =
To subdue the enemy without fighting is the acme of skill.Sun Tzu

"Mayayana" news Wed, 17 Jan 2018 20:13:52 GMT in alt.windows7.general, wrote:

"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.

Actually, most of the time, with the exception of a select few
compilers; that's not the case. They compile to pseudo machine
language with a runtime present inside the executable that performs
the low level translation work. There are some exceptions to this,
but the more well known compilers are not taking your c/c++/basic
source code and translating it verbatim to machine code inside your
executable.

They're including runtimes, some completely self contained inside
your exe (which is why your hello world program in various languages
is quite large compared to the same thing being done in native
assembler) and others which have part of the runtime present inside
the executable and the rest inside external dlls. The latter reduces
your executable final filesize, but, makes it rely on external dlls
being present on the host system in order to operate. The former
allows your program to be completely self contained, but at a cost in
filesize.

And, some compilers are somewhat sloppy in the way they construct
your final executable file. Which again results in filesizes slightly
larger than was necessary.

Assembly is just closer to that than higher-level
languages.

Assembly is as close as you're going to get to machine code without
going directly for machine code. And, depending on what you're doing
with assembly; you can opt for that route directly, too. In fact,
with some HLL languages you could opt for native machine code to be
left as you wrote it, completely untouched by the compiler. You just
have to know what you're doing, obviously. As when your compiled
binary execution reaches the native machine code you left, it's going
to execute it exactly as you wrote it. Whatever error handling the
runtime might have been able to offer is off the table at this point;
the compiler left you on your own, so to speak. If you've made
register changes the rest of your program depends on to function, the
runtime isn't going to be aware of it, so you have to make sure
before your native machine code finishes executing that you put back
whatever you changed exactly like it was when you found it, before
you relinquish control back to the HLL you wrote it in.

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,


I'm not sure what you mean by very sophisticated expert, but, those
of us who are fairly decent with reverse engineering executables can
usually tell with a semi quick glance at the header which language is
most likely responsible for the executable. In some cases, we can
even tell you (just by examining the header for various tell tale
markers) which version of the language you used.

but in general I think the only way you'd know
would be from things like the string table, import
table, etc.

Those are other ways of attempting to determine which programming
language and potentially which libraries (stock and 3rd party) were
used to create the final executable, yes.

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.

To an inexperienced programmer who spends most of his/her time in HLL
and knows little about how his executable actually came to be, I'd
agree. For anyone who isn't terrified at IDA pro, or ollydbg though,
I'd have to disagree.

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.

If you could properly trace the code inside using IDA pro for
example, you'd see that it's actually calling an API for that in a
very standard manner.

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.)

If you're really interested in knowing more about the internal layout
of an executable, you should quit playing with essentially, power
user toys and get under the hood in a real way. IDA Pro does have an
older free version, if you want to snag a copy. It doesn't support
some executable formats because it's an older version, but, unless
you have a specific need to study elf binaries (linux executables) or
various non x86 designed files, you should be fine with the
limitations of the freeware version.

Native win32 assembly can also make full use of Win api functions; In
fact, you're encouraged to do so. They are what replaced the old
interrupt calls one used to make. Using APIs doesn't mean your
program was written and compiled using an HLL language as a result.

Not only does Gibson state on the page with the download link to it
that it's written in assembler, I've found nothing inside the
executable to dispute his claim. In other words, I've found no
evidence that it was compiled, vs assembled.

The executable also contains a digital signature, An embedded .png as
well as .wav file. It also appears to have been assembled using masm
v6. It makes quite a few api calls, but, in this case, it doesn't
have much choice, it's either that or more assembler code to perform
the same functions the apis already offer, with higher risk of
compatability issues.

The program is native win32 assembler, no HLL aspect to it.

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

he's had my respect for quite a few years now, and, I don't see him
losing it anytime soon. Even if I don't always agree with his
viewpoints. He's an accomplished programmer to the level of coder in
my eyes and that of many of my peers who've also been reverse
engineering executables for decades, for various reasons; Some legal,
some not so legal.


--
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
================================================== =
My great dream is that I've won all the beauty contests in the world
and all the people I don't like are forced to build me a castle in
France.

Paul news Jan 2018 02:24:27 GMT in alt.windows7.general, wrote:

J. P. Gilliver (John) wrote:


From what I've seen, C (for example) produces a lot of
inefficient code, which on the whole I'd say I could recognise.

In the hands of the wrong individual, yes.

*******

You can compile to .s format, which is assembler metainstructions,
and see what the code quality looks like. The example at the
top of this page, is a particularly poor choice for an
efficiency explanation. What I want to point out in this link,
is you can generate a .s file using GCC, then examine it in
comfort. You don't have to use a hex editor on the object code, to
review what it's doing.

an HLL runtime still isn't going to outrun native assembler...Yes, it
takes more time and effort to write in pure asm and in many cases,
unless you're doing something that specifically requires it, probably
isn't worth the time. But, you do gain in speed, executable size
(your pure asm will be smaller) and memory requirements of the host
to load and execute your code.

If you don't think the game is honest, there's at least
one free disassembler for x86 you can get. And you can
review the code after object is generated.

IDA pro does have an older freeware version. It does have some
limitations, but, if you're playing with standard win32 executables,
it works well.

--
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
================================================== =
Dumber than Advertised. -- Yakko Warner

"J. P. Gilliver (John)"
Thu, 18 Jan 2018 00:22:19 GMT in
alt.windows7.general, wrote:

In message
, pjp
writes: []
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.

I was somewhat startled in discussion with a youngish computing
graduate - I think in the last ten years, but probably not much
more recent than that - to discover he'd never done any assembler.
But IT is so big these days that there will indeed be room for
people at all levels. And, sad though it may be for some of us
oldies, modern processing power (and storage, both RAM and disc)
are such that it really isn't necessary to write compact code
(unless you're writing for microcontrollers - and even those have
huge amounts compared to what I grew up with).

Those are not valid reasons to cease writing tight/compact code.
Those are excuses to make your program bloated and resource wasteful
and we continue to see ample evidence of just that.



--
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
================================================== =
Reality is a crutch for people who can't handle science fiction.

woo wrote:

Paul wrote:

For a system at work, approximately 120KB of assembler were written
and paged into some cheesy 8 bit processor. It took two guys around
a year to do that. Gibsons code is around that size (even though it
runs on a 32 bit processor).

You're not wrong, when I was reading the thread and looking at
Gibson's page I idly wondered how long it would take me to write a
typical 120KB program in assembler, a ****ing long time is the
conclusion I came to.

A video of his radio show (Security Now) found at Youtube
(https://www.youtube.com/watch?v=Lh6Es_ucAZ8) has him mention that 93KB
is due to Windows 10's requirement for GD icons in applications. I
don't know why he decided to have an icon in his program unless perhaps
it is something of a personal stamp or watermark on his program. That
leaves just 29KB for his actual code and that is what this type of
program in assembler should consume. He also includes quite a bit of
explanative text regarding the results of his tool's tests and those
text blocks also take up many bytes (perhaps 4 to 8KB). I did not
bother digging into the .exe using a hex editor to see if I could find
the text blocks to get a count of the bytes used for that help text.

Security Now [show] 646: The InSpectre
https://www.youtube.com/watch?v=Lh6Es_ucAZ8
Gibson discusses his InSpectre tool, the vulnerabilities, how Haswell
and later Intel processors have the necessary 2 instructions to mitigate
Meltdown but that Microsoft only implement 1 instruction hence the
impact on system responsiveness (until Microsoft wises up to use both
instructions for nearly unbenchmarkable difference). He also has to
address various topics due to queries from his subscribers so the topics
tend to jump around.

He also mentions why AVs were false triggering on his InSpectre.exe file
when users were downloading it. One of his on-off toggles involves a
registry change and AVs where triggering on it. So he encrypted the
registry key's name and data item value. Although his tool still writes
to the registry, the AVs stopped triggering on that behavior (they
didn't know what was the registry key's unencrypted name). He submitted
a test version in his private forum to have his subscribers check if the
AVs were still triggering on his .exe file. The download is dated today
but I don't know if it is his test release he gave to his subscribers
and fellow testers. Avast did not alert on the file's download or run.

In message , VanguardLH
writes
Besides the AVs looking for the malicious behavior, the OS gets patches
to mitigate the attacks. Only time will tell if Microsoft will use the
patches to leverage their customerbase in pushing them to Windows 10 by
not providing the updates to prior versions of Windows.

As the original follow-up was limited to one ng, I'll repeat my
observation that when I run this tester on my 32-bit Windows machine, I
get a message that Microsoft is only providing patches for 64-bit
systems and has no plans to change this.

I have to maintain a couple of 32-bit machines here because of certain
hardware and software constraints.
--
Bill