Jon,
The all 26 a's turned up as:
0xFBFFF9F4FB1521FCFBFFF9F4FB1521FCFBFF
steve
On Sep 14, 2007, at 10:03 AM, Jon Haworth wrote:
Hi Steve,
Might I just say this could be the best Friday afternoon question
ever :-)
Looks like some kind of byte codes; when we enter new passwords,
here are some examples of how they are saved:
Single letters first:
a == 0xFB
b == 0xFC
q == 0x0C
Decimal 251, 252 and 12 respectively - could be the ASCII code of
the character
being translated to hex and then having an offset applied. Hex tops
out at 255
and if you reset to 1 and keep going through the alphabet you match
up with q
at 12 as follows:
A = 251
B = 252
C = 253
D = 254
E = 255
F = 1
G = 2
...
P = 11
Q = 12
If you could test these passwords that would be handy:
e should be 0xFF
f should be 0x01
p should be 0x0B
If non-alphanumeric characters are allowed in passwords for this
system then
these might work as well:
[ should be 0xF5
% should be 0xBF
If those check out then the offset would appear to be 0x9A;
subtracting that
from the hex value of the first character of the password will
produce the
original character's ASCII code. If you get a negative result you
need to loop
back round from the top, e.g. if your result is -0x05 then your
true answer is
0xFF - 0x05 = 0xFA (n.b. I might have made an off by one error
there, I'd need
to test that).
Now the longer example:
aaa = 0xFBFFF9
If there were nothing else involved this should be 0xFBFBFB, so it
looks like
there's a second step to the encryption process.
It could be an algorithm based on the character's position (e.g.
add 0x02 to
the second character, 0x03 to the third, 0x04 to the fourth, etc) -
one way of
interpreting your example is that it's starting with an offset of
0x04 for the
second character, then reducing that offset by an additional 0x06
for each
subsequent character. You can test this theory with the following:
aa should be 0xFBFF
aaaa should be 0xFBFFF9F3
aaaaa should be 0xFBFFF9F3ED
ab should be 0xFB01
abb should be 0xFB01FA
abbb should be 0xFB01FAF4
abbbb should be 0xFB01FAF4EE
Alternatively the offsets could be are hard-coded for each
character's position
(given your example, they'd be +0x06 for the second and -0x02 for
the third),
in which case we're not going to be able to work out a pattern for
deducing
them but will have to brute force them from the output. If you
could provide a
few more password examples that would be great - a couple I can see
being very
useful would be
abcdefghijklmnopqrstuvwxyz
aaaaaaaaaaaaaaaaaaaaaaaaaa (26 letter a's)
Of course there could be something a little more fiendish going on.
Again, more
examples would help with this.
Can anyone start me in the right direction to try to
figure out how it's being done?
HTH!
Cheers
Jon
____ The WDVL Discussion List from WDVL.COM ____
To Join wdvltalk, Send An Email To: mailto:[EMAIL PROTECTED] or
use the web interface http://e-newsletters.internet.com/discussionlists.html/
Send Your Posts To: [email protected]
To change subscription settings, add a password or view the web interface:
http://intm-dl.sparklist.com/read/?forum=wdvltalk
________________ http://www.wdvl.com _______________________
You are currently subscribed to wdvltalk as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
To unsubscribe via postal mail, please contact us at:
Jupitermedia Corp.
Attn: Discussion List Management
475 Park Avenue South
New York, NY 10016
Please include the email address which you have been contacted with.
