Security

Dsniff Dsniff 是一个著名的网络嗅探工具包。其开发者Dug Song早在1999年12月，以密歇根大学CITI研究室 (Center for Information Technology Integration) 的研究成果为基础，开发了这个后来具有很大影响力的网络安全工具包。Dug Song开发Dsniff的本意是揭示网络通信的不安全性，借助这个工具包，网络管理员可以对自己的网络进行审计，也包括渗透测试。但万事总有其两面 性，Dsniff所带来的负面作用也是"巨大"的，首先它是可以自由获取的，任何拥有这个工具包的人都可能做"非正当"的事，其次，Dsniff里面的某 些工具，充分揭示了一些安全协议的"不安全性"，例如针对SSH1和SSL的MITM (Man-In-The-Middle) 攻击工具—SSHmitm和 Webmitm。SSH1和SSL都是建立网络通信加密通道的机制，向来被认为是很安全的，但人们在具体使用时，往往因为方便性上的考虑而忽视了某些环 节，造成实事上的不安全。所以说，最大的不安全性，往往并不在于对安全的一无所知，而在于过于相信自己的安全。 Dub Song在2000年12月发布了Dsniff的v2.3版本，该版本支持OpenBSD、Linux、Solaris系统平台。目前，最新版本是 2001年3月发布的v2.4b1的Beta版 除了针对Unix系统的版本，从网上也可以得到Windows平台上运行的Dsniff早期版 作为一个工具集，dsniff包括的工具分为四类: 纯粹被动地进行网络活动监视的工具，包括: dsniff、filesnarf、mailsnarf 、msgsnarf、urlsnarf、webspy 针对SSH和SSL的MITM (Man-In-The-Middle) “攻击"工具，包括sshmitm和webmitm 发起主动欺骗的工具，包括: arpspoof、dnsspoof、macof 其它工具，包括tcpkill、tcpnice dsniff的安装 sudo pacman -S dsniff 安装完成后，默认 dsniff 的安装目录是 /usr/local/sbin，在这里可以看到 dsniff 所有的工具 dsniff工具介绍 纯粹被动地进行网络活动监视的工具，包括: dsniff、filesnarf、mailsnarf 、msgsnarf、urlsnarf、webspy 针对SSH和SSL的MITM (Man-In-The-Middle) “攻击"工具，包括sshmitm和webmitm 发起主动欺骗的工具，包括: arpspoof、dnsspoof、macof 其它工具，包括tcpkill、tcpnice dsniff dsniff 是一个密码侦测工具，他能够自动分析端口上收到的某些协议的数据包，并获取相应的密码。 dnisff 支持的协议有 FTP, Telnet, SMTP, HTTP, POP, poppass, NNTP, IMAP, SNMP, LDAP, Rlogin, RIP, OSPF, PPTP MS-CHAP, NFS, VRRP, YP/NIS, SOCKS, X11, CVS, IRC, AIM, ICQ, Napster, PostgreSQL, Meeting Maker, Citrix ICA, Symantec pcAnywhere, NAI Sniffer, Microsoft SMB, Oracle SQL*Net, Sybase and Microsoft SQL。 ...

CORS, XSS, Cross Site Scripting, CSRF, Cross-site request forgery CORS, Cross-Origin Resource Sharing, 跨源资源共享, 跨域资源共享 CORS (Cross-Origin Resource Sharing，跨源资源共享) 是一种基于 HTTP 头的机制,允许服务器指示浏览器应该允许哪些源(域、协议或端口)来访问其资源。 核心概念 同源策略 (Same-Origin Policy) 同源策略是浏览器最核心的安全机制之一,用于隔离潜在的恶意文档,防止不同源的网页之间互相干扰。 默认情况下, 网页只能请求与自身同源的资源。 什么是"同源": 两个 URL 只有在以下三个部分完全相同时才被认为是同源的: 协议 (Protocol): http/https 域名 (Domain): 包括子域名 端口 (Port): 默认端口可省略 假设当前页面是: http://www.example.com:80/dir/page.html http://www.example.com/dir2/other.html ✅ 同源 协议、域名、端口相同 http://www.example.com:80/dir/inner/page.html ✅ 同源 80 是 http 默认端口 https://www.example.com/page.html ❌ 不同源 协议不同 (https vs http) http://www.example.com:8080/page.html ❌ 不同源 端口不同 (8080 vs 80) http://api.example.com/page.html ❌ 不同源 域名不同 (子域名不同) http://example.com/page.html ❌ 不同源 域名不同 (缺少 www) ...

