I was downloading kafka and the checksum file looks like this:
kafka_2.10-0.8.2.1.tgz: 44 6E AB
1F 53 29
EB 03 66
29 26 AA
1C B0 84
5D
it looks like Hexadecimal to me, my question is how exactly do i compare it with the output of the command md5sum?
[foot#foo]# md5sum kafka_2.10-0.8.2.1.tgz
446eab1f5329eb03662926aa1cb0845d kafka_2.10-0.8.2.1.tgz
it is exactly the same, but in uppercase, and with spaces...
44 6E AB
1F 53 29
EB 03 66
29 26 AA
1C B0 84
5D
is the same as
44 6E AB 1F 53 29 EB 03 66 29 26 AA 1C B0 84 5D
and removing the spaces
446EAB1F5329EB03662926AA1CB0845D
and finally lower case
446eab1f5329eb03662926aa1cb0845d
Related
After getting data from old software, I can save it to a file with a specific format.
I wanted to extract the data from this file.
Unfortunately, this format is unreadable.
It seems to have specific characters (? or #).
I don't really understand how it is encoded but I have the data in the software to check the answer.
Here is a small sample of the bytes that the file contains:
0000-06f0: 10 db 2f 34-dc 80 c4 3f-8c e7 f7 ae-e6 61 02 40 ../4...? .....a.#
0000-0700: 41 69 af a4-f1 9e c2 3f-d9 e4 52 91-d4 1e 02 40 Ai.....? ..R....#
0000-0710: 50 0f be bc-f0 b5 c3 3f-df 4e 84 c9-0e e0 02 40 P......? .N.....#
0000-0720: 51 fe 42 71-a4 15 c3 3f-52 58 bc ab-ff f5 02 40 Q.Bq...? RX.....#
0000-0730: f6 26 e6 87-3c 27 c3 3f-ef 02 25 a5-db 9b 02 40 .&..<'.? ..%....#
0000-0740: 1e d4 37 19-a1 56 c3 3f-b5 76 c8 6a-34 3c 02 40 ..7..V.? .v.j4<.#
0000-0750: 81 34 51 8c-b0 f8 c4 3f-2e 74 d6 cd-4a 84 01 40 .4Q....? .t..J..#
0000-0760: 14 c7 40 00-7a 93 c5 3f-02 43 07 2b-76 a4 01 40 ..#.z..? .C.+v..#
0000-0770: c9 2d 42 c2-03 51 c6 3f-0c c5 30 d2-b5 38 01 40 .-B..Q.? ..0..8.#
0000-0780: 70 3e bb b0-cb 0a c8 3f-4b b7 12 c7-28 18 00 40 p>.....? K...(..#
0000-0790: 6a ad b4 7a-62 ae c7 3f-90 11 50 41-f1 f2 fd 3f j..zb..? ..PA...?
0000-07a0: 3a e9 01 1a-a7 f4 c7 3f-96 7b d0 a5-33 40 fd 3f :......? .{..3#.?
0000-07b0: 87 a1 ac 47-6c c0 c6 3f-90 78 3d 69-07 43 fe 3f ...Gl..? .x=i.C.?
0000-07c0: 36 d7 1c 39-43 27 c8 3f-d4 a3 47 47-80 df fd 3f 6..9C'.? ..GG...?
If someone knows how to decode it to get, it could be super useful.
Thanks.
I am trying to get the NAL units from an mp4 file using C. I got inside the "mdat" atom and tried extracting the NAL units. The first 3 were as "size, data" where size is the size of data in bytes. After that, I continued looking for the next unit. The size was 0xde02004c, which is too big. When I checked it with the hex editor, I saw that that is indeed true. But then I noticed the "Lavc" written right next to it.
00004930 92 43 19 61 93 4e de 02 00 4c 61 76 63 35 38 2e |.C.a.N...Lavc58.|
00004940 35 34 2e 31 30 30 00 42 20 08 c1 18 38 00 00 00 |54.100.B ...8...|
00004950 c9 01 9e 41 79 09 7f 7a 03 ed 3f 54 39 fb c2 01 |...Ay..z..?T9...|
00004960 c4 53 76 51 2d bf 57 5f 04 25 00 b9 fb df 43 67 |.SvQ-.W_.%....Cg|
00004970 f3 27 b9 f5 d7 e7 95 e9 b4 06 14 6b 4a c7 4e ff |.'.........kJ.N.|
00004980 23 ed 8f 17 d0 4d d4 21 a7 b3 84 0e 65 60 41 67 |#....M.!....e`Ag|
00004990 ec db 10 c9 b3 4c 3f 71 df 6b 73 c2 df cd fe 85 |.....L?q.ks.....|
The previous NAL unit ends right before the bytes "de 02 00 4c", so that should be the size of the next one. But it isn't. It looks like codec information. Why?
Edit: The first bytes of the first nalu:
00 00 02 af 06 05 ff ff ┊ ab dc 45 e9 bd e6 d9 48 │00•×••××┊××E××××H│
b7 96 2c d8 20 d9 23 ee ┊ ef 78 32 36 34 20 2d 20 │××,× ×#×┊×x264 - │
the second:
00 00 41 80 65 ┊ 88 84 01 ff 5e e7 6f ea
36 23 b7 5d 16 f8 5f 54 ┊ a3 5d 7c 9e ac d1 9b f6
and the third:
00 04 cb 41 9a 22 6c 5f
6e 75 69 b0 e3 e1 d9 c9 ┊ d4 71 cb 05 a3 60 09 71 ```
I am currently investigating a disk image with a FAT12 file system for data recovery purposes/researching for file carving. For this investigation, I have the actual files that need to be carved/recovered from the disk image so that I can validate my results obtained from the carving process/recovery.
During the comparison and analysis from the recovered files, I noticed that after exactly 2 clusters (each of size 16384 bytes/32 sectors) of file data there are 4 extra/embedded bytes. These repetitive and distinct 4 bytes that are being noticed after 2 clusters are not found in the corresponding actual files. I think that these bytes are used somehow by the file system, is this right? What is their purposes and how can be identified during the recovery process?
Hex dump:
Actual File that needs to be recovered from disk (hex between 2 clusters):
Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
00016336 BC 55 B4 F8 A5 E1 69 82 2A DD 4A 5D DC 46 B9 80 ¼U´ø¥ái‚*ÝJ]ÜF¹€
00016352 E1 33 D3 F9 76 AE 8A 79 2E 22 0F 58 EE 67 FD AD á3Óùv®Šy." Xîgý
00016368 49 E9 7B 76 45 99 3E 25 69 36 F2 00 8B 71 70 C0 Ié{vE™>%i6ò ‹qpÀ
00016384 FC BB 6D 65 E9 DC F2 30 7E BD 6A B4 BF 17 52 0B ü»meéÜò0~½j´¿ R
00016400 64 9A 2D 13 58 B8 0E FB 13 65 9B 1E 87 93 F9 00 dš- X¸ û e› ‡“ù
00016416 7F 11 55 4F 21 AD A7 3A 51 D7 B9 CF 3C DE 35 25 UO!§:Q×¹Ï<Þ5%
Disk Image:
Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
00132880 BC 55 B4 F8 A5 E1 69 82 2A DD 4A 5D DC 46 B9 80 ¼U´ø¥ái‚*ÝJ]ÜF¹€
00132896 E1 33 D3 F9 76 AE 8A 79 2E 22 0F 58 EE 67 FD AD á3Óùv®Šy." Xîgý
00132912 49 E9 7B 76 45 99 3E 25 69 36 F2 00 8B 71 70 C0 Ié{vE™>%i6ò ‹qpÀ
00132928 **08 B5 A9 88** FC BB 6D 65 E9 DC F2 30 7E BD 6A B4 µ©ˆü»meéÜò0~½j´
00132944 BF 17 52 0B 64 9A 2D 13 58 B8 0E FB 13 65 9B 1E ¿ R dš- X¸ û e›
00132960 87 93 F9 00 7F 11 55 4F 21 AD A7 3A 51 D7 B9 CF ‡“ù UO!§:Q×¹Ï
00132976 3C DE 35 25 <Þ5%
From the above hex dump it can be visualized that 08 B5 A9 88 is exactly between the two clusters, however in the actual file those 4 bytes were eliminated.
The extra 4 bytes that were being encountered between the two clusters were CRCs that were embedded by the Encase disk image file format for security purposes. You can refer to the following link for more detail.
I am working on developing an application for a smart card reader, using the Visa test kit in the C language. On reading card number 2, am getting the following Issuer Public Key Certificate after reading the card:
uint8_t ISSUER_PK_CERTIFICATE[] = {41 03 b1 61 f7 dd 14 34 85 79 1b f6 01 04 ea 10 08 06 9d 16 b6 c3 b3 5b 4e 37 ed 20 25 66 d8 77 6f 48 02 28 32 0a 90 31 ae 28 28 75 fa 1b 3a bf c7 6d 15 6f f4 b5 08 4a fd 9c b0 ef b0 8a 8e 5b 41 fa be 99 3b 04 fe 1b 76 8d ef b6 eb ae d1 77 4d d0 5e 7f f7 0c 45 86 42 85 e6 d0 06 2d 86 65 4e 7a 88 5f 49 f9 f3 11 9f 24 35 18 4c 28 1c 14 93 d2 ac 69 ec c7 88 da c0 75 9a 73 ec d5 f0 28 b3 27 a1 e5 1d c5 cb 43 53 7b 1d 2a a7 04 62 cd a3 c8 74 a5 7c 45 8e 52 15 09 ff 98 73 71 d6 da 8d 7a 4f f5 6f 10 87 89 68 86 33 17 1e f1 d6 9d},
...(ignoring the specifics of formatting in C arrays) where the modulus is 176 and from Visa, I have the following CA Public Key Modulus. The cards are test cards, thus I have no problem sharing the output publicly:
uint8_t VISA_PK_MODULUS[] = {99 6A F5 6F 56 91 87 D0 92 93 C1 48 10 45 0E D8 EE 33 57 39 7B 18 A2 45 8E FA A9 2D A3 B6 DF 65 14 EC 06 01 95 31 8F D4 3B E9 B8 F0 CC 66 9E 3F 84 40 57 CB DD F8 BD A1 91 BB 64 47 3B C8 DC 9A 73 0D B8 F6 B4 ED E3 92 41 86 FF D9 B8 C7 73 57 89 C2 3A 36 BA 0B 8A F6 53 72 EB 57 EA 5D 89 E7 D1 4E 9C 7B 6B 55 74 60 F1 08 85 DA 16 AC 92 3F 15 AF 37 58 F0 F0 3E BD 3C 5C 2C 94 9C BA 30 6D B4 4E 6A 2C 07 6C 5F 67 E2 81 D7 EF 56 78 5D C4 D7 59 45 E4 91 F0 19 18 80 0A 9E 2D C6 6F 60 08 05 66 CE 0D AF 8D 17 EA D4 6A D8 E3 0A 24 7C 9F},
also ignoring the formatting (I have written it like that here for simplicity),
where the modulus is also 176. The CA Public Key index is 5 and the exponent is 3, that's how I retrieved the above key. Now, I have written the following function to implement the RSA decryption algorithm to be able to verify the signature of the certificate:
uint32_t buffer[ISSUER_PK_CERTIFICATE_LENGTH]; //this holds the "decrypted" data
void decryptCertificate(uint8_t exponent)
{
uint32_t buffer[ISSUER_PK_CERTIFICATE_LENGTH]; //the length is in hex
for(int i = 0; i < hexToDecimal(ISSUER_PK_CERTIFICATE_LENGTH); i++) //conversion to integer for my convenience
{
uint32_t powered = pow(ISSUER_PK_CERTIFICATE[i], exponent);
uint32_t remainder = powered / VISA_PK_MODULUS[i];
uint32_t multiplied = remainder * VISA_PK_MODULUS[i];
uint32_t original = powered - multiplied;
buffer[i] = original;
}
}
but the final "decrypted" array does not fit the requirements of the Validation test specified by VISA. Anyone see where I could have gone wrong in the implementation of the above algorithm or can someone point me in the right direction if I have gone wrong? the output of the decryption is as shown:
8f 1b 94 1f 2d 3d 23 00 8b 40 be 00 01 40 06 d0 24 0c 2e 2e 5c 03 35 16 82 7d 5c 08 7b 94 67 4b 0b 84 02 00 8a 14 01 c9 20 9e 98 5d 1c 63 8c 08 43 35 27 14 0c 3d 86 94 61 81 4c 27 3a 48 d0 31 05 01 20 3f b3 40 a1 77 1b 4b ef 5b ab 60 36 38 31 1c 18 01 3d 01 45 e0 43 13 6e 43 d8 4e 6e 29 7a 08 70 41 48 27 37 11 28 00 32 5a 0a 10 34 3e 00 00 0d 49 b0 c7 36 08 30 4d 00 1b 08 99 00 11 b3 27 3d 19 01 35 0c 03 07 2a 5e ed 2f 40 20 8d 02 39 2f 45 13 bd 0d 10 2d 09 41 08 25 08 58 00 01 2c 51 05 06 07 13 a1 cc 0a 1b 88 00 01 04 97
NB: The Visa Specification states the Recovery function as: X = Recover(PK)[S] = Se mod n, given a digital Signature S and public key PK
It appears that you're trying to perform RSA decryption on each byte individually. This is incorrect — the certificate and modulus arrays each represent a single big integer. You will need to use a big-integer math library (or a special-purpose crypto library) to perform this decryption.
As a general comment OpenSSL may be a good fit for you. If its overhead or library size is too large for the card reader, there are other libraries specifically designed for embedded device environments. Check out the crypto library modules on the wiki (Crypto Libraries) and among them CyaSSL, MatrixSSL, PolarSSL, and SharkSSL are known to be for embedded devices.
Is there any way to create a QR code from a byte array? I decoded one using "zxing", and now that I changed it, I want to turn it back. If there is a solution, please tell me. Here is the code churned from "zxing":
40 07 01 18 2b 3c ba 4c 0e 1d bd 8a b4 23 29 10
40 72 b0 fe 7f 12 7c 71 2f f2 2b 8e 2a 2b b9 88
21 93 94 83 c8 b2 57 d8 a1 5f 0f 70 c3 56 8f 88
81 16 70 1d b0 b8 dc 0d ce 4c 1e 7c 01 85 26 74
d3 ae ce 6b b0 4b 02 6a 45 50 11 1b 65 2c 5e e2
cc 4a 65 f2 04 94 27 84 6a 88 2c c1 92 8b 65 b3
4d a4 9a 07 4f 41 14 bd 6e b6 ab 02 ca cc 7b dd
fe 34 60 ec 11 ec 11 ec 11 ec
The array format and the spaces seem important. Now, here is the original QR Code I put into "zxing":
Thanks everyone!
---In Response to the On-Hold Message:---
I tried to convert the array to a QR Code, but it was much different from the original. I expected it to be the same.
There are different ways of encoding the same information for a QR code. One of several possible mask patterns is applied to the information in order to produce a QR code that has a well distributed pattern of black and white pixels. In a QR code on a piece of paper that is bent in some way, the apparent distances of the pixels may vary. Long series of white or black pixels could disturb the reading process. When reading a QR code, the edges between the white and black pixels are used to synchronize with the raster used.
In order to test if the printed QR code is correct, re-read it and compare the information with the information of the original QR code. Don't compare the pictures!
See QR code / Encoding on Wikipedia.