If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Rate Thread | Display Modes |
#16
|
|||
|
|||
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 |
Ads |
#17
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
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 |
#18
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
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. |
#19
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
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. |
#20
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
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 ...) |
#21
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
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 ...) |
#22
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
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 |
#23
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
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. |
#24
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
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. |
#26
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
"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. |
#27
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
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 |
#28
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
"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. |
#29
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
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. |
#30
|
|||
|
|||
Gibson's Meltdown/Spectre Tester
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 |
Thread Tools | |
Display Modes | Rate This Thread |
|
|