I am trying to implement RADIUS protocol. As per the RFC 2866, for RADIUS Accounting, when calculating the Authenticator field these are the steps:
The Authenticator field in an Accounting-Response packet is called
the Response Authenticator, and contains a one-way MD5 hash
calculated over a stream of octets consisting of the Accounting-
Response Code, Identifier, Length, the Request Authenticator field
from the Accounting-Request packet being replied to, and the
response attributes if any, followed by the shared secret. The
resulting 16 octet MD5 hash value is stored in the Authenticator
field of the Accounting-Response packet.
I am trying to calculate it and I can not get the right value:
Code = 5 (0x05) 1 byte
Identifier: 134 (0x86) 1 byte
Length: 20 (0x0014) 2 bytes
Request Authenticator: bac85592365b2e786ad3095a1cf22646 , 16 bytes
There are no Attributes in my response
Shared-secret: 63 21 6d 40 35 32 32 35 (c!m#5225)
so the input for the MD% hash would be:
05860014bac85592365b2e786ad3095a1cf2264663216d4035323235
and I get:
b7ac1e6909302b06bd021aede380dbc5 using these 2 web sites: http://www.md5hashgenerator.com/ and http://www.miraclesalad.com/webtools/md5.php
The actual response has the Authenticator as 9629702dca9469714fb423ca7b1525bc
i am comparing looking at real RADIUS packets being sent by the client/server and the Authenticator that I calculate does not match the one sent by the Server. Any ideas what can be it?
The RFC 2865 at the end has a couple of examples. Example 1, using the shared
secret "xyzzy5461"
User Telnet to Specified Host
The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
RADIUS Server for a user named nemo logging in on port 3 with
password "arctangent".
The Request Authenticator is a 16 octet random number generated by
the NAS.
The User-Password is 16 octets of password padded at end with nulls,
XORed with MD5(shared secret|Request Authenticator).
01 00 00 38 0f 40 3f 94 73 97 80 57 bd 83 d5 cb
98 f4 22 7a 01 06 6e 65 6d 6f 02 12 0d be 70 8d
93 d4 13 ce 31 96 e4 3f 78 2a 0a ee 04 06 c0 a8
01 10 05 06 00 00 00 03
1 Code = Access-Request (1)
1 ID = 0
2 Length = 56
16 Request Authenticator
Attributes:
6 User-Name = "nemo"
18 User-Password
6 NAS-IP-Address = 192.168.1.16
6 NAS-Port = 3
The RADIUS server authenticates nemo, and sends an Access-Accept UDP
packet to the NAS telling it to telnet nemo to host 192.168.1.3.
The Response Authenticator is a 16-octet MD5 checksum of the code
(2), id (0), Length (38), the Request Authenticator from above, the
attributes in this reply, and the shared secret.
02 00 00 26 86 fe 22 0e 76 24 ba 2a 10 05 f6 bf
9b 55 e0 b2 06 06 00 00 00 01 0f 06 00 00 00 00
0e 06 c0 a8 01 03
1 Code = Access-Accept (2)
1 ID = 0 (same as in Access-Request)
2 Length = 38
16 Response Authenticator
Attributes:
6 Service-Type (6) = Login (1)
6 Login-Service (15) = Telnet (0)
6 Login-IP-Host (14) = 192.168.1.3
Problem solved! The online md5 tools expect strings, so even though I was passing the bytes values it was being treated as string, hence the wrong value.
Related
I try to create an elliptic public key by calculate the point on curve from a given number ( my private key ), so I have the coordinates (x,y) of elliptic curve point
I get the coordinates by
myPublicKeyCoordinates = myPrivateKeyValue * GPointOnCurve
How can i build the PEM ( or DER ) file for my public key?
I don't care about language (java, python, javascript, ...)
because i want to known how build the file ( even if i write every single byte... )
Assuming you already know about ITU-T X.680-201508 (the ASN.1 language) and ITU-T X.690-201508 (the BER (and CER) and DER encodings for ASN.1 data), the main defining document for Elliptic Curve Keys and their representation is https://www.secg.org/sec1-v2.pdf from the Standards for Efficient Cryptography Group (not the US Securites and Exchange Commission).
Section C.3 (Syntax for Elliptic Curve Public Keys) says that the general transport container for an EC public key is the X.509 SubjectPublicKeyInfo structure:
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier {{ECPKAlgorithms}} (WITH COMPONENTS
{algorithm, parameters}) ,
subjectPublicKey BIT STRING
}
The possible "algorithms" (which really means key encoding types) is the open-ended set
ECPKAlgorithms ALGORITHM ::= {
ecPublicKeyType |
ecPublicKeyTypeRestricted |
ecPublicKeyTypeSupplemented |
{OID ecdh PARMS ECDomainParameters {{SECGCurveNames}}} |
{OID ecmqv PARMS ECDomainParameters {{SECGCurveNames}}},
...
}
ecPublicKeyType ALGORITHM ::= {
OID id-ecPublicKey PARMS ECDomainParameters {{SECGCurveNames}}
}
...
ECDomainParameters came from C.2:
ECDomainParameters{ECDOMAIN:IOSet} ::= CHOICE {
specified SpecifiedECDomain,
named ECDOMAIN.&id({IOSet}),
implicitCA NULL
}
C.3 mentions about halfway through
The elliptic curve public key (a value of type ECPoint that is an OCTET STRING) is mapped to a subjectPublicKey (a value encoded as type BIT STRING) as follows: The most significant bit of the value of the OCTET STRING becomes the most significant bit of the value of the BIT STRING and so on with consecutive bits until the least significant bit of the OCTET STRING becomes the least significant bit of the BIT STRING.
So we seek backwards and find
An elliptic curve point itself is represented by the following type
ECPoint ::= OCTET STRING
whose value is the octet string obtained from the conversion routines given in Section 2.3.3.
2.3.3 (Elliptic-Curve-Point-to-Octet-String Conversion) has a lot of words, but the best supported format is not using point compression (and P != the point at infinity)
If P = (xP , yP ) != O and point compression is not being used, proceed as follows:
3.1. Convert the field element xP to an octet string X of length (log2 q)/8 octets using the conversion routine specified in Section 2.3.5.
3.2. Convert the field element yP to an octet string Y of length (log2 q)/8 octets using the conversion routine specified in Section 2.3.5.
3.3. Output M = 0416 || X || Y .
2.3.5 is a whole lot of words for "big endian byte order of a length long enough to hold all values in the field" (aka "leave in leading zeros").
So now we party.
Given the FIPS 186-3 reference key on secp256r1 (d=70A12C2DB16845ED56FF68CFC21A472B3F04D7D6851BF6349F2D7D5B3452B38A),
Q is
(8101ECE47464A6EAD70CF69A6E2BD3D88691A3262D22CBA4F7635EAFF26680A8, D8A12BA61D599235F67D9CB4D58F1783D3CA43E78F0A5ABAA624079936C0C3A9)
And the public key DER looks like
// SubjectPublicKeyInfo
30 XA
// AlgorithmIdentifier
30 XB
// AlgorithmIdentifier.id (id-ecPublicKey (1.2.840.10045.2.1))
06 07 2A 86 48 CE 3D 02 01
// AlgorithmIdentifier.parameters, using the named curve id (1.2.840.10045.3.1.7)
06 08 2A 86 48 CE 3D 03 01 07
// SubjectPublicKeyInfo.subjectPublicKey
03 XC 00
// Uncompressed public key
04
// Q.X
81 01 EC E4 74 64 A6 EA D7 0C F6 9A 6E 2B D3 D8
86 91 A3 26 2D 22 CB A4 F7 63 5E AF F2 66 80 A8
// Q.Y
D8 A1 2B A6 1D 59 92 35 F6 7D 9C B4 D5 8F 17 83
D3 CA 43 E7 8F 0A 5A BA A6 24 07 99 36 C0 C3 A9
Count up all the bytes for XA, XB, and XC:
XC = 32 (Q.X) + 32 (Q.Y) + 1 (0x04) + 1 (0x00 for the unused bits) = 66 = 0x42
XB = 19 = 0x13
XA is then 66 + 19 + 2 (tag bytes) + 2 (length bytes) = 89 = 0x59
(And, of course, if any of our length values exceeded 0x7F we would have had to encode them correctly)
So now we are left with
30 59 30 13 06 07 2A 86 48 CE 3D 02 01 06 08 2A
86 48 CE 3D 03 01 07 03 42 00 04 81 01 EC E4 74
64 A6 EA D7 0C F6 9A 6E 2B D3 D8 86 91 A3 26 2D
22 CB A4 F7 63 5E AF F2 66 80 A8 D8 A1 2B A6 1D
59 92 35 F6 7D 9C B4 D5 8F 17 83 D3 CA 43 E7 8F
0A 5A BA A6 24 07 99 36 C0 C3 A9
And, we verify:
$ xxd -r -p | openssl ec -text -noout -inform der -pubin
read EC key
<paste, then hit CTRL+D>
30 59 30 13 06 07 2A 86 48 CE 3D 02 01 06 08 2A
86 48 CE 3D 03 01 07 03 42 00 04 81 01 EC E4 74
64 A6 EA D7 0C F6 9A 6E 2B D3 D8 86 91 A3 26 2D
22 CB A4 F7 63 5E AF F2 66 80 A8 D8 A1 2B A6 1D
59 92 35 F6 7D 9C B4 D5 8F 17 83 D3 CA 43 E7 8F
0A 5A BA A6 24 07 99 36 C0 C3 A9
Private-Key: (256 bit)
pub:
04:81:01:ec:e4:74:64:a6:ea:d7:0c:f6:9a:6e:2b:
d3:d8:86:91:a3:26:2d:22:cb:a4:f7:63:5e:af:f2:
66:80:a8:d8:a1:2b:a6:1d:59:92:35:f6:7d:9c:b4:
d5:8f:17:83:d3:ca:43:e7:8f:0a:5a:ba:a6:24:07:
99:36:c0:c3:a9
ASN1 OID: prime256v1
NIST CURVE: P-256
Printing it as "Private-Key: (256-bit)" is just a bug/quirk of the tool, there's no private key there.
Things are harder for specified parameter curves, but those don't interoperate well (https://www.rfc-editor.org/rfc/rfc5480#section-2.1.1 says that a conforming CA MUST NOT use the specified parameter form, or the implicit form, but MUST use the named form).
I'm programming a low level communication with an Epson tm-t88iv thermal printer on a Linux device, which receives only hexadecimal packages. I have read the manual trying to understand how the checksum is built but i can't manage to recreate it.
the manual says that the checksum are 4 bytes representing the 2 bytes sum of all the data in the package sent.
I have currently four working examples I found by listening to a port on a windows computer with a different program. the last 4 hexadecimals are the checksum (03 marks the end of the data and is included in the checksum calculation, according to the manual).
02 AC 00 01 1C 00 00 03 30 30 43 45
02 AC 00 00 1C 80 80 1C 00 00 1C 00 00 1C 03 30 32 32 31
02 AD 07 01 1C 00 00 1C 31 30 03 30 31 35 33
02 AD 00 00 1C 80 80 1C 00 00 1C 00 00 1C 03 30 32 32 32
I have read somewhere that there is a sum32 algorithm but i can't find any example of it or how to program it.
Wow, this is a bad algorithm! If someone else finds himself trying to understand Epson's terrible low-level communication manual, this is how the check-sum is done:
The checksum base is 30 30 30 30
Sum in hexadecimals all of the data package (for example, 02+89+00+00+1C+80+80+1C+00+01+1C+09+0C+1C+03 = 214)
Then separate the result digit by digit, if its a letter add 1 to the value (for example B2 would be 2|1|4).
sum it to the checksum base number by number starting from right to left (this would be a checksum of 30 32 31 34).
Note: It works perfectly, but for some reason the examples I posted above don't seem to match so much. They are all the printers response, but slightly after it got a hardware problem and had to be reformatted by technical support, so maybe it got fixed.
I hope it helps somebody somewhere.
I am converting a application to use IPP .net API V3. I have already built all the OAuth and saved the token info. Trying to make connection but always get error. I have checked and recheck all the token data and it appears correct. Where did I go wrong? I am using the DevDefined for OAuth and Intuit.Ipp from NuGet (IPP API V3). I am using my test customer token info but noticed the base URL (from the IPP library) is https://quickbooks.api.intuit.com/. Should that still work?
Dim accessToken As String = QBOE.GetOAuthItem(Profile.Common.StoreNum, "accessToken")
Dim accessTokenSecret As String = QBOE.GetOAuthItem(Profile.Common.StoreNum, "accessTokenSecret")
Dim consumerKey As String = ConfigurationManager.AppSettings("consumerKey")
Dim consumerSecret As String = ConfigurationManager.AppSettings("consumerSecret")
Dim oauthValidator As OAuthRequestValidator = New OAuthRequestValidator(accessToken, accessTokenSecret, consumerKey, consumerSecret)
Dim CompanyID As String = QBOE.GetOAuthItem(Profile.Common.StoreNum, "CompanyID")
Dim appToken As String = ConfigurationManager.AppSettings("applicationToken")
Dim context As ServiceContext = New ServiceContext(appToken, CompanyID, IntuitServicesType.QBO, oauthValidator)
Dim service As DataService = New DataService(context)
Dim customer As Customer = New Customer()
'Mandatory Fields
customer.GivenName = "Mary"
customer.Title = "Ms."
customer.MiddleName = "Jayne"
customer.FamilyName = "Cooper"
Dim resultCustomer As Customer = TryCast(service.Add(customer), Customer)
Error Message (errors on service.Add)
Intuit.Ipp.Exception.InvalidTokenException was unhandled by user code
I checked the calls within fiddler2 and noticed the calls for my OAuth is going through workplace.intuit.com:443 but the IPP calls go through quickbooks.api.intuit.com:443. I also noticed fiddler2 list the IPP call with a Result of 200. Output shown below.
HeaderText:
CONNECT quickbooks.api.intuit.com:443 HTTP/1.1
Host: quickbooks.api.intuit.com
Proxy-Connection: Keep-Alive
The data sent represents an SSLv3-compatible ClientHello handshake. For your convenience, the data is extracted below.
Major Version: 3
Minor Version: 1
Random: 53 2E 7C 6E A1 F4 02 4D 9D CF 60 C8 22 CA BC E8 67 6E D8 52 88 54 6F E7 D9 29 52 58 5C 2F 2E 52
SessionID: 9E 01 CB DB D6 C8 78 8D D0 E9 A6 5F 02 1E 2C 6D 5D 69 34 FE FD 3E A5 52 EE 19 07 E7 D9 D6 E5 30
Ciphers:
[002F] TLS_RSA_AES_128_SHA
[0035] TLS_RSA_AES_256_SHA
[0005] SSL_RSA_WITH_RC4_128_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA
[C013] TLS1_CK_ECDHE_RSA_WITH_AES_128_CBC_SHA
[C014] TLS1_CK_ECDHE_RSA_WITH_AES_256_CBC_SHA
[C009] TLS1_CK_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
[C00A] TLS1_CK_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
[0032] TLS_DHE_DSS_WITH_AES_128_SHA
[0038] TLS_DHE_DSS_WITH_AES_256_SHA
[0013] SSL_DHE_DSS_WITH_3DES_EDE_SHA
[0004] SSL_RSA_WITH_RC4_128_MD5
Reply Text:
HTTP/1.1 200 Blind-Connection Established
FiddlerGateway: Direct
StartTime: 01:17:18.298
EndTime: 01:17:18.536
This is a CONNECT tunnel, through which encrypted HTTPS traffic flows. To view the encrypted sessions inside this tunnel, ensure that the Tools > Fiddler Options > HTTPS > Decrypt HTTPS traffic option is checked.
The data sent represents an SSLv3-compatible ServerHello handshake. For your convenience, the data is extracted below.
Major Version: 3
Minor Version: 1
SessionID: 9E 01 CB DB D6 C8 78 8D D0 E9 A6 5F 02 1E 2C 6D 5D 69 34 FE FD 3E A5 52 EE 19 07 E7 D9 D6 E5 30
Random: 63 E2 D0 B1 09 45 E0 28 A4 3B 0B C2 E8 5F 08 F0 D5 F5 8E A7 47 D4 10 E2 D4 D7 5B C4 74 0B 4B E2
Cipher: 0x05
You can try this call as mentioned in the following docs using IPP provided .net devkit.
https://developer.intuit.com/docs/0025_quickbooksapi/0055_devkits/0150_ipp_.net_devkit_3.0/0002_synchronous_calls/0001_data_service_apis
401 clearly signifies that your OAuth tokens/request header is not correct.
To debug this, you can use any standard RestClients ( like RestClient plugins of Mozilla browser or Fiddler) where you can set four OAuth tokens [ consumer key, consumer Secret, access Key and access token) and content-type [application/xml]
URI: https://quickbooks.api.intuit.com/v3/company//customer
Method: POST
Content-Type: application/xml
Mozilla RestClient -
Set OAuth Tokens
Set Content-type ( in header )
https://developer.intuit.com/docs/0025_quickbooksapi/0050_data_services/030_entity_services_reference/customer
If the above approach works, that means your OAuth tokens are fine. You need to check and properly construct the header using devdefined then.
If it doesn't work then you need to generate a new set of access Token and Secret using IPP OAuth Playground.
https://appcenter.intuit.com/Playground/OAuth
Thanks
I have to integrate Passbook with a website that provides PDF417 barcodes with data encoded in binary (as opposed to text), such as this:
Is there any way I can encode this binary chunk in pass.json so that Passbook displays it on the iPhone identically to the original picture?
Again, I cannot switch to text-based barcodes because I do not own the data. Just for clarification, the attached picture contains a PDF417 barcode that, when decoded, contains non-printable characters, such as the NULL character, which is why I refer to it as binary.
UPDATE
This is how the image decodes into a byte array:
01 00 01 00 02 00 E7 C4 B5 96 B8 42 94 B3 B4 75
1A D1 F2 38 92 EA B5 0E 17 5D 0B 2A AA 64 18 CC
28 62 86 E5 74 5D A3 89 09 12 6E D5 7A 1A C9 EE
BF 23 9C E1 60 AD 9E DE 92 6D E5 79 99 C7 91 F1
6A D5 82 2E B6 E3 81 24 F8 0A F8 E6 44 5D 56 D2
00 00 00 00 00 00 40 0D 00 09 20 23 00 96 13 5C
10 EC 0C EA A3 E8 A3 20 30 4B 2A 20 7D 0F BB DF
F7 5E FA 1E 76 F7 40 20 10 08 04 02 81 40 20 30
A3 D5 6C 1A 04 76 14 10
This is how I try to transform it into a utf-8 string:
{"message": "\u0001\u0000\u0001\u0000\u0002\u0000\u00E7\u00C4\u00B5\u0096\u00B8\u0042\u0094\u00B3\u00B4\u0075\u001A\u00D1\u00F2\u0038\u0092\u00EA\u00B5\u000E\u0017\u005D\u000B\u002A\u00AA\u0064\u0018\u00CC\u0028\u0062\u0086\u00E5\u0074\u005D\u00A3\u0089\u0009\u0012\u006E\u00D5\u007A\u001A\u00C9\u00EE\u00BF\u0023\u009C\u00E1\u0060\u00AD\u009E\u00DE\u0092\u006D\u00E5\u0079\u0099\u00C7\u0091\u00F1\u006A\u00D5\u0082\u002E\u00B6\u00E3\u0081\u0024\u00F8\u000A\u00F8\u00E6\u0044\u005D\u0056\u00D2\u0000\u0000\u0000\u0000\u0000\u0000\u0040\u000D\u0000\u0009\u0020\u0023\u0000\u0096\u0013\u005C\u0010\u00EC\u000C\u00EA\u00A3\u00E8\u00A3\u0020\u0030\u004B\u002A\u0020\u007D\u000F\u00BB\u00DF\u00F7\u005E\u00FA\u001E\u0076\u00F7\u0040\u0020\u0010\u0008\u0004\u0002\u0081\u0040\u0020\u0030\u00A3\u00D5\u006C\u001A\u0004\u0076\u0014\u0010";}
However, Passbook does not display an equivalent barcode. In fact, it displays just a few first bytes.
I don't think you want to decode the binary data of the image, but instead want to read the data from the barcode as if it were scanned.
You could use a service like http://zxing.org/w/decode.jspx which gives you the value of the barcode as if it were being scanned.
Send the 'Raw Text' value to pass.json.
I haven't used this service, but after a quick read I'm assuming it goes in 'message' below:
"barcode" : {
"message" : "ABCD 123 EFGH 456 IJKL 789 MNOP",
"format" : "PKBarcodeFormatPDF417",
"messageEncoding" : "iso-8859-1"
}
ref: https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/PassKit_PG/Chapters/Creating.html#//apple_ref/doc/uid/TP40012195-CH4-SW1
I'm reading a book named 802.11 Wireless Networks The Definitive Guide(second edition) recently. I find myself unable to understand the algorithm of WEP shared-key authentication.
In the book, chapter 8.3, section "The legacy of shared-key authentication", it says
The third frame is the mobile station's response to the challenge. To prove that it is allowed on the network, the mobile station constructs a management frame with three information elements: the Authentication Algorithm Identifier, a Sequence Number of 3, and the Challenge Text. Before transmitting the frame, the mobile station processes the frame with WEP (BUT HOW???). The header identifying the frame as an authentication frame is preserved, but the information elements are hidden by WEP.
So, I'd like to ask the kind community here.
Here is my example WEP auth session packets captured with Tamosoft Commview for wifi 6.3.
AP MAC: 000E.2E7C.52A9 (Edimax)
Wifi client: 0020.4A96.23C7 (Lantronix WiPort)
WEP key is 437B7A57F6762CC7271EBB16FC
You can find my packet capture here: http://down.nlscan.com/misc/WEP128-shared-key-success-1.ncf
Packet #55,#57,#59,#61 is the WEP authentication packets. #59 is "the third frame".
============================================================================
Packet #55, Direction: Pass-through, Time:16:11:42.634285, Size: 30
Wireless Packet Info
Signal level: 100%
Rate: 2.0 Mbps
Band: 802.11g
Channel: 11 - 2462 MHz
802.11
Frame Control: 0x00B0 (176)
Protocol version: 0
To DS: 0
From DS: 0
More Fragments: 0
Retry: 0
Power Management: 0
More Data: 0
Protected Frame: 0
Order: 0
Type: 0 - Management
Subtype: 11 - Authentication
Duration: 0x0102 (258)
Destination Address: 00:0E:2E:7C:52:A9
Source Address: 00:20:4A:96:23:C7
BSS ID: 00:0E:2E:7C:52:A9
Fragment Number: 0x0000 (0)
Sequence Number: 0x000E (14)
Authentication
Algorithm Number: 0x0001 (1) - Shared Key
Transaction Sequence Number: 0x0001 (1)
Status Code: 0x0000 (0) - Successful
Raw Data:
0x0000 B0 00 02 01 00 0E 2E 7C-52 A9 00 20 4A 96 23 C7 °......|R©. J–#Ç
0x0010 00 0E 2E 7C 52 A9 E0 00-01 00 01 00 00 00 ...|R©à.......
============================================================================
Packet #57, Direction: Pass-through, Time:16:11:42.638429, Size: 160
Wireless Packet Info
Signal level: 100%
Rate: 1.0 Mbps
Band: 802.11g
Channel: 11 - 2462 MHz
802.11
Frame Control: 0x00B0 (176)
Protocol version: 0
To DS: 0
From DS: 0
More Fragments: 0
Retry: 0
Power Management: 0
More Data: 0
Protected Frame: 0
Order: 0
Type: 0 - Management
Subtype: 11 - Authentication
Duration: 0x013A (314)
Destination Address: 00:20:4A:96:23:C7
Source Address: 00:0E:2E:7C:52:A9
BSS ID: 00:0E:2E:7C:52:A9
Fragment Number: 0x0000 (0)
Sequence Number: 0x0343 (835)
Authentication
Algorithm Number: 0x0001 (1) - Shared Key
Transaction Sequence Number: 0x0002 (2)
Status Code: 0x0000 (0) - Successful
Challenge text: 28 B8 9B EC 79 C1 AC B6 24 AD 54 A5 5A 96 EE 24 3E 25 F2 D5 B8 11 1C 2F E9 8D 2B A2 63 EA 3D 1F 40 6E 8C 3D 2C 7E 37 E9 5C 9C F4 0E F2 9C 50 88 21 DA 35 09 97 AE E3 BA 4E 56 77 9A B4 B1 F2 34 E9 AD
Raw Data:
0x0000 B0 00 3A 01 00 20 4A 96-23 C7 00 0E 2E 7C 52 A9 °.:.. J–#Ç...|R©
0x0010 00 0E 2E 7C 52 A9 30 34-01 00 02 00 00 00 10 80 ...|R©04.......€
0x0020 28 B8 9B EC 79 C1 AC B6-24 AD 54 A5 5A 96 EE 24 (¸›ìyÁ¬¶$T¥Z–î$
0x0030 3E 25 F2 D5 B8 11 1C 2F-E9 8D 2B A2 63 EA 3D 1F >%òÕ¸../é+¢cê=.
0x0040 40 6E 8C 3D 2C 7E 37 E9-5C 9C F4 0E F2 9C 50 88 #nŒ=,~7é\œô.òœPˆ
0x0050 21 DA 35 09 97 AE E3 BA-4E 56 77 9A B4 B1 F2 34 !Ú5.—®ãºNVwš´±ò4
0x0060 E9 AD 8D 98 05 28 A1 AD-3F DA 66 05 60 66 EA 24 é˜.(¡?Úf.`fê$
0x0070 02 DA 14 AC 66 CD DC E6-93 A8 79 23 70 87 39 44 .Ú.¬fÍÜ擨y#p‡9D
0x0080 17 4E 0F AC A2 CA 9F 84-5F 94 66 3C 04 AB 86 8E .N.¬¢ÊŸ„_”f<.«†Ž
0x0090 99 78 AB C9 E9 C0 91 95-9E 52 B1 7C 6B 22 63 C0 ™x«ÉéÀ‘•žR±|k"cÀ
============================================================================
Packet #59, Direction: Pass-through, Time:16:11:42.639825, Size: 168
Wireless Packet Info
Signal level: 100%
Rate: 2.0 Mbps
Band: 802.11g
Channel: 11 - 2462 MHz
802.11
Frame Control: 0x40B0 (16560)
Protocol version: 0
To DS: 0
From DS: 0
More Fragments: 0
Retry: 0
Power Management: 0
More Data: 0
Protected Frame: 1
Order: 0
Type: 0 - Management
Subtype: 11 - Authentication
Duration: 0x0102 (258)
Destination Address: 00:0E:2E:7C:52:A9
Source Address: 00:20:4A:96:23:C7
BSS ID: 00:0E:2E:7C:52:A9
Fragment Number: 0x0000 (0)
Sequence Number: 0x000F (15)
Authentication
Algorithm Number: 0x1300 (4864) - Reserved
Transaction Sequence Number: 0x00F6 (246)
Status Code: 0xB4BA (46266) - Reserved
Raw Data:
0x0000 B0 40 02 01 00 0E 2E 7C-52 A9 00 20 4A 96 23 C7 °#.....|R©. J–#Ç
0x0010 00 0E 2E 7C 52 A9 F0 00-00 13 F6 00 BA B4 A9 F5 ...|R©ð...ö.º´©õ
0x0020 77 E9 5D 1F A2 B2 CE 3A-AD 1E FD 31 EA 55 90 B8 wé].¢²Î:.ý1êU¸
0x0030 56 F6 EF 81 CE C5 95 B6-9B 2F C4 77 BD E0 DD 73 VöïÎÅ•¶›/Äw½àÝs
0x0040 C6 C8 CE F6 0B 3F 0E 8D-08 15 93 5C 26 6E DA 17 ÆÈÎö.?...“\&nÚ.
0x0050 83 34 A2 53 51 65 3C AE-7A 5C A5 EA 04 97 6E F0 ƒ4¢SQe<®z\¥ê.—nð
0x0060 53 02 02 91 08 51 87 8E-83 38 CD 23 35 E7 56 1B S..‘.Q‡Žƒ8Í#5çV.
0x0070 1D A8 52 8F E1 D4 21 FD-46 41 65 AD 26 AB 74 3D .¨RáÔ!ýFAe&«t=
0x0080 E0 13 12 66 F5 C1 67 B3-71 7F 83 77 A0 34 16 55 à..fõÁg³qƒw 4.U
0x0090 25 96 31 01 A0 9C D9 13-1E 7C E6 8F 15 8D 8A 7B %–1. œÙ..|æ.Š{
0x00A0 8E 6B 65 97 74 0B 23 71- Žke—t.#q
============================================================================
Packet #61, Direction: Pass-through, Time:16:11:42.640916, Size: 30
Wireless Packet Info
Signal level: 100%
Rate: 1.0 Mbps
Band: 802.11g
Channel: 11 - 2462 MHz
802.11
Frame Control: 0x00B0 (176)
Protocol version: 0
To DS: 0
From DS: 0
More Fragments: 0
Retry: 0
Power Management: 0
More Data: 0
Protected Frame: 0
Order: 0
Type: 0 - Management
Subtype: 11 - Authentication
Duration: 0x013A (314)
Destination Address: 00:20:4A:96:23:C7
Source Address: 00:0E:2E:7C:52:A9
BSS ID: 00:0E:2E:7C:52:A9
Fragment Number: 0x0000 (0)
Sequence Number: 0x0344 (836)
Authentication
Algorithm Number: 0x0001 (1) - Shared Key
Transaction Sequence Number: 0x0004 (4)
Status Code: 0x0000 (0) - Successful
Raw Data:
0x0000 B0 00 3A 01 00 20 4A 96-23 C7 00 0E 2E 7C 52 A9 °.:.. J–#Ç...|R©
0x0010 00 0E 2E 7C 52 A9 40 34-01 00 04 00 00 00 ...|R©#4......
============================================================================
I know, from the book, how RC4 works and I have written a python program to verify how WEP encrypts a 802.11 packet.
The remaining issue is I just cannot figure out how WEP authentication algorithm works(how #59 is calculated.
Waiting for your generous help.
my speculation says that when the challenge is sent in cleartext, the mobile station picks a random IV and using the pre-shared WEP key, it encrypts the challenge using RC4 when IV is used as the first 3 bytes of the key. These 3 bytes are sent in clear over the channel. Then, the problem starts here as mentioned later in the book. Anyone who is listening to the communication, can eavesdrop and find out the challenge and the ciphertext, xoring these two, the attacker gets the keystream and asks for a new challenge and encrypts it with the same IV as the legitimate user and the same keystream. He can then simply authenticate, though he still does not know the WEP key :)
This is a good question, but specifications and books written about them are often incomplete in the place where you need them the most.
Working source code is your best bet in this case and the linux/net/mac80211/wep.c code is out there for the reading.