jaclaz

Only partially IoT related, but interesting, will the advent of Wi-Fi and IoT cause social clashes with family and friends? http://www.troyhunt.com/2015/12/no-you-cant-join-my-wifi-network.html jaclaz

Well, the idea about making something simple is that it should be actually simple. What is needed is to run: EMET_Conf.exe --import <somepath>CertTrustUpd.xml It's really not rocket science (nor brain surgery) to find the EMET_conf.exe on your system and run the above. jaclaz

Only to make things easier. Get the MicrosoftEasyFix51012.msi. Use UNiextract on it, selecting to expand the archive in a subfolder, either "MSIx" or "LessMSI" or "MSI TC Packer extraction" will do to get the original import.cmd and the CertTrustUpd.xml. If you use the MSIx the files are inside the "Cabfile" (which you can open with 7zip) The batch file is ridiculous , just like making people download 1.2 Mb to get 30 kb of data (that can easily be compressed to 4 Kb) but you know, this is Microsoft. jaclaz

jaclaz

Well, it's strange. Make sure you have the SYS.com file on the diskette, so if you boot from diskette and run it as: SYS C: you should get : or an error message *like*: You cannot have a CHS limit (the first one at around 512 mb in the BIOS and the next one is around 8 Gb). What happens when you try to boot from the internal hard disk (without the diskette and the CD inserted), which error do you get? jaclaz

I am not at all trying to make you look like a fool , if you had this impression I beg your pardon for this miscommunication or misunderstanding , I was plainly stating that the idea of separating the Admin credentials from a specific program execution opens a large security hole, which in an environment where security matters is foolish. (and I stand by my statement) Imagine that one of your N users finds out that he/she can use your hypothetical "MyAdminPassword.spc" to run (say) cmd.exe, or any other program impersonating the Administrator and this ends up causing a loss to the company. Wouldn't your boss (or your boss's boss) be after you in no time? jaclaz

Well, then you should also be 100% accurate when nitpicking, now hopefully everything is clear for all the readers. jaclaz

Of course I know. But I need this to work as per my example.Well, unless you want to intentionally introduce a severe vulnerability to your processes, allow me to doubt that you fully understand the implications of having a "self-standing" crypted set of elevating credentials. Of course, it is trivial to put together a (say) Auto-It doing what you *want* (and I believe there are several examples available), but it is not, really not a good idea[1]. So, you can automate via (say) batch the creation of the N .spc files but you cannot automate their distribution in "multiple folders"? jaclaz [1]See the But ... then, why? in my signature. BTW, this answer is wrong: Because I work as an admin with a windows domain. And our passwords expire every month, including admins.You change it every month because there is such a policy, and such a policy exists in your organization due to some security concerns, which are most probably the same reasons why your users are not given the Admin password or an Admin level account on their machines and why you are currently using runasspc and why your intended modification to the way it works should not even been thought of.

Why do you change the password every month? Wouldn't it be easy to automate the creation of the N .spc files you *need* monthly? You do understand the REASON why RunAsSpc uses the current approach and not the one you are suggesting, right? jaclaz

Maybe there are, if only what you are asking was understandable. You don't really pay a fee per word posted, even without being verbose you can provide some understandable description of what you actually want to do, some reference to the RunAsSPC you mention, why exactly that thingy is not suitable to your specific use, etc., etc. jaclaz

Not only I never said they were separable blocks, but the paragon/explanation was EXACTLY to convey the idea that they are NOT separable blocks and that making even minor edits is a huge PITA and requires a deep knowledge on the matter. The idea of providing a comparison to something the OP may be more familiar with is not that it should be 100% accurate, it is to help him understand the behaviour rather than the technicalities involved. jaclaz

Yes and no. The setup diskette is (obviously) FAT12 (not 32). What are the EXACT contents of the boot floppy you have? As a rule of thumb it is (was) always better to install from a hard disk repository, see here: http://novaonline.nvcc.edu/eli/ist216mb/summer/installing_windows_95.htm You don't actually want to "copy" the floppy to C:. You want to "install" a (minimal) DOS from floppy to C:, then copy to it a few needed files so that you have access to the CD device, then you want to copy the contents of the CD to the hard disk (advised) and finally you want to install the Windows 95. Essentially you want to: boot from floppy SYS C: COPY /b a:\*.* C:\ Then boot from Hard disk. Now the point might be how exactly you partitioned/formatted the hard disk, you should be sure that the partitioning and formatting was done "properly" in the sense of being compatible with the DOS/Win95 you are going to install. So, before SYSsing and COPYing you may want while booted from the floppy to use FDISK and FORMAT to start again from scratch, easier would be to try doing the above and if for any reason the PC does not boot from the internal hard disk redo from start repartitioning and formatting. If you have doubts/questions on the above, please ASK them BEFORE doing something you are not sure about. jaclaz

Yes, but maybe if you pose the real problem, which is - I believe - something *like*: Maybe, just maybe, someone might help you. jaclaz

