基于布隆过滤器的跨平台USB存储设备管控方案

2024-02-10 18:12

本文主要是介绍基于布隆过滤器的跨平台USB存储设备管控方案,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

1、前言

U盘作为移动存储设备之一,是我们日常生活中接触最多和最常用的存储介质。正因如此,针对U盘内容的管理也因为使用场景的多样和复杂性,变得难以实现。
我们的设计思路是先通过某些手段对U盘进行病毒,并在查杀完成后对U盘进行认证。在后续使用过程检测认证U盘是否被篡改以保证U盘的安全性。

2、设计

本方案的设计主要包含两个部分:U盘认证和U盘检测。

2.1 认证
  1. 检测当前设备是否USB存储设备
  2. 根据U盘内容创建合适的布隆过滤器
  3. 遍历U盘文件,以文件名 + 时间戳 + 文件大小的方式生成标志字符串,添加到布隆过滤器中
  4. 保存布隆过滤器
  5. 保存布隆过滤器的时间戳
2.2 检测
  1. 检测当前设备是否USB存储设备
  2. 根据布隆过滤器的时间戳,计算当前系统的时间偏差
  3. 加载布隆过滤器
  4. 遍历U盘文件,以文件名 + 时间戳 + 文件大小的方式生成标志字符串,检测是否命中

3、实现

