Kerberos协议与认证数据包分析

news2025/1/17 1:18:43

Kerberos协议

Kerberos是一种在开放的非安全网络中认证并识别用户身份信息的方法,
它旨使用密钥加密技术为客户端/服务端应用程序提供强身份认证。
目前主流的Kerberos版本是2005年的RFC4120标准的Kerberos v5,
Windows、Linux和MacOs均支持Kerberos协议。

Kerberos基础

Kerberos协议中主要有以下3种角色
1.访问服务的客户端:
    Kerberos客户端代表需要访问资源的用户进行操作的应用程序,比如打开文件,查询数据库或打印文档,
    每个Kerberos客户端在访问资源之前都会请求身份验证。
2.提供服务的服务端
    域内提供服务的服务端,服务端都有唯一的SPN(服务主体名称)。
3.提供认证的KDC（密钥分发中心）
    KDC主要是提供活动目录域内用户和计算机的会话票据和临时会话密钥,其服务账号为krbtgt
    KDC作为活动目录域服务的一部分运行在每个域控制器上。
    需要注意的是krbtgt账号是活动目录系统自动创建的一个账号,其作用是KDC(密钥分发中心)的服务账号,
    密码是系统随机生成的,无法正常登陆主机。

Kerberos简述认证方式:

        服务票据:
        Kerberos认证方式被称为票据(Ticket)客户端要想访问服务端的某个服务,
        需要使用服务端认可的服务票据简称ST(Service Ticket 服务票据),
        客户端在访问服务端之前就需要先具备服务票据。
        TGT:
        客户端在申请服务端票据之前需要先拿到TGT,TGT和ST都是由KDC发放的,
        KDC都运行在域控上可以看成TGT和ST都是域控发放的。
        88端口和464端口:
        Kerberos使用TCP/UDP 88端口进行认证,使用TCP/UDP 464端口进行密码重设。

Kerberos协议两大基础认证模块

AS_REQ & AS_REP 模块
TGS_REQ & TGS_REP模块
微软扩展的两个认证模块:
    S4U（委派拓展模块）:
        微软实现委派而扩展的模块分为S4u2Self、S4u2Proxy。
    PAC（特权属性证书）:
         在Kerberos最初的设计的流程里直说嘛了如何证明客户端的真实身份,
         并没有说明客户端是否有权限访问该服务,因为在域中不同的权限的用户
         能够访问的资源是不同的,因此微软为了解决这个权限为题引入了PAC。

PAC（特权属性证书）简述

PAC是为了解决微软在域中不同权限访问的资源是不同的问题,
因此PAC中包含了各种授权信息、附加凭据信息、配置文件、
和策略信息等，比如用户所属于的用户组,用户所拥有的权限等,
在原本的Kerberos协议是中没有PAC存在的是微软后加的,
微软设计特权属性证书是用来识别用户身份和权限。

在正常的Kerberos认证流程中,KDC（密钥分发中心）TGT（票据）和ST（服务票据）都是带有PAC
的,这样做的好处是服务端接收客户请求的时候不需要借助KDC提供完整的授权信息来完成对用户
权限的判断,只需要根据请求中所包含的PAC（特权属性证书）直接与本地资源的ACP相比较来作出裁决。

PAC结构

typedef unsigned long ULONG;
typedef unsigned long USHORT;
typedef unsigned long long64 ULONG64;
typedef unsigned char UCHAR;
typdef struct _PACTYPE{
    ULONG cBuffers;
    ULONG Version;
    PAC_INFO_BUFFER Buffers[1]
}PACTYPE;

cBuffers:包含数据缓冲区中的条目数
Version:版本
Buffers:包括一个PAC_INFO_BUFFER结构的数组。

PAC签名

PAC主要包括两个数字签名:
1.PAC_SERVER_CHECKSUM
    PAC_SERVER_CHECKSUM是使用服务密钥进行签名
2.PAC_PRIVSVR_CHECKSUM
    PAC_PRIVSVR_CHECKSUM是使用KDC密钥进行签名
为什么需要PAC签名:
    1.PAC_SERVER_CHECKSUM服务密钥签名,以验证此PAC已由服务签名。
    2.PAC_PRIVSVR_CHECKSUM是KDC密钥签名的是为了防止不受信任的服务用无效的PAC为自己伪造票据,
