by 空虚浪子心 http://www.inbreak.net 微博:http://t.qq.com/javasecurity 写道
可能是由于沟通问题,导致struts2官方对我提交的S2-012漏洞名称理解错误,漏洞描述为struts2的某个示例应用出现漏洞,但是struts2是按照框架出现漏洞修补的。而这个s2-012竟然引发了一连串血案。
其实发这篇文章,我非常恼火,任谁手里有一个0day,捂了半天,结果又被别人公开,都会非常恼火。去年我在XCON发布的S2-012漏洞,其实struts2还存在相似的漏洞。在struts中,框架接收到的用户输入,除了参数、值以外,还有其他地方,比如文件名。这个漏洞,是struts2对url中的文件名做了解析,导致的ognl代码执行。
这中间存在一些技术细节,下面展开分析。
enableOGNLEvalExpression的骗局
从漏洞公告上看到这个词,很容易认为是struts2把ognl表达式干掉了,可以选择终结一切。事实上禁止的是OGNL的其中一种调用方式,而这种调用方式,也只是在S2-013这里调用。
struts2有另外一段威武的代码,真正在防守这个漏洞。
org.apache.struts2.views.util.DefaultUrlHelper这个类:
原本是这样写的,代码走到translateAndEncode就会调用ognl执行,它的逻辑一共包括ognl的translate,以及urlencode这两个功能。
private String buildParameterSubstring(String name, String value) {
StringBuilder builder = new StringBuilder();
builder.append(translateAndEncode(name));
builder.append('=');
builder.append(translateAndEncode(value));
return builder.toString();
}
补丁之后,这里被改为仅仅urlencode,不再做ognl执行。这个和enableOGNLEvalExpression没有任何关系。
private String buildParameterSubstring(String name, String value) {
StringBuilder builder = new StringBuilder();
builder.append(encode(name));
builder.append('=');
builder.append(encode(value));
return builder.toString();
}
我没有细看内容,只看方法名的变动,就感觉可以洗洗睡了,不必往下跟进了。
allowStaticMethodAccess骗局
一直以来allowStaticMethodAccess是struts2的poc标配,从第一个poc出现开始,就一直存在。
在2013年5月27日,也就是前几天,大家可以自行查看SVNlog,struts2做了一件很猥琐的事情,把以下代码删除了:
public void setAllowStaticMethodAccess(boolean allowStaticMethodAccess) {
this.allowStaticMethodAccess = allowStaticMethodAccess;
}
这个动作直接导致一个结果,以后在OGNL的POC中执行
#_memberAccess["allowStaticMethodAccess"]=true
一定会报错的,因为没有set方法了。
很有终结一切的意思,就像以后有新的OGNL漏洞,就不能写这一句了。但是我可以绕过这个东西,下面结合s2-015漏洞做个示例。
struts2框架s2-015吐槽
这个漏洞,被人公布出来,实际上,发布者一共发布了几个漏洞,包含S2-015、以及S2-012。具体地址在
https://communities.coverity.com/blogs/security/2013/05/29/struts2-remote-code-execution-via-ognl-injection
非常详细,某同事认为他比我分析的好,所以我就不写翻译了,大家自己看。
后来仔细想了想,猜测老外可能遇到s2-012,导致了该文章的发布,当然,这只是我的个人YY。
发布者手握2个0day,很不幸,我也有这两个0day,去年xcon发布了一个,之后提交了官方,但是他不知道,因为官方到今年才公开修补。
前几天官方突然公开修补了我发布的一个0day,这个老外看到s2-012后,可能也非常恼火,因为这个漏洞和他手头分析的0day刚好相同,所以一怒之下和其他0day一起发出来了,共同组成一篇文章。可以看到,发布者直接从blog发布,之后官方才收到消息开始修补。
这个漏洞的触发代码展现形式和s2-012非常像,所以理解了s2-012后,可以联想到这个0day,很容易通过测试出来,我当时也是看到类似的使用,随手测试就发现了。相信有很多漏洞,都是类似的情况下发现的。甚至可能不止我们手里有,其实你也非常恼火。
S2-015的poc在老外的文章中如下:
http://127.0.0.1:8080/struts2-blank/example/$%7B%23context['xwork.MethodAccessor.denyMethodExecution']=%21%28%23_memberAccess['allowStaticMethodAccess']=true%29,%28@java.lang.Runtime@getRuntime%28%29%29.exec%28'touch%20aaa'%29.waitFor%28%29%7D.action/
由于POC中存在#_memberAccess["allowStaticMethodAccess"]=true,所以发布者提到升级到s2-014可以缓解。
其实发布者误解了,但是struts2开发者没有误解,所以赶紧推出了S2-015。
但是如果不讲出来,你还是会发现那个POC在S2-014之后其实不能打,就如老外文章中所说,被缓解了。那要怎么打呢?
OGNL的POC有个小技巧
这个东西的含义,是允许静态方法执行,那么官方禁止修改这个设置,意思就是永远禁止静态方法执行。
因为POC中的“@java.lang.Runtime@getRuntime”其实就是在执行静态方法,所以才一定要开启静态,但是这只是java代码的一种写法罢了。
我们可以用另一个写法,绕过这个限制。
//by 空虚浪子心 http://www.inbreak.net 微博:http://t.qq.com/javasecurity
(new java.lang.ProcessBuilder('calc')).start()
这段代码中,没有调用任何静态方法,仅仅是new一个对象,之后执行其中一个动态方法,所以不必allowStaticMethodAccess一样能达到执行系统命令的效果。
这个小技巧,可以干很多事情。
1、可以绕过某些WAF,我不告诉你是哪些,免得你拿去骗奖品。
2、可以为以后新的OGNL代码执行铺路,避免0day来了,我们居然因为这个不会写POC。
S2-015的修补
简单说一句,这里没有什么研究价值,这次修补,官方采用了限制action的名称,只能
[a-z]*[A-Z]*[0-9]*[.\-_!/]*
总结struts2出现过的ognl表达式输入点
1、request参数名
2、request参数值
3、request文件名
4、request的cookie名
5、respose的body
惨不忍睹,好像HTTP头基本都出了问题,也没剩下多少了。一个流行框架,能够在这么多地方出现远程代码执行,真是难为struts开发者了。
同时也问一下使用struts的同学们,你们这些年,是怎么过来的?
在阿里巴巴,我时常分析struts2漏洞然后发报告,有时候会是0day,那就要出个补丁给各个项目用,最后等到官方发布补丁时,我们再评估是否需要重新更新回去。导致我们时常劝说开发人员尽量不要使用这个框架,尤其是项目初期评审时,发现struts2,深恶痛绝,说很多很多话用于吓唬开发人员。
在这种趋势下,我对这个东西已经再无任何侥幸心理,决定推出一个虚拟补丁。至于阿里的真实方案,我肯定不能告诉大家,但是可以讲讲思路。
统一防御方案
首先升级到最新版本。
在ognl这个语言的入口,加入拦截代码,一旦发现危险调用,直接干掉。
代码原理是,在OGNL执行之前,对语句做判断,看到有黑名单的代码,就干掉。理论上,开发人员理论上不会自己写OGNL用于操作文件,执行命令等,他们最多从session中取一个值,或者在页面上取一个值。
覆盖掉Ognl.Ognl类,添加如下代码:
public static Object parseExpression(String expression)
throws OgnlException {
// hackedbykxlzx by 空虚浪子心 http://www.inbreak.net 微博:http://t.qq.com/javasecurity
//。。。下面是白名单列表,请各位同学自行搜索java危险代码,之后加入列表,实在不会的,找几个webshell看看,我肯定不会把阿里正在使用的列表告诉你们的。
String evalMethod[] = { "Runtime", "new file" };
String methodString = null;
methodString = expression.toLowerCase();
for (int i = 0; i < evalMethod.length; i++) {
if (methodString.indexOf(evalMethod[i].toLowerCase()) > -1) {
Log.securityLog(Log.getInfo()+"|OGNL正在执行恶意语句|" + methodString
+ "|看到这个消息,请联系安全工程师!!!","4700012@qq.com");
}
}
try {
OgnlParser parser = new OgnlParser(new StringReader(expression));
return parser.topLevelExpression();
} catch (ParseException e) {
throw new ExpressionSyntaxException(expression, e);
} catch (TokenMgrError e) {
throw new ExpressionSyntaxException(expression, e);
}
}
为什么要加入QQ邮箱呢?具体原因不说,只说结果,结果是,我的邮箱可以收到0DAY,你如果真的看懂了,自己猜猜原因?
其实发这篇文章,我非常恼火,任谁手里有一个0day,捂了半天,结果又被别人公开,都会非常恼火。去年我在XCON发布的S2-012漏洞,其实struts2还存在相似的漏洞。在struts中,框架接收到的用户输入,除了参数、值以外,还有其他地方,比如文件名。这个漏洞,是struts2对url中的文件名做了解析,导致的ognl代码执行。
这中间存在一些技术细节,下面展开分析。
enableOGNLEvalExpression的骗局
从漏洞公告上看到这个词,很容易认为是struts2把ognl表达式干掉了,可以选择终结一切。事实上禁止的是OGNL的其中一种调用方式,而这种调用方式,也只是在S2-013这里调用。
struts2有另外一段威武的代码,真正在防守这个漏洞。
org.apache.struts2.views.util.DefaultUrlHelper这个类:
原本是这样写的,代码走到translateAndEncode就会调用ognl执行,它的逻辑一共包括ognl的translate,以及urlencode这两个功能。
private String buildParameterSubstring(String name, String value) {
StringBuilder builder = new StringBuilder();
builder.append(translateAndEncode(name));
builder.append('=');
builder.append(translateAndEncode(value));
return builder.toString();
}
补丁之后,这里被改为仅仅urlencode,不再做ognl执行。这个和enableOGNLEvalExpression没有任何关系。
private String buildParameterSubstring(String name, String value) {
StringBuilder builder = new StringBuilder();
builder.append(encode(name));
builder.append('=');
builder.append(encode(value));
return builder.toString();
}
我没有细看内容,只看方法名的变动,就感觉可以洗洗睡了,不必往下跟进了。
allowStaticMethodAccess骗局
一直以来allowStaticMethodAccess是struts2的poc标配,从第一个poc出现开始,就一直存在。
在2013年5月27日,也就是前几天,大家可以自行查看SVNlog,struts2做了一件很猥琐的事情,把以下代码删除了:
public void setAllowStaticMethodAccess(boolean allowStaticMethodAccess) {
this.allowStaticMethodAccess = allowStaticMethodAccess;
}
这个动作直接导致一个结果,以后在OGNL的POC中执行
#_memberAccess["allowStaticMethodAccess"]=true
一定会报错的,因为没有set方法了。
很有终结一切的意思,就像以后有新的OGNL漏洞,就不能写这一句了。但是我可以绕过这个东西,下面结合s2-015漏洞做个示例。
struts2框架s2-015吐槽
这个漏洞,被人公布出来,实际上,发布者一共发布了几个漏洞,包含S2-015、以及S2-012。具体地址在
https://communities.coverity.com/blogs/security/2013/05/29/struts2-remote-code-execution-via-ognl-injection
非常详细,某同事认为他比我分析的好,所以我就不写翻译了,大家自己看。
后来仔细想了想,猜测老外可能遇到s2-012,导致了该文章的发布,当然,这只是我的个人YY。
发布者手握2个0day,很不幸,我也有这两个0day,去年xcon发布了一个,之后提交了官方,但是他不知道,因为官方到今年才公开修补。
前几天官方突然公开修补了我发布的一个0day,这个老外看到s2-012后,可能也非常恼火,因为这个漏洞和他手头分析的0day刚好相同,所以一怒之下和其他0day一起发出来了,共同组成一篇文章。可以看到,发布者直接从blog发布,之后官方才收到消息开始修补。
这个漏洞的触发代码展现形式和s2-012非常像,所以理解了s2-012后,可以联想到这个0day,很容易通过测试出来,我当时也是看到类似的使用,随手测试就发现了。相信有很多漏洞,都是类似的情况下发现的。甚至可能不止我们手里有,其实你也非常恼火。
S2-015的poc在老外的文章中如下:
http://127.0.0.1:8080/struts2-blank/example/$%7B%23context['xwork.MethodAccessor.denyMethodExecution']=%21%28%23_memberAccess['allowStaticMethodAccess']=true%29,%28@java.lang.Runtime@getRuntime%28%29%29.exec%28'touch%20aaa'%29.waitFor%28%29%7D.action/
由于POC中存在#_memberAccess["allowStaticMethodAccess"]=true,所以发布者提到升级到s2-014可以缓解。
其实发布者误解了,但是struts2开发者没有误解,所以赶紧推出了S2-015。
但是如果不讲出来,你还是会发现那个POC在S2-014之后其实不能打,就如老外文章中所说,被缓解了。那要怎么打呢?
OGNL的POC有个小技巧
这个东西的含义,是允许静态方法执行,那么官方禁止修改这个设置,意思就是永远禁止静态方法执行。
因为POC中的“@java.lang.Runtime@getRuntime”其实就是在执行静态方法,所以才一定要开启静态,但是这只是java代码的一种写法罢了。
我们可以用另一个写法,绕过这个限制。
//by 空虚浪子心 http://www.inbreak.net 微博:http://t.qq.com/javasecurity
(new java.lang.ProcessBuilder('calc')).start()
这段代码中,没有调用任何静态方法,仅仅是new一个对象,之后执行其中一个动态方法,所以不必allowStaticMethodAccess一样能达到执行系统命令的效果。
这个小技巧,可以干很多事情。
1、可以绕过某些WAF,我不告诉你是哪些,免得你拿去骗奖品。
2、可以为以后新的OGNL代码执行铺路,避免0day来了,我们居然因为这个不会写POC。
S2-015的修补
简单说一句,这里没有什么研究价值,这次修补,官方采用了限制action的名称,只能
[a-z]*[A-Z]*[0-9]*[.\-_!/]*
总结struts2出现过的ognl表达式输入点
1、request参数名
2、request参数值
3、request文件名
4、request的cookie名
5、respose的body
惨不忍睹,好像HTTP头基本都出了问题,也没剩下多少了。一个流行框架,能够在这么多地方出现远程代码执行,真是难为struts开发者了。
同时也问一下使用struts的同学们,你们这些年,是怎么过来的?
在阿里巴巴,我时常分析struts2漏洞然后发报告,有时候会是0day,那就要出个补丁给各个项目用,最后等到官方发布补丁时,我们再评估是否需要重新更新回去。导致我们时常劝说开发人员尽量不要使用这个框架,尤其是项目初期评审时,发现struts2,深恶痛绝,说很多很多话用于吓唬开发人员。
在这种趋势下,我对这个东西已经再无任何侥幸心理,决定推出一个虚拟补丁。至于阿里的真实方案,我肯定不能告诉大家,但是可以讲讲思路。
统一防御方案
首先升级到最新版本。
在ognl这个语言的入口,加入拦截代码,一旦发现危险调用,直接干掉。
代码原理是,在OGNL执行之前,对语句做判断,看到有黑名单的代码,就干掉。理论上,开发人员理论上不会自己写OGNL用于操作文件,执行命令等,他们最多从session中取一个值,或者在页面上取一个值。
覆盖掉Ognl.Ognl类,添加如下代码:
public static Object parseExpression(String expression)
throws OgnlException {
// hackedbykxlzx by 空虚浪子心 http://www.inbreak.net 微博:http://t.qq.com/javasecurity
//。。。下面是白名单列表,请各位同学自行搜索java危险代码,之后加入列表,实在不会的,找几个webshell看看,我肯定不会把阿里正在使用的列表告诉你们的。
String evalMethod[] = { "Runtime", "new file" };
String methodString = null;
methodString = expression.toLowerCase();
for (int i = 0; i < evalMethod.length; i++) {
if (methodString.indexOf(evalMethod[i].toLowerCase()) > -1) {
Log.securityLog(Log.getInfo()+"|OGNL正在执行恶意语句|" + methodString
+ "|看到这个消息,请联系安全工程师!!!","4700012@qq.com");
}
}
try {
OgnlParser parser = new OgnlParser(new StringReader(expression));
return parser.topLevelExpression();
} catch (ParseException e) {
throw new ExpressionSyntaxException(expression, e);
} catch (TokenMgrError e) {
throw new ExpressionSyntaxException(expression, e);
}
}
为什么要加入QQ邮箱呢?具体原因不说,只说结果,结果是,我的邮箱可以收到0DAY,你如果真的看懂了,自己猜猜原因?
相关推荐
风光储直流微电网Simulink仿真模型:光伏发电、风力发电与混合储能系统的协同运作及并网逆变器VSR的研究,风光储直流微电网Simulink仿真模型:MPPT控制、混合储能系统、VSR并网逆变器的设计与实现,风光储、风光储并网直流微电网simulink仿真模型。 系统由光伏发电系统、风力发电系统、混合储能系统(可单独储能系统)、逆变器VSR?大电网构成。 光伏系统采用扰动观察法实现mppt控制,经过boost电路并入母线; 风机采用最佳叶尖速比实现mppt控制,风力发电系统中pmsg采用零d轴控制实现功率输出,通过三相电压型pwm变器整流并入母线; 混合储能由蓄电池和超级电容构成,通过双向DCDC变器并入母线,并采用低通滤波器实现功率分配,超级电容响应高频功率分量,蓄电池响应低频功率分量,有限抑制系统中功率波动,且符合储能的各自特性。 并网逆变器VSR采用PQ控制实现功率入网。 ,风光储; 直流微电网; simulink仿真模型; 光伏发电系统; 最佳叶尖速比控制; MPPT控制; Boost电路; 三相电压型PWM变换器;
以下是针对初学者的 **51单片机入门教程**,内容涵盖基础概念、开发环境搭建、编程实践及常见应用示例,帮助你快速上手。
【Python毕设】根据你提供的课程代码,自动排出可行课表,适用于西工大选课_pgj
【毕业设计】[零食商贩]-基于vue全家桶+koa2+sequelize+mysql搭建的移动商城应用
电动汽车充电背景下的微电网谐波抑制策略与风力发电系统仿真研究,电动汽车充电微电网的谐波抑制策略与风力发电系统仿真研究,基于电动汽车充电的微电网谐波抑制策略研究,包括电动汽车充电负 载模型,风电模型,光伏发现系统,储能系统,以及谐波处理模块 风力发电系统仿真 ,电动汽车充电负载模型; 风电模型; 光伏发现系统; 储能系统; 谐波处理模块; 风力发电系统仿真,电动汽车充电微电网的谐波抑制策略研究:整合负载模型、风电模型与光伏储能系统
Vscode部署本地Deepseek的continue插件windows版本
内容概要:本文详细介绍了滤波器的两个关键参数——截止频率(F0)和品质因素(Q),并探讨了不同类型的滤波器(包括低通、高通、带通和带阻滤波器)的设计方法及其特性。文章首先明确了F0和Q的基本概念及其在滤波器性能中的作用,接着通过数学推导和图形展示的方式,解释了不同Q值对滤波器频率响应的影响。文中特别指出,通过调整Q值可以控制滤波器的峰谷效果和滚降速度,进而优化系统的滤波性能。此外,还讨论了不同类型滤波器的具体应用场景,如低通滤波器适用于消除高频噪声,高通滤波器用于去除直流分量和低频干扰,而带通滤波器和带阻滤波器分别用于选取特定频段信号和排除不需要的频段。最后,通过对具体案例的解析,帮助读者更好地理解和应用相关理论。 适合人群:电子工程及相关领域的技术人员、研究人员以及高校学生,特别是那些需要深入了解滤波器设计原理的人群。 使用场景及目标:适用于从事模拟电路设计的专业人士,尤其是希望掌握滤波器设计细节和技术的应用场合。目标是让读者能够灵活运用Q值和F0来优化滤波器设计,提升系统的信噪比和选择性,确保信号的纯净性和完整性。
内容概要:本文主要讲述了利用QUARTUSⅡ进行电子设计自动化的具体步骤和实例操作,详细介绍了如何利用EDA技术在QUARTUSⅡ环境中设计并模拟下降沿D触发器的工作过程,重点探讨了系统规格设计、功能描述、设计处理、器件编译和测试四个步骤及相关的设计验证流程,如功能仿真、逻辑综合及时序仿真等内容,并通过具体的操作指南展示了电路设计的实际操作方法。此外还强调了QUARTUSⅡ作为一款集成了多种功能的综合平台的优势及其对于提高工作效率的重要性。 适用人群:电子工程、自动化等相关专业的学生或者工程师,尤其适用于初次接触EDA技术和QuartusⅡ的用户。 使用场景及目标:旨在帮助用户理解和掌握使用QUARTUSⅡ这一先进的EDA工具软件进行从概念设计到最后成品制作整个电路设计过程的方法和技巧。目标是在实际工作中能够熟练运用QUARTUSⅡ完成各类复杂电子系统的高效设计。 其他说明:文中通过具体的案例让读者更直观理解EDA设计理念和技术特点的同时也为进一步探索EDA领域的前沿课题打下了良好基础。此外它还提到了未来可能的发展方向,比如EDA工具的功能增强趋势等。
Simulink建模下的光储系统与IEEE33节点配电网的协同并网运行:光照强度变化下的储能系统优化策略与输出性能分析,Simulink模型下的光伏微网系统:光储协同,实现380v电压等级下的恒定功率并网与平抑波动,Simulink含光伏的IEEE33节点配电网模型 微网,光储系统并网运行 光照强度发生改变时,储能可以有效配合光伏进行恒定功率并网,平抑波动,实现削峰填谷。 总的输出有功为270kw(图23) 无功为0 检验可以并网到电压等级为380v的电网上 逆变侧输出电压电流稳定(图4) ,Simulink; 含光伏; 配电网模型; 微网; 光储系统; 储能配合; 恒定功率并网; 电压等级; 逆变侧输出。,Simulink光伏微网模型:光储协同并网运行,实现功率稳定输出
基于Andres ELeon新法的双馈风机次同步振荡抑制策略:附加阻尼控制(SDC)的实践与应用,双馈风机次同步振荡的抑制策略研究:基于转子侧附加阻尼控制(SDC)的应用与效能分析,双馈风机次同步振荡抑制策略(一) 含 基于转子侧附加阻尼控制(SDC)的双馈风机次同步振荡抑制,不懂就问, 附加阻尼控制 (SDC)被添加到 RSC 内部控制器的q轴输出中。 这种方法是由Andres ELeon在2016年提出的。 该方法由增益、超前滞后补偿器和带通滤波器组成。 采用实测的有功功率作为输入信号。 有关更多信息,你可以阅读 Andres ELeon 的lunwen。 附lunwen ,关键词:双馈风机、次同步振荡、抑制策略;转子侧附加阻尼控制(SDC);RSC内部控制器;Andres ELeon;增益;超前滞后补偿器;带通滤波器;实测有功功率。,双馈风机次同步振荡抑制技术:基于SDC与RSCq轴控制的策略研究
springboot疫情防控期间某村外出务工人员信息管理系统--
高效光伏并网发电系统MATLAB Simulink仿真设计与MPPT技术应用及PI调节闭环控制,光伏并网发电系统MATLAB Simulink仿真设计:涵盖电池、BOOST电路、逆变电路及MPPT技术效率提升,光伏并网发电系统MATLAB Simulink仿真设计。 该仿真包括电池,BOOST升压电路,单相全桥逆变电路,电压电流双闭环控制部分;应用MPPT技术,提高光伏发电的利用效率。 采用PI调节方式进行闭环控制,SPWM调制,采用定步长扰动观测法,对最大功率点进行跟踪,可以很好的提高发电效率和实现并网要求。 ,光伏并网发电系统; MATLAB Simulink仿真设计; 电池; BOOST升压电路; 单相全桥逆变电路; 电压电流双闭环控制; MPPT技术; PI调节方式; SPWM调制; 定步长扰动观测法。,光伏并网发电系统Simulink仿真设计:高效MPPT与PI调节控制策略
PFC 6.0高效循环加载系统:支持半正弦、半余弦及多级变荷载功能,PFC 6.0循环加载代码:支持半正弦、半余弦及多级变荷载的强大功能,PFC6.0循环加载代码,支持半正弦,半余弦函数加载,中间变荷载等。 多级加载 ,PFC6.0; 循环加载代码; 半正弦/半余弦函数加载; 中间变荷载; 多级加载,PFC6.0多级半正弦半余弦循环加载系统
某站1K的校园跑腿小程序 多校园版二手市场校园圈子失物招领 食堂/快递代拿代买跑腿 多校版本,多模块,适合跑腿,外卖,表白,二手,快递等校园服务 需要自己准备好后台的服务器,已认证的小程序,备案的域名!
【Python毕设】根据你提供的课程代码,自动排出可行课表,适用于西工大选课
COMSOL锂枝晶模型:五合一的相场、浓度场与电场模拟研究,涵盖单枝晶定向生长、多枝晶生长及无序生长等多元现象的探索,COMSOL锂枝晶模型深度解析:五合一技术揭示单枝晶至雪花枝晶的生长机制与物理场影响,comsol锂枝晶模型 五合一 单枝晶定向生长、多枝晶定向生长、多枝晶随机生长、无序生长随机形核以及雪花枝晶,包含相场、浓度场和电场三种物理场(雪花枝晶除外),其中单枝晶定向生长另外包含对应的参考文献。 ,comsol锂枝晶模型; 五合一模型; 单枝晶定向生长; 多枝晶定向生长; 多枝晶随机生长; 无序生长随机形核; 雪花枝晶; 相场、浓度场、电场物理场; 参考文献,COMSOL锂枝晶模型:多场景定向生长与相场电场分析
嵌入式大学生 点阵代码
那个有delphi12 tedgebrowser 使用的dll
基于DQN算法的微网储能优化调度与能量管理:深度强化学习的应用与实践,基于DQN算法的微网储能优化调度与能量管理:深度强化学习的应用与实践,基于DQN算法的微网储能运行优化与能量管理 关键词:微网 优化调度 储能优化 深度强化学习 DQN 编程语言:python 参考文献:《Explainable AI Deep Reinforcement Learning Agents for Residential Demand Side Cost Savings in Smart Grids》 内容简介: 受深层强化学习(RL)最新进展的激励,我们开发了一个RL代理来管理家庭中存储设备的操作,旨在最大限度地节省需求侧的成本。 所提出的技术是数据驱动的,并且RL代理从头开始学习如何在可变费率结构下有效地使用能量存储设备,即收缩“黑匣子”的概念,其中代理所学的技术被忽略。 我们解释了RL-agent的学习过程,以及基于存储设备容量的策略。 ,微网; 优化调度; 储能优化; 深度强化学习; DQN; 家庭存储设备; 需求侧成本节省; 智能电网; RL代理; 能量存储设备。,基于DQN算法的微网储
内容概要:该文档为FM17580的原理图设计文件,重点介绍了这款非接触式IC卡读写芯片的电路设计细节。文档详细列出了各个元器件及其连接方式、引脚分配及具体值设定。特别值得注意的是,为了确保性能和可靠性,在PCB布局时强调了GND线需要尽量以最短路径连回FM175xx芯片的TVSS引脚附近,并且靠近电源输入端(TVDD)。同时明确了FM17580只兼容SPI通讯协议,其他如IIC或UART选项则不在支持范围内。此外还提供了关于降低能耗的选择——移除不必要的ADC检测电路,这对于一些特定应用场景非常有用。 适合人群:具备硬件开发经验和RFID/NFC领域基础知识的技术人员或研究人员。 使用场景及目标:适用于需要详细了解FM17580内部结构和技术特性的项目团队;旨在帮助工程师们快速上手搭建实验平台并测试FM17580的功能特性。主要目的是为实际应用开发提供技术支持和参考。 其他说明:文档最后附带了一些附加信息,包括设计师名字、公司名称以及审查流程的相关内容,但具体内容并未公开。此外还提到该文档是针对FM17580评估板(即FM17580Demo)的设计图纸。文中出现多次类似表格可能是不同版本之间的对比或者记录修改历史的部分内容。