antisamy https://blog.csdn.net/zhujq_icode/article/details/79154063 策略文件 antisamy-slashdot.xml Slashdot (http://www.slashdot.org/)是一个提供技术新闻的网站,它允许用户用有限的HTML是一个提供技术新闻的网站,它允许用户用有限的HTML)格式的内容匿名回帖。 Slashdot不仅仅是目前同类中最酷的网站之一,而且同时也曾是最容易被成功攻击的网站之一。更不幸的是,导致大部分用户遭受攻击的原由是臭名昭着的goatse.cx 图片(请你不要刻意去看)。 Slashdot的安全策略非常严格: 用户只能提交下列的html标签: <b>、<u>、<i>、<a>、<blockquote>，并且还不支持CSS.因此我们创建了这样的策略文件来实现类似的功能。它允许所有文本格式的标签来直接修饰字体、颜色或者强调作用。 antisamy-ebay.xml 众所周知,eBay (http://www.ebay.com/)是当下最流行的在线拍卖网站之一。它是一个面向公众的站点,因此它允许任何人发布一系列富HTML的内容。我们对eBay成为一些复杂XSS攻击的目标,并对攻击者充满吸引力丝毫不感到奇怪。由于eBay允许输入的内容列表包含了比Slashdot是当下最流行的在线拍卖网站之一。它是一个面向公众的站点,因此它允许任何人发布一系列富HTML的内容。我们对eBay成为一些复杂XSS攻击的目标,并对攻击者充满吸引力丝毫不感到奇怪。由于eBay允许输入的内容列表包含了比Slashdot)更多的富文本内容,所以它的受攻击面也要大得多。 antisamy-myspace.xml MySpace (http://www.myspace.com/)是最流行的一个社交网站之一。用户允许提交几乎所有的他们想用的HTML和CSS,只要不包含JavaScript。MySpace现在用一个黑名单来验证用户输入的HTML,这就是为什么它曾受到Samy蠕虫攻击(http://namb.la/)的原因。Samy蠕虫攻击利用了一个本应该列入黑名单的单词(eval)来进行组合碎片攻击的,其实这也是AntiSamy是最流行的一个社交网站之一。用户允许提交几乎所有的他们想用的HTML和CSS,只要不包含JavaScript。MySpace现在用一个黑名单来验证用户输入的HTML,这就是为什么它曾受到Samy蠕虫攻击(http://namb.la/)的原因。Samy蠕虫攻击利用了一个本应该列入黑名单的单词(eval)来进行组合碎片攻击的,其实这也是AntiSamy)立项的原因。 antisamy-anythinggoes.xml 如果你想允许所有有效的HTML和CSS元素输入 (但能拒绝JavaScript或跟CSS相关的网络钓鱼攻击) ,你可以使用这个策略文件。其实即使MySpace也没有这么疯狂。然而,它确实提供了一个很好的参考,因为它包含了对于每个元素的基本规则,所以你在裁剪其它策略文件的时候可以把它作为一个知识库。 antisamy-tinymce.xml 只允许文本格式通过,相对较安全 antisamy.xml 默认规则,允许大部分HTML通过 作者: flying_pig1989 来源: CSDN 原文: https://blog.csdn.net/zhujq_icode/article/details/79154063 版权声明: 本文为博主原创文章,转载请附上博文链接！ 维护记录 时间 修改内容 原因 2026-10-09 修复本地 Hugo 构建的 Raw HTML 警告：代码/配置放入代码块，正文中的尖括号占位符改为行内代码；categories 改为 Web 正文中的 HTML/XML 片段被当作原始 HTML 丢弃；文件名/URL/标题按规范调整