需要注意:
    PAC数据用于访问控制之前,必须检查PAC_SERVER_CHECKSUM签名,验证客户端是否知道服务密钥,
    PAC_PRIVSVR_CHECKSUM签名的验证时可选的,默认不开启它用于验证PAC是否由KDC签发,而不是由
    KDC以外的具有访问服务密钥的第三方放入票据中。

KDC验证PAC

服务端接收客户端发来的AP-REQ消息时,只能校验PAC_SERVER_CHECKSUM签名,并不能校验
PAC_PRIVSVR_CHECKSUM签名,如果要校验PAC_PRIVSVR_CHECKSUM签名服务端还需要将客户端发来的
ST中的PAC签名发给KDC进行校验,大部分服务默认没有KDC验证PAC默认未开启,如果要开启需要将目标
服务主机配置为验证KDC PAC签名,开启后ST中的PAC就发给KDC校验了。

PAC_PRIVSVR_CHECKSUM开启的情况下白银票据攻击能否成功

如果开启了KDC验证PAC,那么白银票据攻击不会成功,白银票据攻击的前提是
关闭了PAC_PRIVSVR_CHECKSUM签名认证,因为服务端会将这个PAC签名以KRB_VERIFY_PAC的消息
通过RPC协议发给KDC，KDC验证这个PAC数字签名后结果以RPC返回码形式发给服务端,服务端根据
返回结果判断PAC的真实性和有效性,就算攻击者拥有服务密钥,能够制作ST也不能伪造KDC的PAC_PRIVSVR_CHECKSUM签名,
无法通过KDC校验。

PAC在Kerberos中的优缺点

优点:
关闭KDC校验PAC
客户端在访问网络资源的时候,服务端不再需要向KDC查询授权信息,
而是直接在本地进行PAC信息域ACL比较,从而节约了网络资源。
缺点:
开启KDC校验PAC
PAC在用户认证阶段引入会导致认证耗时过长,Windows Kerberos客户端会通过RPC调用KDC
上的函数来验证PAC信息,这时候服务单域KDC之间的RPC包流量增加,PAC是微软特有的内容,
开启PAC的域中不支持装有其他操作系统的服务器,限制了域配置的灵活性。

问答小环节

1.S4U和PAC是否是Kerberos协议原本支持的模块
    S4U和PAC是微软的拓展两大模块,原本的Kerberos并没太这俩模块。
2.Linux和MacOs是否支持Kerberos协议
    支持,原生Kerberos协议支持Linux和MacoOs,但是缺少微软的两大拓展模块S4U和PAC。
3.S4U、PAC、ST、TGT、KDC、SPN上述名词全称是什么
    S4U:(委派拓展模块)
    PAC:(特权证书拓展模块)
    ST:(服务票据)
    TGT:(准予票据)
    KDC:(密钥分发中心)
    SPN:(服务主体名称)
4.域控的88端口和464端口的作用是什么
    88端口:Kerberos认证端口
    464端口:密码重设端口
5.KDC返回的TGT和ST是否带有PAC
    在微软的Kerberos认证流程中,KDC返回的PAC都是带有PAC的,
    这样可以在以后对资源的访问中,服务端接收到客户请求的时候不需要借助KDC
    提供完整的授权来完成对用户权限的判断,只需要根据包含PAC语言本地资源ACL
    相比较作出裁决。
6.PAC主要包括那两个数字签名
    PAC_SERVER_CHECKSUM签名
    PAC_PRIVSVR_CHECKSUM签名
7.KDC验证PAC默认是否开启
    默认不开启因为会造成很大的网络资源使用
8.KDC验证PAC的情况下白银票据攻击能否成功
    不能成功,因为就算拥有服务密钥也没有PAC_PRIVSVR_CHECKSUM签名,
    无法通过KDC的PAC校验

数据包分析环境如下

用户:		10.211.55.2
域内主机:	10.211.55.16
域控:		10.211.54.4
使用getST.py请求域内主机的cifs服务ST

Kerberos认证流程

1.AS-REQ:客户端向KDC的AS（认证服务）请求TGT
2.AS-REP:身份认证通过后KDC发放TGT
3.TGS-REQ:客户端拿这TGT向KDC的TGS请求ST（服务票据）
4.TGS-REP:身份认证通过后KDC发放ST(服务票据)
5.AP-REQ:客户端拿着ST向服务端请求服务
下面为可选:
PAC_PRIVSVR_CHECKSUM签名开启校验发送PAC给KDC校验
6.AP-REP:客户端希望认证提供服务的服务端时,服务端返回该该数据
的双向认证,双向认证后的服务端返回服务资源给客户端。

