13 dog250

尚未进行身份认证

我要认证

暂无相关简介

等级
TA的排名 7

多线程并发编程的基本问题

这是个老掉牙的话题,但基本上绝大多数的讨论都跑偏了。绝大多数讨论的核心在于 如何设计一把锁来同步共享变量的访问。 这事实上完全是本末倒置:我们需要设计的一个立交桥,而不是为了设计一个红绿灯!事实上,多线程编程就不应该访问共享变量,如果真的要在多线程访问共享变量,唯一高效的方案就是 严格控制时序。 嗯,先来后到是唯一的方法。至于说设计这样那样的锁,那完全是惰政,只是为了防止出问题而已。早在100多年前,就可以在同一根电话线上传输不同的话路,这得益于严格的时隙分配和复用机制,后来时代进步了,事情反而

2020-10-03 11:40:55

周末说说二叉树之重构

老师在讲这个根据前序,中序的结果重建二叉树的时候,事实上是给出了流程图的,但递归的方法更简单:然后看看left和right的构造就行了:那么代码是不是也很简单呢:struct node *rebuild(int *Preorder, int *Inorder, int StartPre, int EndPre, int StartMid, int EndMid){ struct node *root; int distance; if (StartPre > EndPre || S

2020-09-26 08:37:58

通过一个小实验认识Linux vDSO

这里不再解释vDSO的概念,而直接谈其意义:vDSO类似一个信息公告板,用户可以直取所需,而无需为此办理任何手续。vDSO相当于内核直接暴露出来的一个C库,作为GLIBC的补充。…类似gettimeofday之类的调用,每次都陷入内核去拿一个时间戳,显得有点昂贵了,不如内核把时间戳放在一个公共的可以暴露给任何用户的地方,用户自己去看就行了,这是vDSO的典型用例。为了简单化描述,我们关闭ASLR:[root@localhost ~]# sysctl -w kernel.randomize.

2020-09-26 06:52:28

spin_lock_bh想到的一些事

近日有人问我为什么在PREROUTING这个NF HOOK点的function里需要使用spin_lock/unlock_bh而不是spin_lock/unlock来保护临界区。面对这个问题,有点懵,说到spin_lock族,有很多系列接口:spin_lock/spin_unlockspin_lock_bh/spin_unlock_bhspin_lock_irq/spin_unlock_irqspin_lock_irqsave/spin_unlock_irqrestore…之所以有这么多,

2020-09-24 22:39:23

修改Linux的swap空间实现进程注入

连续两夜的大雨,舒服,下班回到家继续杂耍。昨晚杂耍了一把/proc/$pid/mem,写了一个关于进程代码注入的文章:https://blog.csdn.net/dog250/article/details/108618568这个方法无非还是利用了内核导出到procfs里的一个mem文件,而且幸亏它可写!这并不是一个通用的方法,至于说ptrace,stap这种,则更多的体现为一种工具,而非手艺。swap空间够通用了吧,哪个系统都有,它是现代操作系统的基础设施的重要组成部分,本文就拿swap空间开涮。

2020-09-17 22:35:03

ROP(Return Oriented Programming)原理解析

先看一个代码:#include <stdio.h>#include <stdlib.h>// 下面的dummy_libc_part1和dummy_libc_part2假设是GLIBC库里的任意两段函数void dummy_libc_part1(){ // ... 这里可能会有别的指令 __asm("mov 0(%rsp), %rdi"); __asm("popq %r13"); __asm("call *%r14"); __asm("ret"); // ...

2020-09-17 00:05:26

修改任意Linux进程地址空间实施代码注入

提到进程注入,常规的方案就是使用ptrace,其POKEDATA,POKETEXT命令选项单从名字上就知道是干什么的,这里不再赘述。然而ptrace是个系统化的东西,太复杂,不适合玩手艺,有没有什么适合手工玩的东西呢?当然有!正如读写/dev/mem可以手工完成crash+gdb的功能hack内核一样,每一个用户态进程也有一个mem文件,即 /proc/$pid/mem 。我不敢保证每一个系统该文件都可写,但一旦它可写就好玩了。/proc/$pid/mem文件抽象的一个进程的地址空间,直接写该文

2020-09-16 23:44:29

Linux第一人称侵入进程的好地方

我发现很多hack把戏用惯了下面的伎俩:t = find_taskmodify(t)...这一看就是以第三人称实施动作的。为什么不以第一人称来折腾呢,这不更好隐藏自己并栽赃给运维吗?只要把__schedule().return给hook了,那便是第一人称了,任何进程都要经过此地。这种方法更简单。作为一个例子,请看:https://blog.csdn.net/dog250/article/details/108089212再次重申,绝大部分人即便是给了他们root权限,他们能做的事情依然有限

2020-09-13 10:16:02

TCP的SYN报文可以携带payload吗?

对于敲门服务,是不是厌倦了复杂繁琐的服务端配置?Send TCP SYN packet with payload?众所周知,TCP的SYN报文是不能携带payload的,因为:序列号还没有协商号,无法确定数据的序列号区间。接收窗口还没有确定,不知道payload能不能被接收。…等等,等等…烦透了!在过程中,我非常讨厌去讨论标准,讨厌有人在耳旁叨叨类似“RFC规定…但没有强制…”,“Intel手册XXX…但是…”,正如“C语言未初始化的变量到底是多少”这个问题一样无趣。实际动手试一下不

2020-09-12 08:27:57

制作一枚有针对性的fork炸弹

恕我不再赘述bash实现的fork炸弹。我们看看把一个内部调用了fork的平常的程序制作成一枚fork炸弹是多么的简单。先看代码:#include <stdio.h>#include <stdlib.h>int main(int argc, char **argv){ if (fork() == 0) { printf("I am child\n"); exit(0); } printf("I am parent\n"); return 0

2020-09-09 22:06:28

用nf_conntrack代替ipset搭建敲门验证程序

昨天晚上,杂耍了一个敲门服务:https://blog.csdn.net/dog250/article/details/108479651这里面的trick在于利用了TCP的重传特性:第一个把padding了认证数据,仅用于敲门,注定被丢弃。第二个重传包直接通过第一个敲门包敲开的大门,建立连接。我在服务端使用的是ipset的方案,还是比较清晰的,我觉的不错。早上起来,又思考了另一种方案,基于nf_conntrack来完成,毕竟我玩conntrack玩得那么熟,不拿出来杂耍两下子,总觉得虚度了

2020-09-09 19:43:21

利用TCP重传机制来玩端口敲门服务

TCP无法在连接建立之前进行认证,对于无连接的UDP而言,或者也将不能。TCP有fastopen机制,但并不好用,本文的想法就是基于fastopen的,让第一个SYN包携带数据,然而又不能让它到达TCP层,必须在IP层完成认证。于是顺势就有了所谓的敲门服务。敲门的意义旨在避免非法连接的干扰,一来二去的,即便构不成DoS,服务端也需要对非法连接的客户端进行回应,这不但不安全,暴露了开放端口信息,也浪费了带宽资源。互联网是一个开放的环境, 不要与陌生人说话! 默默地丢掉非法连接比回复一个RST要好很

2020-09-09 00:04:58

如何使用ftrace实时获取系统中的spinlock快照

接上文:https://blog.csdn.net/dog250/article/details/108349046在这篇文章中,我给出了一个拯救panic的方法,其目的更多的是恶作剧性质。但仍然有不足,请看下面代码段中的注释:void stub_panic(const char *fmt, ...){ ... local_irq_enable(); // 这个时候如果current持有自旋锁,那可怎么办??? printk("rq:%d %d\n", preempt_cou

2020-09-03 19:50:50

手工拯救Linux kernel panic!

有的时候,kernel panic并不一定非要真的panic,比如说你自己模块里发生了内存违规访问,在你确定发生panic的地方并不会影响整个内核,其危害半径足以收敛的前提下,panic可以有不同的行为:直接将当前task给schedule出去。虽然在中断上下文这样做可能会危害无辜的进程,使其再也调度不回来了,但也总比整体重启要好。下面的代码展示了如何做:// panic_resched.c#include <linux/module.h>#include <linux/k

2020-09-01 23:34:26

10行代码玩转弹性调度的小把戏

Linux的进程调度器是通用的调度器,无论是O(n)O(n)O(n),O(1)O(1)O(1),还是CFS,均是基于统一的指标来对待所有进程的。也就是说,进程甚至无法自主退让。只要确定了一个进程的优先级,无论是是什么调度算法,该进程的地位总是不会变化,如果能做到下面的策略就好了:系统中进程多了,就加速退让。系统中进程少了,就加速抢占。工人来了,就退让。经理来了,就抢占。…考虑一个进程A在一个特定的系统中运行,它最多只能用40%的CPU,此时,如果有另外的待运行进程,那么这些进程自然分摊另外

2020-08-29 11:24:47

缉拿隐藏进程以及隐藏CPU利用率的进程

前面我介绍过很多隐藏进程的把戏,随后我对每一种把戏有针对性的给出了反制措施,可以翻看我2020/03~2020/08的文章,太多了,不再一一列举。如今,我要介绍一种超级简单的手段,手艺人必备。无论你是隐藏了进程,还是隐藏了进程的CPU利用率,只要它在CPU上运行,在下面的脚本面前,任何隐藏手段终归徒劳:#!/usr/local/bin/stapglobal tbaseglobal tdeltaprobe scheduler.cpu_on{ a = gettimeofday_us() t

2020-08-26 23:04:38

systemtap引用自定义头文件的手艺精简版

先看上一篇:https://blog.csdn.net/dog250/article/details/108230157不够精简是不是?那是因为我的水平还不够6,其实stap是可以直接调用system来执行外部命令的,如此就不需要再进入guru模式来stap自己了。脚本如下:#!/usr/local/bin/stap// selftapprobe process("/usr/local/bin/stap").function("make_any_make_cmd"){ ext = "\'E

2020-08-26 22:22:31

systemtap引用自定义头文件的手艺

自从写第一个guru模式的stap脚本,我就再也不写内核模块了。stap简直太方便了,竟然可以将C语言当脚本语言来玩。随着我写的stap脚本越来越复杂,我需要使用一些半吊子设计模式来让代码更好看些,比如我不会再将所有东西写在一个stap脚本里,我会将一些公共的结构体定义,宏定义写在一个头文件里:// common.h#define VAR 100然后在我的stap脚本里引用它们就是了:#!/usr/local/bin/stap -g// aa.stp#!/usr/local/bin/stap

2020-08-25 23:41:48

揭穿恶作剧重建TCP连接和进程之间的关联

是时候将把戏揭穿了。请先阅读下文:https://blog.csdn.net/dog250/article/details/108113329依照文章中所描述的把戏,我们hack一下两个进程的tcp连接的归属,首先给出hack之前的情景:[root@localhost ~]# netstat -ntpActive Internet connections (w/o servers)Proto Recv-Q Send-Q Local Address Foreign Addres

2020-08-21 08:12:14

制造恶作剧切断TCP连接和进程之间的关联

想不想再玩个恶作剧??很多运维发现系统中有tcp连接异常的时候,会使用netstat/ss命令找出tcp连接对应的处理进程,然后去找研发debug这个进程。比如:[root@localhost ~]# netstat -ntpActive Internet connections (w/o servers)Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program namet

2020-08-20 21:53:09

查看更多

CSDN身份
  • 博客专家
勋章 我的勋章
  • GitHub
    GitHub
    绑定GitHub第三方账户获取
  • 技术圈认证(专家版)
    技术圈认证(专家版)
    博客专家完成年度认证,即可获得
  • 持之以恒
    持之以恒
    授予每个自然月内发布4篇或4篇以上原创或翻译IT博文的用户。不积跬步无以至千里,不积小流无以成江海,程序人生的精彩需要坚持不懈地积累!
  • 1024超级勋章
    1024超级勋章
    授予原创文章总数达到1024篇的博主,感谢你对CSDN社区的贡献,CSDN与你一起成长。
  • 勤写标兵Lv4
    勤写标兵Lv4
    授予每个自然周发布9篇以上(包括9篇)原创IT博文的用户。本勋章将于次周周三上午根据用户上周的博文发布情况由系统自动颁发。
  • 原力计划专属勋章
    原力计划专属勋章
    2019年《原力计划【第一季】》专属勋章,现已经开启第二季活动啦,小伙伴们快去参加吧
  • 学习力
    学习力
    《原力计划【第二季】》第一期主题勋章 ,第一期活动已经结束啦,小伙伴们可以去参加第二期打卡挑战活动获取更多勋章哦。
  • 原力新人
    原力新人
    在《原力计划【第二季】》打卡挑战活动中,成功参与本活动并发布一篇原创文章的博主,即可获得此勋章。
  • 原力探索 · S
    原力探索 · S
    在《原力计划【第二季】》打卡挑战活动中,发布 12 篇原创文章参与活动的博主,即可获得此勋章。(本次活动结束后统一统计发放)
  • 1024达人勋章
    1024达人勋章
    10月24日粉丝/获赞/评论/收藏累计达到1024,即可获得“1024达人”勋章
  • 分享小兵
    分享小兵
    成功上传3个资源即可获取