Allow me to disagree, it would be very unfair to put the blame on Windows 10 (though it certainly represents a - IMNSHO small - part of the issue), in a world recession period and with all offices/business and almost any household having already all the PC's they can actually use, the market has become (as it is normal) stale. Noone (at least in the Western Countries) *needs* yet another PC/device as everyone already has at least one (often more). You change it only if the old one breaks or if *someone* convinces you that what you are using is obsolete, otherwise everyone would have better use for that (usually hard earned) kind of money. The "new technology fans" and the "geeks" usually don't make large numbers, independently from how good (or how bad) is the "new thing". jaclaz

To be fair, that "Ring" (doorbell) thingy issue is not strictly about IOT (in)security but about generic design stupidity. The "firmware fix" (provided that it is actually effective) is meaningless, the real issue is that you have a device connected to your (wireless) network OUTSIDE your house AND NOT inside a locked, resistant, secured, TAMPERPROOF container, set aside the software issue there are most probably several ways to dump the memory of the device and get the credentials if you have physical access to it. Here is the actual report/research: https://www.pentestpartners.com/blog/steal-your-wi-fi-key-from-your-doorbell-iot-wtf/ In any case, and set aside the (in)security of the thingy, it's similar to putting two benjamins tacked on your front door together with a note spelling "Free money, please take it" (though it has to be seen how the device will sell on the - hmmm let's say "second hand" - market ). jaclaz

No, dates are fine. The "pilot" of the drone a Mr. Boggs had the "shooter" a Mr. Merideth arrested right after the shooting. Then a criminal case was filed against Mr. Merideth, that trial was in October 2015 and Mr.Merideth was acquitted. So the Mr. Boggs announced he would sue Mr. Merideth in a civil lawsuit. The article I linked to is about the (earlier, 2015) criminal case, yours is about the (current, 2016) civil one. jaclaz

Or maybe you just fancy (not need) it. Loosely - and with a few exceptions - a new OS installed on an older machine will always be slower, in some cases VERY noticeably, and particularly with a not-so-great amount of RAM (though may other factors may concur with the added sluggishness of the system). If your PC was manufactured/built before 2008/2009 or so and came originally with Windows XP, surely it will be noticeably slower with Windows 7. jaclaz

Well, not entirely unexpected: http://arstechnica.com/tech-policy/2015/10/drone-slayer-cleared-of-charges-i-wish-this-had-never-happened/ I guess it has become a personal matter ... jaclaz

Good , in some cases the issue might be actually memory related, but with 4 Gb of RAM it is not possible. Clearly it is a resource limit of some kind, the "root" cause of similar errors has been reported in the past to be connected with the "driver packs" when they are "integrated", but this should be not your case since you use them as "external" resource. jaclaz

Of which we know nothing about. jaclaz

Just do it. jaclaz

Well, why don't you actually try clicking on the CORRECTED link? jaclaz

Not really-really plainly it means that you weren't able to find in that .dll you examined a reference to USER32.EnumDisplayMonitors. Writing a new driver. I am not sure you understand the way a .dll works. A .dll is nothing but a container with a number of fuctions inside. You can think of it as a number of small .exe files inside a .zip archive. What happens transparently when the .dll is in use. i.e. a function in it is called, is that the archive is opened, a single small executable is loaded into memory and executed and the archive is closed again. The issue here is that this archive is (besides read only) indexed/assembled in such a way that you cannot insert (add) in it anything, not even a single byte. You can normally replace the whole archive with a new version (including the added needed function), but this poses a problem, you need to re-write from scratch all the other functions besides the one you need and rebuild the whole archive or you need to find a function that is never used, that has a suitable name and size and manage to replace it with your new function, and fix checksums/indexes/etc.. This in the case of a "system .dll" such as USER32.DLL is in practice very, very difficult. The question is not really "what program", but rather "How/where can I learn how to edit a .dll" and the answer to this other question is "you study the windows OS in depth, including a bit of low-level (assembly) programming, a lot of reverse engineering and debugging, try and get familiar with each and every available related tool, you try hacking non-system .dll's first and after due time you will know what to do (and also which program to use or you write your own)". jaclaz

No , basically you need a custom Gina or "credential provider". Yep , though it is a "show-stopper" kind of problem and that is exactly the reason why you need a custom Gina or "credential provider", Q.E.D. An alternative might be a "Native NT" or "bootexecute" executable but if creating a custom GINA/credential provider wasn't complex enough, Native NT programs are possibly "worse". There is the pGINA project: http://pgina.org/ http://pgina.org/docs/v3.1/user.html but it's not something I would recommend without a deep knowledge and understanding of the involved matters. It's pretty much binary or you do something before having logged in ("right") or you do that after having logged in (wrong in this case of choosing between different login methods). You might find this of interest: http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/windows-nt-6-boot-process.html jaclaz

Good, now I could suggest you to try the v6.1.3.35 AMD's "pure" AHCI Drivers (only AHCI mode supported) ones Fernando recommends: http://www.win-raid.com/t29f25-Recommended-AHCI-RAID-and-NVMe-Drivers.html and you will say how you already tried them and they don't work as well. jaclaz