AS-REP&AS-REQ

在这里插入图片描述

这是的AS-REQ&AS-REP请求过程,下面将简述下请求过程所包含的内容
AS-REQ:
	1.请求的用户名cname
	2.域名realm
	3.Authenticator用户加密的时间戳
	4.请求的服务名sname
	5.加密类型etype
	6.其他信息、如版本号、消息类型、票据有效时间、是否包含PAC、协商项目等。
	
AS-REP:
	1.版本号、域名、用户等
	2.版本号、域名、请求的服务名
	3.enc-part加密部分
 			Logon Session Key
 			用户名、域名、认证时间、认证到期时间戳
 			PAC
 			PAC_SERVER_CHECKSUM签名
 			PAC_PRIVSVR_CHECKSUM签名
 	krbtgt密钥进行的加密

AS-REQ的Kerberos数据内容分析

在这里插入图片描述

PA-DATA pA-ENC-TIMESTAMP:
预认证,就是用户密码Hash加密时间戳作为value发送给KDC的AS,
然后KDC从活动目录中查询用户的Hash,使用用户Hash进行解密,
获得时间戳如果能解密且时间戳在一定范围内,则证明认证通过,
由于使用了用户密码Hash加密的时间戳,因此也就造成了哈希传递攻击,
需要注意的是在AS-REQ中只有PA-DATA pA-ENC-TIMESTAMP部分是加密的,
这一部分成为预认证,称为Authenticator,使用用户密码Hash或用户密码AES Key
来加密时间戳的。

在这里插入图片描述

PA-DATA pA-PAC-REQUEST:
启用PAC支持的扩展,这里的value对应值为True或False,
KDC根据include的值来确定返回的票据中是否需要挈带PAC。
include-pac:是否包含PAC,这里是True,说明包含PAC。

在这里插入图片描述

kdc-options:用于KDC协商一些设置

在这里插入图片描述

cname:请求的用户名,这个用户是否存在返回的包是有差异的,因此可以通过差异来进行枚举域内用户名,
	当用户存在时,密码正确与否会影响返回包,因此也可以进行密码喷洒。

realm:域名

在这里插入图片描述

sname:请求的服务包含type和value,在AS-REQ中sname始终为krbtgt。

AS-REP数据包分析

KDC的AS接收到客户端发来的AS-REQ后,AS从活动目录库中取出该用户密码,然后用该用户密钥
对请求包中预认证部分进行解密,如果解密成功,并且时间戳在有效时间之内,则说明请求者提供的
用户密钥正确。
AS-REP中的重要字段

在这里插入图片描述

1.ticket:认证权证票据其中ticket中enc-part是加密部分,这部分是使用krbtgt的密码Hash加密的,
因此如果我们拥有krbtgt的Hash就可以自己制作一个ticket,这就是黄金票据攻击的原理。
	TGT包含的内容:
	1.tkt-vno:版本号
	2.realm:域名
	3.sname:服务名
	4.en-part最重要的加密部分使用krbtgt账户的密钥加密,
	主要包括Logon Session Key、请求的用户名cname、域名crealm、认证时间authtime、
	认证到期时间endtime、authorization-data部分信息包含客户单身份等信息，这些信息包含在PAC中,
	PAC凭证信息部分PAC_LOGON_INFO主要是通过User RID和Group RID来辨别用户权限的。
	KDC生成PAC过程:
		KDC在收到客户端发过来的AS-REQ后,从请求中取出cname字段,然后查询活动目录数据库,
		找到sAMAccountName属性为cname字段的值的用户,用该用户的身份生成一个对应的PAC。

在这里插入图片描述

2.外层enc-part:其中Logon Session Key,这部分是用请求的用户密码Hash加密的，
作为下一阶段的认证密钥。
Logon Session Key:
	AS-REP包最外层的那部分便是加密的Logon Session Key,用户确保客户端和KDC下一个阶段的通信安全,
	使用请求用户的密钥加密。
	解密后包含如下内容:
	认证时间authtime、认证到期时间endtime、域名srealm、请求服务名sname、
	协商标志flags等信息,可以看到在AS-REP中存在了两个Logon Session Key,其中一个位于TGT中由
	krbtgt hash加密、另一个存在于外层enc-part中由AS-REQ中cname的用户名密钥Hash加密。
