如何在读写CMOS

如何在读写CMOS :(

70h是地址，71h是数据，你说怎么读？呵呵

                               新来的客人想发言必须注册！请点击此处！  


原有信息:
序 号:257109
标 题:一个字“强！！！！！！！！！！”。 (32千字)
发信人:柯南[CCG]
时 间:2003-3-3 13:38:34
阅读次数:99
详细信息:

朋友的水平，真是另人刮目相待，读了这片文章有醍醐灌顶之感。遗憾的是有写地方我能力有限，没有看透，呵呵（笑..........)。
有一点你好象没有删除Section对象ZwClose 搞定。
还有这里有一篇和\\Device\\PhysicalMemory有点关系的文章，好象你不只可以读bios，如果有system权限的话，还可以写bios呢！，呵呵^@^...希望兄弟研究研究（做点XXX毒啦），我能力有限就算了，期待你的大做！
以下是转载：

原文：“Playing with Windows /dev/(k)mem”（p59-0x10）
原作者：crazylord <crazylord@minithins.net>

翻译：Refdom


1、介绍

2、介绍WINDOWS对象
2.1 它们是什么
2.2 它们的结构
2.3 对象操作

3、介绍 \\Device\\PhysicalMemory
3.1 对象
3.2 需要写权限？

4、玩 \\Device\\PhysicalMemory
4.1 读/写内存
4.2 什么是Callgate
4.3 不用驱动运行ring0代码
4.4 深入到进程表
4.5 Bonus Track

5、代码示例
5.1 kmem.h
5.2 chmod_mem.c
5.3 winkdump.c
5.2 winkps.c
5.4 fun_with_ipd.c