GitHub 的 Personal Access Token（PAT）有两套互相独立、并列的机制：Classic 和 Fine-grained。两者各自有独立的设置页面和独立的 token 值，互不共享权限、互不影响——改了一个的 scope，对另一个没有任何作用。 对比 Classic token (ghp_...) Fine-grained token (github_pat_...) 权限粒度 粗粒度，按 scope 打勾（repo、admin:org、workflow …），一个 scope 覆盖你有权限的所有仓库/组织 细粒度，创建时指定 Resource owner（个人账号或某个具体组织），再选具体仓库（全部/指定几个），每个仓库单独授予 Contents / Administration / Issues 等权限 作用范围 只要本人对某组织/仓库有权限，token 默认就能操作（除非组织手动 Restrict） 天生绑死在创建时选的 Resource owner，只能代表操作那一个账号或组织下的资源 安全性 权限范围大，一旦泄露风险高 权限可以缩得很小，泄露影响面小，GitHub 官方推荐新场景一律用这个 过期时间 早期可选"永不过期" 设计上引导必须设置过期时间 组织侧控制 只有"全允许 / 全禁止"的粗暴开关（组织 Settings → Personal access tokens → Tokens (classic)） 组织可以看到每一个申请访问本组织资源的 fine-grained token，逐个 Approve / Deny / 撤销，可审计 Fine-grained 要解决的问题 Classic token 加 scope 解决不了几个结构性问题，这也是 GitHub 推出 fine-grained token 的原因： ...

CSRF/XSRF CSRF (Cross-site request forgery) 跨站请求伪造，也被称成为"one click attack"或者session riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本 (XSS) ，但它与XSS非常不同，并且攻击方式几乎相左。XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行 (因此对其进行防范的资源也相当稀少) 和难以防范，所以被认为比XSS更具危险性。攻击通过在授权用户访问的页面中包含链接或者脚本的方式工作。例如: 一个网站用户 Bob 可能正在浏览论坛，而同时另一个用户 Alice 也在此论坛中，并且后者刚刚发布了一个具有 Bob 银行链接的图片消息。设想一下，Alice 编写了一个在 Bob 的银行站点上进行取款的 form 提交的链接，并将此链接作为图片 tag。如果 Bob 的银行在 cookie 中保存他的授权信息，并且此 cookie 没有过期，那么当 Bob 的浏览器尝试装载图片时将提交这个取款 form 和他的 cookie，这样在没经 Bob 同意的情况下便授权了这次事务。 CSRF 是一种依赖 web 浏览器的、被混淆过的代理人攻击 (deputy attack) 。在上面银行示例中的代理人是 Bob 的 web 浏览器，它被混淆后误将 Bob 的授权直接交给了 Alice 使用。 下面是CSRF的常见特性: 依靠用户标识危害网站 利用网站对用户标识的信任 欺骗用户的浏览器发送HTTP请求给目标站点 另外可以通过IMG标签会触发一个GET请求，可以利用它来实现CSRF攻击。风险在于那些通过基于受信任的输入form和对特定行为无需授权的已认证的用户来执行某些行为的web应用。已经通过被保存在用户浏览器中的cookie进行认证的用户将在完全无知的情况下发送HTTP请求到那个信任他的站点，进而进行用户不愿做的行为。 使用图片的CSRF攻击常常出现在网络论坛中，因为那里允许用户发布图片而不能使用JavaScript。贴图只是GET的方式，很多时候我们需要伪造POST的请求。一个办法是利用跨站，当然目标站点可能不存在跨站，这个时候我们可以从第三方网站发动攻击。 比如我要攻击一个存在问题的blog，那就先去目标blog留言，留下一个网址，诱其主人点击过来 (这个就要看你的忽悠本事咯:p) ，然后构造个HTML表单提交些数据过去。 多窗口浏览器就帮了一点忙。 多窗口浏览器 (firefox、遨游、MyIE……) 便捷的同时也带来了一些问题，因为多窗口浏览器新开的窗口是具有当前所有会话的。即我用IE登陆了我的Blog，然后我想看新闻了，又运行一个IE进程，这个时候两个IE窗口的会话是彼此独立的，从看新闻的IE发送请求到Blog不会有我登录的cookie；但是多窗口浏览器永远都只有一个进程，各窗口的会话是通用的，即看新闻的窗口发请求到Blog是会带上我在blog登录的cookie。 想一想，当我们用鼠标在Blog/BBS/WebMail点击别人留下的链接的时候，说不定一场精心准备的CSRF攻击正等着我们。 前后端分离架构下还有 CSRF 风险吗 前后端分离本身不是防 CSRF 的银弹，关键要看前端如何保存和发送身份凭证。 ...

