Editing DS4-BT

Jump to navigation Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.

Latest revision Your text
Line 45: Line 45:
In comparison, USB has 250x (4ms)
In comparison, USB has 250x (4ms)


=== Overlapping channels BT/Wi-Fi ===
=== Overlapping channels BT/WiFi ===
* [[Bluetooth#Overlapping_channels_BT.2FWiFi|Overlapping channels BT/WiFi]]


* [[Wireless#Overlapping_channels_BT.2FWi-Fi|Overlapping channels BT/Wi-Fi]]
=== Bluetooth Adressing ===
 
=== Bluetooth Addressing ===


Each Bluetooth unit has a unique 48-bit address (BD_ADDR).
Each Bluetooth unit has a unique 48-bit address (BD_ADDR).
Line 211: Line 210:
**0x0100: L2CAP
**0x0100: L2CAP
*0x0800: Maximum Attribute Byte count (2048)?
*0x0800: Maximum Attribute Byte count (2048)?
*0x3505: Data element (Type descriptor: 6, Size index: 5) 5 bytes
*0x0A: Data element (type:1, Size index: 2 (4 bytes)
**0x0A: Data element (type:1, Size index: 2 (4 bytes))
**0x0000FFFF: Attribute ID list
**0x0000FFFF: Attribute ID list
*0x00: Continuation State
*0x00: Continuation State
Line 600: Line 598:
===== 0x01 =====
===== 0x01 =====
The transaction type is DATA (0x0a), and the report type is INPUT (0x01).
The transaction type is DATA (0x0a), and the report type is INPUT (0x01).
The protocol code is 0x01.
The protocol code is 0x11.


This report is sent until the GET REPORT FEATURE 0x02 is received.
This report is sent until the GET REPORT FEATURE 0x02 is received.
Line 764: Line 762:
|-
|-
|[16 - 17]
|[16 - 17]
|colspan="8"|Angular velocity X
|colspan="8"|Acceleration X
|-
|-
|[18 - 19]
|[18 - 19]
|colspan="8"|Angular velocity Y
|colspan="8"|Acceleration Y
|-
|-
|[20 - 21]
|[20 - 21]
|colspan="8"|Angular velocity Z
|colspan="8"|Acceleration Z
|-
|-
|[22 - 23]
|[22 - 23]
|colspan="8"|Acceleration X
|colspan="8"|Gyroscope Roll?
|-
|-
|[24 - 25]
|[24 - 25]
|colspan="8"|Acceleration Y
|colspan="8"|Gyroscope Yaw?
|-
|-
|[26 - 27]
|[26 - 27]
|colspan="8"|Acceleration Z
|colspan="8"|Gyroscope Pitch?
|-
|-
|[28 - 32]
|[28 - 32]
Line 814: Line 812:
|colspan="8"|finger 2 coordinates
|colspan="8"|finger 2 coordinates
|-
|-
|[46]
|[36]
|colspan="8"|packet counter
|colspan="8"|packet counter
|-
|-
Line 899: Line 897:
The protocol code is 0x11.
The protocol code is 0x11.


First bit at byte 2 specifies whether to enable control. Byte at index 4 specifies which individual control to enable.
Byte at index 4 changes from 0xf0 to 0xf3 in the first reports. Making it always 0xf0 does not seem to change something.


Report example:
Report example:
Line 907: Line 905:
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, <span style="background:lime">0xd8, 0x8e, 0x94, 0xdd</span>
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, <span style="background:lime">0xd8, 0x8e, 0x94, 0xdd</span>
Speculation:
0x11 may be not a packet ID but encoded packet size.
Lower digit (0x01) satisfies formula: '''((packet_size - 15) >> 6) + 1'''
(packet_size does not include '0xa2'; >> - bit shift right - equivalent to integer division by 64)
This formula seems to work for all packets (0x11..0x18).
Packet 0x19 looks like clamped by max packet size.


{| class="wikitable"
{| class="wikitable"
Line 936: Line 927:
|colspan="8"|'''0x11'''
|colspan="8"|'''0x11'''
|-
|-
|[2]
|[2 - 3]
|colspan="1"|Controls
|colspan="7"|Unknown
|-
|[3]
|colspan="8"|Unknown
|colspan="8"|Unknown
|-
|-
|[4]
|[4]
|colspan="4"|0x0f
|colspan="8"|0xf0 disables the rumble motors, 0xf3 enables them
|colspan="1"|Unknown
|colspan="1"|Flash
|colspan="1"|Color
|colspan="1"|Rumble
|-
|-
|[5 - 6]
|[5 - 6]
Line 1,073: Line 1,056:
     0030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
     0030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
     0040  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
     0040  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
     0050  00 00 00 <span style="background:pink;">f6 69</span> 02 <span style="background:#ffff00;">9c 75 19 24</span> 00 00 00 00 00 00  ....i..u.$......
     0050  00 00 00 f6 69 02 9c 75 19 24 00 00 00 00 00 00  ....i..u.$......
     0060  00 00 76 db 6d bb 6d b6 dd b6 db 6e db 6d b7 6d  ..v.m.m....n.m.m
     0060  00 00 76 db 6d bb 6d b6 dd b6 db 6e db 6d b7 6d  ..v.m.m....n.m.m
     0070  b6 db b6 db 6d db 6d b6 ed b6 db 76 db 6d bb 6d  ....m.m....v.m.m
     0070  b6 db b6 db 6d db 6d b6 ed b6 db 76 db 6d bb 6d  ....m.m....v.m.m
Line 1,080: Line 1,063:
     00a0  b7 6d b6 db b6 db 6d db 6d b6 ed b6 db 76 db 6d  .m....m.m....v.m
     00a0  b7 6d b6 db b6 db 6d db 6d b6 ed b6 db 76 db 6d  .m....m.m....v.m
     00b0  bb 6d b6 dd b6 db 6e db 6d b7 6d b6 db b6 db 6d  .m....n.m.m....m
     00b0  bb 6d b6 dd b6 db 6e db 6d b7 6d b6 db b6 db 6d  .m....n.m.m....m
     00c0  db 6d b6 ed b6 db <span style="background:#ffff00;">9c 75 19 24</span> 00 00 00 00 00 00  .m.....u.$......
     00c0  db 6d b6 ed b6 db 9c 75 19 24 00 00 00 00 00 00  .m.....u.$......
     00d0  00 00 76 db 6d bb 6d b6 dd b6 db 6e db 6d b7 6d  ..v.m.m....n.m.m
     00d0  00 00 76 db 6d bb 6d b6 dd b6 db 6e db 6d b7 6d  ..v.m.m....n.m.m
     00e0  b6 db b6 db 6d db 6d b6 ed b6 db 76 db 6d bb 6d  ....m.m....v.m.m
     00e0  b6 db b6 db 6d db 6d b6 ed b6 db 76 db 6d bb 6d  ....m.m....v.m.m
Line 1,343: Line 1,326:


==== HID features reports ====
==== HID features reports ====
There is a periodic report sequence that consists in 5 0xf0 SET FEATURE reports, 2 0xf2 GET FEATURE reports, and 19 0xf1 GET FEATURE REPORTS. Each sequence takes about 30 seconds, and a new sequence starts about 30 seconds after the end of the last one. There is 1 second between two reports sent by the PS4.
There is another periodic report sequence that consists in one 0x03 SET FEATURE report and 1 0x04 GET FEATURE report. A new sequence starts about 30 seconds after the end of the last one. The 0x03 SET FEATURE report is sent 5 seconds after the 0x04 GET FEATURE report.
These two periodic sequences seem to be independent as they do not have the same period, and they have two distinct sequence counters.
A user-mode application can obtain (get) and set feature information by using this report designation.
A user-mode application can obtain (get) and set feature information by using this report designation.
===== GET FEATURE=====
====== 0x02 ======


===== GET FEATURE=====
====== 0x04 ======


Each GET FEATURE report sent by the PS4 is answered by the DS4 with a DATA FEATURE report.
====== 0x06 ======


====0x02====
The transaction type is DATA (0x0a), and the report type is FEATURE (0x03).
The protocol code is 0x06.


{| class="wikitable"
The bytes in this report do not seem to fluctuate. They are the same in two different controllers.
 
Report example:
<pre>0xa3, 0x06, 0x41, 0x75, 0x67, 0x20, 0x20, 0x33, 0x20, 0x32, 0x30, 0x31, 0x33, 0x00, 0x00, 0x00,
0x00, 0x00, 0x30, 0x37, 0x3a, 0x30, 0x31, 0x3a, 0x31, 0x32, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x01, 0x00, 0x31, 0x03, 0x00, 0x00, 0x00, 0x49, 0x00, 0x05, 0x00, 0x00, 0x80,
0x03, 0x00, 0x4b, 0x52, 0x02, 0xc7</pre>
 
{| class="wikitable"
|+Data Format
|+Data Format
|-
|-
Line 1,371: Line 1,359:
|-
|-
|[0]
|[0]
|colspan="4"|0x04 GET REPORT
|colspan="4"|0x0a
|colspan="1"|0x01
|colspan="2"|0x00
|colspan="1"|0x00
|colspan="4"|0x03
|colspan="4"|0x03 FEATURE
|-
|-
|[1]
|[1]
|colspan="8"|Report id
|colspan="8"|0x06
|-
|[2 - 49]
|colspan="8"|A date: Aug 3 2013 07:01:12
|-
|-
|[2 - 3]
|[50 - 53]
|colspan="8"|Buffer size.
|colspan="8"|CRC-32 of the previous bytes.
|}
|}


====== 0x02 ======
====== 0xA3 ======


The transaction type is DATA (0x0a), and the report type is FEATURE (0x03).
The transaction type is DATA (0x0a), and the report type is FEATURE (0x03).
The protocol code is 0x02.
The protocol code is 0xa3.


The bytes in this report do not seem to fluctuate.
It is identical to 0x06 except that there's no CRC-32 at the end of the packet.


Report example:
Report example:
<pre>0xa3, 0x02, 0x01, 0x00, 0xff, 0xff, 0x01, 0x00, 0x5e, 0x22, 0x84, 0x22, 0x9b, 0x22, 0xa6, 0xdd,
<pre>0xa3, 0xa3, 0x41, 0x75, 0x67, 0x20, 0x20, 0x33, 0x20, 0x32, 0x30, 0x31, 0x33, 0x00, 0x00, 0x00,
0x79, 0xdd, 0x64, 0xdd, 0x1c, 0x02, 0x1c, 0x02, 0x85, 0x1f, 0x9f, 0xe0, 0x92, 0x20, 0xdc, 0xe0,
0x00, 0x00, 0x30, 0x37, 0x3a, 0x30, 0x31, 0x3a, 0x31, 0x32, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x4d, 0x1c, 0x1e, 0xde, 0x08, 0x00</pre>
0x00, 0x00, 0x00, 0x01, 0x00, 0x31, 0x03, 0x00, 0x00, 0x00, 0x49, 0x00, 0x05, 0x00, 0x00, 0x80,
0x03, 0x00</pre>


{| class="wikitable"
{| class="wikitable"
Line 1,414: Line 1,405:
|-
|-
|[1]
|[1]
|colspan="8"|0x02
|colspan="8"|0xa3
|-
|-
|[2 - 37]
|[2 - 49]
|colspan="8"|TODO, work in progress.
|colspan="8"|A date: Aug 3 2013 07:01:12
|}
|}


====== 0x04 ======
====== 0xF1 ======
 
02 15 20 08 00 04 00 41 00 4b f1 40 00


The transaction type is DATA (0x0a), and the report type is FEATURE (0x03).
====== 0xF2 ======
The protocol code is 0x04.


Most bytes from index 4 change between two reports.
===== SET FEATURE=====


Report example:
====== 0x03 ======
<pre>0xa3, 0x04, 0x02, 0x00, 0x38, 0x85, 0x35, 0xd5, 0x7a, 0x81, 0x61, 0x2e, 0x21, 0x13, 0x7b, 0xda,
0xd5, 0x94, 0x25, 0x98, 0x5f, 0x67, 0xd1, 0x60, 0x9d, 0xfb, 0x95, 0xba, 0xff, 0xba, 0x1c, 0x48,
0xbf, 0xe2, 0x15, 0x0d, 0xff, 0x66, 0x63, 0x5f, 0x64, 0xc1, 0x46, 0x47, 0xcd, 0xd1, 0x9c, 0x84</pre>


{| class="wikitable"
====== 0xF0 ======
|+Data Format
|-
|width="100"|byte index
|width="60"|bit 7
|width="60"|bit 6
|width="60"|bit 5
|width="60"|bit 4
|width="60"|bit 3
|width="60"|bit 2
|width="60"|bit 1
|width="60"|bit 0
|-
|[0]
|colspan="4"|0x0a
|colspan="2"|0x00
|colspan="4"|0x03
|-
|[1]
|colspan="8"|0x04
|-
|[2]
|colspan="8"|sequence counter (init = 0x02, step = 1)
|-
|[3]
|colspan="8"|0x00
|-
|[4 - 43]
|colspan="8"|TODO, work in progress.
|-
|[44 - 47]
|colspan="8"|CRC-32 of the previous bytes.
|}
 
====== 0x06 ======
 
The transaction type is DATA (0x0a), and the report type is FEATURE (0x03).
The protocol code is 0x06.
 
The bytes in this report do not seem to fluctuate. They are the same in two different controllers.
 
Report example:
<pre>0xa3, 0x06, 0x41, 0x75, 0x67, 0x20, 0x20, 0x33, 0x20, 0x32, 0x30, 0x31, 0x33, 0x00, 0x00, 0x00,
0x00, 0x00, 0x30, 0x37, 0x3a, 0x30, 0x31, 0x3a, 0x31, 0x32, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x01, 0x00, 0x31, 0x03, 0x00, 0x00, 0x00, 0x49, 0x00, 0x05, 0x00, 0x00, 0x80,
0x03, 0x00, 0x4b, 0x52, 0x02, 0xc7</pre>
 
{| class="wikitable"
|+Data Format
|-
|width="100"|byte index
|width="60"|bit 7
|width="60"|bit 6
|width="60"|bit 5
|width="60"|bit 4
|width="60"|bit 3
|width="60"|bit 2
|width="60"|bit 1
|width="60"|bit 0
|-
|[0]
|colspan="4"|0x0a
|colspan="2"|0x00
|colspan="4"|0x03
|-
|[1]
|colspan="8"|0x06
|-
|[2 - 49]
|colspan="8"|A date: Aug 3 2013 07:01:12
|-
|[50 - 53]
|colspan="8"|CRC-32 of the previous bytes.
|}
 
====== 0xA3 ======
 
The transaction type is DATA (0x0a), and the report type is FEATURE (0x03).
The protocol code is 0xa3.
 
It is identical to 0x06 except that there's no CRC-32 at the end of the packet.
 
Report example:
<pre>0xa3, 0xa3, 0x41, 0x75, 0x67, 0x20, 0x20, 0x33, 0x20, 0x32, 0x30, 0x31, 0x33, 0x00, 0x00, 0x00,
0x00, 0x00, 0x30, 0x37, 0x3a, 0x30, 0x31, 0x3a, 0x31, 0x32, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x01, 0x00, 0x31, 0x03, 0x00, 0x00, 0x00, 0x49, 0x00, 0x05, 0x00, 0x00, 0x80,
0x03, 0x00</pre>
 
{| class="wikitable"
|+Data Format
|-
|width="100"|byte index
|width="60"|bit 7
|width="60"|bit 6
|width="60"|bit 5
|width="60"|bit 4
|width="60"|bit 3
|width="60"|bit 2
|width="60"|bit 1
|width="60"|bit 0
|-
|[0]
|colspan="4"|0x0a
|colspan="2"|0x00
|colspan="4"|0x03
|-
|[1]
|colspan="8"|0xa3
|-
|[2 - 49]
|colspan="8"|A date: Aug 3 2013 07:01:12
|}
 
====== 0xF1 ======
The transaction type is DATA (0x0a), and the report type is FEATURE (0x03).
The protocol code is 0xf1.
 
This report is part of the authentication sequence: it contains challenge response data.
 
Report example:
<pre>0xa3, 0xf1, 0x01, 0x00, 0x00, 0x0c, 0xb2, 0x25, 0x71, 0x82, 0xc3, 0x2e, 0xaa, 0x73, 0xf5, 0x3e,
0x06, 0x72, 0x12, 0xeb, 0xd7, 0xbd, 0xa6, 0x4e, 0xd0, 0x25, 0xd0, 0x4d, 0xd4, 0xe9, 0x3a, 0x8d,
0xb4, 0xf2, 0x3b, 0x5e, 0x82, 0x9c, 0xc7, 0x02, 0x04, 0xa5, 0x44, 0xd5, 0x64, 0x74, 0xc2, 0x03,
0x3b, 0x45, 0xd6, 0x99, 0x9d, 0x79, 0x11, 0xa6, 0x3d, 0x5e, 0x3a, 0xdf, 0xdd, 0x3a, 0x51, 0x8e,
0xb3</pre>
 
{| class="wikitable"
|+Data Format
|-
|width="100"|byte index
|width="60"|bit 7
|width="60"|bit 6
|width="60"|bit 5
|width="60"|bit 4
|width="60"|bit 3
|width="60"|bit 2
|width="60"|bit 1
|width="60"|bit 0
|-
|[0]
|colspan="4"|0x0a
|colspan="2"|0x00
|colspan="4"|0x03
|-
|[1]
|colspan="8"|0xf1
|-
|[2]
|colspan="8"|sequence counter (init = 0x01, step = 1)
|-
|[3]
|colspan="8"|report counter (init = 0x00, step = 1, max = 0x12)
|-
|[4]
|colspan="8"|0x00
|-
|[5 - 60]
|colspan="8"|Challenge response data.
|-
|[61 - 64]
|colspan="8"|CRC-32 of the previous bytes.
|}
 
The sequence is 1040 bytes long with the following structure:
 
<pre>
struct ds4_response {
unsigned char signature[0x100];
unsigned char serial_num[0x10];
unsigned char n[0x100];
unsigned char e[0x100];
unsigned char casig[0x100];
};
</pre>
 
<u>signature</u> - is a PSS signature of the nonce, signed with DS4's private key<br>
<u>serial_num</u> - is the controller/cert serial number<br>
<u>n</u> - DS4's Public Key prime<br>
<u>e</u> - DS4's Public Key exponent<br>
<u>casig</u> - is a PSS signature (signed by Sony's CA private key) of the <u>serial_num</u>, <u>n</u> and <u>e</u><br>
 
The last (19th) packet is padded with 24 bytes.
 
====== 0xF2 ======
 
The transaction type is DATA (0x0a), and the report type is FEATURE (0x03).
The protocol code is 0xf2.
 
This report is part of the authentication sequence: it indicates if the challenge response is ready.
 
Report example:
<pre>0xa3, 0xf2, 0x01, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0d, 0x6a, 0x3c,
0xef</pre>
 
{| class="wikitable"
|+Data Format
|-
|width="100"|byte index
|width="60"|bit 7
|width="60"|bit 6
|width="60"|bit 5
|width="60"|bit 4
|width="60"|bit 3
|width="60"|bit 2
|width="60"|bit 1
|width="60"|bit 0
|-
|[0]
|colspan="4"|0x0a
|colspan="2"|0x00
|colspan="4"|0x03
|-
|[1]
|colspan="8"|0xf2
|-
|[2]
|colspan="8"|sequence counter (init = 0x01, step = 1)
|-
|[3]
|colspan="3"|0x00
|colspan="1"|0x01 = not ready
0x00 = ready
|colspan="7"|0x00
|-
|[4 - 12]
|colspan="8"|padded with 0x00.
|-
|[13 - 16]
|colspan="8"|CRC-32 of the previous bytes.
|}
 
===== SET FEATURE=====
These reports are sent by the PS4. The DS4 replies with a handshake, which is a packet with a single 0x00 byte.
 
====== 0x03 ======
 
The transaction type is SET REPORT (0x05), and the report type is FEATURE (0x03).
The protocol code is 0x03.
 
Most bytes from index 4 change between two reports.
 
Report example:
<pre>0x53, 0x03, 0x02, 0x00, 0xf1, 0xdf, 0xd3, 0x7b, 0x4f, 0x49, 0x0b, 0x0b, 0x7c, 0x79, 0xde, 0xad,
0x5d, 0xa3, 0x41, 0x8a, 0x9c, 0x2e, 0xaf, 0x09, 0xc4, 0xa6, 0x80, 0xb4, 0x82, 0x87, 0x2c, 0xbf,
0x86, 0xe0, 0x2a, 0x86, 0x60, 0xa0, 0x23, 0x33</pre>
 
{| class="wikitable"
|+Data Format
|-
|width="100"|byte index
|width="60"|bit 7
|width="60"|bit 6
|width="60"|bit 5
|width="60"|bit 4
|width="60"|bit 3
|width="60"|bit 2
|width="60"|bit 1
|width="60"|bit 0
|-
|[0]
|colspan="4"|0x05
|colspan="2"|0x00
|colspan="4"|0x03
|-
|[1]
|colspan="8"|0x03
|-
|[2]
|colspan="8"|sequence counter (init = 0x02, step = 1)
|-
|[3]
|colspan="8"|0x00
|-
|[4 - 35]
|colspan="8"|TODO, work in progress.
|-
|[36 - 39]
|colspan="8"|CRC-32 of the previous bytes.
|}
 
====== 0xF0 ======
 
 
The transaction type is SET REPORT (0x05), and the report type is FEATURE (0x03).
The protocol code is 0xf0.
 
This report is part of the authentication sequence: it contains challenge data.
 
Report example:
<pre>0x53, 0xf0, 0x01, 0x00, 0x00, 0x64, 0x01, 0x21, 0x58, 0x26, 0x03, 0xcc, 0xb8, 0x28, 0x78, 0xa9,
0xb5, 0x8c, 0x2c, 0x90, 0x3b, 0xe2, 0xf7, 0xee, 0x1c, 0x91, 0x2b, 0x0c, 0x79, 0xa6, 0xe7, 0xae,
0x7e, 0x49, 0xee, 0x36, 0x72, 0x81, 0xc2, 0x25, 0x41, 0x74, 0x45, 0x01, 0x15, 0xa0, 0x23, 0x1a,
0x4c, 0x27, 0x31, 0xcc, 0xc5, 0xe0, 0x8d, 0x6c, 0x1e, 0x42, 0x83, 0x93, 0x20, 0xa0, 0x35, 0xac,
0x82</pre>
 
{| class="wikitable"
|+Data Format
|-
|width="100"|byte index
|width="60"|bit 7
|width="60"|bit 6
|width="60"|bit 5
|width="60"|bit 4
|width="60"|bit 3
|width="60"|bit 2
|width="60"|bit 1
|width="60"|bit 0
|-
|[0]
|colspan="4"|0x05
|colspan="2"|0x00
|colspan="4"|0x03
|-
|[1]
|colspan="8"|0xf0
|-
|[2]
|colspan="8"|sequence counter (init = 0x01, step = 1)
|-
|[3]
|colspan="8"|report counter (init = 0x00, step = 1, max = 0x04)
|-
|[4]
|colspan="8"|0x00
|-
|[5 - 60]
|colspan="8"|Challenge data.
|-
|[61 - 64]
|colspan="8"|CRC-32 of the previous bytes.
|}
 
The packet with report counter = 0x04 only carries 32 bytes of data (it is padded with zeros). Therefore the length of the challenge message is 4x56+32 = 256 bytes.




{{Reverse Engineering}}
{{Reverse Engineering}}
<noinclude>[[Category:Main]]</noinclude>
<noinclude>[[Category:Main]]</noinclude>
Please note that all contributions to PS4 Developer wiki are considered to be released under the GNU Free Documentation License 1.2 (see PS4 Developer wiki:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following hCaptcha:

Cancel Editing help (opens in new window)