WYS*WYGWYS*WYSWYSG
When compressed above string using LZW algorithm it gave an output codes as below.
87 89 83 42 256 71 256 258 262 262 71
So you can see size of output codes bigger than that of the string.now I need to know How should I store it in a file?
Thank you.
Related
I just started to learn web assembly . I found this text
"In binary format The first four bytes represent the Wasm binary magic
number \0asm; the next four bytes represent the Wasm binary version in
a 32-bit format"
I am not able to understand this . Can anyone explain me this
\0 is a character with code 0 (the first 00 in 00617369), the remaining three are literal characters a, s and m. With codes 97, 115 and 109 respectively, or 61, 73 and 6d in hex.
For one value I am getting two different values when I am casting nvarchar to binary.
For the value A12875 I am getting a result like 0x4131323837350000000000000000000000000000
I get this when I am using a select statement.
If the same statement is executed in a stored procedure I am getting a result like this
0x2000410031003200380000000000000000000000
I am using the same query
select cast('A12875' as binary(20))
What is the difference?`
The difference is character encoding. A character encoding is a way to represent characters as bytes.
The characters you have, and their unicode code points are
A code point 41
1 code point 31
2 code point 32
8 code point 38
7 code point 37
5 code point 35
If you use UTF-8 (or Latin-1 or even ASCII) to encode this string you will get, left padded in a field of 20 bytes:
41 31 32 38 37 35 00 00 ... 00
But there are other character encodings. It looks like when you run a stored procedure, it is choosing UTF-16LE as the encoding, and that somehow a space character ends up in front. In UTF-16LE the code point 41 is represented as
41 00
because it would normally be 0041 but the bytes are reversed. So you would expect:
41 00 31 00 32 00 38 00 37 00 35 00 ... 00 00
The space character is code point 20 so it is represented as 20 00. I don't know why they put the space up front; it could be a funny way of making a byte order mark, i.e. 2000 for little endian and 0020 for big endian.
At any rate you should look at the SQL Server documentation to see how to use character encodings when characters are converted to bytes. You know, whenever you try to covert characters to bytes, you must specify an encoding. Maybe a default is there, but in general characters->bytes make no sense without an encoding. In your scenario, the two different environments used two different defaults.
How can i test a c++ program with given input test cases?
For example an input like this
23 45 78 45 12 67 23 76 56 34
34 65 78 45 74 3 98 34 23 97
I want to be able to input these numbers from a text file into a program at run-time and test expected output. I cannot input thousands of numbers by hand in a console so are there any softwares that allow these kind of testing?
This is already being used in InterviewStreet, they use given test cases and match the expected output to test a program.
--Edit--
Is there any way i can pass values from a text file into stdin ?
You could write a little bash script to run all of your tests. An individual test would look something like this:
#!/bin/bash
testprog < input1.txt > output1.txt
diff expected_output1.txt output1.txt
# examine the return code of diff to see if the files are different?
can anybody tell me why amazon want a base64 of the hmac-sha1/sha256 hash?
http://docs.amazonwebservices.com/AmazonSimpleDB/latest/DeveloperGuide/HMACAuth.html
I know that base64 is to represent binary date in ascii but sha1/sha256 is already ascii – I mean its only hex.
Thanks
Timo
Those hashes are not ASCII–the reason you see hex digits is because the software you use to generate them takes the binary output of the digest and turns it into an ASCII string of hex digits.
For instance, the MD5 digest will fill an array of 16 bytes. You can also represent it as a string of 32 characters, but the most basic form of the digest is still the array of bytes.
When you change an array of bytes into a hex string, you need 8 bits (one full character) to represent every 4 bits of data. Although it's not frequently called that way, you could say that this uses "base16" encoding, since you're grabbing 4 bits at a time and mapping them to a 16-character alphabet.
Base64, on the other hand, grabs 6 bits at a time and maps them to a 64-character alphabet. This means that you need 8 bits (again, one full character) to represent every 6 bits of data, which has half the wasted bits of base16. A base16-encoded string will always be twice as big as the original; a base64-encoded string will only be four thirds as big. For a SHA256 hash, base16 does 64 bytes, but base64 does approximately 43.
For example, the bytes, hex, and base64 samples below encode the same bytes:
bytes: 243 48 133 140 73 157 28 136 11 29 189 101 194 101 116 64 172 227 220 78
hex: f330858c499d1c880b1dbd65c2657440ace3dc4e
base64: 8zCFjEmdHIgLHb1lwmV0QKzj3E4=.
It's only that AWS requires its values to be base64 encoded.
I am trying to work out the format of a password file which is used by a LOGIN DLL of which the source cannot be found. The admin tool was written in AFX, so I hope that it perhaps gives a clue as to the algorithm used to encode the passwords.
Using the admin tool, we have two passwords that are encoded. The first is "dinosaur123456789" and the hex of the encryption is here:
The resulting hex values for the dinosaur password are
00h: 4A 6E 3C 34 29 32 2E 59 51 6B 2B 4E 4F 20 47 75 ; Jn<4)2.YQk+NO Gu
10h: 6A 33 09 ; j3.
20h: 64 69 6E 6F 73 61 75 72 31 32 33 34 35 36 37 38 ; dinosaur12345678
30h: 39 30 ; 90
Another password "gertcha" is encoded as
e8h: 4D 35 4C 46 53 5C 7E ; GROUT M5LFS\~
I've tried looking for a common XOR, but failed to find anything. The passwords are of the same length in the password file so I assume that these are a reversible encoding (it was of another age!). I'm wondering if the AFX classes may have had a means that would be used for this sort of thing?
If anyone can work out the encoding, then that would be great!
Thanks, Matthew
[edit:]
Okay, first, I'm moving on and going to leave the past behind in the new solution. It would have been nice to use the old data still. Indeed, if someone wants to solve it as a puzzle, then I would still like to be able to use it.
For those who want to have a go, I got two passwords done.
All 'a' - a password with 19 a's:
47 7D 47 38 58 57 7C 73 59 2D 50 ; G}G8XW|sY-P
79 68 29 3E 44 52 31 6B 09 ; yh)>DR1k.
All 'b' - a password with 16 b's.
48 7D 2C 71 78 67 4B 46 49 48 5F ; H},qxgKFIH_
69 7D 39 79 5E 09 ; i}9y^.
This convinced me that there is no simple solution involved, and that there is some feedback.
Well, I did a quick cryptanalysis on it, and so far, I can tell you that each password appears to start off with it's ascii value + 26. The next octet seems to be the difference between the first char of the password and the second, added to it's ascii value. The 3d letter, I haven't figured out yet. I think it's safe to say you are dealing with some kind of feedback cipher, which is why XOR turns up nothing. I think each octets value will depend on the previous.
I can go on, but this stuff takes a lot of time. Hopefully this may give you a start, or maybe give you a couple of ideas.
But since the output is equal in length with the input this looks like some fixed key cipher. It may be a trivial xor.
I suggest testing the following passwords:
* AAAAAAAA
* aaaaaaaa
* BBBBBBBB
* ABABABAB
* BABABABA
* AAAABBBB
* BBBBAAAA
* AAAAAAAAAAAAAAAA
* AAAAAAAABBBBBBBB
* BBBBBBBBAAAAAAAA
This should maybe allow us to break the cipher without reverse engineering the DLL.
Can the dll encode single character passwords? Or even a zero-character password?
You're going to want to start with the most trivial test cases.
You may be looking at this problem from the wrong angle. I would think that the best why to figure out how the password hashes are created is to reverse engineer the login dll.
I would recommend IDA Pro for this task. It's well worth the price for the help is gives you is reversing executable code into readable assembler. There are other disassemblers that are free if you don't want to pay money but I haven't come across anything as powerful as IDA Pro. A free static disassembler / debugger that I would recommend would be PEBrowse from SmidgeonSoft as it's good for quickly poking around a live running system and has good PDB support for loading debugging symbols.