简述:TGT和加密的Logon Session Key,TGT部分是使用krbtgt密钥加密的,Long Session Key是使用用户密钥加密的。

TGS-REQ数据包分析

		客户端收到KDC的AS-REP后使用用户密钥解密enc_Logon Session Key,
		也就是最外层的enc-part,得到Logon Session Key,并且也获得了TGT和Logon Session
		Key,之后会将这俩本地缓存现在客户端需要凭借这张TGT向KDC购买相应的ST,
		ST是KDC的另一个服务TGS授权服务发放的,在这阶段微软引入了两个扩展自协议,
		S4u2Self、S4u2Proxy跟委派相关。
		
		TGS-REQ主要包含的内容如下：
		域名realm
		请求服务名sname
		TGT
		Authenticator(Longn Session key加密的时间戳)
		加密类型etype
		其他信息、版本号、消息类型、协商类型、到期时间等。

在这里插入图片描述

padata:
	可以从下面的图片中看到padata中包含了ap-req,这是TGS-REQ必须携带的部分,这部分包含了AS_REP中
	获取到的TGT票据和使用原始的Logon Session Key加密的时间戳。

在这里插入图片描述

ap-req:
	TGS_REQ必须携带的部分。
ticket:AS-REQ回复包中返回的TGT。

在这里插入图片描述

在这里插入图片描述

authenticator:原始Logon Session Key加密的时间戳,用于保证会话安全，该字段主要用于下一阶段的会话安全
认证,确保下一阶段的会话安全,TGS-REQ的ap-req中的authenticator字段的值使用的是上一步AS-REP中返回
Logon Session Key加密的时间戳。

TGS-REP数据包分析

KDC的TGS服务接收到TGS-REQ之后会进行如下操作,首先使用krbtgt密钥解密
TGT中的加密部分,得到Logon Session Key和PAC等信息,解密成功则说明该TGT是
KDC颁发的,然后验证PAC的签名,签名正确证明PAC未经过篡改,最后使用Logon Session
Key解密authenticator得到时间戳等信息,Logon Session Key解密authenticator得到时间戳
信息,如果能够解密成功，并且票据时间在有效范围,则验证了会话安全性,在完成上述检测后
KDC的TGS完成了对客户端的认证,TGS会发送回复包给客户端。
需要注意:
	TGS-REP中KDC并不会验证客户端是否有权限访问服务端,因此不管用户有没有访问
	服务的权限,只要TGT正确,均会返回ST。

在这里插入图片描述

ticket:即ST。
enc-part(ticket中的):这部分是服务的密钥加密的。

在这里插入图片描述

enc-part(最外层的):
	这部分是用原始的Logon Session Key加密的,里面最重要的字段是Service Session Key,
	作为下一阶段的认证密钥。

在这里插入图片描述

TGS-REP包中最重要的就是ST和Service Session Key,ST中加密部分是使用服务密钥加密的,而
Service Session Key是使用Logon Session Key加密的。
ST:
	TGS-REP包中的ticket便是ST，ST中包含明文显示的信息,如版本号、tkt-vno、域名
	realm、请求的服务名sname、但是最终的还是加密部分,加密部分是使用服务密钥加密的,
	主要包含Server Session Key,请求的用户名cname、域名crealm、认证时间authtime、
	认证到期时间endtime、authorization-data等信息，其中authorization-data部分包含客户端的
	身份权限等信息,如果对authorization-data进行解密查看PAC的凭据信息部分PAC_LOGON_INFO,
	主要是通过User RID和Group RID来辨别用户权限的。
Service Session Key:
	即是最外层的enc-part部分使用原始的Logon Session Key加密,用于确保客户端和KDC下一阶段
	的通信安全,主要包含认证时间authtime、认证到期时间endtime、域名srealm、请求的服务名sname、
	协商标志flage等信息，在ST中也包含Service Session Key。

AP-REQ&&AP-REP双向认证

AP-REQ:
	客户端接收到KDC的TGS回复后,通过缓存的Logon Session Key解密enc_Service Session Key得到
	Service Session Key,同时它也拿到了ST,Service Session Key和ST会被客户端缓存,客户端访问指定服务
	时,将发起AP-REQ。
	AS-REQ Kerberos内容:
		ap-req
			ticket	票据
			sname	加密的时间戳
			enc-part
		authenticator