--[ 1 介绍

本文介绍Windows /dev/kmem，我的研究是在Windows 2000 professional上实施的，这意味着本文中的
多数代码都可以在windows 2000版本上运行，稍经改动，也可以运行在XP上。很明显Windows 9x/Me不会支持，
因为它们的核心结构并不相同。


--[ 2 介绍Windows对象

Windows2000使用对象模型来提供非常简单的方式操作多数基本的核心元素。我们可以在本节看看这些对
象和怎么去操作它们。

----[ 2.1 What are they?

按照微软的说法，设计对象管理器只要来达到下面这些目的：
* 使用命名对象方便识别
* 支持POSIX子系统
* 提供方便的方法来操作系统资源
* 提供一种装填机制来限制进程使用的资源
* 顺应C2安全的要求。

有27种不同的对象类型：
* Adapter * File * Semaphore
* Callback * IoCompletion * SymbolicLink
* Controler * Job * Thread
* Desktop * Key * Timer
* Device * Mutant * Token
* Directory * Port * Type
* Driver * Process * WaitablePort
* Event * Profile * WindowStation
* EventPair * Section * WmiGuid

多数这些对象从命令就能够看出它们是关于什么的了。我会解释一些模糊的名字：
* 一个EventPair只是2个Event对象
* Mutant也被称为互斥体（Mutex），是一种处理资源访问的同步机制
* Port被LPC(Local Procedure Call)作Inter-Processus 通讯。
* Semaphore是限制访问资源的计数器
* Token (Access Token)是安全对象
* WindowStation是桌面对象容器。

这些对象可能类似目录树结构一样组织成：

- \\
- ArcName (symbolic links to harddisk partitions)
- NLS (sections ...)
- Driver (installed drivers)
- WmiGuid
- Device (/dev linux like)
- DmControl
- RawDmVolumes
- HarddiskDmVolumes
- PhysicalDmVolumes
- Windows
- WindowStations
- RPC Control
- BaseNamedObjects
- Restricted
- ?? (current user directory)
- FileSystem (information about installable files system)
- ObjectTypes (contains all avaible object types)
- Security
- Callback
- KnownDlls (Contains sections of most used DLL)

\"??\"目录是当前用户目录，\"Device\"可以被看作跟LINUX上的/dev一样。你可以在Sysinternals网站上
找到这个结构。

----[ 2.2 他们的结构

每个对象都包含两部分：对象头和对象实体。Sven B. Schreiber在\"Windows 2000 Undocumented Secrets\"
一书中定义了多数没公开的头部结构。我们可以来看看这些头结构。

---
from w2k_def.h:

typedef struct _OBJECT_HEADER {
/*000*/ DWORD PointerCount; // number of references
/*004*/ DWORD HandleCount; // number of open handles
/*008*/ POBJECT_TYPE ObjectType; // pointer to object type struct
/*00C*/ BYTE NameOffset; // OBJECT_NAME offset
/*00D*/ BYTE HandleDBOffset; // OBJECT_HANDLE_DB offset
/*00E*/ BYTE QuotaChargesOffset; // OBJECT_QUOTA_CHARGES offset
/*00F*/ BYTE ObjectFlags; // OB_FLAG_*
/*010*/ union
{ // OB_FLAG_CREATE_INFO ? ObjectCreateInfo : QuotaBlock
/*010*/ PQUOTA_BLOCK QuotaBlock;
/*010*/ POBJECT_CREATE_INFO ObjectCreateInfo;
};
/*014*/ PSECURITY_DESCRIPTOR SecurityDescriptor;
/*018*/ } OBJECT_HEADER, *POBJECT_HEADER;
---

头部中的每个偏移量都是负数偏移量，因此你如果想从头结构中找到OBJECT_NAME结构，你应该这样计算：
address = object_header_address - name_offset

OBJECT_NAME结构允许创建者通过赋一个名字让对象对其他进程可见。
OBJECT_HANDLE_DB结构允许核心跟踪当前谁正在使用该对象。
OBJECT_QUOTA_CHARGES结构用来定义了进程访问对象的配额。
OBJECT_TYPE结构存储关于对象类型的全局信息，比如：默认的安全权限，对象大小，进程使用对象的默
认配额等。

对象绑定的安全描述符可以让核心来限制对象访问。

每一个对象类型的内部程序都十分接近C++对象中的构造和析构：
* dump method -可能是为了调试目的，总为NULL
* open method -当对象句柄打开时被调用
* close method -当对象句柄关闭时被调用
* delete method -当对象句柄删除时被调用
* parse method -查询对象列表时被调用
* security method -读写保护的当前的对象时被调用
* query method -当线程查询对象名时调用
* \"ok to close\" -线程关闭句柄时调用

对象体的结构完全依靠对象类型，在DDK中只有很少部分的对象体结构被公开。如果你对这些结构感兴
趣，你可以使用google  或者查看chapeaux-noirs的主页（参见[4]）


--- [ 2.3 对象操作

以用户模式的观点来看，对象操作只要是通过Windows API来执行。比如，为了访问文件对象，可以使
用 fopen()/open()，它们调用 CreateFile(). 我们转化到核心模式 （NtCreateFile()）在ntoskrnl.exe
中调用IoCreateFile()。通过反编译IoCreateFile(),可以看见一些函数，比如：ObOpenObjectByName,
ObfDereferenceObject,……

（BTW：如果用在DDK站点(参见[2])下载的win2k symbols，只能看见这些函数，用支持Windows Symbols
文件的反编译器比如IDA/kd/Softice 因为这些函数没有被导出。）

每个函数都以Ob开头，表示同对象管理器相关。基本上，普通的开发者不必去处理这些对象，但我们要
去看看。

对于用户模式，所有的对象管理器相关函数都可以被ntdll.dll输出，这里有一些例子：
NtCreateDirectoryObject, NtCreateSymbolicLinkObject, NtDuplicateObject,
NtMakeTemporaryObject, NtOpenDirectoryObject, ...

有些函数在MSDN中公开了，但是多数没有。

如果你真想理解对象的工作方法，最好看看ntoskrnl.exe中导出的以Ob开头的函数。有21个导出函数，
其中6个是公开的。

如果你想看看其他15个的原型，去ntifs.h的主页（参见[3]）或者去chapeaux-noirs站点（参见[4]）。


--[ 3 - 介绍\\Device\\PhysicalMemory

为了查看对象信息，我们需要一个类似微软DDK中的核心调试工具。好，让我们现在开始……


Microsoft(R) Windows 2000 Kernel Debugger
Version 5.00.2184.1
Copyright (C) Microsoft Corp. 1981-1999

Symbol search path is: c:\\winnt\\symbols

Loading Dump File [livekd.dmp]
Full Kernel Dump File

Kernel Version 2195 UP Free
Kernel base = 0x80400000 PsLoadedModuleList = 0x8046a4c0
Loaded kdextx86 extension DLL
Loaded userkdx extension DLL
Loaded dbghelp extension DLL
f1919231 eb30 jmp f1919263
kd> !object \\Device\\PhysicalMemory
!object \\Device\\PhysicalMemory
Object: e1001240 Type: (fd038880) Section
ObjectHeader: e1001228
HandleCount: 0 PointerCount: 3
Directory Object: fd038970 Name: PhysicalMemory

从kd(kernel debugger)剖析基本对象告诉我们一些信息。不必解释所有内容的意义，他们中的大多数
都非常清楚只要你读了文章开头，如果没有，请\"jmp dword Introduction_to_Windows_Objects\"。

感兴趣的是，它是一个Section对象，清楚地表明我们要处理内存。现在我们要dump对象的头结构。
kd> dd e1001228 L 6
dd e1001228 L 6
e1001228 00000003 00000000 fd038880 12200010
e1001238 00000001 e1008bf8

details:
--> 00000003 : PointerCount = 3
--> 00000000 : HandleCount = 0
--> fd038880 : pointer to object type = 0xfd038880
--> 12200010 --> 10 : NameOffset
--> 00 : HandleDBOffset
--> 20 : QuotaChargeOffset
--> 12 : ObjectFlags = OB_FLAG_PERMANENT & OB_FLAG_KERNEL_MODE
--> 00000001 : QuotaBlock
--> e1008bf8 : SecurityDescriptor

NameOffset存在，不要惊讶，这个对象有一个名字……，但是没有HandleDBOffset。这意味着这个对象
不跟踪分配的句柄。QuotaChargeOffset并不有意思，ObjectFlags告诉我们这个对象是永久对象，并且被核
心创建。

到现在还没有非常有意思的东西……

dump这个对象的名字结构，只是确信我们没有走错方向 。 （记住偏移量是负数）

kd> dd e1001228-10 L3
dd e1001228-10 L3
e1001218 fd038970 001c001c e1008ae8

--> fd038970 : pointer to object Directory
--> 001c001c --> 001c : UNICODE_STRING.Length
--> 001c : UNICODE_STRING.MaximumLength
--> e1008ae8 : UNICODE_STRING.Buffer (pointer to wide char string)

kd> du e1008ae8
du e1008ae8
e1008ae8 \"PhysicalMemory\"

现在出现有意思的部分了，安全描述符：

kd> !sd e1008bf8
!sd e1008bf8
->Revision: 0x1
->Sbz1 : 0x0
->Control : 0x8004
SE_DACL_PRESENT
SE_SELF_RELATIVE
->Owner : S-1-5-32-544
->Group : S-1-5-18
->Dacl :
->Dacl : ->AclRevision: 0x2
->Dacl : ->Sbz1 : 0x0
->Dacl : ->AclSize : 0x44
->Dacl : ->AceCount : 0x2
->Dacl : ->Sbz2 : 0x0
->Dacl : ->Ace[0]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl : ->Ace[0]: ->AceFlags: 0x0
->Dacl : ->Ace[0]: ->AceSize: 0x14
->Dacl : ->Ace[0]: ->Mask : 0x000f001f
->Dacl : ->Ace[0]: ->SID: S-1-5-18

->Dacl : ->Ace[1]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl : ->Ace[1]: ->AceFlags: 0x0
->Dacl : ->Ace[1]: ->AceSize: 0x18
->Dacl : ->Ace[1]: ->Mask : 0x0002000d
->Dacl : ->Ace[1]: ->SID: S-1-5-32-544

->Sacl : is NULL

总之，这意味着\\Device\\PhysicalMemory对象有下面的权限：

user SYSTEM: Delete, Change Permissions, Change Owner, Query Data,
Query State, Modify State
user Administrator: Query Data, Query State

基本上，管理员用户没有权限写，但是SYSTEM可以，这实际上意味着管理员也可以做到！

一定注意到实际上这不象/dev/kmem！！在LINUX中/dev/kmem映射虚拟内存，\\Device\\PhysicalMemory
映射物理内存，本文更确切的标题应该是\"Playing with Windows /dev/mem\"因为/dev/mem映射物理内存，
但/dev/kmem听起来更熟悉些。

据我所知，在我写这篇文章的时候，Section对象体结构还没有解剖开，因此我们还不能分析它的结构。


----[ 3.2 需要“写”权限？

好，我们是用户administrator，并且打算玩玩感兴趣的对象，该怎么做呢？正如多数Windows管理员
所知，可以用schedule服务运行任何进程作为SYSTEM用户。如果你想确信你可以，只要启动schedule用
“net start schedule”并且去打开一个任务执行regedit.exe

c:\\>at <when> /interactive regedit.exe

之后可以试试看看SAM注册表，如果能查看，那么你SYSTEM用户，如果不能，你就仍旧是administrator
因为只有用户SYSTEM才拥有读的权力。

好，如果我们是administrator用户，但如果我们允许任何人写\\Device\\PhysicalMemory会发生什么
呢？（当然是为了学习的目的）

我们只要给这个对象添加另一个ACL，就可以了。按照下面的步骤：

1、打开\\Device\\PhysicalMemory句柄 (NtOpenSection)
2、找到它的安全描述符 (GetSecurityInfo)
3、在当前ACL中添加Read/Write授权 (SetentriesInAcl)
4、更新安全描述符 (SetSecurityInfo)
5、关闭先前打开的句柄

可以参考示例代码：chmod_mem.c

当运行了chmod_mem.exe，我们再一次dump\\Device\\PhysicalMemory的安全描述符。

kd> !object \\Device\\PhysicalMemory
!object \\Device\\PhysicalMemory
Object: e1001240 Type: (fd038880) Section
ObjectHeader: e1001228
HandleCount: 0 PointerCount: 3
Directory Object: fd038970 Name: PhysicalMemory
kd> dd e1001228+0x14 L1
dd e1001228+0x14 L1
e100123c e226e018
kd> !sd e226e018
!sd e226e018
->Revision: 0x1
->Sbz1 : 0x0
->Control : 0x8004
SE_DACL_PRESENT
SE_SELF_RELATIVE
->Owner : S-1-5-32-544
->Group : S-1-5-18
->Dacl :
->Dacl : ->AclRevision: 0x2
->Dacl : ->Sbz1 : 0x0
->Dacl : ->AclSize : 0x68
->Dacl : ->AceCount : 0x3
->Dacl : ->Sbz2 : 0x0
->Dacl : ->Ace[0]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl : ->Ace[0]: ->AceFlags: 0x0
->Dacl : ->Ace[0]: ->AceSize: 0x24
->Dacl : ->Ace[0]: ->Mask : 0x00000002
->Dacl : ->Ace[0]: ->SID: S-1-5-21-1935655697-436374069-1060284298-500

->Dacl : ->Ace[1]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl : ->Ace[1]: ->AceFlags: 0x0
->Dacl : ->Ace[1]: ->AceSize: 0x14
->Dacl : ->Ace[1]: ->Mask : 0x000f001f
->Dacl : ->Ace[1]: ->SID: S-1-5-18

->Dacl : ->Ace[2]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl : ->Ace[2]: ->AceFlags: 0x0
->Dacl : ->Ace[2]: ->AceSize: 0x18
->Dacl : ->Ace[2]: ->Mask : 0x0002000d
->Dacl : ->Ace[2]: ->SID: S-1-5-32-544

->Sacl : is NULL

新的ACE(access-control entry)是Ace[0]，拥有0x00000002权限（SECTION_MAP_WRITE）。需要更多
信息，可以查看MSDN中的Security win32 API [9]


--[ 4 - 玩转\\Device\\PhysicalMemory

为什么要来处理\\Device\\PhysicalMemory？我可以说用来读、写、修补内存。这已经足够了。


----[ 4.1 读写内存

我们开始吧……

为了读写\\Device\\PhysicalMemory，必须：

1、打开对象句柄 (NtOpenSection)
2、转化虚拟内存地址为物理地址
3、映射section到物理空间 (NtMapViewOfSection)
4、在被映射的内存中读写数据
5、关闭section的映射 (NtUnmapViewOfSection)
6、关闭对象句柄 (NtClose)

现在我们的主要目的是怎么转化虚拟内存地址为物理地址。我们知道在核心模式(ring0)，有一个函
数 MmGetPhysicalAddress (ntoskrnl.exe)可以做到。但是我们现在在ring3，因此必须来“模拟”这个
函数。

---
from ntddk.h
PHYSICAL_ADDRESS MmGetPhysicalAddress(void *BaseAddress);
---

PHYSICAL_ADDRESS是quad-word (64 bits)的。原本打算在文章开头分析一下汇编代码，但是它太长
了。地址转化也很普通，我只想快点进行这个题目。

quad-word的低位被传递给eax，高位传递给edx。要转化虚拟地址到物理地址，可以有两种办法：

* case 0x80000000 <= BaseAddress < 0xA0000000:
我们唯一要做的只是提供一个0x1FFFF000掩码虚拟地址

* case BaseAddress < 0x80000000 && BaseAddress >= 0xA0000000
这种办法对于我们来说有点问题，因为我们并没有办法在这个范围转化地址，因为我们需要读cr3记
录或者运行非ring3可调用的汇编指令。需要更多信息，可参考Intel Software Developer\'s Manual
Volume 3 (see [5]).

EliCZ告诉我，以他的经验可以猜测一个物理地址偏移掩码，保留部分的索引。掩码：0xFFFF000

这是一个轻量级版本的MmGetPhysicalAddress()

PHYSICAL_MEMORY MyGetPhysicalAddress(void *BaseAddress) {
if (BaseAddress < 0x80000000 || BaseAddress >= 0xA0000000) {
return(BaseAddress & 0xFFFF000);
}
return(BaseAddress & 0x1FFFF000);
}

对于限定地址边界为[0x80000000, 0xA0000000]主要是这情况不能更成功地猜测正确。这就是为什么
如果你想更准确最好还是调用实际上的MmGetPhysicalAddress()。我们可以在一些章节中看到怎么做的。

请参考程序：See winkdump.c

使用winkdump之后，我意识到实际上还存在另外的问题。当转化0x877ef000以上的虚拟地址，物理地
址得到的结果是0x00000000077e0000以上，但在我的系统上根本不可能！

kd> dd MmHighestPhysicalPage l1
dd MmHighestPhysicalPage l1
8046a04c 000077ef

从上看出最后的物理页面定位在0x0000000077ef0000。这意味着我们只能dump一小片内存，但总之本
文的目的是为了得到更好的了解关于怎么用\\Device\\PhysicalMemory，而不只是做一个好的memory dumper。
虽然可dump的范围是ntoskrnl.exe 和 HAL.dll (Hardware Abstraction Layer)映射的区域，你仍然可以
做一些工具来dump系统调用表：

kd> ? KeServiceDescriptorTable
? KeServiceDescriptorTable
Evaluate expression: -2142852224 = 8046ab80

0x8046ab80是系统服务表结构，象这样的：

typedef struct _SST {
PDWORD ServiceTable; // array of entry points
PDWORD CounterTable; // array of usage counters
DWORD ServiceLimit; // number of table entries
PBYTE ArgumentTable; // array of byte counts
} SST, *PSST;


C:\\coding\\phrack\\winkdump\\Release>winkdump.exe 0x8046ab80 16
*** win2k memory dumper using \\Device\\PhysicalMemory ***

Virtual Address : 0x8046ab80
Allocation granularity: 65536 bytes
Offset : 0xab80
Physical Address : 0x0000000000460000
Mapped size : 45056 bytes
View size : 16 bytes

d8 04 47 80 00 00 00 00 f8 00 00 00 bc 08 47 80 | ..G...........G.

Array of pointers to syscalls: 0x804704d8 (symbol KiServiceTable)
Counter table : NULL
ServiceLimit : 248 (0xf8) syscalls
Argument table : 0x804708bc (symbol KiArgumentTable)

我们还没有dump248个系统调用地址，只是看了看类似这样的：

C:\\coding\\phrack\\winkdump\\Release>winkdump.exe 0x804704d8 12
*** win2k memory dumper using \\Device\\PhysicalMemory ***

Virtual Address : 0x804704d8
Allocation granularity: 65536 bytes
Offset : 0x4d8
Physical Address : 0x0000000000470000
Mapped size : 4096 bytes
View size : 12 bytes

bf b3 4a 80 6b e8 4a 80 f3 de 4b 80 | ..J.k.J...K.

* 0x804ab3bf (NtAcceptConnectPort)
* 0x804ae86b (NtAccessCheck)
* 0x804bdef3 (NtAccessCheckAndAuditAlarm)

在下面一节，我们会理解什么是callgate，以及我们同\\Device\\PhysicalMemory怎么用它们去解决
刚才地址转化的问题。


----[ 4.2 什么是 callgate

callgate是一种能让程序运行在比它实际权限更高权限下的机制。比如，ring3的程序可以去执行
ring0代码。

要创建一个callgate，必须指定：
1) 需要代码执行在什么ring等级
2) 当跳转到ring0时会被执行的函数地址
3) 传递给函数的参数

当callgate被访问的时候，处理器首先进行权限检查，保存当前的SS，ESP，CS，EIP寄存器，然后
加载segment selector和新的堆栈指针（ring0堆栈），从TSS到SS，EIP寄存器。这个指针就可以指到新
的ring0堆栈。SS和ESP寄存器被PUSH到堆栈中，参数被拷贝。CS和EIP（保存的）PUSH到堆栈中去调用程
序到新的堆栈。新的segment selector被加载用来处理从callgate被加载到CS和EIP中的新的代码片段和
指令指针。最后，它跳转到在创建callgate时候指定的函数地址。

一旦完成后，在ring0执行的函数必须清除自己的堆栈，这就是为什么我们在代码中定义函数的时候
要用_declspec(naked)(MS VC++ 6) (类似GCC中的__attribute__(stdcall))

---
from

--------------------------------------------------------------------------------
相关信息:

如何在windows程序中读取bios内容（物理内存内容） (5千字)(火翼[CCG] 3-2 2:13 阅读 502)
中国的Cracker水平开始提高技术了 !! Toye快放 \"精\" !! (空)(WinDos2K 3-2 6:17 阅读 17)
老兄的写文速度真是惊人！佩服佩服！ (空)(夜月 3-2 8:18 阅读 2)
火翼兄强，学习仰慕中 (空)(呆呆豆 3-2 9:37 阅读 1)
好东西，收藏哦！ (空)(doskey 3-2 10:53 阅读 2)
98下不知是什么结果？待试。 (空)(ircbox 3-2 11:45 阅读 1)
98下面可以进入ring0去读取 (空)(lllaaa[BCG] 3-2 13:22 阅读 4)
98下没有这几个api（准确地说是只有个空壳），进入ring0读取就好了 (空)(火翼[CCG] 3-2 13:51 阅读 2)
Cool! (空)(Nnewell 3-2 11:54 阅读 0)
以上的代码有毛病，我今天test一天了，MSDN里头说要在passive_level下面才能执行成功！ (72字)(夜月 3-2 15:22 阅读 22)
没有什么问题啊， (104字)(pll621 3-2 15:26 阅读 39)
能不能把你的程序发给我？我看看。我用的masm23，OpenSection的时候总是返回80000002h (17字)(夜月 3-2 16:00 阅读 4)
我的是vc写的，你要么？ (空)(pll621 3-2 16:43 阅读 0)
读出来的东西确实是f000:0000的内容，在我的机器上好像每次的一样，没仔细比较 (77字)(火翼[CCG] 3-2 16:00 阅读 16)
贴段98下相同功能的代码 (1千字)(pll621 3-2 16:03 阅读 132)
大家通报一声，测试BIOS ID,BIOS　DATE是否偏移地址是固定的。 (250字)(ircbox 3-2 16:36 阅读 26)
yes (1千字)(pll621 3-2 16:41 阅读 69)
我的系统：Win2000 Server。 (空)(夜月 3-2 17:20 阅读 0)
我的Win32Asm源代码，死活不正确！ (1千字)(夜月 3-2 17:18 阅读 67)
哪位帮忙看看怎么会不对呢？火翼的程序在我机器上执行完全正常。 (空)(夜月 3-2 17:21 阅读 0)
不错 (1千字)(bbbsl 3-2 17:27 阅读 57)
例程和源代码下载见内 (37字)(火翼[CCG] 3-2 16:45 阅读 117)
哪位老大能不能帮忙看看为什么我的ASM代码不正确？ (87字)(夜月 3-2 22:31 阅读 13)
我这几天有点忙，不一定有时间，你发个可执行文件过来吧，我找时间看一下 (54字)(火翼[CCG] 3-2 23:43 阅读 5)
一个字“强！！！！！！！！！！”。 (32千字)(柯南[CCG] 昨天13:38 阅读 99)
接！ (34千字)(柯南[CCG] 昨天13:40 阅读 49)
接 (18千字)(柯南[CCG] 昨天13:42 阅读 44)
接 (2千字)(柯南[CCG] 昨天13:44 阅读 50)
好文章！收藏研究！火翼兄，我已经把可执行文件发到你的邮箱，用S-ice跟一下即可 (223字)(夜月 昨天14:55 阅读 5)
英文版 http://www.phrack-dont-give-a-shit-about-dmca.org/phrack/59/p59-0x10.txt (空)(WinDos2K 昨天15:44 阅读 17)

--------------------------------------------------------------------------------
发布响应:
  响应信息前,请确认您发表的信息符合中华人民共和国法律法规、本站规定，并符合本论坛的主题。
声明：

这个是  火翼[CCG]   的 例子

//write By 火翼[CCG]
// biossave.cpp : 定义应用程序的入口点。
//
#include \"stdafx.h\"
#include \"biossave.h\"
#define MAX_LOADSTRING 100

//write By 火翼[CCG]
typedef struct _UNICODE_STRING {
  USHORT  Length;//长度
  USHORT  MaximumLength;//最大长度
  PWSTR  Buffer;//缓存指针，访问物理内存时，此处指向UNICODE字符串\"\\device\\physicalmemory\"
} UNICODE_STRING,*PUNICODE_STRING;


//write By 火翼[CCG]
typedef struct _OBJECT_ATTRIBUTES {
    ULONG Length;//长度 18h
    HANDLE RootDirectory;//  00000000
    PUNICODE_STRING ObjectName;//指向对象名的指针
    ULONG Attributes;//对象属性00000040h
    PVOID SecurityDescriptor;        // Points to type SECURITY_DESCRIPTOR，0
    PVOID SecurityQualityOfService;  // Points to type SECURITY_QUALITY_OF_SERVICE，0
} OBJECT_ATTRIBUTES;
typedef OBJECT_ATTRIBUTES *POBJECT_ATTRIBUTES;

typedef DWORD  (__stdcall *ZWOS)(PHANDLE,ACCESS_MASK,POBJECT_ATTRIBUTES);
typedef DWORD  (__stdcall *ZWMV)(HANDLE,HANDLE,PVOID,ULONG,ULONG,PLARGE_INTEGER,PSIZE_T,DWORD,ULONG,ULONG);
typedef DWORD  (__stdcall *ZWUMV)(HANDLE,PVOID);


//write By 火翼[CCG]
// 全局变量：
HINSTANCE hInst; // 当前实例
TCHAR szTitle[MAX_LOADSTRING]; // 标题栏文本
TCHAR szWindowClass[MAX_LOADSTRING]; // 主窗口类名


//write By 火翼[CCG]
// 此代码模块中包含的函数的前向声明：
int APIENTRY _tWinMain(HINSTANCE hInstance,
                     HINSTANCE hPrevInstance,
                     LPTSTR    lpCmdLine,
                     int       nCmdShow)
{
  // TODO: 在此放置代码。
MSG msg;
HACCEL hAccelTable;
UNICODE_STRING struniph;
OBJECT_ATTRIBUTES obj_ar;
ZWOS ZWopenS;
ZWMV ZWmapV;
ZWUMV ZWunmapV;
HANDLE hSection;
HMODULE hinstLib;
DWORD ba;
LARGE_INTEGER so;
SIZE_T ssize;
so.LowPart=0x000f0000;//物理内存的基址，就是f000:0000
so.HighPart=0x00000000;
ssize=0xffff;
wchar_t strPH[30]=L\"\\\\device\\\\physicalmemory\";
FILE *f1;

//write By 火翼[CCG]

// 初始化全局字符串
//变量初始化
    ba=0;//联系后的基址将在这里返回
    struniph.Buffer=strPH;
struniph.Length=0x2c;//注意大小是按字节算
struniph.MaximumLength =0x2e;//也是字节
    obj_ar.Attributes =64;//属性
obj_ar.Length =24;//OBJECT_ATTRIBUTES类型的长度
obj_ar.ObjectName=&struniph;//指向对象的指针
obj_ar.RootDirectory=0;
obj_ar.SecurityDescriptor=0;
    obj_ar.SecurityQualityOfService =0;
//读入ntdll.dll,得到函数地址
    hinstLib = LoadLibrary(\"ntdll.dll\");
ZWopenS=(ZWOS)GetProcAddress(hinstLib,\"ZwOpenSection\");
    ZWmapV=(ZWMV)GetProcAddress(hinstLib,\"ZwMapViewOfSection\");
ZWunmapV=(ZWUMV)GetProcAddress(hinstLib,\"ZwUnmapViewOfSection\");
//调用函数，对物理内存进行映射
    ZWopenS(&hSection,4,&obj_ar);
ZWmapV((HANDLE)hSection,(HANDLE)0xffffffff,&ba,0,0xffff,&so,&ssize,1,0,2);
    f1=fopen(\"bios.mem\",\"wb+\");
fwrite((void*)ba,65536,1,f1);
fclose(f1);
MessageBox(NULL,\"Bios saved to bios.mem!\",\"Save OK\",MB_OK);
return 0;

}
//write By 火翼[CCG]

老兄这篇文章是在什么论坛上？

                              新来的客人想发言必须注册！请点击此处！  


原有信息:
序 号:257109
标 题:一个字“强！！！！！！！！！！”。 (32千字)
发信人:柯南[CCG]
时 间:2003-3-3 13:38:34
阅读次数:99
详细信息:

朋友的水平，真是另人刮目相待，读了这片文章有醍醐灌顶之感。遗憾的是有写地方我能力有限，没有看透，呵呵（笑..........)。
.....

转错了阿，完全不相干 :)

存储CMOS当前状态，然后执行读写操作，最后恢复。地址为0x70，数据为0x71，难道还有比这更简单的吗？