背景知识 github.com/golang-jwt/jwt Authentication 和 Authorization 的区别 Authentication: 认证，指的是验证用户的身份，例如你希望以 A 的身份登录，那么应用程序需要通过用户名和密码确认你真的是 A 。 Authorization: 授权，指的是确认你的身份之后提供给你权限，例如用户 A 可以修改数据，而用户 B 只能阅读数据。 由于 http 协议是无状态的，每一次请求都无状态。当一个用户通过用户名和密码登录了之后，他的下一个请求不会携带任何状态，应用程序无法知道他的身份，那就必须重新认证。因此我们希望用户登录成功之后的每一次 HTTP 请求，都能够保存他的登录状态。 目前主流的用户认证方法有基于 token 和基于 session 两种方式，常见的还有三种细分形态： 无状态 JWT (Stateless JWT)：包含 Session 数据的 JWT Token，Session 数据直接编码进 Token 内。 有状态 JWT (Stateful JWT)：包含 Session 引用或其 ID 的 JWT Token，Session 数据存储在服务端。 Session token（又称 Session cookie）：标准的、可被签名的 Session ID，例如各类 Web 框架 (译者注: 包括 Laravel) 内已经使用了很久的 Session 机制，Session 数据同样存储在服务端。 以上背景知识整理自 Wi1dcard 的文章，原文地址：https://learnku.com/articles/22616（版权归原作者所有，商业转载请联系作者获得授权）。 Session vs JWT 详解 以下内容整理自 chengkai 的文章《聊一聊JWT与session》，原文地址：https://juejin.cn/post/6844903542449242126（版权归原作者所有）。 ...

2014 年，我在第一家公司接到了一个非常规的项目：对一款 Android APK 做安全评估。说"非常规"，是因为那时部门的项目周期动辄两三个月到两三年，而这个只有一周。领导把任务交给我，大概是觉得我平时喜欢折腾各种新东西, 当时业余时间在研究树莓派。 背景 客户是一家制造电梯的公司，他们有一套电梯维保工单系统，安装在配发给维修工程师的 Android 平板上。工程师通过这个 APK 查看维护保养订单、处理故障报修。这个 APK 由另一家第三方公司（vendor-A）开发。 客户委托我所在的公司（vendor-H）对这个 APK 做安全评估，核心问题是：这个 APK 能不能被破解？里面内置的密钥等敏感数据能不能被提取出来？ 这本质上是一次白盒逆向测试，只是用了"安全评估"这个更正式的说法。 第一次评估：一周内出报告 拿到 APK 之后，我先去查了 Android APK 逆向的相关资料。 APK 文件本质上是一个 zip 包，解压后可以看到 classes.dex——这是 Android Dalvik 虚拟机的字节码文件，而不是标准 Java 的 .class 文件。逆向的第一步是用 dex2jar 把 classes.dex 转换成普通的 jar 包，再用 jd-gui 等 Java 反编译工具将 jar 里的 .class 文件反编译成可读的 Java 源码。具体流程可以参考我当时整理的 Android APK 反编译。 第一版 APK 虽然有一些保护措施——把部分逻辑封装成单独的 jar 包作为依赖，密钥也不是直接明文写死，而是在运行时动态加载/生成——但通过反编译拿到全部源码之后，这些都可以被分析清楚。我新建了一个 Java 工程，把 APK 里的密钥加载逻辑复制进去单独执行，成功还原出了被保护的密钥。 此外，代码里也存在硬编码的敏感信息。 第一次评估报告在一周内交付给了客户，列出了几个可被利用的安全漏洞。 第二次评估：加壳技术 几个月后，客户再次找到我们，带来了 vendor-A 升级后的新版 APK。 ...

