I'm trying to decode a BPSK signal on GNU Radio and I'm struggling a bit so I hope maybe you will be able to help me.
The flowgraph I'm using is the following :
The bit frame I'm sending at the input of the flowgraph is :
1a cf fc 1d ff fd 55 53 33 3b bb a5 a5 8d 8d ed
ed 6d 6c 93 6e 3b 68 5b 60 db 7e db 56 db 36 db
b6 da 49 27 1c 74 2f 4f 94 ea 31 67 bc 8a 51 e7
3d 74 53 4f 3b 14 5b cf 25 14 73 cf 45 14 f3 ce
ba e9 a6 9d 89 d2 1d 38 2c 5f 90 d5 c1 32 fc 46
af 09 94 1d cf d2 ea c6 99 09 dc 1d 2f d3 95 3a
33 a7 ba 75 a7 4d 8b 12 1b c7 da f5 26 b3 89 ba
1d a7 d2 75 38 b3 a1 ba 7d a7 52 74 c7 4e f4 e9
4e 9c e9 d1 62 c3 79 04 a3 f1 85 42 0c f8 11 5f
c3 2a fb 99 5a 23 27 84 75 f0 b2 be 46 57 08 cb
As you can see, I'm using the "Constellation Modulator" block followed by the "Symbol Sync" block to simulate the modulation/demodulation. The decoding is then implemented by the block "Constellation decoder"
We can see in the picture below that everything seems to work perfectly : when I compare the input bit stream to the output bit stream the bits are synchronized
However when I open the file at the output of the flowgraph I'm unable to get the bit frame that I had at the input.
Do you know how I could fix this issue ? Any help is appreciated :)
Thanks and have a good day
The usual: your bits are right, but you have no framing, so your receiver doesn't know where a byte (or any other data unit) starts.
You'll need to add some framing! That can be as simple as a binary preamble that you look for.
Ok so I tried adding some framing with the "Correlate Access Code" block and an access code 1acffc1d in binary. Here is the flowgraph :
Gnuradio Flowgraph
The block then finds a tag at sample 53 and on the Time Sink we can verify that the tag is indeed 1acffc1d (in binary).
Results
However I'm not able to make the block "Tagged File Sink" work. On the documentation it is said that the tag must be "burst" for the block to start writing data to a new file but I don't really understand what it means.
Thanks again for your help.
Nicolas
Edit : I downloaded the module gr-satellites and used the block sync and create packed pdu and everything worked fine.
Related
I am using this sample example to do some AES encryption/decyption inside a module. All the calls pass successfully but the decrypted text is not same as the plain text.
[ 4703.053265] encrypting -> plain: bb 2b d7 fb fc c6 0c f6 82 92 cd e1 62 2f 9f 95 .+..........b/..
[ 4703.053277] encrypted: 91 1c 91 51 3c 22 77 dd 82 b4 b7 52 c7 95 af 18 ...Q<"w....R....
[ 4703.053280] Encryption triggered successfully
[ 4703.053290] decrypting -> encrypted: 91 1c 91 51 3c 22 77 dd 82 b4 b7 52 c7 95 af 18 ...Q<"w....R....
[ 4703.053295] decrypted: 31 81 92 38 37 da ac 6c 1b fd 4e 86 a1 1b 06 26 1..87..l..N....&
[ 4703.053297] Decryption triggered successfully
Source at :
https://kernel.readthedocs.io/en/sphinx-samples/crypto-API.html#code-example-for-symmetric-key-cipher-operation
Any hint in right direction would be appreciated !
Storing key and iv in the caller and passing a copy of it to encryption and decryption call works fine.
I have interfaced my Energy Meter with RS232, and then used a RS232-to-USB-Cable to interface with my PC. My Energy Meter uses Modbus Protocol.
I get readings like these through Modbus Slave / Modbus Poll software. How do I get it in the right format?
000024-Rx:AB 26 EA 59 94 FD B2 65 90 65 E4 AB 26 1D CA BA FE 57 8A 55 CA 55 FF
000025-Rx:AB 26 EA 59 94 FD B2 65 90 65 E4 AB 26 1D CA BA FC D7 8A 55 8A 55 FF
000026-Rx:AB 26 EA 59 94 FD B2 65 90 65 A4 AB A6 EB B2 AE FA 57 CA 55 CA 55 FF
000027-Rx:AB 26 EA 59 94 FD B2 65 90 65 A4 AB A6 EB B2 AE FA 57 CA 55 CA 55 FF
.
.
000040-Rx:AB 26 EA D6 EB FF B2 65 94 65 C6 AB 26 EB B2 AE FA 55 8A D5 8A 55 FF
You should learn how to footle around on manufacturer websites to find any information which might be even close to what you need. There is a mod bus protocol manual for your meter if you go to Support->Downloads, put a check mark against just Multifunction Meters, and on the listing row RISH EM 1320/30/40 click the right hand link in the column Manuals.
The manual is here: http://www.rishabh.co.in/index.php/products/download/349
That manual seems to give the register addresses you should look at for different values. I obviously can't know what your modbus polling software is actually doing to get the data you posted, you need to make it look at the modbus registers that have the data you are interested in using the manual as a guide. No I don't know any more about your particular meter.
BTW if you had actually tried I'm sure you could have found this yourself.
I have been using wireshark for a project I am working on, and I noticed that a lot of, seemingly malformed, messages are being send over my wlan0 interface. I am not sure where they come from, so I was hoping that someone could shed some light on this.
I run Ubuntu 12.04 on a Dell XPS 13.
The only thing I can think of is posting one of these messages here:
0000 5c f8 a1 96 0f 5f 00 1e 0b 70 b0 98 00 4c 50 03 \...._...p...LP.
0010 00 20 00 00 00 00 1e e0 1f e8 a3 93 99 f4 41 9d . ............A.
0020 93 76 82 9d 4e 99 da 43 cb bc 29 86 83 9c 8e f4 .v..N..C..).....
0030 20 df a9 4f e9 3e df a1 32 2c 59 e3 e6 a6 8a 97 ..O.>..2,Y.....
0040 40 ce fc a2 74 f2 a7 5d ce 12 e5 69 74 ec 4c e1 #...t..]...it.L.
0050 8e cd d3 19 92 b0 84 12 29 6f ........)o
A lot of these messages seem to use the LLC (Logical link control) protocol, though not all. Any suggestions are welcome.
In wireshark, I am able to see the encrypted data to and fro from my PC. It does not use diffie hellman algorihm for key exchange because I see only the Client Key Exchange packet but there is no Server Key Exchange packet. That means the browser is sending the encrypted key to the server(encrypted using the server's public key).
But I do not see any encrypted data in that packet("Client Key Exchange"). How to view the encrypted key?
You won't see the encrypted shared-key, it's not exchanged. You can see the encrypted pre-master secret when using RSA authenticated key exchange. (Note that using Ephemeral Diffie-Hellman isn't the only reason for not seeing a server key exchange message: it could also use a DH_DSS or DH_RSA cipher suite, but this is unusual as far as I know).
If you follow the instructions about decrypting SSL with Wireshark, use the "SSL debug file" option to store the logs into a file. (Note that the user interface has changed slightly in newer versions of Wireshark, in the way you configure the private key.)
The log files will contain the pre-master secret and the shared keys.
(By the way, you need the server's private key to do this, of course.)
Using the sample data provided on the Wireshark page, you get:
pre master encrypted[128]:
65 51 2d a6 d4 a7 38 df ac 79 1f 0b d9 b2 61 7d
73 88 32 d9 f2 62 3a 8b 11 04 75 ca 42 ff 4e d9
cc b9 fa 86 f3 16 2f 09 73 51 66 aa 29 cd 80 61
0f e8 13 ce 5b 8e 0a 23 f8 91 5e 5f 54 70 80 8e
7b 28 ef b6 69 b2 59 85 74 98 e2 7e d8 cc 76 80
e1 b6 45 4d c7 cd 84 ce b4 52 79 74 cd e6 d7 d1
9c ad ef 63 6c 0f f7 05 e4 4d 1a d3 cb 9c d2 51
b5 61 cb ff 7c ee c7 bc 5e 15 a3 f2 52 0f bb 32
pre master secret[48]:
03 00 ff 84 56 6d a0 fb cc fd c6 c8 20 d5 f0 65
18 87 b0 44 45 9c e3 92 f0 4d 32 cd 41 85 10 24
cb 7a b3 01 36 3d 93 27 12 a4 7e 00 29 96 59 d8
master secret[48]:
1e db 35 95 b8 18 b3 52 58 f3 07 3f e6 af 8a a6
ab c3 a4 ed 66 3a 46 86 b6 e5 49 2a 7c f7 8c c2
ac 22 bb 13 15 0f d8 62 a2 39 23 7b c2 ff 28 fb
key expansion[136]:
11 60 e4 e1 74 e9 a1 cf 67 f9 b7 bc ef bc a7 c7
b3 f7 33 aa b2 42 d0 1c a6 4e fb e9 9b 13 dd 29
63 aa 17 1f 47 71 95 71 08 e0 4b 8e e1 da 7b 4a
5a f3 c2 32 bd e0 a5 82 6d 14 44 3a d6 cb 2d c0
7d 57 be a8 37 de 5d d9 a1 07 fd 1b 22 71 b9 4b
7a 1e 0f 70 37 14 97 0a f0 db 98 3b 7b 74 e3 2d
51 66 2e 31 68 90 ac 6f e6 53 3c c9 5e 48 0c 05
bc 9f 92 e7 f9 91 98 f5 95 1c c4 bf d9 cb 26 ef
35 70 5e ad 21 22 3e f6
Client MAC key[20]:
11 60 e4 e1 74 e9 a1 cf 67 f9 b7 bc ef bc a7 c7
b3 f7 33 aa
Server MAC key[20]:
b2 42 d0 1c a6 4e fb e9 9b 13 dd 29 63 aa 17 1f
47 71 95 71
Client Write key[32]:
08 e0 4b 8e e1 da 7b 4a 5a f3 c2 32 bd e0 a5 82
6d 14 44 3a d6 cb 2d c0 7d 57 be a8 37 de 5d d9
Server Write key[32]:
a1 07 fd 1b 22 71 b9 4b 7a 1e 0f 70 37 14 97 0a
f0 db 98 3b 7b 74 e3 2d 51 66 2e 31 68 90 ac 6f
Client Write IV[16]:
e6 53 3c c9 5e 48 0c 05 bc 9f 92 e7 f9 91 98 f5
Server Write IV[16]:
95 1c c4 bf d9 cb 26 ef 35 70 5e ad 21 22 3e f6
Until recently the dissection of the ClientKeyExchange was like this(version 1.6 and below):
TLSv1 Record Layer: Handshake Protocol: Client Key Exchange
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 134
Handshake Protocol: Client Key Exchange
Handshake Type: Client Key Exchange (16)
Length: 130
But if you use this verison(1.7.2 upwards) the key dissection will be like this:
TLSv1 Record Layer: Handshake Protocol: Client Key Exchange
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 134
Handshake Protocol: Client Key Exchange
Handshake Type: Client Key Exchange (16)
Length: 130
RSA Encrypted PreMaster Secret
Encrypted PreMaster length: 128
Encrypted PreMaster: 761b1beac35e59de9a3bb9f74ebf9109b738e8ad346
You can see the encrypted pre-master:)
Awesome write up here explaining how SSL works, notice at no time during this handshake is the private key ever sent over the wire.
http://4orensics.wordpress.com/2011/10/21/ssl-in-a-nutshell/
Long story short there is no way to decrypt SSL streams without the server's private key (unless you work for the NSA or something), however you may want to look into getting in between the server and client during the handshake and if the user does not check the validity of the certificate that is presented you are in business.
Here is a tool that can do that for you among many others
http://mitmproxy.org/
Of note I highly recommend the sans reading room article on SSL Mitm(Man in the Middle) attacks.
I have a RSA 1024 key pair generated using standard call from PKCS#11.
I need to generate a PKCS#10 CSR for the public key.
MS has the IEnroll4 dll which will allow to raise a CSR using createRequestWStr. The samples indicate that you need to generate a new key pair(a container with 2 objects in MS CAPI) and MS automatically gives the the public key context for csr generation.
In my case, I already have a key pair generated using pkcs#11(as 2 objects but no key container). MS dll is not allowing me to proceed further.
QUERY 1:
Can some body point out how I can resolve this issue.
----------------------------------------------------------------------------
Alternatively, I was thinking to write my own code for CSR generation based on RSA standards. I am having the ASN 1.0 format
The ASN.1 syntax for a Certification Request is:
CertificationRequest ::= SEQUENCE {
certificationRequestInfo CertificationRequestInfo,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature Signature
}
SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
Signature ::= BIT STRING
CertificationRequestInfo ::= SEQUENCE {
version Version,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
attributes [0] IMPLICIT Attributes
}
Attributes ::= SET OF Attribute
QUERY 2:
How do I use the above syntaxes? I am totally new to this syntax? Which resources should I need to look at to write my own code?
If you need to generate your certificate-request with the PKCS#11-interface (i.e. you cannot use a CSP-interface instead) your best bet is to avoid IEnroll.
For C++ your (free and open source) options seems to be to look into OpenSSL or Botan. I am not terribly fond of OpenSSL's API, but it works. I have never used Botan, but it seems pretty nice. There are also many excellent choices if you are willing to pay for them.
Alternatively, if you want to write the ASN.1 yourself you probably want to read A Layman's Guide to a Subset of ASN.1, BER, and DER. The formal specifications are in X.208 and X.209, but those are hard reading.
You want to generate a DER encoding of the ASN.1 (that is described in the link).
Here is an example encoding:
308201493081b3020100300e310c300a06035504031303666f6f30819d300d06092a864886f70d01
0101050003818b00308187028181009c921beeef551bcb051518f0c48bfe72cb1d5609a64a005e0c
008580bb81b3a43cea280d5bffa4e777733845fc2f485f1c8ccc0b2914f30d1e41369fd4a6758a3c
c887834c4d6177bd96b9f341232b00d453f28f2ae5ad5e3b0324d0b5b440a0901968fd556470dd4d
2ea2e99dd99c580703c042853265374cd3622f6c3369e5020103300d06092a864886f70d01010505
000381810068c0266a16117b37fb15ad143e2941ff8b8f082daf4ec02789db01636f51c739f199fb
19c56228cc12b9e482b966f8650fa3fdb24e31e97eef15f61aabc91dc194aeba4ebce5eab0c5e3db
36cc090a0e4b2c7d3ac27eeb0d3900d73bd88172464b890a8f9a58a0d34c0f5e226b6173cc92a316
4bbbf1d12f29d1e2ad3f36c977
or translated with the excellent dumpasn1 utility:
0 30 329: SEQUENCE {
4 30 179: SEQUENCE {
7 02 1: INTEGER 0
10 30 14: SEQUENCE {
12 31 12: SET {
14 30 10: SEQUENCE {
16 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
21 13 3: PrintableString 'foo'
: }
: }
: }
26 30 157: SEQUENCE {
29 30 13: SEQUENCE {
31 06 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
42 05 0: NULL
: }
44 03 139: BIT STRING 0 unused bits, encapsulates {
48 30 135: SEQUENCE {
51 02 129: INTEGER
: 00 9C 92 1B EE EF 55 1B CB 05 15 18 F0 C4 8B FE
: 72 CB 1D 56 09 A6 4A 00 5E 0C 00 85 80 BB 81 B3
: A4 3C EA 28 0D 5B FF A4 E7 77 73 38 45 FC 2F 48
: 5F 1C 8C CC 0B 29 14 F3 0D 1E 41 36 9F D4 A6 75
: 8A 3C C8 87 83 4C 4D 61 77 BD 96 B9 F3 41 23 2B
: 00 D4 53 F2 8F 2A E5 AD 5E 3B 03 24 D0 B5 B4 40
: A0 90 19 68 FD 55 64 70 DD 4D 2E A2 E9 9D D9 9C
: 58 07 03 C0 42 85 32 65 37 4C D3 62 2F 6C 33 69
: [ Another 1 bytes skipped ]
183 02 1: INTEGER 3
: }
: }
: }
: }
186 30 13: SEQUENCE {
188 06 9: OBJECT IDENTIFIER
: sha1withRSAEncryption (1 2 840 113549 1 1 5)
199 05 0: NULL
: }
201 03 129: BIT STRING 0 unused bits
: 68 C0 26 6A 16 11 7B 37 FB 15 AD 14 3E 29 41 FF
: 8B 8F 08 2D AF 4E C0 27 89 DB 01 63 6F 51 C7 39
: F1 99 FB 19 C5 62 28 CC 12 B9 E4 82 B9 66 F8 65
: 0F A3 FD B2 4E 31 E9 7E EF 15 F6 1A AB C9 1D C1
: 94 AE BA 4E BC E5 EA B0 C5 E3 DB 36 CC 09 0A 0E
: 4B 2C 7D 3A C2 7E EB 0D 39 00 D7 3B D8 81 72 46
: 4B 89 0A 8F 9A 58 A0 D3 4C 0F 5E 22 6B 61 73 CC
: 92 A3 16 4B BB F1 D1 2F 29 D1 E2 AD 3F 36 C9 77
: }