I'm studying in French, so I'll try to translate the terms as best as I can, so sorry if it may be unclear.
I have to find the coded message (CRC) with this 10 bits message : 0011111111 and x^2 + x as the polynomial divisor.
I don't have much knowledge in binary and CRC yet, but I still know how to calculate one, but this one is a bit more tricky for me since the polynomial divisor is not an usual one.
There are a lot of examples with divisors such as x^5 + x^4 + 1, but I have yet to find an example with something that resemble this one (x^2 + x).
Here's what I did, but I'm pretty sure that it isn't right at all
001111111100 | 110
110
00111
110
00111
110
00110
110
0000
Do you guys have any idea what I'm doing wrong here?
Thanks a lot!
You can try this :
Computation of CRC with 110 on 0011111111, and see that the result is 2, with a good explanation step by step.
Related
I am trying to understand what this decimal code would be as a binary:
I understand how to normally get the answer, because I would take 425 and then figure out that 256 + 128 + 32 + 8 + 1 = 425, which would be 110101001 in binary.
However, I am completely thrown off by the d in the decimal. How can I understand what it is and how to solve this (if the answer is different than 110101001)?
For an internet challenge I need to try to get the password. But for the moment I'm stuck.
What is the best way to get the value of bigString where crc32(bigString) == 0xFFFFFFFF? (0xFFFFFFFF is not the real value, I want to calculate it myself and not spoil the fun for the other people who are trying the challenge)
The things you already know is bigString is a combination of 3 passwords: password1 (32 hexadecimal chars) + password2 (32 hexadecimal chars) + password3 (40 hexadecimal chars). So you know bigString is 104 chars long with the only possible values "0123456789ABCDEF".
Reversing is impossible and just bruteforcing seems almost impossible because it has 104 chars. What are the other possibilities?
I don't understand your challenge, but I can answer:
What is the best way to get the value of bigString where
crc32(bigString) == 0xFFFFFFFF ?
First off, you should realize that unless "bigString" is only 32 bits, there is more than one solution to that equation. Depending on how many bits more than 32 there are in bigString, the number of solutions grow exponentially with the number of bits.
My spoof.c code solves that equation directly. You give it the exclusive-or of the CRC of the string you have with the CRC you want, the length of the message, and the bit locations in the message that you are permitting to be changed. For a CRC-n, there needs to be at least n such bit locations provided. Ideally more than that should be provided to increase the probability of finding a solution. spoof.c will then tell you which of those bits to invert to give you the desired CRC.
I have a question from Patterson's computer Organization book.
Here they gave two numbers A and B which are 8 bit signed integer. The values of A and B are 216 and 255 respectively. They are asking to find A+B and A - B and report if there is any overflow/underflow.
Now my doubt is - you cannot even represent 216 in 8 bit signed numbers. The range is [-128,127]. So the question is invalid!!
I would really appreciate if anyone confirms my doubt.
Thanks.
The question is not invalid at all. In fact, questions of this type are quite common to ensure you understand overflow/underflow just wrap around the bit representations like when an odometer rolls over to all zeros when the milage gets too high. Since I am a Computer Science faculty, as well, I'll try to assist without answering the Patterson problem directly.
You are correct to instinctively feel 216 is not representable in a signed 8 bit number, but let's look at how these things actually work.
Say you have a signed 4 bit machine and need to store the number -11. You might be clever and note that the range of signed 4 bit numbers is [-8,7], so -11 must be impossible. Not so... First, store 11... that's 0000...0000001011_2 in general, but we must squeeze it into 4 bits, losing all but the low order 4 bits. So 11 = 1011_2. At this point you might be saying, "but isn't that a negative number?" Well, if you have any horses, hold them for a minute. Now negate 4 bit 11 to get 4 bit -11... 2s comp negation requires flipping all bits and adding 1, so -1011_2 = 0100_2 + 1 = 0101_2.
Ok, you can stop holding your horses now. It is true that 0101_2 is actually +5, but might it also be just as good as -11? Remember your early math days when your teachers told you to check your results?... we can do the same here to feel all warm and cozy about +5 being the same as -11. For example -11 + 6 = -5, right? So if we add 6 to 0101_2 and get -5, we should be satisfied with our seemingly out-of-range -11, correct? Of course! :-) So let's see... 6 = 0110_2 in 4 bits, now let's add.
0101
+ 0110
------
1011
So what is 1011_2? It's negative; we can tell because the sign bit (left most bit) is 1. To find its magnitude, we can just negate it... -1011_2 = 0100_2 + 1 = 0101_2, which to our astonishment is 5, so the original result, 1011_2 is -5, the answer one should have expected.
Maybe we're not convinced this is Ok. Let's verify -11 is 0101_2 by adding 14. That should give us a result of 3 because -11 + 14 = 3. Uh oh... 14 also seems to be out of range, but let's work like a machine and just do what we're told, no matter how stupid it might seem. +14 is 0000...0001110_2 generally, but we have to squeeze it into 4 bits by losing all but the low order 4 bits. So +14 in signed 4 bits is 1110_2. Let's add that to -11...
0101 // -11
+ 1110 // +14
------
10011 ...but this also needs to get squeezed into 4 bits, so it's 0011
Hey, isn't 0011_2 the same thing as +3? It is! So it looks like you actually can store numbers that appear outside the obvious range and they can still be used accurately for at least some math.
So hopefully this has given you an idea of how you can approach storing 255 and 216 in a signed 8 bit format without worry. But I'll leave the detection of overflow/underflow to you :-P
Good luck.
i want to do the following subtraction using ones complement
Octal(24)-Hex(4B) and give a binary answer
Octal(24) is 20 decimal
and Hex(4B) is 75 in decimal
20->10100
75->1001011
taking 1s complement of 75
0110100 and adding to 20
10100
+0110100
=1001000
adding the carry with the result
001000
+ 1
=001001 which is wrong
Where am i going wrong ?
I am new here, sorry if any mistakes in the way its typed.
You have a small few mistakes in your version. let me show you a correct solution and then show you your mistake(s)
We have the octal number 24 and the hex number 4B. both are fairly easy to translate to binary.
every octal digit represents 3 binary digits.
2 4
+++ +++
010 100
every hexadecimal digit represents 4 digits.
4 B
++++ ++++
0100 1011
now you build the complement:
~01001011
---------
10110100
the you need to add one. Otherwise you get 2 zeros. (+0 => 00000000, -0 => 11111111). this actually makes it a two's complement, but its needed unless you want weird results when crossing the 0-border
10110100
+00000001
---------
10110101
now your complement is done. Next step is to add both numbers
00010100 #The Octal 24
+10110101 #The complement
---------
11001001
The first digit is a 1 therefore its negative (as we'd expect since we did 20 - 75)
Therefore we need to reverse it.
First we subtract one: 11001000
Then we invert it again: 00110111
Which is decimal 55. Therefore 11001001 is decimal -55.
20 - 75 = -55
Voila, we are done :)
First tiny note: you made a small mistake when converting 0x4B (= Hex 4B) into binary format. one digit is wrong :)
Also, you forgot to add one. Then you did some weird stuff i don't get here:
adding the carry with the result 001000 + 1 =001001 which is wrong
Also, you didn't use fixed size numbers which made it impossible to you to find out if the result was negative. I sticked to 8 Bit here (except during octal -> binary conversion). (Keep in mind that with 8 bit your number range is from -127 to +128.) And in the end - as you couln't see its a negative number - you did not revert the process.
I hope this explanation helped you out :)
I was playing around with 2's complement and found a quicker way of finding the value of a negative binary. Please help me prove this(right or wrong) or why it works! Thanks in advance!
2's complement is very useful for finding the value of a binary, however I thought of a much more concise way of solving such a problem(never seen anyone else publish it):
take a binary, for example: 1101 which is [assuming that space "1" is the sign] equal to -3.
using 2's complement we would do this...flip 1101 to 0010...add 0001 + 0010 ===> gives us 0011. 0011 in positive binary = 3. therefore 1101 = -3!
What I realized:
instead of all the flipping and adding, you can just do the basic method for solving for a positive binary(lets say 0101) is (23 * 0) + (22 * 1) + (21 * 0) + (20 * 1) = 5.
Do exactly the same concept with a negative!(with a small twist)
take 1101, for example:
for the first number instead of 23 * 1 = 8 , do -(23 * 1) = -8.
then continue as usual, doing -8 + (22 * 1) + (21 * 0) + (20 * 1) = -3
Note: this seemed to work for every test I did.
Thanks for looking. Also, if you haven't seen this before please let me know, I never seen this anywhere.
This solution seems to work for the tests which I did! Thanks for the quick solution to 2's complement, I will still test out some more difficult questions.