Android APK加壳技术方案 本文章由Jack_Jia编写,转载请注明出处。 文章链接: http://blog.csdn.net/jiazhijun/article/details/8678399 作者: Jack_Jia 邮箱: 309zhijun@163.com 一、什么是加壳？ 加壳是在二进制的程序中植入一段代码,在运行的时候优先取得程序的控制权,做一些额外的工作。大多数病毒就是基于此原理。PC EXE文件加壳的过程如下: 二、加壳作用 加壳的程序可以有效阻止对程序的反汇编分析,以达到它不可告人的目的。这种技术也常用来保护软件版权,防止被软件破解。 三、Android Dex文件加壳原理 PC平台现在已存在大量的标准的加壳和解壳工具,但是Android作为新兴平台还未出现APK加壳工具。Android Dex文件大量使用引用给加壳带来了一定的难度,但是从理论上讲,Android APK加壳也是可行的。 在这个过程中,牵扯到三个角色: 加壳程序: 加密源程序为解壳数据、组装解壳程序和解壳数据 解壳程序: 解密解壳数据,并运行时通过DexClassLoader动态加载 源程序: 需要加壳处理的被保护代码 阅读该文章,需要您对DEX文件结构有所了解,您可以通过以下网址了解相关信息: http://blog.csdn.net/jiazhijun/article/details/8664778 根据解壳数据在解壳程序DEX文件中的不同分布,本文将提出两种Android Dex加壳的实现方案。 (一) 解壳数据位于解壳程序文件尾部 该种方式简单实用,合并后的DEX文件结构如下。 加壳程序工作流程: 加密源程序APK文件为解壳数据 把解壳数据写入解壳程序Dex文件末尾,并在文件尾部添加解壳数据的大小。 修改解壳程序DEX头中checksum、signature 和file_size头信息。 修改源程序AndroidMainfest.xml文件并覆盖解壳程序AndroidMainfest.xml文件。 解壳DEX程序工作流程: 读取DEX文件末尾数据获取借壳数据长度。 从DEX文件读取解壳数据,解密解壳数据。以文件形式保存解密数据到a.APK文件 通过DexClassLoader动态加载a.apk。 (二) 解壳数据位于解壳程序文件头 该种方式相对比较复杂, 合并后DEX文件结构如下: 加壳程序工作流程: 加密源程序APK文件为解壳数据 计算解壳数据长度,并添加该长度到解壳DEX文件头末尾,并继续解壳数据到文件头末尾。 (插入数据的位置为0x70处) 修改解壳程序DEX头中checksum、signature、file_size、header_size、string_ids_off、type_ids_off、proto_ids_off、field_ids_off、 method_ids_off、class_defs_off和data_off相关项。 分析map_off 数据,修改相关的数据偏移量。 修改源程序AndroidMainfest.xml文件并覆盖解壳程序AndroidMainfest.xml文件。 解壳DEX程序工作流程: 从0x70处读取解壳数据长度。 从DEX文件读取解壳数据,解密解壳数据。以文件形式保存解密数据到a.APK 通过DexClassLoader动态加载a.APK。 四、加壳及脱壳代码实现 http://blog.csdn.net/jiazhijun/article/details/8809542

