I have an archive encoded with gzip 1.5. I'm unable to decode it using the C zlib library. zlib inflate() return EC -3 stream.msg = "unknown compression method".
$ gzip --list --verbose vmlinux.z
method crc date time compressed uncompressed ratio uncompressed_name
defla 12169518 Apr 29 13:00 4261643 9199404 53.7% vmlinux
The first 32 bytes of the file are:
00000000 1f 8b 08 08 29 f4 8a 60 00 03 76 6d 6c 69 6e 75 |....)..`..vmlinu|
00000010 78 00 ec 9a 7f 54 1c 55 96 c7 6f 75 37 d0 fc 70 |x....T.U..ou7..p|
I see the first 18 bytes are the RFC-1952 gzip header.
After the NULL, I expect the next byte to be RFC-1951 deflate or RFC-1950 zlib (I'm not sure which)
So, I pass zlib inflate() a z_stream:next_in pointing to to the byte #0x12.
If this were deflate encoded, then I would expect the next byte #0x12 to be 0aabbbbb (BFINAL=0 and BTYPE=some compression)
If this were zlib encoded, I would expect the next byte #0x12 to take the form 0aaa1000 bbbccccc
Instead, I see #0x12 EC = 1110 1100 Which fits neither of those.
For my code, I took the uncompress() code and modified it slightly with allocators appropriate to my environment and several different experiments with the window bits (including 15+16, -MAX_WBITS, and MAX_WBITS).
int ZEXPORT unzip (dest, destLen, source, sourceLen)
Bytef *dest;
uLongf *destLen;
const Bytef *source;
uLong sourceLen;
{
z_stream stream;
int err;
stream.next_in = (Bytef*)source;
stream.avail_in = (uInt)sourceLen;
/* Check for source > 64K on 16-bit machine: */
if ((uLong)stream.avail_in != sourceLen) return Z_BUF_ERROR;
stream.next_out = dest;
stream.avail_out = (uInt)*destLen;
if ((uLong)stream.avail_out != *destLen) return Z_BUF_ERROR;
stream.zalloc = (alloc_func)my_alloc;
stream.zfree = (free_func)my_free;
/*err = inflateInit(&stream);*/
err = inflateInit2(&stream, 15 + 16);
if (err != Z_OK) return err;
err = inflate(&stream, Z_FINISH);
if (err != Z_STREAM_END) {
inflateEnd(&stream);
return err == Z_OK ? Z_BUF_ERROR : err;
}
*destLen = stream.total_out;
err = inflateEnd(&stream);
return err;
}
How can I correct my decoding of this file?
That should work fine, assuming that my_alloc and my_free do what they need to do. You should verify that you are actually giving unzip() the data that you think you are giving it. The data you give it needs to start with the 1f 8b.
(Side comment: "unzip" is a lousy name for the function. It does not unzip, since zip is an entirely different format than either gzip or zlib. "gunzip" or "ungzip" would be appropriate.)
You are manually reading the bits in the deflate stream in the wrong order. The least significant bits are first. The low three bits of ec are 100, indicating a non-last dynamic block. 0 for non-last, then 10 for dynamic.
You can use infgen to disassemble a deflate stream. Its output for the 14 bytes provided is this initial portion of a dynamic block:
dynamic
count 286 27 16
code 0 5
code 2 7
code 3 7
code 4 5
code 5 5
code 6 4
code 7 4
code 8 2
code 9 3
code 10 2
code 11 4
code 12 4
code 16 7
code 17 7
lens 4 6 7 7 7 8 8 8 7 8
repeat 3
lens 10
Related
By using an online tool and wikipedia I found out that every sha-256 encrypted string is 64 chars longs containing numbers and characters. Hence I assumed that there are 34^36 combinations ( 2^216 simplified by an algebra calculator ).
After doing some research I found out that most people said there are 2^256 combinations. Could someone explain ? To make the context clear, I write a paper about cryptocurrencies and try to explain how many different combinations there are to encrypt and how long this could take ( therefore how many guesses it could take) and compare this to the amount of total atoms in the universe (roughly 10^85).
SHA-256 produces 256 bits which is 32 bytes, not characters, each byte has 256 possible values.
There are 256 bits and each bit has 2 values (0 or 1), thus 2^256.
There are 32 bytes and each byte has 256 values, thus 256^32.
Note: 2^256 == 256^32 ~= 10^77.
The 32 bytes can be encoded many ways, in hexadecimal it would be 64 characters, in Base64 it would be 44 characters.
Total combinations of SHA-256 is
115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936
A sha-256 hash has 64 characters, 32 hex combinations, because a hex has 2 characters.
3a 7b d3 e2 36 0a 3d 29 ee a4 36 fc fb 7e 44 c7 35 d1 17 c4 2d 1c 18 35 42 0b 6b 99 42 dd 4f 1b
Above is a hash where the hex combinations are separated so you can count 32.
There are 16 characters available to hex 0-9&a-f and 16^2 or 256 combinations in hex.
With 32 slots for a hex in a sha-256 you use 256^32 to get:
115792089237316195423570985008687907853269984665640564039457584007913129639936
Available sha-256 hashes.
i seem to always get incorrect output when decoding this base64 string in vb.net ( i think its base64? it really looks like it )
im using the frombase64string function
and i did it like this
Dim b64str = "0DDQQL3uAikQBgAAc4cqK4WnSQBg4SAgExEAAF3BAmAILYojRgkBhUrBAgEDRw=="
Dim i As String = System.Text.Encoding.Unicode.GetString(Convert.FromBase64String(b64str))
MsgBox(i)
but i always get this output
バ䃐⤂ؐ
that doesn't seem right
0DDQQL3uAikQBgAAc4cqK4WnSQBg4SAgExEAAF3BAmAILYojRgkBhUrBAgEDRw==
It looks like Base64, the length is a correct size, the characters belong to the Base64 character set and the trailing "==" is reasonable. Of course it might not be a Base64 encoding.
Base64 decoding results in:
D0 30 D0 40 BD EE 02 29 10 06 00 00 73 87 2A 2B 85 A7 49 00 60 E1 20 20 13 11 00 00 5D C1 02 60 08 2D 8A 23 46 09 01 85 4A C1 02 01 03 47
Now the problem, this is not a character string, it is an array of 8-bit bytes. Thus it can not be displayed as characters. The 0x00 bytes will signal the end of a string to the print method and the no-representable characters may be ignored, displayed with special characters or multiple bytes may display as must-byte unicode characters. The only guaranteed and usual display is in hexadecimal as above.
That String can be virtually anything. It might be the result of an encryption algorithm, like sha*. Your mistake is that you assume that it must be base64 because it might be.
It is a valid observation that it might be base64, so it was a perfectly valid thing to run that function, but it is you who has to determine whether based on the results it is base64 or something else, based on particular logic, which was not described in the question.
I created a simple model in Spin in which two processes S send messages to another process R. Process R then sends responses to both processes. I would like to define the property "if process x sends a message, then process y eventually receives it", as shown below. The problem is that although the simulation is working as expected, verification is not. The property I defined at line 9 is always passing without errors although I injected a fault at line 17 that should make verification fail. Am I missing something here?
1 byte r1PId;
2 byte s1PId;
3 byte s2PId;
4
5 byte nextM = 1;
6
7 chan toS[2] = [2] of {byte};
8
9 ltl p1 {[] ((s[s1PId]:m > 0) -> <>(s[s1PId]:m == r:m))}
10
11 proctype r(byte id; chan stoR)
12 {
13 do
14 :: true
15 byte c; byte m; byte m2;
16 stoR?c, m2;
17 m = 67; //should be m = m2
18
19 byte response = 50;
20
21 toS[c]!response;
22 od
23 }
24
25 proctype s(byte id; chan rtoS; chan stoR)
26 {
27 byte m;
28 atomic
29 {
30 m = nextM;
31 nextM = nextM+1;
32 }
33 stoR!id, m;
34 byte response;
35 rtoS?response;
36 }
37
38 init{
39 chan toR = [10] of {byte, byte};
40 r1PId = run r(10, toR);
41 s1PId = run s(0, toS[0], toR);
42 s2PId = run s(1, toS[1], toR);
43 }
There seems to be a scope problem. When the process s terminates, its local variables will be out of scope. In that case, the reference s[s1PId]:m will be 0.
On the other hand, in the process r, the variable m is declared inside a block. It is initialized to 0 every time before stoR?c, m2.
As a result, the reference r:m will always be 0 after receiving messages twice.
So, <>(s[s1PId]:m == r:m) will always be true.
To quick fix this, you can either (i) move the declaration byte m in r outside the loop; or (ii) add an infinite loop in s to prevent its termination.
I am trying to port a program which queries an LDAP server from Perl to Go, and with the Go version I am receiving a response that the filter is malformed:
00000057: LdapErr: DSID-0C0C0968, comment: The server was unable to decode a search request filter, data 0, v1db1\x00
I have used tcpdump to capture the data transmitted to the server with both the Perl and Go versions of my program, and have found that they are sending slightly different filter packets. This question is not about any possible bugs in the Go program, but simply about understanding the contents of the LDAP filter packets.
The encoded filter is:
(objectClass=*)
And the Perl-generated packet (which the server likes) looks like this:
ASCII . . o b j e c t C l a s s
Hex 87 0b 6f 62 6a 65 63 74 43 6c 61 73 73
Byte# 0 1 2 3 4 5 6 7 8 9 10 11 12
The Go-generated packet (which the server doesn't like) looks like this:
ASCII . . . . o b j e c t C l a s s
Hex a7 0d 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73
Byte# 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
This is my own breakdown of the packets:
##Byte 0: Tag
When I dissect Byte 0 from both packets, I see they are identical, except for the Primitive/Constructed bit, which is set to Primitive in the Perl version, and Constructed in the Go version. See DER encoding for details.
Bit# 87 6 54321
Perl 10 0 00111
Go 10 1 00111
Bits 87: In both packets, 10 = Context Specific
Bit 6: In the Perl version 0 = Primitive, in the Go version 1 = Constructed
Bits 54321: 00111 = 7 = Object descriptor
##Byte 1: Length
11 bytes for the Perl version, 13 for the Go version
##Bytes 2-3 for the Go version
Byte 2: Tag 04: Substring Filter (See section 4.5.1 of RFC 4511)
Byte 3: Length of 11 bytes
##Remainder: Payload
For both packets this is simply the ASCII text objectClass
My reading of RFC 4511 section 4.5.1 suggests that the Go version is "more" correct, yet the Perl version is the one that works with the server. What gives?
Wireshark is able to parse both packets, and interprets them both equally.
The Perl version is correct, and the Go version is incorrect.
As you point out, RFC 4511 section 4.5.1 specifies encoding for the filter elements, like:
Filter ::= CHOICE {
and [0] SET SIZE (1..MAX) OF filter Filter,
or [1] SET SIZE (1..MAX) OF filter Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeDescription,
approxMatch [8] AttributeValueAssertion,
extensibleMatch [9] MatchingRuleAssertion,
... }
And in this case, the relevant portion is:
present [7] AttributeDescription,
The AttributeDescription element is defined in section 4.1.4 of the same specification:
AttributeDescription ::= LDAPString
-- Constrained to <attributedescription>
-- [RFC4512]
And from section 4.1.2:
LDAPString ::= OCTET STRING -- UTF-8 encoded,
-- [ISO10646] characters
So this means that the present filter component is an octet string, which is a primitive element. Go is incorrectly converting it to a constructed element, and the directory server is correctly rejecting that malformed request.
I read about ISO 8583 messaging at WIKI and Code Project; I understood ISO 8583 messages can basically be divided in 3 parts:
MTI (Message Type Indicator)
1.1. Version
1.2. Message Class
1.3. Message Function
1.4. Message Origin
Bitmap
Indicate which data elements are present.
DataElement
The essence of the whole ISO message, contain information about the transaction such as:
transaction type,
amount,
customerid, etc.
So, after reading these two web references, I want to make divide my ISO messaging log as MTI, bitmap, and Data Element.
For example:
(0800 2020000000800000 000000 000001 3239313130303031)
MTI: 0800 (1987 version, Network Management Message, Request, Acquirer)
Bitmap: 20 20 00 00 00 80 00 00 (eg. 20 = 0010 0000 ,so position 3 is on)
DataElement:(by seeing Bitmap , we can defined data element as follow)
field 03:000000 (Processing Code)
field 11:000001 (Systems trace audit number)
field 41:3239313130303031 (Card acceptor terminal idenfication)
But my challenge is that I already have ISO 8583 messaging log from my ATM Machine.
This actual output messaging log is not very clear like the one in the snippet above.
So I cannot divide this message to MTI, Bitmap and Data element like upper example.
00000:00 5B 30 31 31 30 30 30 30 30 30 30 30 38 32 30 80 38 00 00 [.[01100000000820.8..]
00020:00 81 00 00 04 00 00 00 00 00 00 00 33 36 32 39 31 30 31 30 [............36291010]
00040:32 39 35 37 31 30 33 31 31 30 30 30 30 30 30 35 30 33 31 53 [2957103110000005031S]
00060:55 32 30 31 31 31 30 33 31 31 30 32 39 35 37 32 30 31 31 31 [U2011103110295720111]
00080:30 33 31 31 30 32 39 35 37 33 30 30 31 [0311029573001 ]
I have no previous experience in ISO 8583 message and welcome suggestions.
Got it,
This message is divided as follows:
First 2 bytes are the message length 00 5B = 91
Followed by 14 bytes of header = 01100000000820
Followed somehow by BMP as follows:
Primary BMP = 80 38 00 00 00 81 00 00 = Fields {1, 11,12, 13, 41, 48} exist
Field 1 means secondary BMP exist
Secondary BMP = 04 00 00 00 00 00 00 00 = Field 70 exist
I am not sure where is MTI, will it be the 0820 at the trailer of the header? since it is in ASCII and usually it comes in numeric value of 08 20 but this might be part of the specs. 0820 means network management advice
anyways, the fields from the decoded BMP as follows:
DE 11 = 362910
System Trace Audit Number
DE 12 = 102957
Local transaction time hh(24)mmss
DE 13 = 1031
Local transaction date MMDD
DE 41 = 10000005
terminal ID
DE 48 = (031) SU20111031102957201110311029573
notice the 3 digits length field preceding the remaining data in this field. which is a generic (future/private use) field
DE 70 = 001
network management information code <001 = sign on>
From DE 70 value 001 this is a sign on message, which must be a 0800 MTI.
To get more information about the location of the MTI and the meaning of DE 48, you should read the manual (technical specs) of this device to get more information.
while sending ISO 8583 message we are converting it in BCD/HEX form ,use Wireshark tool to
track communication between IP and Ports.
A good online bitmap analysis tool is https://neapay.com/online-tools/bitmap-fields-decoder.html.
Sometime helps the https://codebeautify.org/hex-string-converter tool.
For a better understanding of the ISO 8583 message format, it is useful to analyse each field manually. However, each field can have length and value subfields in different formats (BCD, EBCDIC, ASCII ...). And some fields may have inner fields, for example BMP 48 or 60 often used as containers for nested field trees. These inner fields may have tag, length and value. And nested fields of these fields may have different formats again :). For example the https://github.com/credibledoc/credible-doc/blob/master/iso-8583-packer/doc/ebcdic/ebcdic-decimal-tag-packer.md page describes a field with EBCDIC tag and BCD value.
You can use the https://github.com/credibledoc/credible-doc/tree/master/iso-8583-packer Java library (I am the author) for building ISO 8583 messages. The example of ISO message above can be unpacked and packed with the iso-8583-packer library.
Message data:
<f name="Root" lenHex="005B">
<f name="Header" val="0110000000" valHex="30313130303030303030"/>
<f name="MTI" val="0820" valHex="30383230"/>
<f name="Bitmap" bitmapHex="80380000008100000400000000000000" bitSet="{1, 11, 12, 13, 41, 48, 70}">
<f name="SystemTraceAuditNumber" fieldNum="11" val="362910" valHex="333632393130"/>
<f name="LocalTransactionTimeHHMMSS" fieldNum="12" val="102957" valHex="313032393537"/>
<f name="LocalTransactionDateMMDD" fieldNum="13" val="1031" valHex="31303331"/>
<f name="TerminalId" fieldNum="41" val="10000005" valHex="3130303030303035"/>
<f name="PrivateData_48" fieldNum="48" val="SU20111031102957201110311029573" lenHex="303331" valHex="53553230...39353733"/>
<f name="NetworkManagementInformationCode" fieldNum="70" val="001" valHex="303031"/>
</f>
</f>
Message Structure:
<f type="LEN_VAL" name="Root" lengthPacker="BinaryLengthPacker" bodyPacker="AsciiBodyPacker">
<f type="VAL" name="Header" bodyPacker="AsciiBodyPacker" len="10"/>
<f type="VAL" name="MTI" bodyPacker="AsciiBodyPacker" len="4"/>
<f type="BIT_SET" name="Bitmap" bitMapPacker="IfbBitmapPacker">
<f type="VAL" fieldNum="11" name="SystemTraceAuditNumber" bodyPacker="AsciiBodyPacker" len="6"/>
<f type="VAL" fieldNum="12" name="LocalTransactionTimeHHMMSS" bodyPacker="AsciiBodyPacker" len="6"/>
<f type="VAL" fieldNum="13" name="LocalTransactionDateMMDD" bodyPacker="AsciiBodyPacker" len="4"/>
<f type="VAL" fieldNum="41" name="TerminalId" bodyPacker="AsciiBodyPacker" len="8"/>
<f type="LEN_VAL" fieldNum="48" name="PrivateData_48" lengthPacker="AsciiLengthPacker" bodyPacker="AsciiBodyPacker"/>
<f type="VAL" fieldNum="70" name="NetworkManagementInformationCode" bodyPacker="AsciiBodyPacker" len="3"/>
</f>
</f>
The example above can be found on GitHub https://github.com/credibledoc/credible-doc/blob/master/iso-8583-packer/src/test/java/com/credibledoc/iso8583packer/examples/UnderstandingIso8583MessageLogTest.java
BMP 55 often contains TLV EMV data. The https://paymentcardtools.com/emv-tlv-parser tool is useful in the case.