@hx1997 权限控制是依赖于内核的安全性的，只要内核保持在最新（打补丁）的状态这种安全性并不脆弱。如果打破内核的权限控制基本上就是内核的漏洞。在这一点上来看，安全性基本上可以保证，并不脆弱。如果有人能突破，可以致电微软领取奖金。

@acess
IE 的保护模式实际上就是对 IE 做了一些限制。在 IE 的保护模式下，IE 进程设置了 Administrators 组为拒绝，并且设置了 Low Mandatory Level （低进程完整性级别）。IE 进程想对系统做出修改就必须提升权限，实际上也就是标准账户提升到管理员账户的过程，并且由于一般用户默认的都是 Medium Mandatory Level （中进程完整性级别）所以实际上 IE 在保护级别下得到的权限比一般标准账户的权限更低一些，当然要提权也会更加困难。
浏览器存在漏洞是无可避免的，所以才需要经常更新。微软也好 Google 也好，保证的就是公开的能导致安全问题的漏洞都会被修复，所以只要保持更新“不下载、运行就是安全的”这种印象是基本上正确的。退一步，即使浏览器存在漏洞导致了代码被执行，也会有 DEP,ASLR 这样的安全机制来妨碍代码的执行，虽然这些保护是可以绕过的，但是毫无疑问的提升了代码的执行难度，有相当多的漏洞可能因为绕过这些安全机制的必要条件无法实现而导致实际上无法利用。（并不是说有漏洞就一定能被利用，并且成功入侵，这样的理解是不正确的）我们在退一步，即使有漏洞，能绕过 DEP,ASLR 这样的安全机制，成功的运行起来了，代码仍然会运行在低权限下，想对系统进一步进行修改，那么就必须提高权限，想要提高这样的权限，如果没有用户许可又必须使用内核漏洞来实现。虽然这些安全机制单点都是可以破解的，但是复合起来很显然会发挥更强大的功效。
一种安全机制的出现与其说是为了彻底杜绝某类攻击，不如说是大幅提高攻击成本。就像楼主举得例子，Windows 要求加载的驱动必须有数字签名，那么攻击者去签发一个带数字签名的证书不就得了？说起来很容易，可是数字证书是要花钱的，并且个人不能申请对代码签名用的证书，一般要求是公司进行申请，申请成功之后，如果证书被发现用于恶意软件，那么证书还可以被吊销。
我不能说要求驱动必须进行数字签名是一个好方法，但是这样的手段确实提高了攻击者的攻击成本或者攻击难度。

就目前的情况来看。
已经公开的，没有发布补丁的，在最新版 Windows 下从标准账户权限加上中等完整性保护级别，不需要任何特殊条件只执行一段代码就能提权到管理员权限或者更高权限的方法是不存在的。这一条正是微软一直在守护的底线，如果有技术逾越了这条底线，微软是一定要修复这个问题的。
在这样的基础上，其实已经足够保障一定程度的安全性，至少代码不能随意破坏系统，这其实已经足够了。
顺便，既然谈到权限问题，我最近正好写了一些代码对 Windows 权限的管理做出了一些补充方案。
取名 wesuex，代码和生成的二进制文件已经放在了 github 上，使用说明在此 https://www.exvs.org/?p=430
通过 wesuex，可以一定程度的加强权限控制，比如创建的受限制进程，大多数情况下将无法在通过其他方法提权。可以算作是一种补充性的方案。

@acess UAC 始终是安全性和易用性一起妥协的折中方案。UAC 也不仅仅是仅仅一个提示框而已，进程完整性级别是一个完整的内核概念。从低完整级别升级到高完整级别是一个内核权限提升的过程，这种过程在用户看来就是 UAC 点了一下是，所以所谓的绕过只是提升过程中不出现提示而已，目前的 UAC 绕过方案基本都是让高权限进程来加载代码的方式来达到绕过的效果。
每一种技术都是有局限性的，我们再三强调这个问题。不谈条件就谈安全性是永远没有解的，楼主的问题就像是，既然门，墙壁，房屋都是挡不住一切攻击的，那么我们究竟需要什么来保护自家的安全。这种答案我想在我有生之年应该是找不到的。