加壳与脱壳 http://blog.csdn.net/lzyzuixin/article/details/4104334 加壳一般是指保护程序资源的方法. 脱壳一般是指除掉程序的保护,用来修改程序资源. 病毒加壳技术与脱壳杀毒方法 : 壳是什么？脱壳又是什么？这是很多经常感到迷惑和经常提出的问题,其实这个问题一点也不幼稚。当你想听说脱壳这个名词并试着去了解的时候,说明你已经在各个安全站点很有了一段日子了。下面,我们进入"壳"的世 界吧。 金蝉脱壳的故事 我先想讲个故事吧。那就是金蝉脱壳。金蝉脱壳属于三十六计中的混战计。金蝉脱壳的本意是: 寒蝉在蜕变时,本体脱离皮壳而走,只留下蝉蜕还挂在枝头。此计用于军事,是指通过伪装摆脱敌人,撤退或转移,以实现我方的战略目标的谋略。稳住对方,撤退或转移,决不是惊慌失措,消极逃跑,而是保留形式,抽走内容,稳住对方,使自己脱离险境达到己方战略目标,己方常常可用巧妙分兵转移的机会出击另一部分敌人。三国时期,诸葛亮六出祁山,北伐中原,但一直未能成功,终于在第六次北伐时,积劳成疾,在五丈原病死于军中。 维遵照诸葛亮的吩咐,在诸葛亮死后,秘不发丧,对外严密封锁消息。他带着灵柩,秘密率部撤退。司马懿派部队跟踪追击蜀军。姜维命工匠仿诸葛亮摸样,雕了一个木人,羽扇纶巾,稳坐车中。并派杨仪率领部分人马大张旗鼓,向魏军发动进攻。魏军远望蜀军,军容整齐,旗鼓大张,又见诸葛亮稳坐车中,指挥若定,不知蜀军又耍什么花招,不敢轻举妄动。司马懿一向知道诸葛亮"诡计多端",又怀疑此次退兵乃是诱敌之计,于是命令部队后撤,观察蜀军动向。姜维趁司马懿退兵的大好时机,马上指挥主力部队,迅速安全转移,撤回汉中。等司马懿得知诸葛亮已死,再进兵追击,为时已晚。相信这个故事,大家在大型连续剧《三国演义》里已经看过了。呵呵,只是没有理解得这么深入罢了！而在黑客入侵技术中,金蝉脱壳则是指: 删除系统运行日志 攻击者攻破系统后,常删除系统运行日志,隐藏自己的痕迹…呵呵 二、壳,脱壳,加壳 在自然界中,我想大家对壳这东西应该都不会陌生了,由上述故事,我们也可见一斑。自然界中植物用它来保护种子,动物用它来保护身体等等。同样,在一些计算机软件里也有一段专门负责保护软件不被非法修改或反编译的程序。它们一般都是先于程序运行,拿到控制权,然后完成它们保护软件的任务。就像动植物的壳一般都是在身体外面一样理所当然 (但后来也出现了所谓的"壳中带籽"的壳) 。由于这段程序和自然界的壳在功能上有很多相同的地方,基于命名的规则,大家就把这样的程序称为"壳"了。就像计算机病毒和自然界的病毒一样,其实都是命名上的方法罢了。 从功能上抽象,软件的壳和自然界中的壳相差无几。无非是保护、隐蔽壳内的东西。而从技术的角度出发,壳是一段执行于原始程序前的代码。原始程序的代码在加壳的过程中可能被压缩、加密……。当加壳后的文件执行时,壳－这段代码先于原始程序运行,他把压缩、加密后的代码还原成原始程序代码,然后再把执行权交还给原始代码。 软件的壳分为加密壳、压缩壳、伪装壳、多层壳等类,目的都是为了隐藏程序真正的OEP (入口点,防止被破解) 。关于"壳"以及相关软件的发展历史请参阅吴先生的《一切从"壳"开始》。 壳的概念 作者编好软件后,编译成exe可执行文件。 1.有一些版权信息需要保护起来,不想让别人随便改动,如作者的姓名,即为了保护软件不被破解,通常都是采用加壳来进行保护。 2.需要把程序搞的小一点,从而方便使用。于是,需要用到一些软件,它们能将exe可执行文件压缩, 3.在黑客界给木马等软件加壳脱壳以躲避杀毒软件。实现上述功能,这些软件称为加壳软件。 (二) 加壳软件最常见的加壳软件 ASPACK ,UPX,PEcompact 不常用的加壳软件WWPACK32；PE-PACK ；PETITE NEOLITE (三) 侦测壳和软件所用编写语言的软件 因为脱壳之前要查他的壳的类型。 1.侦测壳的软件fileinfo.exe 简称fi.exe (侦测壳的能力极强) 。 2.侦测壳和软件所用编写语言的软件language.exe (两个功能合为一体,很棒) ,推荐language2000中文版 (专门检测加壳类型) 。 3.软件常用编写语言Delphi,VisualBasic (VB) -最难破,VisualC (VC) 。 (四) 脱壳软件 软件加壳是作者写完软件后,为了保护自己的代码或维护软件产权等利益所常用到的手段。目前有很多加壳工具,当然有盾,自然就有矛,只要我们收集全常用脱壳工具,那就不怕他加壳了。软件脱壳有手动脱和自动脱壳之分,下面我们先介绍自动脱壳,因为手动脱壳需要运用汇编语言,要跟踪断点等,不适合初学者,但我们在后边将稍作介绍。 加壳一般属于软件加密,现在越来越多的软件经过压缩处理,给汉化带来许多不便,软件汉化爱好者也不得不学习掌握这种技能。现在脱壳一般分手动和自动两种,手动就是用TRW2000、TR、SOFTICE等调试工具对付,对脱壳者有一定水平要求,涉及到很多汇编语言和软件调试方面的知识。而自动就是用专门的脱壳工具来脱,最常用某种压缩软件都有他人写的反压缩工具对应,有些压缩工具自身能解压,如UPX；有些不提供这功能,如: ASPACK,就需要UNASPACK对付,好处是简单,缺点是版本更新了就没用了。另外脱壳就是用专门的脱壳工具来对付,最流行的是PROCDUMP v1.62 ,可对付目前各种压缩软件的压缩档。在这里介绍的是一些通用的方法和工具,希望对大家有帮助。我们知道文件的加密方式,就可以使用不同的工具、不同的方法进行脱壳。下面是我们常常会碰到的加壳方式及简单的脱壳措施,供大家参考: 脱壳的基本原则就是单步跟踪,只能往前,不能往后。脱壳的一般流程是: 查壳->寻找OEP->Dump->修复 找OEP的一般思路如下: 先看壳是加密壳还是压缩壳,压缩壳相对来说容易些,一般是没有异常,找到对应的popad后就能到入口,跳到入口的方式一般为。 我们知道文件被一些压缩加壳软件加密,下一步我们就要分析加密软件的名称、版本。因为不同软件甚至不同版本加的壳,脱壳处理的方法都不相同。 常用脱壳工具: 文件分析工具 (侦测壳的类型) : Fi,GetTyp,peid,pe-scan, OEP入口查找工具: SoftICE,TRW,ollydbg,loader,peid dump工具: IceDump,TRW,PEditor,ProcDump32,LordPE PE文件编辑工具PEditor,ProcDump32,LordPE ...

