社区
进程/线程/DLL
帖子详情
对改写kernel32.dll挂接自己的代码段有什么好办法吗??
sucker
2002-12-05 02:04:08
或者有什么替代的办法吗?98要写vxd,NT也要写WDM么??
...全文
38
4
打赏
收藏
对改写kernel32.dll挂接自己的代码段有什么好办法吗??
或者有什么替代的办法吗?98要写vxd,NT也要写WDM么??
复制链接
扫一扫
分享
转发到动态
举报
写回复
配置赞助广告
用AI写文章
4 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
xiangshifu1
2002-12-05
打赏
举报
回复
在 www.codeproject.com中 有一篇文章,专门讲 api拦截的,很经典,也很好用,自己看一看吧!
蒋晟
2002-12-05
打赏
举报
回复
http://www.csdn.net/Develop/read_article.asp?id=15645
在Winlogon.exe里面运行代码
sucker
2002-12-05
打赏
举报
回复
我说的就是api hook之类的技术
野男孩
2002-12-05
打赏
举报
回复
98下可以不写VXD,NT下我不知道.可以查找一下关于API HOOK之类的文章
windows用户称拦截api
Windows用户层下拦截api的原理与实现(附源码) (2008-03-29 16:15:07)转载▼ 标签: computer 杂谈 声明:本页所发布的技术文章及其附件,供自由技术传播,拒绝商业使用。本页文章及其附件的所有权归属本文作者,任何使用文档中所介绍技术者对其后果自行负责,本文作者不对其承担任何责任。 Email:redcoder163.com 目录 1 摘要 2 win2000和xp的内存结构和进程地址空间 3 函数堆栈的一些知识 4 关于拦截的整体思路 5 附件
代码
下载以及说明 一:摘要 拦截api的技术有很多种,大体分为用户层和内核层的拦截.这里只说说用户层的拦截(内核层也可以用,关键是让你的拦截程序获得ring0特权).而用户层也分为许多种:修改PE文件导入表,直接修改要拦截的api的内存(从开始到最后,使程序跳转到指定的地址执行).不过大部分原理都是修改程序流程,使之跳转到你要执行的地方,然后再返回到原地址.原来api的功能必须还能实现.否则拦截就失去作用了.修改文件导入表的方法的缺点是如果用户程序动态加载(使用LoadLibrary和GetProcAddress函数),拦截将变得复杂一些.所以这里介绍一下第二种方法,直接修改api,当然不是全局的.(后面会说到) 需要了解的一些知识: 1.windows内存的结构属性和进程地址空间 2.函数堆栈的一些知识 二:win2000和xp的内存结构和进程地址空间 windows采用4GB平坦虚拟地址空间的做法。即每个进程单独拥有4GB的地址空间。每个进程只能访问自己的这4GB的虚拟空间,而对于其他进程的地址空间则是不可见的。这样保证了进程的安全性和稳定性。但是,这4GB的空间是一个虚拟空间,在使用之前,我们必须先保留一
段
虚拟地址,然后再为这
段
虚拟地址提交物理存储器。可是我们的内存大部分都还没有1GB,那么这4GB的地址空间是如何实现的呢?事实上windows采用的内存映射这种方法,即把物理磁盘当作内存来使用,比如我们打开一个可执行文件的时候,操作系统会为我们开辟这个4GB的地址空间:0x00000000--0xffffffff。其中0x00000000--0x7fffffff是属于用户层的空间.0x80000000--0xffffffff则属于共享内核方式分区,主要是操作系统的线程调度,内存管理,文件系统支持,网络支持和所有设备驱动程序。对于用户层的进程,这些地址空间是不可访问的。任何访问都将导致一个错误。开辟这4GB的虚拟地址空间之后,系统会把磁盘上的执行文件映射到进程的地址空间中去(一般是在地址0x00400000,可以通过修改编译选项来修改这个地址)而一个进程运行所需要的动态库文件则一般从0x10000000开始加载。但是如果所有的动态库都加载到这个位置肯定会引起冲突。因此必须对一些可能引起冲突的
dll
编译时重新修改基地址。但是对于所有的操作系统所提供的动态库windows已经定义好了映射在指定的位置。这个位置会随着版本的不同而会有所改变,不过对于同一台机器上的映射地址来说都是一样的。即在a进程里映射的
kernel
32
.
dll
的地址和在进程b里的
kernel
32
.
dll
的地址是一样的。对于文件映射是一种特殊的方式,使得程序不需要进行磁盘i/o就能对磁盘文件进行操作,而且支持多种保护属性。对于一个被映射的文件,主要是使用CreateFileMapping函数,利用他我们可以设定一些读写属性:PAGE_READONLY,PAGE_READWRITE,PAGE_WRITECOPY.第一参数指定只能对该映射文件进行读操作。任何写操作将导致内存访问错误。第二个参数则指明可以对映射文件进行读写。这时候,任何对文件的读写都是直接操作文件的。而对于第三个参数PAGE_WRITECOPY顾名思义就是写入时拷贝,任何向这
段
内存写入的操作(因为文件是映射到进程地址空间的,对这
段
空间的读写就相当于对文件进行的直接读写)都将被系统捕获,并重新在你的虚拟地址空间重新保留并分配一
段
内存,你所写入的一切东西都将在这里,而且你原先的指向映射文件的内存地址也会实际指向这
段
重新分配的内存,于是在进程结束后,映射文件内容并没有改变,只是在运行期间在那
段
私有拷贝的内存里面存在着你修改的内容。windows进程运行所需要映射的一些系统
dll
就是以这种方式映射的,比如常用的nt
dll
.
dll
,
kernel
32
.
dll
,gdi
32
.
dll
.几乎所有的进程都会加载这三个动态库。如果你在一个进程里修改这个映射文件的内容,并不会影响到其他的进程使用他们。你所修改的只是在本进程的地址空间之内的。事实上原始文件并没有被改变。 这样,在后面的修改系统api的时候,实际就是修改这些动态库地址内的内容。前面说到这不是修改全局api就是这个原因,因为他们都是以写入时拷贝的方式来映射的。不过这已经足够了,windows提供了2个强大的内存操作函数ReadProcessMemory和WriteProcessMemory.利用这两个函数我们就可以随便对任意进程的任意用户地址空间进行读写了。但是,现在有一个问题,我们该写什么,说了半天,怎么实现跳转呢?现在来看一个简单的例子: MessageBox(NULL, "World", "Hello", 0); 我们在执行这条语句的时候,调用了系统api MessageBox,实际上在程序中我没有定义UNICODE宏,系统调用的是MessageBox的ANSI版本MessageBoxA,这个函数是由user
32
.
dll
导出的。下面是执行这条语句的汇编
代码
: 0040102A push 0 0040102C push offset string "Hello" (0041f024) 00401031 push offset string "World" (0041f01c) 00401036 push 0 00401038 call dword ptr [__imp__MessageBoxA@16 (0042428c)] 前面四条指令分别为参数压栈,因为MessageBoxA是__stdcall调用约定,所以参数是从右往左压栈的。最后再CALL 0x0042428c 看看0042428c这
段
内存的值: 0042428C 0B 05 D5 77 00 00 00 可以看到这个值0x77d5050b,正是user
32
.
dll
导出函数MessageBoxA的入口地址。 这是0x77D5050B处的内容, 77D5050B 8B FF mov edi,edi 77D5050D 55 push ebp 77D5050E 8B EC mov ebp,esp 理论上只要改变api入口和出口的任何机器码,都可以拦截该api。这里我选择最简单的修改方法,直接修改qpi入口的前十个字节来实现跳转。为什么是十字节呢?其实修改多少字节都没有关系,只要实现了函数的跳转之后,你能把他们恢复并让他继续运行才是最重要的。在CPU的指令里,有几条指令可以改变程序的流程:JMP,CALL,INT,RET,RETF,IRET等指令。这里我选择CALL指令,因为他是以函数调用的方式来实现跳转的,这样可以带一些你需要的参数。到这里,我该说说函数的堆栈了。 总结:windows进程所需要的动态库文件都是以写入时拷贝的方式映射到进程地址空间中的。这样,我们只能拦截指定的进程。修改目标进程地址空间中的指定api的入口和出口地址之间的任意数据,使之跳转到我们的拦截
代码
中去,然后再恢复这些字节,使之能顺利工作。 三:函数堆栈的一些知识 正如前面所看到MessageBoxA函数执行之前的汇编
代码
,首先将四个参数压栈,然后CALL MessageBoxA,这时候我们的线程堆栈看起来应该是这样的: | | <---ESP |返回地址| |参数1| |参数2| |参数3| |参数4| |.. | 我们再看MessageBoxA的汇编
代码
, 77D5050B 8B FF mov edi,edi 77D5050D 55 push ebp 77D5050E 8B EC mov ebp,esp 注意到堆栈的操作有PUSH ebp,这是保存当前的基址指针,以便一会儿恢复堆栈后返回调用线程时使用,然后再有mov ebp,esp就是把当前esp的值赋给ebp,这时候我们就可以使用 ebp+偏移 来表示堆栈中的数据,比如参数1就可以表示成[ebp+8],返回地址就可以表示成[ebp+4]..如果我们在拦截的时候要对这些参数和返回地址做任何处理,就可以使用这种方法。如果这个时候函数有局部变量的话,就通过减小ESP的值的方式来为之分配空间。接下来就是保存一些寄存器:EDI,ESI,EBX.要注意的是,函数堆栈是反方向生长的。这时候堆栈的样子: |....| |EDI| <---ESP |ESI| |EBX| |局部变量| |EBP | |返回地址| |参数1| |参数2| |参数3| |参数4| |.. | 在函数返回的时候,由函数自身来进行堆栈的清理,这时候清理的顺序和开始入栈的顺序恰恰相反,类似的汇编
代码
可能是这样的: pop edi pop esi pop ebx add esp, 4 pop ebp ret 0010 先恢复那些寄存器的值,然后通过增加ESP的值的方式来释放局部变量。这里可以用mov esp, ebp来实现清空所有局部变量和其他一些空闲分配空间。接着函数会恢复EBP的值,利用指令POP EBP来恢复该寄存器的值。接着函数运行ret 0010这个指令。该指令的意思是,函数把控制权交给当前栈顶的地址的指令,同时清理堆栈的16字节的参数。如果函数有返回值的话,那在EAX寄存器中保存着当前函数的返回值。如果是__cdecl调用方式,则执行ret指令,对于堆栈参数的处理交给调用线程去做。如wsprintf函数。 这个时候堆栈又恢复了原来的样子。线程得以继续往下执行... 在拦截api的过程之中一个重要的任务就是保证堆栈的正确性。你要理清每一步堆栈中发生了什么。 四:形成思路 呵呵,不知道你现在脑海是不是有什么想法。怎么去实现拦截一个api? 这里给出一个思路,事实上拦截的方法真的很多,理清了一个,其他的也就容易了。而且上面所说的2个关键知识,也可以以另外的形式来利用。 我以拦截CreateFile这个api为例子来简单说下这个思路吧: 首先,既然我们要拦截这个api就应该知道这个函数在内存中的位置吧,至少需要知道从哪儿入口。CreateFile这个函数是由
kernel
32
.
dll
这个动态库导出的。我们可以使用下面的方法来获取他映射到内存中的地址: HMODULE h
kernel
32
= LoadLibrary("
Kernel
32
.
dll
"); PVOID dwCreateFile = GetProcAddress(hkernei
32
, "CreateFileA"); 这就可以得到createfile的地址了,注意这里是获取的createfile的ansic版本。对于UNICODE版本的则获取CreateFileW。这时dwCreateFile的值就是他的地址了。对于其他进程中的createfile函数也是这个地址,前面说过windows指定了他提供的所有的
dll
文件的加载地址。 接下来,我们该想
办法
实现跳转了。最简单的方法就是修改这个api入口处的
代码
了。但是我们该修改多少呢?修改的内容为什么呢?前面说过我们可以使用CALL的方式来实现跳转,这种方法的好处是可以为你的拦截函数提供一个或者多个参数。这里只要一个参数就足够了。带参数的函数调用的汇编
代码
是什么样子呢,前面也已经说了,类似与调用MessageBoxA时的
代码
: PUSH 参数地址 CALL 函数入口地址(这里为一个偏移地址) 执行这2条指令就能跳转到你要拦截的函数了,但是我们该修改成什么呢。首先,我们需要知道这2条指令的长度和具体的机器
代码
的值。其中PUSH对应0x68,而CALL指令对应的机器码为0xE8,而后面的则分别对应拦截函数的参数地址和函数的地址。注意第一个是一个直接的地址,而第二个则是一个相对地址。当然你也可以使用0xFF0x15这个CALL指令来进行直接地址的跳转。 下面就是计算这2个地址的值了, 对于参数和函数体的地址,要分情况而定,对于对本进程中api的拦截,则直接取地址就可以了。对于参数,可以先定义一个参数变量,然后取变量地址就ok了。 如果是想拦截其他进程中的api,则必须使用其他一些方法,最典型的方法是利用VirtualAllocEx函数来在其他进程中申请和提交内存空间。然后用WriteProcessMemory来分别把函数体和参数分别写入申请和分配的内存空间中去。然后再生成要修改的数据,最后用WriteProcessMemory来修改api入口,把入口的前10字节修改为刚刚生成的跳转数据。比如在远程进程中你写入的参数和函数体的内存地址分别为0x00010000和0x00011000,则生成的跳转数据为 68 00 00 01 00 E8 00 10 01 00(PUSH 00010000 CALL 00011000),这样程序运行createfile函数的时候将会先运行PUSH 00010000 CALL 00011000,这样就达到了跳转的目的。此刻我们应该时刻注意堆栈的状态,对于CreateFile有 HANDLE CreateFile( LPCTSTR lpFileName, DWORD dwDesiredAccess, DWORD dwShareMode, LPSECURITY_ATTRIBUTES lpSecurityAttributes, DWORD dwCreationDisposition, DWORD dwFlagsAndAttributes, HANDLE hTemplateFile ); 可以看到其有7个参数,于是在调用之前,堆栈应该已经被压入了这7个参数,堆栈的样子: |....| <---ESP |createfile执行后的下一条指令地址| |参数1| |参数2| |参数3| |参数4| |参数5| |参数6| |参数7| |..| 这是执行到我们的跳转语句:PUSH 00010000,于是堆栈又变了: |....| <---ESP |00010000| |createfile执行后的下一条指令地址| |参数1| |参数2| |参数3| |参数4| |参数5| |参数6| |参数7| |..| 接着执行CALL 00011000,堆栈变为: |...| <---ESP |api入口之后的第六个字节的指令的地址| |00010000| |createfile执行后的下一条指令地址| |参数1| |参数2| |参数3| |参数4| |参数5| |参数6| |参数7| |..| 接下来就到了我们的拦截函数中拉,当然,函数肯定也会做一些类似动作,把EBP压栈,为局部变量分配空间等。这时候堆栈的样子又变了: |EDI| <---ESP |ESI| |EBX| |局部变量| |EBP| dwMessageBox; pfnMessageBox(NULL, PFileName, PFileName, MB_ICONINFORMATION |MB_OK); //输出要打开的文件的路径..... } 对于你要使用的其他函数,都是使用同样的方式,利用这个参数来传递我们要传递的函数的绝对地址,然后定义这个函数指针,就可以使用了。 好了,接下来我们该让被拦截的api正常工作了,这个不难,把他原来的数据恢复一下就可以了。那入口的10个字节。我们在
改写
他们的时候应该保存一下,然后也把他放在参数中传递给拦截函数,呵呵,参数的作用可多了。接着我们就可以用WriteProcessMemory函数来恢复这个api的入口了,
代码
如下: PFN_GETCURRENTPROCESS pfnGetCurrentProcess = (PFN_GETCURRENTPROCESS)pRP->dwGetCurrentProcess; PFN_WRITEPROCESSMEMORY pfnWriteProcessMemory = (PFN_WRITEPROCESSMEMORY)pRP->dwWriteProcessMemory; if(!pfnWriteProcessMemory(pfnGetCurrentProcess(), (LPVOID)pfnConnect, (LPCVOID)pRP->szOldCode, 10, NULL)) pfnMessageBox(NULL, pRP->szModuleName1, pRP->szModuleName2, MB_ICONINFORMATION | MB_OK); 其中这些函数指针的定义和上面的类似。 而参数中的szoldcode则是在源程序中在修改api之前保存好,然后传给拦截函数,在源程序中是用ReadProcessMemory函数来获取他的前10个字节的: ReadProcessMemory(GetCurrentProcess(), (LPCVOID)RParam.dwCreateFile, oldcode, 10, &dwPid) strcat((char*)RParam.szOldCode, (char*)oldcode); 接下来如果你还继续保持对该api的拦截,则又该用WriteProcessMemory 来修改入口了,跟前面的恢复入口是一样的,只不过把szOldCode换成了szNewCode了而已。这样你又能对CreateFile继续拦截了。 好了,接下来该进行堆栈的清理了,也许你还要做点其他事情,尽管做去。但是清理堆栈是必须要做的,在函数结束的时候,因为在我们放任api恢复执行之后,他又return 到我们的函数中来了,这个时候的堆栈是什么样子呢? |EDI| <---ESP |ESI| |EBX| |局部变量| |EBP| <---EBP |api入口之后的第六个字节的指令的地址| |00010000| |createfile执行后的下一条指令地址| |参数1| |参数2| |参数3| |参数4| |参数5| |参数6| |参数7| |..| 我们的目标是把返回值记录下来放到EAX寄存器中去,把返回地址记录下来,同时把堆栈恢复成原来的样子。 首先我们恢复那些寄存器的值,接着释放局部变量,可以用mov esp, ebp.因为我们不清楚具体的局部变量分配了多少空间。所以使用这个方法。 __asm {POP EDI POP ESI POP EBX //恢复那些寄存器 MOV EDX, [NextIpAddr]//把返回地址放到EDX中,因为待会儿 //EBP被恢复后,线程中的所有局部变量就不能正常使用了。 MOV EAX, [RetValue]//返回值放到EAX中,当然也可以修改这个返回值 MOV ESP, EBP//清理局部变量 POP EBP//恢复EBP的值 ADD ESP, 28H //清理参数和返回地址,注意一共(7+1+1+1)*4 PUSH EDX //把返回地址压栈,这样栈中就只有这一个返回地址了,返回之后栈就空了 RET } 这样,一切就完成了,堆栈恢复了应该有的状态,而你想拦截的也拦截到了。 五:后记 拦截的方式多种多样,不过大体的思路却都相同。要时刻注意你要拦截的函数的堆栈状态以及在拦截函数中的对数据的引用和函数的调用(地址问题)。
windows钩子编程大全
二、API Hook的原理 这里的API既包括传统的Win
32
APIs,也包括任何Module输出的函数调用。熟悉PE文件格 式的朋友都知道,PE文件将对外部Module输出函数的调用信息保存在输入表中,即.idata
段
。 下面首先介绍本
段
的结构。 输入表首先以一个IMAGE_IMPORT_DESCRIPTOR(简称IID)数组开始。每个被PE文件隐式链接 进来的
DLL
都有一个IID.在这个数组中的最后一个单元是NULL,可以由此计算出该数组的项数。 例如,某个PE文件从两个
DLL
中引入函数,就存在两个IID结构来描述这些
DLL
文件,并在两个 IID结构的最后由一个内容全为0的IID结构作为结束。几个结构定义如下: IMAGE_IMPORT_DESCRIPTOR struct union{ DWORD Characteristics; ;00h DWORD OriginalFirstThunk; }; TimeDateStamp DWORD ;04h ForwarderChain DWORD ;08h Name DWORD ;0Ch FirstThunk DWORD ;10h IMAGE_IMPROT_DESCRIPTOR ends typedef struct _IMAGE_THUNK_DATA{ union{ PBYTE ForwarderString; PDWORD Functions; DWORD Ordinal; PIMAGE_IMPORT_BY_NAME AddressOfData; }u1; } IMAGE_IMPORT_BY_NAME结构保存一个输入函数的相关信息: IMAGE_IMPORT_BY_NAME struct Hint WORD ? ;本函数在其所驻留
DLL
的输出表中的序号 Name BYTE ? ;输入函数的函数名,以NULL结尾的ASCII字符串 IMAGE_IMPORT_BY_NAME ends OriginalFirstThunk(Characteristics):这是一个IMAGE_THUNK_DATA数组的RVA(相对于PE文件 起始处)。其中每个指针都指向IMAGE_IMPORT_BY_NAME结构。 TimeDateStamp:一个
32
位的时间标志,可以忽略。 ForwarderChain:正向链接索引,一般为0。当程序引用一个
DLL
中的API,而这个API又引用别的
DLL
的API时使用。 NameLL名字的指针。是个以00结尾的ASCII字符的RVA地址,如"
KERNEL
32
.
DLL
"。 FirstThunk:通常也是一个IMAGE_THUNK_DATA数组的RVA。如果不是一个指针,它就是该功能在
DLL
中的序号。 OriginalFirstThunk与FirstThunk指向两个本质相同的数组IMAGE_THUNK_DATA,但名称不同, 分别是输入名称表(Import Name Table,INT)和输入地址表(Import Address Table,IAT)。 IMAGE_THUNK_DATA结构是个双字,在不同时刻有不同的含义,当双字最高位为1时,表示函数以 序号输入,低位就是函数序号。当双字最高位为0时,表示函数以字符串类型的函数名 方式输入,这时它是指向IMAGE_IMPORT_BY_NAME结构的RVA。 三个结构关系如下图: IMAGE_IMPORT_DESCRIPTOR INT IMAGE_IMPORT_BY_NAME IAT -------------------- /-->---------------- ---------- ---------------- |01| 函数1 ||02| 函数2 || n| ... |"USER
32
.
dll
" | |--------------------| | | FirstThunk |---------------------------------------------------------------/ -------------------- 在PE文件中对
DLL
输出函数的调用,主要以这种形式出现: call dword ptr[xxxxxxxx] 或 jmp [xxxxxxxx] 其中地址xxxxxxxx就是IAT中一个IMAGE_THUNK_DATA结构的地址,[xxxxxxxx]取值为IMAGE_THUNK_DATA 的值,即IMAGE_IMPORT_BY_NAME的地址。在操作系统加载PE文件的过程中,通过IID中的Name加载相应 的
DLL
,然后根据INT或IAT所指向的IMAGE_IMPORT_BY_NAME中的输入函数信息,在
DLL
中确定函数地址, 然后将函数地址写到IAT中,此时IAT将不再指向IMAGE_IMPORT_BY_NAME数组。这样[xxxxxxxx]取到的 就是真正的API地址。 从以上分析可以看出,要拦截API的调用,可以通过
改写
IAT来实现,将自己函数的地址写到IAT中, 达到拦截目的。 另外一种方法的原理更简单,也更直接。我们不是要拦截吗,先在内存中定位要拦截的API的地址, 然后
改写
代码
的前几个字节为 jmp xxxxxxxx,其中xxxxxxxx为我们的API的地址。这样对欲拦截API的 调用实际上就跳转到了咱们的API调用去了,完成了拦截。不拦截时,再
改写
回来就是了。 这都是自己从网上辛辛苦苦找来的,真的很好啊
C++系列第2:C++2.0(11+14+17+20)详解及多线程实战
学习并掌握C++2.0(11+14+17+20)的新特性,学习线程及线程池的...121 3)、什么是单线程和多线程 121 4)、线程池 122 5)、四种常见的线程池 123 线程池的架构与流程 123 线程池
代码
实战 125
引用“
kernel
32
”读写ini配置文件
引用“
kernel
32
”读写ini配置文件unityini
kernel
32
配置文件 引用“
kernel
32
”读写ini配置文件 OverView
kernel
32
.
dll
是Windows中非常重要的
32
位动态链接库文件,属于内核级文件。它控制着系统的内存管理、数据的输入输出操作和中断处理,当Windows启动时,
kernel
32
.
dll
就驻留在内存中特定的写...
关于彩虹猫病毒的分析
点击加载,会出现这样的一个提示框。 再次点击确定后,又会弹出“最后警告”的提示框 用PEID打开,查看有无壳。发现没有壳 用StudyPE+查看导入表 导入表名 作用
KERNEL
32
.
dll
控制着系统的内存管理、数据的输入输出操作和中断处理 USER
32
.
dll
创建窗口和发送消息,与用户界面相关 GDI
32
.
dll
用来绘制图像和显示文字 ADVAPI
32
.
dll
负责对象的安全性,注册表的操控以及事件日志 SHELL
32
.
dll
用于打开网页和文件,建立文件时的
进程/线程/DLL
15,471
社区成员
49,181
社区内容
发帖
与我相关
我的任务
进程/线程/DLL
VC/MFC 进程/线程/DLL
复制链接
扫一扫
分享
社区描述
VC/MFC 进程/线程/DLL
社区管理员
加入社区
获取链接或二维码
近7日
近30日
至今
加载中
查看更多榜单
社区公告
暂无公告
试试用AI创作助手写篇文章吧
+ 用AI写文章