@acess 微软这方面的处理确实不太积极。不过也没必要悲观，该修的问题始终要修。
Windows 使用了这么多技术也确实一定程度的保障了用户的安全性，这一点是毋庸置疑的，很多技术也并不是 Windows 独有，Linux 下面同样也在使用 ASLR 之类的技术。安全并不是一件绝对的事情，都只是相对的，至于你相信不相信，那就仁者见仁智者见智了。

没有任何一种技术是万能的，无论放到哪里都一样，修修补补是常态。
UAC 其实也不存在所谓完美绕过，都是有一定前提条件的，比如楼主贴的例子，要求必须是 UAC 出于默认等级才可以通过这些方法提权。如果什么都不要能绕过完整的 UAC 保护，那么就是内核上的漏洞了，微软是必须出补丁修复的。

才亏这么点算个毛。
如果只想赚不能承受一点亏损，建议立刻清仓远离股市永远不要入市。

10.123.321.0
是什么鬼 IP ？ IPV4 里最大地址 255 ， 321 是什么鬼
IP 本身就不合法

招商银行欢迎你。
招商银行的批量转账只需要知道卡号，开户行所在城市，银行名字就可以转账了。转账全免费， 5W 以下实时到账。

C 是按值传递的。
这个例子里面 test 函数里面的 p 是 main 函数里面指针 p 的拷贝，所以 test 里面对指针修改不影响 main 函数里面的指针。
如果想在函数里修改传入的指针，请传入指向指针的指针。

@geelaw
@wangqianping
PowerShell 这种用法当然也是可以的，但是用 system 函数执行这样的命令本来是会阻塞等待命令完成的，而这样操作则不会阻塞，从同步变成了异步，如果要获取命令行返回的结果也会有一些问题。总的来说，不推荐使用这样的方法。
最简单的就是任务计划来操作，任务计划提供了以管理员或者指定账户执行的功能，通过任务计划来启动主程序就什么事都没有了。
如果使用 CreateProcessAsUser 或者 CreateProcessWithLogonW 这样的 API 当然也可以做到通过密码登陆账户然后在创建管理员进程，但是那实在是太麻烦了。

@geelaw
@wangqianping
当然，如果已经具有管理员程序的进程创建的新进程，如果没有做过特殊限制的话，那么子进程将会继承父进程的管理员权限。

所以打开一个管理员权限的 CMD 然后再执行其他程序也是可以的。
个人不喜欢使用 PowerShell ，比起直接执行会有一些其他的问题，所以使用 PowerShell 的方法我个人并不推荐。

对于一个开启 UAC 的机器， UAC 启动时给出的提示环境与普通桌面并不处于一个 Session ，一般也会叫他安全桌面，这个环境下与其他 Session 是隔离的，所以没办法做到自动允许 UAC 提示或者自动输入密码。这一点是微软本身的设计，也是为了保障 UAC 不被非法绕过。
所以自动输入密码来使进程提升权限是不可行的，如果每次不定时启动一个程序都要求用户允许，体验太糟糕。所以根本的解决办法就是父进程启动时一次性使用管理员权限，然后子进程直接继承权限就好。如果需要开机自动启动并且具有管理员权限，可以使用任务计划来启动。

@wangqianping 找到 Python 的解释器，比如 python.exe ， pythonw.exe ，右键属性-》兼容性选项卡-》以管理员身份运行

支付宝也是找合作的上海银行来汇款的。
不建议使用支付宝进行国际汇款，原因是失败概率很高。上海银行的国际汇款一样要经过外汇局审批的，收到外管局监控。
如果要国际汇款，老老实实找银行，别找支付宝。

@wangqianping 权限是根据运行进程的权限决定的。
如果你的 Python 解释器是管理员权限，那么 os.system()就是管理员权限来执行。
如果你要在非管理员权限中创建管理员权限的进程，那估计就只能自己调 Windows API 了（比如 ShellExecuteEx ），而且免不了 UAC 提示。

要执行命令的话直接 os.system()不就好了么？