bitwarden auto fill Chrome extension> bitwarden> settings> option> autofill> enable auto-fill on page load podman server https://hub.docker.com/r/vaultwarden/server # docker pull vaultwarden/server:1.33.2-alpine podman pull vaultwarden/server:1.35.2-alpine podman run -d --name bitwarden -v bitwarden-data:/data/ -p 8000:80 docker.io/vaultwarden/server:latest docker run -d --name bitwarden --restart=always -v bitwarden-data:/data/ -p 8000:80 vaultwarden/server:1.28.1-alpine 测试一下，直接用浏览器访问 80 端口应该能看到 bitwarden 的登录页面，注册用户的话会被要求通过 https 访问。 client Linux (Arch): pacman -S bitwarden macOS (Homebrew): 桌面应用： brew install --cask bitwarden 命令行工具（CLI）： brew install bitwarden-cli bitwarden ssh key, bw-key download bw-key from https://github.com/haipengno1/bw-key/releases ...

selinux 临时关闭 selinux # 查询 selinux 状态 sestatus # 临时关闭selinux setenforce 0 永久关闭 SELinux vim /etc/selinux/config 把 #SELINUX=enforcing 改成 SELINUX=disabled https://www.ibm.com/developerworks/cn/linux/l-secure-linux-ru/index.html http://okeeper.leanote.com/post/CentOS7%E4%B8%AD%E5%85%B3%E9%97%ADselinux https://my.oschina.net/oaoa/blog/185833 SELinux 初探 在进入了 CentOS 5.x 之后,SELinux 已经是个非常完备的核心模块了！CentOS 5.x 提供了很多管理 SELinux 的命令与机制, 因此在整体架构上面比以前的版本要单纯且容易操作管理！所以,在这一版以后,我们建议大家千万不要关掉 SELinux 这玩意儿！ 让我们来仔细的玩玩这家伙吧！ 小标题的图示什么是 SELinux 什么是 SELinux 呢？其实他是『 Security Enhanced Linux 』的缩写,字面上的意义就是安全强化的 Linux 之意！那么所谓的『安全强化』是强化哪个部分？ 是网络资安还是权限管理？底下就让我们来谈谈吧！ 当初设计的目标: 避免资源的误用 SELinux 是由美国国家安全局 (NSA) 开发的,当初开发这玩意儿的目的是因为很多企业界发现, 通常系统出现问题的原因大部分都在於『内部员工的资源误用』所导致的,实际由外部发动的攻击反而没有这么严重。 那么什么是『员工资源误用』呢？举例来说,如果有个不是很懂系统的系统管理员为了自己配置的方便,将网页所在目录 /var/www/html/ 的权限配置为 drwxrwxrwx 时,你觉得会有什么事情发生？ 现在我们知道所有的系统资源都是透过程序来进行存取的,那么 /var/www/html/ 如果配置为 777 , 代表所有程序均可对该目录存取,万一你真的有启动 WWW 服务器软件,那么该软件所触发的程序将可以写入该目录, 而该程序却是对整个 Internet 提供服务的！只要有心人接触到这支程序,而且该程序刚好又有提供使用者进行写入的功能, 那么外部的人很可能就会对你的系统写入些莫名其妙的东西！那可真是不得了！一个小小的 777 问题可是大大的！ ...

