I am trying to inspect h264 bitstream coming from hardware encoder on TI Davinci board.
00 00 0b c8 25 88 84 27 e4 a2 8e 32 77 87 ec 16 86 37 d7 8e 99 e1 8c 3b 8b ce fe a5 fc e9 9c f3 34 87 9f d7 ff 66 7d c1 ce ed 62 18 05 35 00 08 0f f6 69 12 08 a8 32 5e c7 fe c8 bf 77 e4 62 e4 9e 8b b0 6e f0 39 60 5b e8 26 78 52 d8 24 75 5c 2f 06 ce 71 04 aa cb e3 19 d0 dd 02 b5 e7 0e a7 ce 77 70 a9 7c 46 1e 65 b3 7b 02 c9 d4 72 d7 97 36 f3 59 93 e5 e6 92 ff 8f ba 29 03 d5 da 0a 7a 14 1f 19 b5 88 b1 98 7a 3b e1 58 a2 88 a1 5a 4a
The first 4 bytes seams to be size of the trailing chunk ...
What is the format of this bitstream?
How to extract nal_unit_type and slice_type/pict_type ?
Is there forbidden zero bit present ?
this source states that stream does not need to contain start codes, sequence parameter set NALUs and picture parameter set NALUs. And in that case decoder must obtain SPS and PPS NALUs externally (Some kind of extradata parameter to decoder..).
The ITU-T H.264 standard and the ISO/IEC MPEG-4 AVC standard (formally, ISO/IEC 14496-10 – MPEG-4 Part 10, Advanced Video Coding) are jointly maintained so that they have identical technical content. (http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC)
The H.264 spec can be downloaded for free at:
http://www.itu.int/rec/T-REC-H.264/en
The ISO version costs currently CHF 323.00 at http://webstore.iec.ch/
The bitstream format is defined in ISO/IEC 14496-10:
Information technology — Coding of audio-visual objects — Part 10:
Advanced Video Coding
You can download the standard from itu.int website.
The data you provided looks like NAL Unit 5 (lower 5 bits of first byte of payload, after first 4 bytes with length are skipped) and it does not carry SPS/PPS units.
See also previous topics on H.264 decoding, e.g. H.264 stream header
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 am tasked with decoding data stored on a Aztec barcode using an iOS device. I have access to the code that assembles the string sent to the barcode printer, but the printing itself is a black box.
As I step through the process, I can see that the string sent to the printer looks like this (note that other than the first 8 characters this is a encrypted string):
_36_30_30_30_30_34_7c_5d_49_0b_ea_f7_93_ba_89_d2_c6_c2_41_2a_d7_1c_49_8c_6d_4b_5c_07_5a_ca_7a_6a_c6_d5_d0_6c_f7_20_76_5b_e0_18_46_93_7e_2a_30_0d_14_3a_1a_e5_66_7c_05_f9_df_96_8a_f1_45_a5_4a_6e_2f_89_3f_f0_93_1f_bc_3e_77_5b_27_0c_58_df_55_37_4c_ae_8a_e7_c3_c6_16_5b_57_db_7c_2d_2c_8b_1c_e3_a4_44_1b_c4_ba_6a_c6_98_93_ae_2d_20_6e_9f_e8_0f_eb_bc_9f_2e_8a_e7_cf_da_22_96_e1_74_de_b2_f0_29_ec_b1_c1_75_43_1f_b2_e5_1f_a5_f6_06_3e_97_a1_a1_93_f4_51_4a_c4_14_9f_1a_c2_5b_ba_02_45_44_2b_b3_c2_5b_ba_02_45_44_2b_b3_c2_5b_ba_02_45_44_2b_b3_c2_5b_ba_02_45_44_2b_b3_c2_5b_ba_02_45_44_2b_b3_c2_5b_ba_02_45_44_2b_b3_06_0b_12_75_85_8b_07_fb
And the printed barcode looks like this:
However, when I use a generic iOS barcode reader to read it back (I've tried a few), I get the following:
600004|]I�ê÷ºÒÆÂA*×�ImK\�ZÊzjÆÕÐl÷ v[à�F~*0
�:�åf|�ùßñE¥Jn/?ð�¼>w['�XßU7L®çÃÆ�[WÛ|-,�ã¤D�ĺjÆ®- nè�PÐk^¡±xOS5·Óþ�ßá×D¢\���¥ö�>¡¡ôQJÄ��Â[º�ED+³Â[º�ED+³Â[º�ED+³Â[º�ED+³Â[º�ED+³Â[º�ED+³���u�û
This bares a resemblance the original string (for example the first few characters). But I have no idea what type of encoding this is, or how to translate it to the hex codes I was expecting to see.
I would love to know:
1) What am I looking at here?
2) How can I convert this string back into the original format?
Note: For clarity, what you refer to as the encrypted string, I will refer to as the hex code, to further differentiate from the random-looking string at the end of your post.
Summary
I believe the encoding you're seeing in the string is a bungled ASCII/ISO-8859-1 encoding. It is omitting some characters, making it impossible to recover your original hex code from that string. After finding a scanner that properly handles the barcode, it turns out the barcode does not match your hex code.
Encoding
Wikipedia says that by default1, byte codes in Aztec are interpreted as ASCII when between 0 and 127, and as ISO-8859-1 when between 128 and 255. So when you substitute the letters and symbols you're getting with the proper hex values from those two encodings, you get the following:
36 30 30 30 30 34 7C 5D 49 EA F7 BA D2 C6 C2 41 2A D7 49 6D 4B 5C 5A CA 7A 6A C6 D5 D0 6C F7 20 76 5B E0 46 7E 2A 30 0A 3A E5 66 7C F9 DF F1 45 A5 4A 6E 2F 3F F0 BC 3E 77 5B 27 58 DF 55 37 4C AE E7 C3 C6 5B 57 DB 7C 2D 2C E3 A4 44 C4 BA 6A C6 AE 2D 20 6E E8 50 D0 6B 5E A1 B1 78 4F 53 35 B7 D3 FE DF E1 D7 44 A2 5C
This is similar to your encrypted hex code, but with some bytes omitted, and the stuff after the bolded E8 byte is different. The omitted bytes are all from the 00 - 1F and 80 - 9F ranges. The 00 - 1F range in ASCII are control codes, most of which are rarely used and not well supported by many applications. The other range is undefined in ISO-8859-12. So any application trying to interpret these bytes as ASCII/ISO-8859-1 strings may result in unpredictable behaviour.
If you remove bytes from these ranges in your encrypted hex code, you get essentially3 the same thing I got, up to the E8 byte. The byte you have after E8 is 0F. I've never heard of this control code before, but apparently it's called "Shift In" and its function is to "Return to regular character set after Shift Out." Since we're already having trouble with character sets, I can only assume that this control code is responsible for the interpretation errors after the E8 byte.
Edit: One of your recent edits modified the string, and it now contains a few of these characters: �. This is Unicode's replacement character, a character that often replaces others when there is character encoding issues, or a process has trouble interpreting a particular character. In this case, it is replacing many bytes from the 00 - 1F range, which are the ASCII controls. It remains impossible to recover. The 80 - 9F range is still omitted.
A better barcode reader
In order to properly interpret the barcode, you'll need a reader that does not interpret the hex code as encoded strings, but as a byte stream. At the very least, you need a reader that will still preserve the 00 - 1F and 80 - 9F ranges.
One such reader that I've found is NeoReader. It is entirely possible you've already tried it, but copy-pasting can cause errors with these special code ranges.
I scanned the code with it on an iOS 7 device, then hit the "Copy to Clipboard" button that the app provides. Then, I pasted the string at the top of this converter and hit convert. I usually use this converter for Unicode stuff, but other dedicated text to hex converters I found were not able to handle the string and its special codes. If you scroll down to the "Hexadecimal code points," you should be able to see the needed hexadecimal codes, though they are prefixed with an extra 004.
The string it produces (though take it with a grain of salt, I had some copy paste-errors and it appears the special controls were removed upon posting it):
600004|]I ê÷ºÒÆÂA*×ImK\ZÊzjÆÕÐl÷ v[àF~*0
:åf|ùßñE¥Jn/?ð¼>w[' XßU7L®çÃÆ[WÛ|-,ã¤DĺjÆ®- nèPÐk^¡±xOS5·Óþßá×D¢\¥ö>¡¡ôQJÄÂ[ºED+³Â[ºED+³Â[ºED+³Â[ºED+³Â[ºED+³Â[ºED+³ uû
Hex code comparison (differences are marked by < >):
Your hex code: 36 30 30 30 30 34 7C 5D 49 0B EA F7 93 BA 89 D2 C6 C2 41 2A D7 1C 49 8C 6D 4B 5C 07 5A CA 7A 6A C6 D5 D0 6C F7 20 76 5B E0 18 46 93 7E 2A 30 <0D> 14 3A 1A E5 66 7C 05 F9 DF 96 8A F1 45 A5 4A 6E 2F 89 3F F0 93 1F BC 3E 77 5B 27 0C 58 DF 55 37 4C AE 8A E7 C3 C6 16 5B 57 DB 7C 2D 2C 8B 1C E3 A4 44 1B C4 BA 6A C6 98 93 AE 2D 20 6E 9F E8 0F <EB BC 9F 2E 8A E7 CF DA 22 96 E1 74 DE B2 F0 29 EC B1 C1 75 43 1F B2 E5> 1F A5 F6 06 3E 97 A1 A1 93 F4 51 4A C4 14 9F 1A C2 5B BA 02 45 44 2B B3 C2 5B BA 02 45 44 2B B3 C2 5B BA 02 45 44 2B B3 C2 5B BA 02 45 44 2B B3 C2 5B BA 02 45 44 2B B3 C2 5B BA 02 45 44 2B B3 06 0B 12 75 85 8B 07 FB
NeoReader string: 36 30 30 30 30 34 7C 5D 49 0B EA F7 93 BA 89 D2 C6 C2 41 2A D7 1C 49 8C 6D 4B 5C 07 5A CA 7A 6A C6 D5 D0 6C F7 20 76 5B E0 18 46 93 7E 2A 30 <0A> 14 3A 1A E5 66 7C 05 F9 DF 96 8A F1 45 A5 4A 6E 2F 89 3F F0 93 1F BC 3E 77 5B 27 0C 58 DF 55 37 4C AE 8A E7 C3 C6 16 5B 57 DB 7C 2D 2C 8B 1C E3 A4 44 1B C4 BA 6A C6 98 93 AE 2D 20 6E 9F E8 0F <81 50 D0 6B 5E A1 B1 78 4F 53 35 B7 D3 FE 1F DF E1 90 D7 44 A2 5C 00 19> 1F A5 F6 06 3E 97 A1 A1 93 F4 51 4A C4 14 9F 1A C2 5B BA 02 45 44 2B B3 C2 5B BA 02 45 44 2B B3 C2 5B BA 02 45 44 2B B3 C2 5B BA 02 45 44 2B B3 C2 5B BA 02 45 44 2B B3 C2 5B BA 02 45 44 2B B3 06 0B 12 75 85 8B 07 FB
The difference explained
It turns out, that the barcode does not actually match your hex code. Where our two codes diverge, at that 0F byte, the barcode actually follows what NeoReader suggests. This is shown in the image below, which is zoomed in on the bottom-right quadrant of the barcode (the blue lines indicate parts that do not encode data, they are to help orient the scanner).
I managed to manually5 decode that section of barcode, with help from this video tutorial. Your barcode, however, does not use the string encoding method shown there, as it uses a binary shift escape to work with 8-bit values. From there I believe the one 0A <-> 0D difference is due to a copy paste error on my part.
Unfortunately, since the printer is a black box to you, it does not appear as though you can fix this problem yourself.
Footnotes
I could not find an Aztec Code specification, but the behaviour seems to be relatively consistent with the default.
ISO-8859-1 is essentially a superset of ASCII, but it technically leaves the ASCII control code range undefined. This is usually ignored in practice.
The only difference is the italicized 0A character I have, which is a new line character. Your string has 0D, another new line character. Different systems handle new lines differently, and its not uncommon for them to automatically change the new line characters. Unlike most other ASCII control codes, new line characters are usually well supported.
The reason for this is complicated. Glossing over a few details, I believe that upon hitting the convert button, it is first converted to UTF-16 (Javascript's native string encoding). The byte values for the ASCII/ISO-8859-1 characters are the same in UTF-16. However, UTF-16 is a 16-bit encoding rather than an 8-bit encoding, hence, the extra 00.
That was painful.
First of all, I've tried the following online barcode reader:
intbusoft : server error
onlinebarcodereader : no code found
datasymbol : code different from yours
pqscan : no code found
zxing : code longer than your.
This makes me think that your bar-code may be not so well construct...
Here's your output:
600004|]Iê÷ºÒÆÂA*×ImK\ZÊzjÆÕÐl÷ v[àF~*0
:åf|ùßñE¥Jn/?ð¼>w['XßU7L®çÃÆ[WÛ|-,ã¤DĺjÆ®- nèPÐk^¡±xOS5·Óþßá×D¢\
and here's the one from zxing:
600004|]I�ê÷ºÒÆÂA*×�ImK\�ZÊzjÆÕÐl÷ v[à�F~*0
�:�åf|�ùßñE¥Jn/?ð�¼>w['�XßU7L®çÃÆ�[WÛ|-,�ã¤D�ĺjÆ®- nè�PÐk^¡±xOS5·Óþ�ßá×D¢\���¥ö�>¡¡ôQJÄ��Â[º�ED+³Â[º�ED+³Â[º�ED+³Â[º�ED+³Â[º�ED+³Â[º�ED+³���u�û
(maybe this difference is due to a copy/paste manipulation on your side)
This is the matching that I was able to find:
6 0 0 0 0 4 | ] I � ê ÷ º Ò Æ Â
36 30 30 30 30 34 7c 5d 49 0b ea f7 93 ba 89 d2 c6 c2
A * × � I m K \ � Z Ê z j Æ Õ Ð l
41 2a d7 1c 49 8c 6d 4b 5c 07 5a ca 7a 6a c6 d5 d0 6c
÷ v [ à � F ~ * 0 � : � å f |
f7 20 76 5b e0 18 46 93 7e 2a 30 0d 14 3a 1a e5 66 7c
� ù ß ñ E ¥ J n / ? ð � ¼ >
05 f9 df 96 8a f1 45 a5 4a 6e 2f 89 3f f0 93 1f bc 3e
w [ ' � X ß U 7 L ® ç Ã Æ � [ W Û
77 5b 27 0c 58 df 55 37 4c ae 8a e7 c3 c6 16 5b 57 db
| - , � ã ¤ D � Ä º j Æ ® -
7c 2d 2c 8b 1c e3 a4 44 1b c4 ba 6a c6 98 93 ae 2d 20
n è � P
6e 9f e8 0f eb
And this seems to be some Unicode UCS-2 encoding.
After this, I can't explain the difference between output and expected hexadecimal values
Some time ago I started trying to mod my Samsung Galaxy S3 (International edition (I9300)), and I ended up with the Bootlogo, this is the FIRST image that you see when you turn on the Galaxy S3. I wanted to change it, as it is quite easy on other devices.
This is where I ran into troubles, I asked around on XDA-developes [link 1] (http://forum.xda-developers.com/galaxy-s3/help/removal-bootlogo-t2662444) and [link 2] (http://forum.xda-developers.com/showthread.php?t=2317694) but most of the answers led me nowhere. I ended up with the sboot.bin which is the secondary boot program (I guess this is how you can call it). To open it was quite difficult for a noob like me, but with hexadecimal editor HxD I opened it and actually found the bootlogo! (I copied the bytes into a jpg and it showed up normally.) I changed the bytes with another jpg image I made myself, and tried to flash it to the phone, but it failed. everything I tried afterwards failed, and I wondered why.
I downloaded a couple of sboot.bin for the i9300, but different countries, and I compared the hex code. There seemed to be subtle changes: one was in the compile date and serie nr. And there rest was a jumble of random character 256 bytes long.
I found that there are 4 sequences of 256 bytes long throughout the sboot.bin. An example of one:
EA E9 0C 62 B0 E0 68 86 5A 7B BD CA 50 3D 21 02
17 2C AC 10 09 49 62 E1 DA EB F4 94 B6 74 68 15
E6 90 2F CA 2F 75 67 C6 34 AE A3 A0 8F BC 60 62
63 87 8C C4 6C 8A 39 AA 7C 8A C7 E1 14 A3 C1 37
51 43 85 C0 09 97 05 AF 32 86 32 8C 58 7D C1 8F
91 A1 5E F1 9F D7 24 DF 08 82 1B AD FA C7 72 24
BC 35 34 6F 0F 42 C9 4E 7F AB FC 72 BC 64 71 84
DC 30 BB D5 AD D4 DE 01 9A E9 FB AA 1F 69 6F 52
3D E9 2A 52 6B 7E 9B 79 DE BD 7C 55 31 51 D6 99
BE 74 4F 22 6F 23 2F BF 7A 81 EF 5B 20 BF 75 03
D3 84 61 37 81 50 ED 71 66 4F 3D 34 0E 5A 33 4D
86 E2 E7 D0 8F 2B 48 5E 85 B5 E6 3F 56 51 70 74
CE 87 52 2D 47 D0 39 F6 CD 50 EE 76 F4 8E 79 7C
90 CF 4C 07 D5 47 AF 86 3D 33 3B A1 2A 70 74 4F
D1 60 9F 9E 28 96 C9 6E 9D DA 12 CB E1 8C 5B A5
CA AC 84 E2 26 1E 6F FD 4E EE B8 53 6E 7B 30 19
Maybe because it is helpful: one block is somewhat in the beginning, one is almost in the end, and the last two are at the real end of the file. So maybe the last two blocks are actually one big 512 byte block...
So I have come as far as to think that it might be a checksum or signature. But I am not sure how to find out what kind it is and how to generate one my self. searching for it hasn't helped me, because I cannot seem to find anything this long (256 bytes) only 256 bits long...
I was wondering if maybe someone could see what kind of siganture/checksum this is (Is this possible?) or how I can find out myself. or what I should do next...
[Edit on 25-08]
Alright, Since nobody has been able to answer the question yet, I was thinking of offering an incentive. I am willing to pay 1000 USD to whoever can help me alter the BOOTLOGO of the I9300!!!
Frank
Bootlogo is in the tar package /PARAMS and is called as logo.jpg, it should be writable via adb shell in twrp with this command:
cat /dev/block/platform/sdio_mmc/by-name/PARAMS > /sdcard/PARAMS.tar
Please note that PARAMS partition has stored SBOOT params at the end of the file. Just count 512 bytes from the last one, this is the last param, 512 bytes above is the next, until end of tar package.
Seems to be a checksum, though I cant be sure. One thing is certain, you've gone extremely deep in stuff. It could help to ask the guys at samsung, or somebody with great knowledge of kernels.
The first and second bootloader are signed.
A first bootloader that don't check the signatures of the second bootloader exist, so if you install that, you can then use u-boot as second bootloader.
See https://blog.forkwhiletrue.me/posts/an-almost-fully-libre-galaxy-s3/ for more details.
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.