AP-REP:
	这一步是可选的当客户端希望验证提供服务的服务端时(也就是AP-REQ请求中mutual-required选项为True),
	服务端返回AP-REP信息,服务端接收到客户端发来的AP-REQ消息后通过服务密钥解密ST得到Service Session Key和
	PAC等信息,然后用Service Session Key解密Authenticator得到时间戳,如果解密成功且时间戳在有效范围内,
	则验证了客户端的身份,验证了客户端的身份后,服务端从ST中取出PAC中代表用户身份权限信息的数据,
	与请求服务的ACL做对比,生成相应的访问令牌,同时服务端会检查AP-REQ中请求的mutual-required选项
	是否为True,如果是则说明客户端想验证服务端的身份,此时服务端会用Service Session Key加密时间戳
	作为Authenticator在AP-REP包中发送给客户端进行验证,如果mutual-required选项为False,服务端会根据访问
	令牌的权限决定是否返回相应的服务给客户端。
	
	双向认证:
	这里的认证过程是双向认证：

		1、服务端验证客户端：防止非法用户操作
		
		当需要访问服务时，客户端将Ticket和使用Server Session Key加密的客户端信息和时间戳发送给服务端。
		
		服务端收到客户端的请求，使用该服务的NTML hash解密Ticket，得到Server Session Key，再使用Server Session Key解密其他数据，然后将解密出来的数据和Ticket解密出来的数据进行比较，验证通过后，因为启用了PAC，服务端会将PAC发送给DC询问此用户是否有访问权限。DC收到PAC后会解密PAC，然后通过PAC中的SID判断用户信息、用户权限等，最后将结果返回到服务端。这里如果设置了ACL，服务端还会判断ACL有没有限制用户请求的服务，全部通过后服务端成功验证客户端。
		
		2、客户端验证服务端：防止误入恶意服务
		
		服务端将使用Server Session Key加密的客户端信息和时间戳（这里的时间戳是第三阶段客服端发送给服务端的时间戳）发送给客户端，客户端使用Server Session Key解密数据，解密成功之后客户端将时间戳和原来发送的时间戳进行对比，如果一致则客户端成功认证服务端。
		
		Kerberos认证的第三阶段完成，Kerberos认证完成，客户端和服务端建立通信。
		简单来说:服务端验证客户端需要开启PAC_PRIVSVR_CHECKSUM签名校验将PAC转交给DC询问可以防止白银票据攻击,客户端AP-REQ请求中mutual-required选项为True服务端使用Server Session Key加密的客户端信息和时间戳,Server Session Key是由原始Logon Session Key加密的以此验证服务端

S4u2Self&S4u2Proxy

微软对Kerberos协议扩展了两个自协议:S4u2Self(Service for User to Self)和S4u2Proxy(Service for User to Proxy)。
S4u2Self:
S4u2Self可以代表仁医用户请求针对自身的服务票据,S4u2Proxy可以用上一步获取的ST以用户名义请求针对其他
指定服务的ST。
	跟正常的TGS-REQ相比,S4u2Self协议的TGS-REQ包会多一个PA-DATA pa-FOR-USER,
	name为要模拟的用户,并且sname也是请求的服务自身。
S4u2Proxy:
和正常的TGS-REQ包相比,S4u2Proxy协议的TGS-REQ包会增加一个additional-tickets字段,
该字段的内容就是上一步利用S4u2Self请求的ST。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/198006.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

Quartz入门看这一篇文章就够了

Quartz入门看这一篇文章就够了

第一章 Quartz简介 第一节 Quartz是什么? 1Quartz [kwɔːts]是一个完全由Java编写的开源的作业调度框架第二节 Quartz可以用来做什么? 比如说买火车票下单之30分钟之后,查看是否付款付款完成之后,在乘车日期的时候是否乘车或者每个月1号扣房贷每个月20号自动还信用卡想定时…
阅读更多...
为什么要使用采购管理软件 采购管理软件推荐

为什么要使用采购管理软件 采购管理软件推荐

在企业发展道路上，采购部门是一个非常重要的组织，它会直接影响到企业的经济效益。企业在采购活动中，如果还是采用传统线下的采购方式，那么很容易导致采购信息不集中，效率低，出错率高，最终损害企…
阅读更多...
爱情呼叫转移-深度广度遍历合集