加密哈希函数 SHA256，SHA512，RipeMD， WHIRLPOOL， Bcrypt wiloon.com/bcrypt 什么是密码哈希函数？ A 密码哈希函数 是一组散列函数之一，适用于SSL /TLS。 像其他哈希函数一样，密码哈希函数是一种单向数学算法，用于将任何大小的数据映射到固定大小的位字符串。 加密哈希函数广泛用于信息安全实践中，例如数字签名，消息身份验证代码和其他形式的身份验证。 加密哈希函数应具有以下属性 (来源： 维基百科): 1.相同的消息始终导致相同的哈希值 (即，函数为 确定性). 2.快速计算哈希值。 3.具有相同散列值的两个消息 (称为“冲突”）是不可行的。 4.故意创建产生给定哈希值的消息是不可行的。 5.对消息的轻微更改应在很大​​程度上更改所得的哈希值，以使其看起来与原始哈希不相关。 最常用的加密哈希函数包括MD5，SHA-1和SHA-2。 每个哈希的唯一性对于密码哈希功能的完整性至关重要。 这才是真正将密码哈希函数与其他哈希函数区分开的地方-确保以唯一且不可复制的方式识别特定消息。 数字签名方案 (例如 文件签署, 代码签名或 S/MIME 邮箱地址）通常要求对消息进行加密哈希计算并包含在签名中。 然后，收件人的软件将独立计算哈希值，以验证邮件的完整性。 网站还经常发布可下载文件的哈希值。 用户下载文件时，可以使用自己的软件独立计算哈希值，从而验证文件的完整性。 密码安全性还依赖于加密哈希。 用户提供的密码被散列，然后与存储的散列进行比较。 加密哈希函数广泛用于安全协议，例如 SSL /TLS 和SSH，以及其他依赖数据完整性的应用程序。 加密货币使用哈希算法来使用新的安全可验证交易数据块更新区块链。 (例如，BitCoin使用SHA-2进行交易验证。） 什么是SHA-1？ SHA-1 (安全哈希算法1） 是一种加密哈希函数，可以将任意长的数据字符串转换为固定大小为160位的摘要。 该摘要通常显示为40个字符的十六进制数字。 SHA-1算法现已推出 被认为是不安全的。 SHA-1证书不再符合CA / B论坛基准要求，或不再受当前主要Web浏览器版本的支持。 安全哈希算法 (SHA）系列哈希函数由不同的集合 (SHA-0，SHA-1，SHA-2，SHA-3）组成。 什么是SHA-2？ SHA-2 (安全哈希算法2） “加密”是指可以将任意长数据串转换为固定大小 (224、256、384或512位）摘要的加密哈希函数系列。 256位SHA-2，也称为 SHA-256，是最常用的版本。 摘要通常显示为固定值的十六进制数。 (例如，SHA-256返回64个字符的代码。） SHA-2在安全协议 (例如SSL /TLS. 查表法 查表法对于破解一系列算法相同的哈希值有着无与伦比的效率。主要的思想就是预计算密码字典中的每个密码，然后把哈希值和对应的密码储存到一个用于快速查询的数据结构中。一个良好的查表实现可以每秒进行数百次哈希查询，即使表中储存了几十亿个哈希值。 ...