WonderGate/bplXX.mopera.ne.jp: Difference between revisions

From WSdev Wiki
Jump to navigationJump to search
No edit summary
No edit summary
 
(8 intermediate revisions by the same user not shown)
Line 1: Line 1:
For the MobileWonderGate software, NTT DoCoMo operated network servers for validating and redirecting URL requests:
For the MobileWonderGate software, NTT DoCoMo operated network servers for handling URL requests:


* <code>bpl01.mopera.ne.jp</code>
* <code>bpl01.mopera.ne.jp</code>
Line 5: Line 5:


These servers listened on TCP port 5555 for request packets in the following format, and issued a response in the same format.
These servers listened on TCP port 5555 for request packets in the following format, and issued a response in the same format.
Pages accessed via the mopera network server reported themselves as <code>Mozilla/3.0 (compatible; InfoBridge-mopera 1.1.1; Linux)</code>, as opposed to the browser's own <code>SWAN/1.0</code>.


== Packet format ==
== Packet format ==
Line 35: Line 37:
| Response type:
| Response type:
* 0x0010 - response: allow + 0 blocks
* 0x0010 - response: allow + 0 blocks
* 0x0012 - response: deny + 1 block
* 0x0012 - response: deny/redirect? + 1 block
* 0x0021 - response: require ID/password + 1 block
* 0x0021 - response: require ID/password + 1 block
* 0x0023 - response: unknown (too large?) + 0 blocks
* 0x0023 - response: unknown (too large?) + 0 blocks
|-
|-
| 0x04 || 4 || Total packet size in bytes, including all headers and blocks
| 0x04 || 4? (>= 2) || Total packet size in bytes, including all headers and blocks
|-
| 0x08 || 4 || Unknown
|-
|-
| 0x0C || 4 || Unknown
| 0x08<br/>
0x0F
| ?
| Unknown
|-
|-
| 0x10 || 4 || Unknown (216.0.192.1?)
| 0x10 || 4? || Unknown (216.0.192.1?)
|-
|-
| 0x14 || 4 || Unknown (255.255.0.0?)
| 0x14 || 4? || Unknown (255.255.0.0?)
|}
|}


Line 67: Line 70:
* 0x22 - 0x00? byte, followed by query field name string, followed by query field value string
* 0x22 - 0x00? byte, followed by query field name string, followed by query field value string
|}
|}
=== Multipart blocks ===
Sending a block with a block size of <code>0xFFFF</code> and a block type of <code>0x00</code> in a response will trigger a multipart block mode, which sends data in portions between a header and footer.
While the <code>0xFFFF/0x00</code> preamble has to be included in the total length from the global header, the remainder of the multipart block section does not have to be.
{| class="wikitable"
|+ Header
! Offset
! Length
! Description
|-
| 0x00 || 1 || Number of parts?
|-
| 0x01<br/>
0x04
| ?
| Unknown
|}
{| class="wikitable"
|+ Part
! Offset
! Length
! Description
|-
| 0x00<br/>
0x01
| ?
| Unknown
|-
| 0x02
| 2
| Length of data, in bytes
|-
| 0x04<br/>
0x05
| ?
| Unknown
|-
| 0x06...
| <length>
| Data
|}
{| class="wikitable"
|+ Footer
! Offset
! Length
! Description
|-
| 0x00<br/>
0x01
| ?
| Unknown
|}
== TODO ==
* How does one send an HTTP response through the bridge? This has to be possible, as the bridge had its own distinct user agent.

Latest revision as of 08:29, 22 August 2023

For the MobileWonderGate software, NTT DoCoMo operated network servers for handling URL requests:

  • bpl01.mopera.ne.jp
  • bpl02.mopera.ne.jp

These servers listened on TCP port 5555 for request packets in the following format, and issued a response in the same format.

Pages accessed via the mopera network server reported themselves as Mozilla/3.0 (compatible; InfoBridge-mopera 1.1.1; Linux), as opposed to the browser's own SWAN/1.0.

Packet format

Every packet sent from and to the server follows the same format: a global header, followed by an arbitrary number of blocks with their respective headers.

Header

Offset Length Description
0x00 1 Unknown, always 0x01
0x01 1 Header size in bytes, always 0x18
0x02 2 Request type/Browser configuration: 
ee?i ?s?w ???? ??p?
|| |  | |        +- POST request
|| |  | +---------- Width: 0 = 1-screen, 1 = 2-screen
|| |  +------------ Image size: 0 = 50%, 1 = 100%
|| +--------------- Images: 0 = enabled, 1 = disabled
++----------------- Encoding: 0 = auto, 1 = S-JIS, 2 = EUC
Response type:
  • 0x0010 - response: allow + 0 blocks
  • 0x0012 - response: deny/redirect? + 1 block
  • 0x0021 - response: require ID/password + 1 block
  • 0x0023 - response: unknown (too large?) + 0 blocks
0x04 4? (>= 2) Total packet size in bytes, including all headers and blocks
0x08

0x0F

? Unknown
0x10 4? Unknown (216.0.192.1?)
0x14 4? Unknown (255.255.0.0?)

Block header

Blocks typically consist of zero-terminated strings - a final zero appears to be omitted.

Offset Length Description
0x00 2 Block size in bytes, including header
0x02 1 Block type:
  • 0x01 - 0x00? byte, followed by requested URL string
  • 0x03 - 0x00? byte, followed by previous URL string (referrer?)
  • 0x11 - ID string, followed by PASS string
  • 0x22 - 0x00? byte, followed by query field name string, followed by query field value string

Multipart blocks

Sending a block with a block size of 0xFFFF and a block type of 0x00 in a response will trigger a multipart block mode, which sends data in portions between a header and footer.

While the 0xFFFF/0x00 preamble has to be included in the total length from the global header, the remainder of the multipart block section does not have to be.

Header
Offset Length Description
0x00 1 Number of parts?
0x01

0x04

? Unknown
Part
Offset Length Description
0x00

0x01

? Unknown
0x02 2 Length of data, in bytes
0x04

0x05

? Unknown
0x06... <length> Data
Footer
Offset Length Description
0x00

0x01

? Unknown

TODO

  • How does one send an HTTP response through the bridge? This has to be possible, as the bridge had its own distinct user agent.
Retrieved from "https://ws.nesdev.org/w/index.php?title=WonderGate/bplXX.mopera.ne.jp&oldid=96"