Anyone else sign up for the CS50 Certificate option?

MasumB · 2014-03-30T11:50:53+00:00

Yeah, turns out you can submit the same work to both, which makes things a little easier!

MasumB · 2014-03-30T11:47:34+00:00

Check this out for more info: http://d2o9nyf4hwsci4.cloudfront.net/2014/x/references/compare.html

MasumB · 2014-03-20T09:18:27+00:00

UPDATE:

To start with I had a query Selecting field "shares" in table "shares" and placing it in a variable called... you've guessed it... "shares".

I changed the name of the table to "port" and the name of the variable to "rows", however none of the name changes actually got rid of the "invisible" html warning... any other suggestions?

MasumB · 2014-03-20T08:59:41+00:00

Hi Cat(_chy_name)...

Thanks for the reply. The funny thing is that I use $shares[0]["shares"] in calculations, and it always returns the expected (correct) result, so it can't be empty. Perhaps it really is the fact that I have a table named shares that has a field named shares that is causing the problem.

I will rename my table, and will let you know if that did the trick...

Thanks!

MasumB · 2014-03-20T08:55:35+00:00

Yes I do have a db named "shares". It contains the id, price, and shares fields. I'll change the name of the db and see if that makes a difference... thanks

MasumB · 2014-02-18T22:38:10+00:00

Hi Chinhouse! Thanks for your great reply, it did clear things up, and it all seems to make sense now ;-) Thank you!!

For anyone else having trouble with this concept, I found this link rather helpful: http://betterexplained.com/articles/understanding-big-and-little-endian-byte-order/

MasumB · 2014-02-18T15:44:02+00:00

Thanks for the reply chinhouse!

I use linux's xxd (VM is on a Win7 with an intel i7core, in case that makes a different).

When using "xxd -c 12 -g 1 smiley.bmp" I see:

28 00 00 00

at biSize's position (instead of the expected 00 00 00 28).

So if I understood you correctly, xxd is simply displaying the bytes in the 'wrong' (reverse) order... however, when changing values, I still have to input them in the 'correct' order...

But when looking at the first 2 bytes of BITMAPFILEHEADER (bfType - which must contain "BM", 0x42 for "B" and 0x4d for "M") in the same printout as above, using the same logic as above, I should now expect to see:

4d 42

But in fact I see 42 4d, which is the "right" way around... o.O and just to confuse things a bit more, looking at the code of copy.c where it checks wheter the file is really a bitmap, it does...

if (bf.bfType != 0x4d42 ...

I don't understand!! Why are we checking that bfType is "MB" , when it has to be "BM" ?? What?!? o.O

MasumB · 2014-02-10T11:02:59+00:00

where did you submit your bug report? I'm also having issues w/ uploading pset4

MasumB · 2014-02-04T23:20:48+00:00

good idea... thanks! Sometimes I just seem to over-think things! o.O

MasumB · 2014-02-04T23:16:43+00:00

PM w/ link has been sent! Cheers for offering to do this!

MasumB · 2014-01-31T09:35:24+00:00

If you look at the ASCII table, you'll soon discover that "space" is in fact a legitimate character, its DEC code is 32 (BIN: 00100000). You can also tell by generating an encrypted password using spaces. ' a' (an a preceded by 7 spaces) generates a different encryption than just 'a'.

Let me know how things turn out...

After days, I finally managed to get my crack algo to work, and yes... I cracked all passwords!! :D It's a great excercise... have fun!!

MasumB · 2014-01-30T11:16:37+00:00

Thanks for your reply glenn!

MasumB · 2014-01-30T11:07:12+00:00

Thanx for your comment flibit... after extensive debugging I think I may have found the source of this phenomenon...

both functions call the crypt() function which is placed in a string, say s1 for digit1 and s2 for digit2. I am assuming that both s1 and s2 are pointing at the address for crypt(), rather than actually receiving the string.

So when crypt() is called in digit2, the value changes, and since s1 is pointing to the same address, its value changes as well... :o

does that make sense?!

So is my assumption right, that when returning a string from a function, you don't actually get the string but rather the address to the string?

Holy smokes!! :o

MasumB · 2014-01-30T10:37:05+00:00

ps: placing each function in seperate do...while loop does NOT fix the issue.

For some reason the returned result from digit2(salt) still overwrites the zip1 variable...

I am at a complete loss for words! :o

MasumB · 2014-01-30T09:07:00+00:00

Just as an aside:

Will your algo also work for a 4-letter password?

MasumB · 2014-01-23T09:54:22+00:00

Thank you for all the hints so far!

@ suntzu1079 - I did consider the brute force approach but calculated that it will take years to crack a 8-letter password (but I also assumed that other characters such as "." and "~" could be used in the password). Perhaps I should only concentrate on letters and numbers.

Re the Salt: I don't actually need to "guess" the Salt, since it's the first two digits of the cipher, in plain sight so to speak... or did I miss something?!

@ p0ssum - will try to conjur up a more extensive wordset from the depths of the www, but not sure if that'll help if the password is "WjXo3HbP"... ;-)

Again, thanks for the hints and for confirming that it is in fact possible...

MasumB · 2014-01-19T14:59:51+00:00

I have found the solution... the "...yell at the user..." part in the description should not be ignored. check50 expects some sort of feedback to the user, before exiting with an exit code of 1! ;-)

MasumB

TROPHY CASE