3.1 设备检测
#ifdef _WIN32if (driver_[0] != 'A' && driver_[0] != 'B' &&// 判断设备是否可移动介质GetDriveTypeA(driver_.c_str()) == DRIVE_REMOVABLE) {// 判断设备是否加载if (GetVolumeInformationA(driver_.c_str(), NULL, NULL, NULL, NULL, NULL,NULL, 0)) {return true;}}
#elsestd::ifstream mounts("/proc/mounts");if (mounts.is_open()) {std::string line;while (std::getline(mounts, line)) {std::stringstream ss(line);std::string device, mount_point;ss >> device >> mount_point;if (driver_.substr(0, driver_.length() - 1) == mount_point) {if (0 == strncmp("/dev/sd", device.c_str(), 7)) {ss.str("");ss << "/sys/block/";// 获取块设备for (size_t i = 5; i <= device.length(); ++i) {  //if ('0' <= device[i] && '9' >= device[i]) {break;}ss << device[i];}std::error_code err;std::string dev_pci_name =fs::read_symlink(ss.str(), err).generic_string();// 检测pci总线中是否包含"usb"标识if (dev_pci_name.find("usb") != std::string::npos) {return true;}}return false;}}}
#endifreturn false;
3.2 文件遍历
  std::stringstream ss;try {for (fs::recursive_directory_iterator it(driver_path);it != fs::recursive_directory_iterator(); it++) {std::string path = it->path().generic_u8string().substr(driver_path.size(), std::string::npos);// 跳过认证文件if (strcmp(kBloomFilterPath, path.c_str()) == 0 ||strcmp(kTimeMarkPath, path.c_str()) == 0 ||strcmp(kUsbAuthDir, path.c_str()) == 0)continue;if (!fs::is_directory(it->path()) && !fs::is_regular_file(it->path()))continue;ss.str("");ss << path;// 获取文件的filetimeauto time = tm_::duration_cast<tm_::seconds>(it->last_write_time().time_since_epoch()).count();ss << (time - elapse);size_t file_size = 0x1000;if (fs::is_regular_file(it->path())) {file_size = it->file_size();}ss << file_size;if (!bf_.BloomAdd(ss.str())) {return error_code::kIOFailure;}}} catch (fs::filesystem_error &e) {return error_code::kIOFailure;}
3.3 布隆过滤器
  // Hash算法:Fnv1a_64 uint64_t hash = 0xcbf29ce484222325ull;const uint8_t *bytes = static_cast<const uint8_t *>(data);for (size_t i = 0; i < numBytes; ++i) {hash ^= bytes[i];hash *= 0x100000001b3ull;}uint8_t seed_arr[32] = {0};
#ifdef _WIN32numBytes = sprintf_s((char *)seed_arr, sizeof(seed_arr) - 1, "%d", seed);
#elsenumBytes = snprintf((char *)seed_arr, sizeof(seed_arr) - 1, "%d", seed);
#endiffor (size_t i = 0; i < numBytes; ++i) {hash ^= seed_arr[i];hash *= 0x100000001b3ull;}return hash;

4、难点记录

4.1 时间戳获取

C++17标准中提供的std::filesystem::last_write_time()函数返回的类型为std::filesystem::file_time_type
查阅官方文档可知,file_time_type在C++17中的实现是基于平台的,不支持跨平台。
在MSVC的代码中可以发现,Windows平台提供的file_time_type是基于FileTime实现的。即在Windows C++中,FileTime的计算方式是从1601年1月1日开始的100纳秒为单位的时间。
因此当我们需要将std::filesystem::last_write_time()转换为UTC时间戳时,首先需要使用duration_cast将单位转换为秒。

auto time = tm_::duration_cast<tm_::seconds>(it->last_write_time().time_since_epoch()).count();

通过上一步,我们取得了从1601年1月1日开始的秒为单位的时间戳。下一步,我们需要减去FileTime和UTC时间之前的差值。

从C++文档中我们可以查到std::chrono::system_clock使用的正是1970年开始的UTC时间,因此可以通过以下手段获取秒为单位的差值。

auto elapse = tm_::duration_cast<tm_::seconds>(fs::file_time_type::clock::now().time_since_epoch() - tm_::system_clock::now().time_since_epoch()).count();

最后,通过以上两个数据,我们计算出文件修改时间的UTC时间戳。

auto mtime = time - elapse
4.2 时间戳不一致

在实际测试中发现,即同一个文件在Windows和Linux系统中获取的时间戳在某些情况会出现不一致的问题。
经过调查发现,是由于Windows 与 Linux 看待硬件时间的方式不同。
Windows 把电脑的硬件时钟(RTC)看成是本地时间,即 RTC = Local Time,Windows 会直接显示硬件时间;
而 Linux 则是把电脑的硬件时钟看成 UTC 时间,即 RTC = UTC,那么 Linux 显示的时间就是硬件时间加上时区。
针对这个问题,和团队成员讨论后最终决定了一个方案。通过在认证阶段生成一个标识时间戳,在检测阶段计算和标识时间戳的差值来重新对齐时间。

// 生成标识时间
auto time = tm_::duration_cast<tm_::seconds>(fs::last_write_time(bf_path).time_since_epoch()).count();
struct {uint64_t magic;time_t base_time;
} bin = {kTmMagic, time - elapse};// 获取标识时间, 计算差值
auto time = tm_::duration_cast<tm_::seconds>(fs::last_write_time(bf_path, err).time_since_epoch()).count();
auto time_diff = bin.base_time - (time - elapse);  // Get System Time Diff between auth and scan

完整项目代码

这篇关于基于布隆过滤器的跨平台USB存储设备管控方案的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/697764

相关文章

Python + Streamlit项目部署方案超详细教程(非Docker版)

《Python+Streamlit项目部署方案超详细教程(非Docker版)》Streamlit是一款强大的Python框架,专为机器学习及数据可视化打造,:本文主要介绍Python+St... 目录一、针对 Alibaba Cloud linux/Centos 系统的完整部署方案1. 服务器基础配置(阿里

SpringSecurity中的跨域问题处理方案

《SpringSecurity中的跨域问题处理方案》本文介绍了跨域资源共享(CORS)技术在JavaEE开发中的应用,详细讲解了CORS的工作原理,包括简单请求和非简单请求的处理方式,本文结合实例代码... 目录1.什么是CORS2.简单请求3.非简单请求4.Spring跨域解决方案4.1.@CrossOr

使用MyBatis TypeHandler实现数据加密与解密的具体方案

《使用MyBatisTypeHandler实现数据加密与解密的具体方案》在我们日常的开发工作中,经常会遇到一些敏感数据需要存储,比如用户的手机号、身份证号、银行卡号等,为了保障数据安全,我们通常会对... 目录1. 核心概念:什么是 TypeHandler?2. 实战场景3. 代码实现步骤步骤 1:定义 E

Python实现繁体转简体功能的三种方案

《Python实现繁体转简体功能的三种方案》在中文信息处理中,繁体字与简体字的转换是一个常见需求,无论是处理港澳台地区的文本数据,还是开发面向不同中文用户群体的应用,繁简转换都是不可或缺的功能,本文将... 目录前言为什么需要繁简转换?python实现方案方案一:使用opencc库方案二:使用zhconv库

MyBatis Plus中执行原生SQL语句方法常见方案

《MyBatisPlus中执行原生SQL语句方法常见方案》MyBatisPlus提供了多种执行原生SQL语句的方法,包括使用SqlRunner工具类、@Select注解和XML映射文件,每种方法都有... 目录 如何使用这些方法1. 使用 SqlRunner 工具类2. 使用 @Select 注解3. 使用

SpringBoot基于注解实现数据库字段回填的完整方案

《SpringBoot基于注解实现数据库字段回填的完整方案》这篇文章主要为大家详细介绍了SpringBoot如何基于注解实现数据库字段回填的相关方法,文中的示例代码讲解详细,感兴趣的小伙伴可以了解... 目录数据库表pom.XMLRelationFieldRelationFieldMapping基础的一些代

前端缓存策略的自解方案全解析

《前端缓存策略的自解方案全解析》缓存从来都是前端的一个痛点,很多前端搞不清楚缓存到底是何物,:本文主要介绍前端缓存的自解方案,文中通过代码介绍的非常详细,需要的朋友可以参考下... 目录一、为什么“清缓存”成了技术圈的梗二、先给缓存“把个脉”:浏览器到底缓存了谁?三、设计思路:把“发版”做成“自愈”四、代码

解决docker目录内存不足扩容处理方案

《解决docker目录内存不足扩容处理方案》文章介绍了Docker存储目录迁移方法:因系统盘空间不足,需将Docker数据迁移到更大磁盘(如/home/docker),通过修改daemon.json配... 目录1、查看服务器所有磁盘的使用情况2、查看docker镜像和容器存储目录的空间大小3、停止dock

Spring Gateway动态路由实现方案

《SpringGateway动态路由实现方案》本文主要介绍了SpringGateway动态路由实现方案,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随... 目录前沿何为路由RouteDefinitionRouteLocator工作流程动态路由实现尾巴前沿S

分析 Java Stream 的 peek使用实践与副作用处理方案

《分析JavaStream的peek使用实践与副作用处理方案》StreamAPI的peek操作是中间操作,用于观察元素但不终止流,其副作用风险包括线程安全、顺序混乱及性能问题,合理使用场景有限... 目录一、peek 操作的本质:有状态的中间操作二、副作用的定义与风险场景1. 并行流下的线程安全问题2. 顺