rest_framework.responseDRF常用序列化类主要有
rest_framework.serialziers.Serializerrest_framework.serialziers.ModelSerializerrest_framework.serialziers.ListSerializer本篇介绍rest_framework.serialziers.Serializer
rest_framework.responserest_framework.exceptionsAPIView视图类产生的异常，都可以提供异常处理方案rest_framework.views.exception_handler，但是处理范围有限通常出于一些原因我们需要自定义异常处理，而非使用DRF的默认异常。
自定义异常处理的常见应用场景如下：
rest_framework.parsers用DRF做测试会发现，用浏览器请求API返回DRF定制的页面，对开发者相当友好，如下图：
而若使用python第三方模块requests或者postman等工具，这则返回的是原生的json数据。
实现这种差别响应的，正是本节的主角——(响应)渲染模块。
rest_framework.renders
rest_framework.request.Request：主要类urls.py，走as_view方法，但是视图类没有该方法，所以请求走的是APIView的as_view方法APIView的as_view调用父类(django原生View)的as_view，同时还禁用了 csrf 认证as_view中dispatch方法请求走的又是APIView的dispatch
APIView也可以走dispatch，视图类是先继承APIView，APIView中没有再去原生View中因此直接从APIView的dispatch入口看源码。
rest_framework.request
rest_framework.request.Request：主要类前后端分离是大势所趋
最近在学习Django Rest Framework，官方教程较短，看完感觉并没有学习到最佳实践，对DRF的了解还是不成体系。官方API文档虽然详细一些，但内容多且零散更适合查阅，对于系统性学习来说还是差了一点。
于是找到了一套不错的DRF源码分析视频来学习，并且在这里记下学习笔记。
参考了这两位同学的笔记，大部分是视频讲师在视频里做过的课堂笔记。
根据我个人理解对笔记做了部分修改、整理和补充。这里有我的测试代码可供参考，包括django项目、db数据和postman的测试数据包。
Dark Mode —— 中老年程序🐶的眼睛续命必备功能
Mac、Win 纷纷推出了 Dark Mode，安卓也原生支持了随着夜幕降临自动调整屏幕亮度（蓝光）的功能，看来保护眼睛、关爱程序猿是大势所趋。
这里，我们尝试了3种使Hexo Next主题切换为darkmode的方式。
几年没有碰Blog，最近打算重新开始写，因此需要更新hexo以及Next主题。
由于不怎么懂前端，不出意外意外地遇到了一堆坑，这里记录一下：
v6.17.1 => v13.7.0v3.2.x => v4.2.0v4.x => v7.8.0我的系统使用nvm管理多版本node，首先更新npm：
1 | npm install -g npm |
清除npm缓存，可能需要 sudo
1 | npm cache clean -f |
本菜谱是根据「下厨房」菜谱「毛豆肉丁炒茄子」 改进而来。
改进后的菜谱在食材中去掉了茄丁，用胡萝卜丁替换，因茄丁按照原菜谱的处理方式仍比较吸盐，且原菜谱中处理茄丁不像烹制肉末茄子那样会使用过量油煎透，这会导致最终烹制的茄丁带有些许生茄特有的腥味。
后续佐料以及烹制方法也有较大改动，具体见新菜谱。
学习炒菜已两月有余，觉得有些普适性的经验值得总结，便在此记录一下。
本篇总结一下不同食材的吸盐度。
一道菜通常由多种食材混合烹制而成，其咸味轻重会直接影响口感。不同食材对盐的吸收能力不尽相同，因此较好地平衡不同食材的咸度是佳作的重要因素之一。但网上绝大多数菜谱或教程很少考虑这一点，大多数菜谱都是在所有食材都已入锅且烹制即将完成前放入盐的，这容易造成一道菜最终由于不同食材咸淡不均而影响口感。
堆管理系统的三类操作：堆块分配、堆块释放和堆块合并归根结底都是堆链表的修改。例如，分配就是将堆块从空表中“卸下”；释放是把堆块“链入”空表；合并稍微复杂点，但也可以看成是把若干个堆块先从空表中“卸下”，修改块首信息（大小），之后把更新的新块“链入”空表。
所有“卸下”和“链入”堆块的工作都发生在链表，如果我们能伪造链表结点的指针，在“卸下”和“链入”的过程中就有可能获得一次读写内存的机会。
堆溢出利用的精髓就是用精心构造的数据去溢出下一个堆块的块首，改写块首中的前向指针(flink)和后向指针(blink)，然后再分配、释放、合并等操作发生时伺机获得一次向内存任意地址写入任意数据的机会。
我们把这种能够向内存任意位置写入任意数据的机会成为”DWORD SHOOT“。注意：DWORD SHOOT发生时，我们不但可以控制射击的目标（任意地址），还可以选用适当的子弹（4字节恶意数据）。
这里举一个例子来说明链表操作中DWORD SHOOT究竟是怎样发生的。将一个结点从双向链表中“卸下”的函数很可能是类似这样的。
最近在啃《0day安全：软件漏洞分析技术》（第二版）一书，打算入门二进制漏洞分析。书中第五章“堆溢出利用”较前几章难度有所增大，原因在于堆结构较之前学习的栈更复杂，第五章中的例子涵盖了堆的分布、堆块分配和释放、堆溢出利用，利用堆溢出进行攻击的例子是通过修改P.E.B（进程环境块）中指向RtlEnterCriticalSection()函数的指针，该函数在程序退出时被调用。在调试完所有例子以后，对堆的内部细节和堆溢出利用终于有了些许的理解。
第六章中也涉及到堆溢出利用，不过此处是利用Windows异常处理机制S.E.H（异常处理结构体）来实现攻击的，看完后打算调试一遍，发现几天前通过调试建立的对内存中堆分布和操作的理解都忘得差不多了，这时候终于体会到 学习过程中根据自己的体会做一些重要笔记并且据此定期复习的重要性，因此有了本篇。
希望这是个好的开头，提醒自己谨记对于复杂的重难点，要以日志的形式形成学习笔记，以供日后温故知新。
关于堆以及P.E.B、S.E.H等机制的介绍，0day书中已经非常系统详尽，本文不再赘述，这里仅给出我的实验调试过程，记录其中踩的坑以及一些体会，因此以过程截图为主，相关简述为辅。第六章中堆的例子作者并没有给出相关代码及过程细节，这里也会附上。由于初学，文中难免存在错误，欢迎指正。
对于SSH交互而言，很难以纯socket去实现，因为SSH的认证过程中涉及到各种算法，工作量太大，因此考虑使用已有的SSH模块实现。
SSH交互最常用的是第三方模块是paramiko：
我们常常需要使用编程语言实现与某些终端交互，以实现交互过程的可控性。具体到这类涉及终端交互的漏洞，只有编写合适的PoC/Exp，并与目标有正确的交互逻辑，才能进行漏洞验证。
这里，我们以Juniper后门漏洞CVE-2015-7755为例，介绍如何使用Python编写Telnet交互程序，且:
Juniper后门漏洞相关信息可参见Freebuf相关文章。简而言之，即可使用任意用户名及密码 <<< %s(un='%s') = %u 来登录一些Juniper ScreenOS设备的Telnet及SSh服务。
初版PoC程序我使用了相对底层的socket模块来简单实现，用于检测单个目标没有问题，但在高并发扫描的时候效率极低，猜测是I/O阻塞的原因。
转而使用系统库内置模块telnetlib：
使用telnet模块后并发扫描的效率就非常高了，CPU及带宽占用率都上去了。简单翻阅telnetlib的源码，发现它是有I/O控制的。
Juniper设备使用get命令来获取设备的各类信息，可以使用 get ? 来查看相关命令，其中最重要的是2个：
但存在一个问题，如上2个命令返回的全部信息总量通常比较大，一般>=40KB，而服务端不是一次性将信息全部输出给客户端的，而是分批输出到管道中的，客户端需要不断地键入回车，来顺序获取各个信息分段。
这就要求程序能不断获取结果信息，并正确判断最后一个分段以适时终止。