爱情呼叫转移-深度广度遍历合集

1.这件事是特殊的，还是普遍的？ 工作中常常会遇到各种各样的问题，不管黑猫白猫，抓到老鼠就是好猫。哪只猫好，往往需要对比分析。 如何做数据对比，需要加入哪些数据来分析，在哪里进行数据对比&am…
阅读更多...
查找 二分查找 （终极巩固）

查找 二分查找 （终极巩固）

二分条件&#xff1a; 1) 序列有序 2&#xff09;支持随机访问 二分思想&#xff1a; 大体思想是二分之后如果目标值在左侧&#xff0c;则中间包括右边区间所有pass掉 right mid - 1; 目标在右侧&#xff0c;则中间包括左边所有pass left mid 1; 注意点 left < rig…
阅读更多...
Python Fiddler抓包工具教学，获取公众号（pc客户端）数据

Python Fiddler抓包工具教学，获取公众号（pc客户端）数据

前言 今天来教大家如何使用Fiddler抓包工具&#xff0c;获取公众号&#xff08;PC客户端&#xff09;的数据。 Fiddler是位于客户端和服务器端的HTTP代理&#xff0c;是目前最常用的http抓包工具之一。 开发环境 python 3.8 运行代码pycharm 2021.2 辅助敲代码requests 第三方…
阅读更多...
VS2022 开发Qt之修改软件图标

VS2022 开发Qt之修改软件图标

开发环境本次实验使用的开发环境是win10 64位系统 IDE使用VS2022,Qt版本是Qt5,15.写博客背景最近再练习使用VS开发Qt,到修改软件图标的事情.在网上搜索了一番大部分修改图标的都是基于Qt自带的编译器,由于本人使用的VS的IDE和自带的编译器设置方法有所不同,在一番查找实验后还整…
阅读更多...
【论文学习】YOLOv1-YOLOv4

【论文学习】YOLOv1-YOLOv4

文章目录You Only Look Once,Unified ,Real-Time Object DetectionAbstractIntroductionUnified DetectionNetwork DesignTrainingInferenceLimitations of YOLOComparison to Other Detection SystemsYOLO9000:Better,Faster,StrongerAbstractIntroductionBetterBatch Normali…
阅读更多...
【C++之类和对象】日期类的实现

【C++之类和对象】日期类的实现

目录前言一、日期类的基本样式二、构造函数三、拷贝构造函数四、赋值运算符重载五、日期比较1. 判断一个日期是否小于另一个日期2. 判断一个日期和另一个日期是否相等3. 判断一个日期是否小于等于另一个日期4. 判断一个日期是否大于另一个日期5. 判断一个日期是否大于等于另一个…
阅读更多...
独孤九剑xss通关教程

独孤九剑xss通关教程

独孤九剑xss通关教程 独孤九剑第一式&#xff1a; 这里过滤了 () 构造payload&#xff1a; ?data"><svg><script>%26%23x65%3B%26%23x76%3B%26%23x61%3B%26%23x6c%3B%26%23x28%3B%26%23x6c%3B%26%23x6f%3B%26%23x63%3B%26%23x61%3B%26%23x74%3B%26%23…
阅读更多...
开门红，农民大衣哥兔年第一条祝福，为何在百万艺人中选择杨语莲

开门红，农民大衣哥兔年第一条祝福，为何在百万艺人中选择杨语莲

俗话说&#xff1a;人逢喜事精神爽。这句话用到农民歌唱家大衣哥身上&#xff0c;就再贴切不过了&#xff0c;因为在新年即将来临之际&#xff0c;他的儿子小伟又一次结婚了。大衣哥是一个非常接地气的明星&#xff0c;这些年来他无绯闻不炒作&#xff0c;堪称为娱乐圈的楷模&a…
阅读更多...
开学季，送初三学生什么礼物最实用？2023学生护眼台灯分享

开学季，送初三学生什么礼物最实用？2023学生护眼台灯分享

春节的新学期即将到来&#xff0c;送给初中孩子什么礼物比较好呢&#xff0c;还是要对学习有所帮助的&#xff0c;还需要培养孩子的兴趣&#xff0c;在挑选礼物时&#xff0c;也是斟酌了很久&#xff0c;面对现在很多孩子的有近视问题&#xff0c;在我国的近视人数达到7亿人&am…
阅读更多...
java面试题(十一)IO流篇

