Difference between revisions of "Project:RELaserSoftware"

From London Hackspace Wiki
Jump to: navigation, search
Line 93: Line 93:
*  http://www.rabbitlaserusa.com/DriverDisk/MPC03/MPC03LV3030/MPC03-LV%
*  http://www.rabbitlaserusa.com/DriverDisk/MPC03/MPC03LV3030/MPC03-LV%
*  http://www.rabbitlaserusa.com/0/
*  http://www.rabbitlaserusa.com/0/
== Driver ==
Works for VID 0548, PID 1005.
Description of the device is EZ-USB (68013A), which is basically a serial interface.

Revision as of 15:38, 15 January 2011

Reverse Engineering Laser Software

The laser software by Leetro is bad, we need to know about the .mol file that is created by it so we can create our own in some fashion. Also if it does anything fancy when it downloads itself via USB.


The software is available here. Please scan this with antivirus software before use.

There is a special patched version that cannot currently (but hopefully one day) will be useful for exploring .mol files on babbage in EB4890's folder.

Note that this says there's software bounds protection with firmware versions or above (once origin is set)
the above, translated by google
Has comments on the .ini file settings

Current Repo

Current Repo of work done by user:JasperWallace

Initial Analysis of .mol file

Looking at: /Solexious/MarioBoxes/MINIMARIO.MOL

No ASCII strings (looking using strings)

Does not appear to be compressed (too many zeroes)

0x000 Header
0x200 One set of information What?
0x400 Another set of information.
0xa10 Likely co-ordinate data. Quite repetitive. Analysis document was mario boxes, with many repetitions of sub boxes, so that makes sense. It looks like possible 16bit number co-oords as the numbers range from a few thousands to hundreds. 32bits are in unrealistic ranges (huge in negative ranges).

To Do

Create simple .mol files with slight changes in

  • One co-ordinate of a point
  • The colour of one line
  • The speed of one colour
  • The power of one colour

And find diffs.


Vendor: 0548 Product: 1005

The protocol seems to be fairly simple. I have a capture of some file downloads and deleting a file.

looks like:

commands are sent to endpoint 0x04 and read form 0x88, sent commands are (byte)length and then length bytes

commands 5 and 6 seem to be start and end

example command block:

>w04 0002     00000000: 01 05
*r88 0001     00000000: 04
>w04 0006     00000000: 05 01 01 83 01 7a
*r88 0001     00000000: 06
*r88 0001     00000000: 05
>w04 0002     00000000: 01 04
*r88 0014     00000000: 0f 01 83 53 51 55 41 52 45 20 20 4d 4f 4c 00 0e
    00000010: 00 00 00 66
>w04 0002     00000000: 01 06

That last reply packet includes the ascii for 'SQUARE MOL' with two spaces in the middle to pad it to 11 characters. This must be a file name in DOS 8.3 format with the . implied between the 8th and 9th characters.

This presumably maps directly to a FAT16 entry, so don't let it be null or begin with a dot!

It isn't, the protocol dosn't seem to be doing any block level management at all, looks like the controller is nice enough to do that for us JasperWallace 01:11, 28 November 2010 (UTC)

State Dump

Now all in this mercurial repo:


Random Links that may be useful


Works for VID 0548, PID 1005. Description of the device is EZ-USB (68013A), which is basically a serial interface.