Linux4.14的设备树下已经对itop4412做了支持,本来应该很容易进行移植,可是在使用讯为给的资料中,对exynos4412-itop-scp-core.dtsi中原本的代码全部进行了注释,并自己添加了部分节点.导致我移植完成后cpu只有一个核心在工作. 于是重新到linux官网下载源码得到exynos4412-itop-scp-core.dtsi文件,编译烧写后发现卡在 Starting kernel ... Uncompressing Linux... done, booting t

在"linux lcd设备驱动剖析二"文章中,我们详细分析了s3c24xxfb_probe函数. 文章链接:http://blog.csdn.net/lwj103862095/article/details/18189765 s3c2410fb.c中s3c24xxfb_probe是非常重要的函数之一,但仅仅分析probe函数,貌似感觉有点不够过瘾,貌似缺少分析了一个非常重要的成员.在probe函数中有一句:fbinfo->fbops   = &s3c2410fb_ops;

先说说开发环境吧: 1 内核:linux2.6.xx 2 uboot:买开发板带的 注释:在最后我又添加了问题得到完美解决的办法. 问题:uboot启动完成,kernel启动时lcd屏幕出现杂色(比如:下半屏出现红色等 ) 分析原因:造成这个问题的原因可能是因为uboot启动完成,lcd显示缓冲区内有其 他数据,而这时kernel启动还未完成lcd相关初始化,还未向缓冲器写数据造成的 . 解决办法:在uboot完成启动内核的结尾,关闭lcd(也就是把背光关了),再在内 核启动时lcd初始化中把l

在上一篇文章<驱动开发:内核中实现Dump进程转储>中我们实现了ARK工具的转存功能,本篇文章继续以内存为出发点介绍VAD结构,该结构的全程是Virtual Address Descriptor即虚拟地址描述符,VAD是一个AVL自平衡二叉树,树的每一个节点代表一段虚拟地址空间.程序中的代码段,数据段,堆段都会各种占用一个或多个VAD节点,由一个MMVAD结构完整描述. VAD结构的遍历效果如下: 那么这个结构在哪?每一个进程都有自己单独的VAD结构树,这个结构通常在EPROCESS结构里面里

在上一章<驱动开发:内核LDE64引擎计算汇编长度>中,LyShark教大家如何通过LDE64引擎实现计算反汇编指令长度,本章将在此基础之上实现内联函数挂钩,内核中的InlineHook函数挂钩其实与应用层一致,都是使用劫持执行流并跳转到我们自己的函数上来做处理,唯一的不同的是内核Hook只针对内核API函数,但由于其身处在最底层所以一旦被挂钩其整个应用层都将会受到影响,这就直接决定了在内核层挂钩的效果是应用层无法比拟的,对于安全从业者来说学会使用内核挂钩也是很重要. 挂钩的原理可以总结为,通

最近需要对Linux的一个内核模块进行调整实验,故决定先在虚拟机中完成编译调试工作,最后再在真实的系统上进行测试.为了防止遗忘,把过程记录于此. 1. 准备系统环境 首先从官网下载最新版的VirtualBox和Debian Wheezy 7.3.0的32位网络安装版CD镜像文件(debian-7.3.0-i386-netinst.iso).然后就可以载入光盘开始安装了,安装的时候有几点需要注意: 选择语言.地区的时候,最好选择English / Hong Kong,如果选择中文则可能会出现乱码

linux 4.9内核,bbr的带宽估计问题. 一个正常的bbr流量图: 对应的ttl图形: 一个异常的bbr流量图: 可以看出,异常的bbr流量图,出现了一个很低的带宽,且稳定在这个带宽10s左右,而正常情况下,这个文件下载不应该超过10s,由于流量消耗大于流量的下载,导致了用户播放卡顿. 通过分析,我们确认了bbr在应对delay_ack时,出现带宽估计偏低的情况,比如正常的min_rtt是1.3ms,但是delay_ack的时候,是40ms左右,而由于probe_rtt需要10秒之后进行,

