A while back I wrote a conversion of RFC 1321 (RSA Data Security’s Message-Digest Algorithm for C) to ASPECT script.  During this conversion I discovered that the C code that was used to generate a rotate no carry bit-shift did not work as intended.  (In the RFC they refer to it as circularly shifting.)

Back then Wikipedia didn’t have an article on bitwise operations and I did not have the access to mathematic books.  I was doing some coding this last weekend and found an irregularity which I have still not successfully reproduced or explained, and while doing research on the matter, I came across the bitwise operation article at Wikipedia and discovered why ASPECT does not work as intended:

The reason for this is that C uses a logical shift whereas ASPECT uses an arithmetic shift.  This plays havoc with RFC 1321 and as such I had to do some mathematical tinkering to get an arithmetic shift to behave like a logical shift, which allows for the creation of a rotate no carry shift.

This is the code that comes from RFC 1321

#define ROTATE_LEFT(x, n) (((x) << (n)) | ((x) >> (32-(n))))

This is the resultant code with the arithmetic to logical shift conversion code:

func ROTATE_LEFT : integer
 param integer x, n
 integer z
 z = (x >> (32-n)) & ~(0×80000000 >> (31-n))
 return ( (x << n) | z )
endfunc

In order to reduce compiler and stack overhead, this could probably be shorted to a #define that looks like this (I haven’t tested this):

#define ROTATE_LEFT(x,n)  ( (x << n) | (x >> (32-n)) & ~(0×80000000 >> (31-n)) )

In summary you replace

((x) >> 32-(n))

with

 (x >> (32-n)) & ~(0×80000000 >> (31-n))

This causes the arithmetic shift to operate like a logical shift if the sign bit is set to 1 (which is the only time an arithmetic and logical shift operate differently).  I posted a bit of source to my script page which demonstrates this “bug” and the fix.

NOTE: A circular shift (or rotate no carry shift) is not inherent in either C source or ASPECT, hence the creation of the ROTATE_LEFT function in ASPECT source (or the compiler #define in C source)

Merry Christmas

 

Added my “Matrix” style “screen saver” to the Symantec Procomm scripts page.  I really enjoy ASPECT scripting.  I’ve found it’s very flexible.  Amazing to think that Symantec hasn’t updated Prcomm in over 5 years.  There just isn’t a lot more to be added to what they have, unless they were going to start doing other emulation modes (like Telnet/SSL, rlogin or SSH, etc.)

The best part about it is that it’s extensible.  Meaning that back in 2003, I did some coding using the C++ language to write a DLL API to further extend the functionality of Procomm.  Specifically, I added the ability for Procomm to access POP3 email via a API call to a DLL I wrote.  The idea was to retrieve instructions to perform certain tasks via email, perform them in an automated fashion, and then return to log to the person who requested the task via email.  Heck, if you wanted, you could write rlogin DLLs and have Procomm emulate rlogin via the DLL functionality.

Sadly, I lost my dedication to the projects I was working on because I didn’t have access to a Meridian-1 system full time to do testing with.  Later I did get a Meridian-1 second-hand, but I never recovered the urge to continue building the tools (other enjoyable tasks to pursue.)  Now, I’m finding the drive again.

 

Moved Meridian-1 resources page (http://www.datarave.net/meridian) to blog.

 

Updated code to:

  1. Recognize Canadian area codes (to permit Canadian users to add all US and Canadian NPAs but exclude all other NPAs).
  2. Added protection against NPA.TXT corruption: Validate NPA value from NPA.TXT before sending value to SL1 interface.  (Value must be between 200 and 999).
  3. Updated NPA.TXT to include all area codes created since last update.  Still excluding 800, 866, 877 and 900 NPAs to permit these to be manually configured as SPNs.
  4. Updated X11BARS documentation.

Thank you Andrew Chapelle for the bug report.

 

Today I got an email from someone in Canada who used a Meridian-1 script that I wrote.   They asked

Hello,

Was running your ESN script, and the NXXs went in beautiful, but then the NPAs started inputing garbage instead of the NPA.  I’m running Procomm version 4.8, and your script version V0.982.

Do you have a newer version, or a fix?

The interesting thing is that the script they are talking about is something I wrote back in 2003 and posted to my website (http://www.datarave.net/meridian).  After some consideration, it seems like a good move to transition that page to my blog and then redirect it.  So, happy day, new project.

Additionally, the request has made me realized that the script (0.98.04, the latest version [update: actually 0.99.03 is the latest]) isn’t posted, and further, that the latest version has some flaws in it.

  1. If the text file that is included in the script package gets corrupted, then the script will choke (as the user reports), and
  2. The code is outdated considering the latest daylight savings time changes enforced by the government.

Wheee, happy day, project 2.

Favorite Books

Favorite Music

© 2011 Undecided Suffusion theme by Sayontan Sinha