I have Arduino with some RF 433 receiver and 433 remote to my gate (Moovo/Nice - chip EG301).
I can read codes from this remote, but every next click (on the same button) generate diffrent codes:
Canal C Serie D Rolling Code EDC9976E
Canal C Serie D Rolling Code 760643E1
Canal C Serie D Rolling Code 516B67F9
Canal C Serie D Rolling Code 84AAE281
Clear signals in HEX:
Received 65 bits (x1): 01 0a ea a3 34 9f ff ff fd
Received 17 bits (x1): 01 0a ea
Received 65 bits (x1): 00 50 b2 58 a6 9f ff ff fd
Received 17 bits (x1): 00 50 b2
Received 65 bits (x1): 00 e0 6f 9e 28 9f ff ff fd
Received 17 bits (x1): 00 e0 6f
How can I 'save' my remote and recognize it next time?
EDIT:
My reveiver is simple module MX-RM-5V.
If I good searched, signal from remote is encrypted by keeloq.
Maybe I need special reveiver with handle keeloq?
Rolling code is a protocol that roll codes to make it harder to replicate the remote control.
As you probably know, you can go to any store selling remotes and buy a copyable remote for fixed codes, and for these type of devices your program will suffice, but not for rolling codes.
I need to compress data stored in Redis. I write the data from R (with package rredis) to Redis like this:
redisSet("x","{\"email\":\"master#disaster.com\",\"Ranking\":[{\"Number\":37665,\"rank\":1},{\"Number\":41551,\"rank\":2},{\"Number\":21684,\"rank\":3},{\"Number\":35946,\"rank\":4}]}")
Instead of 4 elements in the list of this value there will be 4000 in the real scenario and 70000 keys like that in total. At the moment each of these keys take ~0.15 MB.
I read that it is possible to compress the memory usage of those entries in Redis significantly, e.g. with algorithms like LZO or Snappy. But I could not find information about the concrete implementation.
Some suggestions to solve the problem? Thanks!
There's no built-in way for that.
However, Redis can store binary data, so you can compress your data with any preferred compression algorithm, and store the compressed binary data to Redis. When reading the data, you need to get the binary data, and decompress it with the same compression algorithm.
Thanks for the hint! I was able to implement it, here are some details:
I used a compression function implemented in R (base package), as suggested.
memCompress()
I tried different compressions gzip and bzip2.
memCompress(type="gzip",...)
memCompress(type="bzip2",...)
Here is the code with a toy example:
#In R:
x<-"{\"email\":\"master#disaster.com\",\"Ranking\":[{\"Number\":37665,\"rank\":1},{\"Number\":41551,\"rank\":2},{\"Number\":21684,\"rank\":3},{\"Number\":35946,\"rank\":4}]}"
y<-memCompress(charToRaw(x),type="gzip")
# [1] 78 9c 4d c9 3d 0a 80 20 00 06 d0 bb 7c b3 04 e6 4f e5 d4 09 1a 5a a3 c1 4a 42 ca 02 ad 29 bc 7b 11 48 6d 0f de 05 e3 b4 5d a1 e0 74 38 8c
# [47] af 27 1b 5e 64 e3 ee 40 d0 ea 6d b1 db 0c d5 5d 68 4e 37 18 0f c5 0a 29 05 81 7f 0a 8a 46 f2 0d a7 42 d0 34 f9 7f 72 2a 4b 9e 86 fd 87 89
# [93] 8a cb 34 3c f6 f1 06 b3 67 2d c4
rawToChar(memDecompress(y,type="gzip"))
# [1] "{\"email\":\"master#disaster.com\",\"Ranking\":[{\"Number\":37665,\"rank\":1},{\"Number\":41551,\"rank\":2},{\"Number\":21684,\"rank\":3},{\"Number\":35946,\"rank\":4}]}"
# R to redis:
redisConnect(host="XXX.XX.XX.XXX", port=XXXX, timeout =10) # Insert your redis information (IP and port)
x<-"{\"email\":\"master#disaster.com\",\"Ranking\":[{\"Number\":37665,\"rank\":1},{\"Number\":41551,\"rank\":2},{\"Number\":21684,\"rank\":3},{\"Number\":35946,\"rank\":4}]}"
redisSet("x",x) #Wrong transfer of character string to redis
# redis-cli # On redis server
# get x # On redis server
# "X\n\x00\x00\x00\x02\x00\x03\x03\x02\x00\x02\x03\x00\x00\x00\x00\x10\x00\x00\x00\x01\x00\x04\x00\t\x00\x00\x00\x93{\"email\":\"master#disaster.com\",\"Ranking\":[{\"Number\":37665,\"rank\":1},{\"Number\":41551,\"rank\":2},{\"Number\":21684,\"rank\":3},{\"Number\":35946,\"rank\":4}]}"
redisSet("x",charToRaw(x)) #Right transfer of character string to redis
# redis-cli # On redis server
# get x # On redis server
# "{\"email\":\"master#disaster.com\",\"Ranking\":[{\"Number\":37665,\"rank\":1},{\"Number\":41551,\"rank\":2},{\"Number\":21684,\"rank\":3},{\"Number\":35946,\"rank\":4}]}"
redisSet("x",memCompress(charToRaw(x),type="gzip")) #Right transfer of compressed string to redis
# redis-cli # On redis server
# get x # On redis server
# "x\x9cM\xc9=\n\x80 \x00\x06\xd0\xbb|\xb3\x04\xe6O\xe5\xd4\t\x1aZ\xa3\xc1JB\xca\x02\xad)\xbc{\x11Hm\x0f\xde\x05\xe3\xb4]\xa1\xe0t8\x8c\xaf'\x1b^d\xe3\xee#\xd0\xeam\xb1\xdb\x0c\xd5]hN7\x18\x0f\xc5\n)\x05\x81\x7f\n\x8aF\xf2\r\xa7B\xd04\xf9\x7fr*K\x9e\x86\xfd\x87\x89\x8a\xcb4<\xf6\xf1\x06\xb3g-\xc4"
# I have not implemented the reimport to R yet. So feel free to add it :)
There is no improvement for this short string. But for the long version (4000 instead of 4 elements in the json file) there was a huge improvement:
Compression gives an improvement by ~85% in memory usage and writing time in this case!
Compressed:
Time to write 500 users with 4.000 elements each to redis: 12.62 sec
Memory kept by 500 users with 4.000 elements each on redis: 11.782 MB
Uncompressed:
Time to write 500 users with 4.000 elements each to redis: 88.76 sec
Memory kept by 500 users with 4.000 elements each on redis: 78.192 MB
I am aware that most of the Base64 encoding has == at the end. Is there any other which uses does the same?
For example, I found this:
nijdRcCHIUnketWzFbcxmvqQKKDnFW05LSE3ttTjoqyBna7JT87AwxeKdoOszXYODMRm6UfA8jK97qgV8A==
But it is not a Base64 kind. What else can it be?
The string you have posted is a valid Base64 string.
A Base64 string will end with == if and only if the number of bytes it encodes, mod 3, equals 1.
>>> for i in range(10):
... print(i, base64.b64encode(b"\x00"*i))
...
0 b''
1 b'AA=='
2 b'AAA='
3 b'AAAA'
4 b'AAAAAA=='
5 b'AAAAAAA='
6 b'AAAAAAAA'
7 b'AAAAAAAAAA=='
8 b'AAAAAAAAAAA='
9 b'AAAAAAAAAAAA'
Do you see the pattern?
It happens that 16-byte (128-bit) encryption keys are very commonly encoded in Base64, and since 16 mod 3 = 1, their encoding will end with ==. But your string, decoded, is 61 bytes (488 bits) long. That is too big to be most sorts of encryption key, and too small to be an RSA key.
This is your string, decoded, and then hexdumped:
00000000 9e 28 dd 45 c0 87 21 49 e4 7a d5 b3 15 b7 31 9a |.(.E..!I.z....1.|
00000010 fa 90 28 a0 e7 15 6d 39 2d 21 37 b6 d4 e3 a2 ac |..(...m9-!7.....|
00000020 81 9d ae c9 4f ce c0 c3 17 8a 76 83 ac cd 76 0e |....O.....v...v.|
00000030 0c c4 66 e9 47 c0 f2 32 bd ee a8 15 f0 |..f.G..2.....|
0000003d
I don't see anything in there to tell me what it actually is, and file(1) is also stumped. It could be random enough to be encrypted, but I can't tell for sure by eye. (And if it is random, that doesn't mean it's encrypted! It could just be the output of a random number generator.)
It is important to understand that Base64 is not encryption, because it has no key. I didn't need to know or guess any piece of secret information to reverse the Base64 encoding of your string. (The term 'encoding' can be confusing — it is more general. UTF-8, Base64, and DEFLATE are all encodings, and so is AES-CBC, but of all of them, only AES-CBC is encryption.)
Short brief: I have a small toy that uses infrared signals from a remote to change colors of some lights, as well as their patterns. I've managed to capture the pattern timings, wrote a script in python to convert it to 1's and 0's, and then I have an android app that will convert the 1's and 0's to the IR timings for the blaster. I've tested all of these patterns and they make the toy respond as expected from my phone.
Instead of trying to capture every single pattern manually, I think there's some sort of patterns inside the codes - I'm trying to figure them out. It looks like there's a check at the end of each, but that's the part I can't crack. I've tried simple checksum-like things, as well as revEng.
In all honesty, this is a bit over my head - my experience is mostly web-based. I don't even know for sure if there's a CRC code, but it makes sense looking at the data.
Here are a few samples - I've provided them as the binary as well as translated to HEX (less characters to stare at).
Pattern titles are Color / Animation / Transition / Speed
Light Blue / Double Flash / Fade / Normal
1001001100111011011010011100101001010010111110100011011001101000001000110100101011010111101111011110111101001011110110101011101100101001
93 3b 69 ca 52 fa 36 68 23 4a d7 bd ef 4b da bb 29
Light Blue / Solid / None / Normal
1110001100110011011011100111101111111010100111001010010100101111001010110001000011110110101001111110101110100011100001101000111110111101111011011001
e3 33 6e 7b fa 9c a5 2f 2b 10 f6 a7 eb a3 86 8f bd ed 90
Light Blue / Pulse / Straight / Slow
10110011001110110110111100101010010111101111011010101001111011111010001100000110110110011010011100101001010010111010101
b3 3b 6f 2a 5e f6 a9 ef a3 06 d9 a7 29 4b aa
Light Blue / Pulse / Straight / Normal
10110011001110110110111100101011001111101111011010101001111011111010001100000110110110011010011100101001010010111101011
b3 3b 6f 2b 3e f6 a9 ef a3 06 d9 a7 29 4b d6
Light Blue / Pulse / Fade / Fast
11100011001100110110111001111010001000101001110010100101001011111010001101100110111110000011011010001011111010111011111010011111101111110110110000001
e3 33 6e 7a 22 9c a5 2f a3 66 f8 36 8b eb be 9f bf 6c 08
Light Blue / Pulse / Fade / Normal
1110001100110011011011100111101010000000100111001010010100101111101000110110011011111000001101101000101111101011101111101010111110111111011011
e3 33 6e 7a 80 9c a5 2f a3 66 f8 36 8b eb be af bf 6c
Light Blue / Pulse / Fade / Slow
1110001100110011011011100111101111000110100111001010010100101111101000110110011011111000001101101000101111101011101111101101011110111111011011101011
e3 33 6e 7b c6 9c a5 2f a3 66 f8 36 8b eb be d7 bf 6e b0
You can see that the Pulse / Fade patterns all start the same, as well as the Pulse / Straight - which makes me believe even more that the entire IR sequence is simply a list of parameters, not necessarily pre-defined patterns.
tl;dr: Are there CRC patterns at the ends of these, and how can I figure them out?
Out of curiosity, I spent some time looking through TCP dumps of an https web connection I made. I have been able to make sense of most of it, but I am stuck on one particular TLS Record. Here is the hex dump:
16 03 01 00 24 ae f5 83 cb 35 db dd 67 f5 bf 4a
c7 52 b5 16 56 59 52 40 fa 7b f8 f6 40 a7 13 74
0a f3 b0 6e 5b 4f 2b 88 a3
The previous Record is a Change Cipher Spec Record (i.e. Content Type 0x14) if that helps. Also, I used wget to make the request.
As far as I can tell, this should follow the handshake subprotocol (16), uses TLS 1.0 (03 01), the message length is 36 Bytes (00 24). And here is where I am stuck: what does the ae mean?! At first I thought it might have something to do with SNI or some other TLS extension, but so far no luck there either.
Any help interpreting this would be appreciated.
There is no HandshakeType with a value of 174. The 174 shows up because the TLS connection just finished negotiating a cipher suite, and is now encrypting the record's payload!