下图简单描述了网卡驱动与Linux内核之间的联系: 关于上图的一些说明: 系统初始化: 1. 协议模块调用 dev_add_pack() 来注册协议处理函数到链表 &ptype_base: 2. __init br_init() 用于初始化桥接相关的操作: 3. __init net_dev_init() 初始化了两个软中断: 网卡驱动初始化: 1. 网卡驱动在其 probe() 函数里面初始化 net_device 结构体,用来描述网卡,以及提供操作网卡的接口: 配置网卡: 1. 当我们通过i

s3c2440 lcd驱动源码文件是:drivers/video/s3c2410fb.c 看驱动源码首先当然是先看入口函数,这里是s3c2410fb_init函数 [cpp] view plain? int __init s3c2410fb_init(void) { /* 注册一个s3c2410fb_driver平台驱动 */ int ret = platform_driver_register(&s3c2410fb_driver); if (ret == 0) ret = platform_d

[STM8L]基于STM8L152的TAB段式LCD液晶驱动的分析 - 单片机干货 - 中国电子技术论坛 - 最好最受欢迎电子论坛!.md 主控芯片为STM8L152C4T6自带LCD控制器,低功耗系列,最近公司用到这个芯片,第一次接触STM8,刚毕业第一次做产品,也算是满成功的,发个帖纪念一下, 顺便记录一下自己学习段式LCD的过程,在查找段式LCD工作资料的过程中,确实有几篇好的博客,给了很大的帮助,但是仍然觉得不够详细,希望这次分析能够帮助到大家.首先看STM8的LCD控制器的两个关键寄存

在上一篇博文<驱动开发:内核通过PEB得到进程参数>中我们通过使用KeStackAttachProcess附加进程的方式得到了该进程的PEB结构信息,本篇文章同样需要使用进程附加功能,但这次我们将实现一个更加有趣的功能,在某些情况下应用层与内核层需要共享一片内存区域通过这片区域可打通内核与应用层的隔离,此类功能的实现依附于MDL内存映射机制实现. 应用层(R3)数据映射到内核层(R0) 先来实现将R3内存数据拷贝到R0中,功能实现所调用的API如下: IoAllocateMdl 该函数用于创建

多数ARK反内核工具中都存在驱动级别的内存转存功能,该功能可以将应用层中运行进程的内存镜像转存到特定目录下,内存转存功能在应对加壳程序的分析尤为重要,当进程在内存中解码后,我们可以很容易的将内存镜像导出,从而更好的对样本进行分析,当然某些加密壳可能无效但绝大多数情况下是可以被转存的. 在上一篇文章<驱动开发:内核R3与R0内存映射拷贝>介绍了一种方式SafeCopyMemory_R3_to_R0可以将应用层进程的内存空间映射到内核中,要实现内存转储功能我们还是需要使用这个映射函数,只是需要在此

在笔者上一篇文章<驱动开发:内核枚举IoTimer定时器>中我们通过IoInitializeTimer这个API函数为跳板,向下扫描特征码获取到了IopTimerQueueHead也就是IO定时器的队列头,本章学习的枚举DPC定时器依然使用特征码扫描,唯一不同的是在新版系统中DPC是被异或加密的,想要找到正确的地址,只是需要在找到DPC表头时进行解密操作即可. DPC定时器的作用: 在内核中可以使用DPC定时器设置任意定时任务,当到达某个节点时自动触发定时回调,定时器的内部使用KTIMER对象

在上一篇文章<驱动开发:内核枚举DpcTimer定时器>中我们通过枚举特征码的方式找到了DPC定时器基址并输出了内核中存在的定时器列表,本章将学习如何通过特征码定位的方式寻找Windows 10系统下面的PspCidTable内核句柄表地址. 首先引入一段基础概念: 1.在windows下所有的资源都是用对象的方式进行管理的(文件.进程.设备等都是对象),当要访问一个对象时,如打开一个文件,系统就会创建一个对象句柄,通过这个句柄可以对这个文件进行各种操作. 2.句柄和对象的联系是通过句柄表来进

在笔者上一篇文章<驱动开发:内核特征码搜索函数封装>中为了定位特征的方便我们封装实现了一个可以传入数组实现的SearchSpecialCode定位函数,该定位函数其实还不能算的上简单,本章LyShark将对特征码定位进行简化,让定位变得更简单,并运用定位代码实现扫描内核PE的.text代码段,并从代码段中得到某个特征所在内存位置. 老样子为了后续教程能够继续,先来定义一个lyshark.h头文件,该头文件中包含了我们本篇文章所必须要使用到的结构体定义,这些定义的函数如果不懂请去看LyShark

在笔者之前的文章<驱动开发:内核特征码搜索函数封装>中我们封装实现了特征码定位功能,本章将继续使用该功能,本次我们需要枚举内核LoadImage映像回调,在Win64环境下我们可以设置一个LoadImage映像加载通告回调,当有新驱动或者DLL被加载时,回调函数就会被调用从而执行我们自己的回调例程,映像回调也存储在数组里,枚举时从数组中读取值之后,需要进行位运算解密得到地址. 我们来看一款闭源ARK工具是如何实现的: 如上所述,如果我们需要拿到回调数组那么首先要得到该数组,数组的符号名是Psp

在笔者上一篇文章<驱动开发:内核枚举LoadImage映像回调>中LyShark教大家实现了枚举系统回调中的LoadImage通知消息,本章将实现对Registry注册表通知消息的枚举,与LoadImage消息不同Registry消息不需要解密只要找到CallbackListHead消息回调链表头并解析为_CM_NOTIFY_ENTRY结构即可实现枚举. 我们来看一款闭源ARK工具是如何实现的: 注册表系统回调的枚举需要通过特征码搜索来实现,首先我们可以定位到uf CmUnRegisterCa

在笔者上一篇文章<驱动开发:内核枚举Registry注册表回调>中我们通过特征码定位实现了对注册表回调的枚举,本篇文章LyShark将教大家如何枚举系统中的ProcessObCall进程回调以及ThreadObCall线程回调,之所以放在一起来讲解是因为这两中回调在枚举是都需要使用通用结构体_OB_CALLBACK以及_OBJECT_TYPE所以放在一起来讲解最好不过. 我们来看一款闭源ARK工具是如何实现的: 首先我们需要定义好结构体,结构体是微软公开的,如果有其它需要请自行去微软官方去查.

在笔者上一篇文章<驱动开发:内核注册并监控对象回调>介绍了如何运用ObRegisterCallbacks注册进程与线程回调,并通过该回调实现了拦截指定进行运行的效果,本章LyShark将带大家继续探索一个新的回调注册函数,PsSetLoadImageNotifyRoutine常用于注册LoadImage映像监视,当有模块被系统加载时则可以第一时间获取到加载模块信息,需要注意的是该回调函数内无法进行拦截,如需要拦截则需写入返回指令这部分内容将在下一章进行讲解,本章将主要实现对模块的监视功能. 监

在笔者上一篇文章<驱动开发:内核监视LoadImage映像回调>中LyShark简单介绍了如何通过PsSetLoadImageNotifyRoutine函数注册回调来监视驱动模块的加载,注意我这里用的是监视而不是监控之所以是监视而不是监控那是因为PsSetLoadImageNotifyRoutine无法实现参数控制,而如果我们想要控制特定驱动的加载则需要自己做一些事情来实现,如下LyShark将解密如何实现屏蔽特定驱动的加载. 要想实现驱动屏蔽其原理很简单,通过ImageInfo->Im

在笔者前一篇文章<驱动开发:内核枚举Registry注册表回调>中实现了对注册表的枚举,本章将实现对注册表的监控,不同于32位系统在64位系统中,微软为我们提供了两个针对注册表的专用内核监控函数,通过这两个函数可以在不劫持内核API的前提下实现对注册表增加,删除,创建等事件的有效监控,注册表监视通常会通过CmRegisterCallback创建监控事件并传入自己的回调函数,与该创建对应的是CmUnRegisterCallback当注册表监控结束后可用于注销回调. CmRegisterCallb