Hacker Newsnew | past | comments | ask | show | jobs | submit | CSm1n's commentslogin

> No, you can't. When you use 7-era toolchain (e.g. VS 2012) it sets the minimum client version in PE header to Vista, not XP much less 2k.

Yes, you can! There are even multiple Windows 10 era toolchains that officially support XP. VS 2017 was the last release that could build XP binaries.


"Without following any special procedure". I know you can install older toolchains and then build using those, but I can do as much on any platform (e.g. by using a chroot). The default on VS2012 is Vista-only binaries.

It is a flag that says whether the loader data is initialized or not.

The layout of PEB_LDR_DATA “leaked” long time ago in public PDBs.

More context: It has nothing to do with debugging. However, if you attach to the process early enough, you might see the flag as 0 and eventually it would switch to 1. That is probably what threw him off.


"you might see the flag as 0 and eventually it would switch to 1"

Sorry, noob question: Were there easy avaiable tools (in the debugger), to monitor a variable like this and have the debugger stop exactly when it was going to change, so you could see which thread and function did it and why?


Yes: many debuggers support setting watchpoints[1] that break on writes to a particular memory location.

Depending on the platform and the debugger, these can be implemented using CPU architecture-specific debugging features, or in software, by single-step program execution and checking watched addresses for changes after each step.

[1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Set-W...


Yes, x86 kernel-mode debuggers support hardware breakpoints that cause the attached debugger (running on a separate machine, of course) to break not just when a specific address/instruction is executed, but also whenever some address is written to (and also possibly read-from too, I think?)


The repositories shown on the first page of GitHub search are not actual exploits. They all expect to be run through an admin powershell/command line. Under normal conditions (default user and UAC on) you will get a warning before the script is able to gain administrative access. Try to run them again under a normal user and they won't be able to disable/bypass Defender.

It's the same as sudo'ing an unknown script you received in an email. At that point you're begging to be pwned.


Sort by Best match or Most stars. Those github repos are just examples. Pro malware creators wouldn't just copy and paste some code or else it would be detected fairly easily.

UAC is easily bypassed as well. In fact, the majority of wontfix exploits has something to do with UAC.

> They all expect to be run through an admin powershell/command line.

Admin rights will be acquired by using exploits (of which there are many) or by using built-in tools found in the Windows system directory, for example Wscript.exe. No internet connection required. No fetching of external files. You have no say in whether you can allow it to run or not.

> you will get a warning before the script is able to gain administrative access.

False. You wouldn't even know. Not a visible commandline window to be seen. It's all silent. A well-developed exploit will delete most of it's traces.

This is all pretty basic knowledge in the sec research community. Test it and verify it for yourself. I test hardening configurations using a Windows VM.


UAC is generally quite easy to bypass and not a real security boundary.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: