OpenWrt 的世界︰樹莓派 3B 【路由器】移星轉斗《四‧五》 Scapy 七

有人說大腦是個不設防的城市,因此務須警醒『人』『言』,切莫偏『信』的好。早在網景推出『JavaScript』網頁手稿語言︰

JavaScript,一種高階程式語言,通過解釋執行,是一門動態型別物件導向基於原型)的直譯語言[4]。它已經由ECMA(歐洲電腦製造商協會)通過ECMAScript實現語言的標準化[4]。它被世界上的絕大多數網站所使用,也被世界主流瀏覽器ChromeIEFireFoxSafariOpera)支援。JavaScript是一門基於原型、函式先行的語言[5],是一門多範式的語言,它支援物件導向編程,指令式編程,以及函數語言程式設計。它提供語法來操控文字,陣列,日期以及正規表示式等,不支援I/O,比如網路,儲存和圖形等,但這些都可以由它的宿主環境提供支援。

雖然JavaScript與Java這門語言不管是在名字上,或是在語法上都有很多相似性,但這兩門程式語言從設計之初就有很大的不同,JavaScript的語言設計主要受到了Self(一種原型程式設計語言)和Scheme(一門函數語言程式設計語言)的影響[5]。在語法結構上它又與C語言有很多相似(例如if條件語句、while迴圈、switch語句、do-while迴圈等)[6]

在用戶端,JavaScript在傳統意義上被實現為一種解釋語言,但在最近,它已經可以被即時編譯(JIT)執行。隨著最新的HTML5CSS3語言標準的推行它還可用於遊戲、桌面和行動應用程式的開發和在伺服器端網路環境執行,如Node.js

時,就已經知道可能的資安疑慮。所以瀏覽器才將 JavaScript 程式放在

沙盒 (電腦安全)

計算機安全領域,沙盒英語:sandbox,又譯為沙箱)是一種安全機制,為執行中的程式提供的隔離環境。通常是作為一些來源不可信、具破壞力或無法判定程式意圖的程式提供實驗之用[1]

沙盒通常嚴格控制其中的程式所能存取的資源,比如,沙盒可以提供用後即回收的磁碟及記憶體空間。在沙盒中,網路存取、對真實系統的存取、對輸入裝置的讀取通常被禁止或是嚴格限制。從這個角度來說,沙盒屬於虛擬化的一種。

沙盒中的所有改動對作業系統不會造成任何損失。通常,這種技術被電腦技術人員廣泛用於測試可能帶毒的程式或是其他的惡意代碼[2]

裡執行!這樣不就安全了嗎?殊不知由於廠商追求產品特色,大開便門;使用者以為安全,隨意打開權限;加上許多其他原由︰

………

造成的資安問題或許更勝於『電腦病毒』的哩??

─── 《樹莓派 0W 狂想曲︰資安探測器《♪♪》

 

市場『競爭』所引發之『攻防』,是否是軟體『門戶』的由來耶?

Undocumented feature

Undocumented features also known using the term Feature, not a bug are software features that are frequently found in software releases. Sometimes the documentation is omitted through simple oversight, but undocumented features are often essential elements of the software that are not intended for use by end users, but left available for use by the vendor for software support and development.

Since the suppliers of the software usually consider the software documentation to constitute a contract for the behavior of the software, undocumented features are generally left unsupported, and may be removed or changed at will and without notice to the users.

Types

Undocumented features (for example, the ability to change the switch character in MS-DOS, usually to a hyphen) can be included for compatibility purposes (in this case with Unix utilities) or for future-expansion reasons. However; if the software provider changes their software strategy to better align with the business, the absence of documentation makes it easier to justify the feature’s removal.

New versions of software might omit mention of old (possibly superseded) features in documentation but keep them implemented for users who’ve grown accustomed to them.[1]

While an incorrect use of the term, in some cases software bugs are referred to -jokingly- as undocumented features. (“It’s not a bug; it’s an undocumented feature!“) [2] This usage may have been popularised in some of Microsoft’s responses to bug reports for its first Word for Windows product,[3] but doesn’t originate there. The oldest surviving reference on Usenet dates to 5 March 1984.[4] Between 1969 and 1972, Sandy Mathes, a systems programmer for PDP-8 software at Digital Equipment Corporation (DEC) in Maynard, MA, used the terms “bug” and “feature” in her reporting of test results to distinguish between undocumented actions of delivered software products that were unacceptable and tolerable, respectively. This usage may have been perpetuated.[5]

Exceptions

Ironically, undocumented features themselves have become a major feature of computer games. Developers often include various cheats and other special features (“easter eggs“) that are not explained in the packaged material, but have become part of the “buzz” about the game on the Internet and among gamers. The undocumented features of foreign games are often elements that were not localized from their native language.

Closed source APIs can also have undocumented functions that are not generally known. These are sometimes used to gain a commercial advantage over third-party software by providing additional information or better performance to the application provider.

 

『非官方』之『擴充』,是否都『可疑』乎??

TCP/UDP埠列表

電腦之間依照網際網路傳輸層TCP/IP協定的協定通訊,不同的協定都對應不同的。並且,利用資料包的UDP也不一定和TCP採用相同的埠號碼。以下為兩種通訊協定的埠列表連結:

埠狀態顏色圖例

以下圖例表明了埠的狀態:

使用狀態 敘述 顏色
官方 應用與埠組合記錄在IANA的埠分配列表中[1]
非官方 應用與埠組合不在IANA的埠分配列表中
多重使用 已知多個應用程式使用這個埠

0到1023號埠

以下列表僅列出常用埠,詳細的列表請參閱IANA網站。

描述 狀態
0/TCP,UDP 保留埠;不使用(若傳送過程不準備接受回覆訊息,則可以作為源埠) 官方
1/TCP,UDP TCPMUX(傳輸控制協定埠服務多路開關選擇器) 官方
5/TCP,UDP RJE(遠端作業登入) 官方
7/TCP,UDP Echo(回顯)協定 官方
9/UDP DISCARD(丟棄)協定 官方
9/TCP,UDP 網路喚醒 非官方
11/TCP,UDP SYSTAT協定 官方
13/TCP,UDP DAYTIME協定 官方
15/TCP,UDP NETSTAT協定 官方
17/TCP,UDP QOTD(Quote of the Day,每日參照)協定 官方
18/TCP,UDP 訊息傳送協定 官方
19/TCP,UDP CHARGEN(字元發生器)協定 官方
20/TCP,UDP 檔案傳輸協定 – 預設資料埠 官方
21/TCP,UDP 檔案傳輸協定 – 控制埠 官方
22/TCP,UDP SSH(Secure Shell) – 遠端登入協定,用於安全登入檔案傳輸SCPSFTP)及埠重新定向 官方
23/TCP,UDP Telnet終端仿真協定 – 未加密文字通訊 官方
25/TCP,UDP SMTP(簡單郵件傳輸協定) – 用於郵件伺服器間的電子郵件傳遞 官方

………

 

或許未來的

Communication protocol

In telecommunication, a communication protocol is a system of rules that allow two or more entities of a communications system to transmit information via any kind of variation of a physical quantity. The protocol defines the rules, syntax, semantics andsynchronization of communication and possible error recovery methods. Protocols may be implemented by hardware, software, or a combination of both.[1][not in citation given]

Communicating systems use well-defined formats for exchanging various messages. Each message has an exact meaning intended to elicit a response from a range of possible responses pre-determined for that particular situation. The specified behavior is typically independent of how it is to be implemented. Communication protocols have to be agreed upon by the parties involved.[2] To reach agreement, a protocol may be developed into a technical standard. A programming language describes the same for computations, so there is a close analogy between protocols and programming languages: protocols are to communication what programming languages are to computations.[3]

Multiple protocols often describe different aspects of a single communication. A group of protocols designed to work together are known as a protocol suite; when implemented in software they are a protocol stack.

Internet communication protocols are published by the Internet Engineering Task Force (IETF). The IEEE handles wired and wireless networking, and the International Organization for Standardization (ISO) handles other types. The ITU-T handles telecommunication protocols and formats for the public switched telephone network (PSTN). As the PSTN and Internet converge, the standards are also being driven towards convergence.

 

『創新』者,在

Adding new protocols

Adding new protocol (or more correctly: a new layer) in Scapy is very easy. All the magic is in the fields. If the fields you need are already there and the protocol is not too brain-damaged, this should be a matter of minutes.

Simple example

A layer is a subclass of the Packet class. All the logic behind layer manipulation is held by thePacket class and will be inherited. A simple layer is compounded by a list of fields that will be either concatenated when assembling the layer or dissected one by one when disassembling a string. The list of fields is held in an attribute named fields_desc. Each field is an instance of a field class:

class Disney(Packet):
    name = "DisneyPacket "
    fields_desc=[ ShortField("mickey",5),
                 XByteField("minnie",3) ,
                 IntEnumField("donald" , 1 ,
                      { 1: "happy", 2: "cool" , 3: "angry" } ) ]

In this example, our layer has three fields. The first one is a 2-byte integer field named mickey and whose default value is 5. The second one is a 1-byte integer field named minnie and whose default value is 3. The difference between a vanilla ByteField and an XByteField is only the fact that the preferred human representation of the field’s value is in hexadecimal. The last field is a 4-byte integer field named donald. It is different from a vanilla IntField by the fact that some of the possible values of the field have literate representations. For example, if it is worth 3, the value will be displayed as angry. Moreover, if the “cool” value is assigned to this field, it will understand that it has to take the value 2.

If your protocol is as simple as this, it is ready to use:

>>> d=Disney(mickey=1)
>>> ls(d)
mickey : ShortField = 1 (5)
minnie : XByteField = 3 (3)
donald : IntEnumField = 1 (1)
>>> d.show()
###[ Disney Packet ]###
mickey= 1
minnie= 0x3
donald= happy
>>> d.donald="cool"
>>> raw(d)
’\x00\x01\x03\x00\x00\x00\x02’
>>> Disney( )
<Disney mickey=1 minnie=0x3 donald=cool |>

This chapter explains how to build a new protocol within Scapy. There are two main objectives:

  • Dissecting: this is done when a packet is received (from the network or a file) and should be converted to Scapy’s internals.
  • Building: When one wants to send such a new packet, some stuff needs to be adjusted automatically in it.

 

之前,務須『慎思』也!

※ 註︰

 

『方便』其後『蛻變』的人,展翅高飛呦◎

Next-generation network

The next-generation network (NGN) is a body of key architectural changes in telecommunication core and access networks. The general idea behind the NGN is that one network transports all information and services (voice, data, and all sorts of media such as video) by encapsulating these into IP packets, similar to those used on the Internet. NGNs are commonly built around the Internet Protocol, and therefore the term all IP is also sometimes used to describe the transformation of formerly telephone-centric networks toward NGN.

NGN is a different concept from Future Internet, which is more focused on the evolution of Internet in terms of the variety and interactions of services offered.

Introduction of NGN

NGN Seminar in Fusion Technology Center byNICT(Japan) researcher

According to ITU-T, the definition is:

A next-generation network (NGN) is a packet-based network which can provide services including Telecommunication Services and is able to make use of multiple broadband, quality of Service-enabled transport technologies and in which service-related functions are independent from underlying transport-related technologies. It offers unrestricted access by users to different service providers. It supports generalized mobility which will allow consistent and ubiquitous provision of services to users.[1]

From a practical perspective, NGN involves three main architectural changes that need to be looked at separately:

  • In the core network, NGN implies a consolidation of several (dedicated or overlay) transport networks each historically built for a different service into one core transport network (often based on IP and Ethernet). It implies amongst others the migration of voice from a circuit-switched architecture (PSTN) to VoIP, and also migration of legacy services such as X.25, frame relay (either commercial migration of the customer to a new service like IP VPN, or technical emigration by emulation of the “legacy service” on the NGN).
  • In the wired access network, NGN implies the migration from the dual system of legacy voice next to xDSL setup in local exchanges to a converged setup in which the DSLAMs integrate voice ports or VoIP, making it possible to remove the voice switching infrastructure from the exchange.[2]
  • In the cable access network, NGN convergence implies migration of constant bit rate voice to CableLabs PacketCable standards that provide VoIP and SIP services. Both services ride over DOCSIS as the cable data layer standard.

In an NGN, there is a more defined separation between the transport (connectivity) portion of the network and the services that run on top of that transport. This means that whenever a provider wants to enable a new service, they can do so by defining it directly at the service layer without considering the transport layer – i.e. services are independent of transport details. Increasingly applications, including voice, tend to be independent of the access network (de-layering of network and applications) and will reside more on end-user devices (phone, PC, set-top box).