java面试题(十一)IO流篇

2.21 请介绍TreeMap的底层原理 参考答案 TreeMap基于红黑树&#xff08;Red-Black tree&#xff09;实现。映射根据其键的自然顺序进行排序&#xff0c;或者根据创建映射时提供的 Comparator 进行排序&#xff0c;具体取决于使用的构造方法。TreeMap的基本操作containsKey、g…
阅读更多...
三维重建——商汤NeuralRecon算法详解与论文解读

三维重建——商汤NeuralRecon算法详解与论文解读

论文地址：https://arxiv.org/abs/2104.00681 1.三维重建任务概述 三维重建，就是将2D的图片信息重建为3D的信息。应用领域广泛。可以应用于原型设计、虚拟现实等。 2.三维重建基础 （1） 相机成像 相机成像一般是小孔成像的原理，f就是焦距，o就是光圈；右图为光圈大小对清晰…
阅读更多...
【多尺度注意力的轻量化图像超分辨率】

【多尺度注意力的轻量化图像超分辨率】

MSAR-Net: Multi-scale attention based light-weight image super-resolution &#xff08;MSAR-Net&#xff1a;基于多尺度注意力的轻量化图像超分辨率&#xff09; 近年来&#xff0c;单幅图像超分辨率&#xff08;SISR&#xff09;技术在视频和图像处理领域得到了广泛的应…
阅读更多...
Python基础语法预习，开学查漏补缺

Python基础语法预习，开学查漏补缺

嗨害大家好鸭~我是小熊猫 Python3 基础语法 Python学习资料电子书 点击此处跳转文末名片 编码 默认情况下&#xff0c;Python 3 源码文件以 UTF-8 编码&#xff0c; 所有字符串都是 unicode 字符串。 当然你也可以为源码文件指定不同的编码&#xff1a; # -*- coding: cp-125…
阅读更多...
（HR职场）什么是计划能力?如何提高计划能力？

（HR职场）什么是计划能力?如何提高计划能力？

不论是学习还是工作&#xff0c;光靠努力是不行的&#xff0c;还得有计划&#xff0c;有周密的部署&#xff0c;懂得按计划做事情的人&#xff0c;不仅可以高效率地完成工作&#xff0c;还能在枯燥的工作中寻找到乐趣。这就是做计划的意义和必要性。当然光有计划也不行&#xf…
阅读更多...
ArcGIS基础：将多个面要素融合成一个多边形面要素操作

ArcGIS基础：将多个面要素融合成一个多边形面要素操作

操作目标&#xff1a;有多个多边形要素&#xff0c;并且字段属性没有统一的&#xff0c;可以采用以下两种办法融合成一个面要素。 如下所示&#xff0c;是对被选中的高亮数据进行处理的。 下面介绍第一种方法&#xff1a; 保持数据选中状态&#xff0c;找到【地理处理】下的…
阅读更多...
Codeforces Round #849 (Div. 4) D Distinct Split

Codeforces Round #849 (Div. 4) D Distinct Split

题目&#xff1a;大概翻译&#xff1a;让我们把一个字符串x的f(z)函数表示为该字符串包含的不同字符数。例如&#xff0c;f(abc)3。f(bbbb) 1, 和 f(babacaba) 3. 给定一个字符串s&#xff0c;将其分成两个非空字符串a和b&#xff0c;使f(a)f(b)为最大可能。换句话说&#xf…
阅读更多...
2023软考软件设计师易混淆知识点~（7）

2023软考软件设计师易混淆知识点~（7）

将2023上半年软考《软件设计师》易混淆知识点&#xff0c;分享给大家&#xff0c;快来跟着一起打卡学习吧&#xff01;--<<<点击链接加入群聊【软考学习交流群】>>>易混淆点 :对称加密和非对称加密1、对称加密技术:KeKd;加密解密共用一个密钥;特点:加密强度不…
阅读更多...
python设计模式-适配器设计模式，装饰器设计模式

python设计模式-适配器设计模式，装饰器设计模式

适配器设计模式 适配器模式可用作两个不兼容接口之间的桥梁。 这种类型的设计模式属于结构模式&#xff0c;因为此模式结合了两个独立接口的功能。 这种模式涉及一个类&#xff0c;它负责连接独立或不兼容接口的功能。 一个现实的例子是读卡器&#xff0c;它是存储卡和笔记本电…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023