GM MDI serial number..

The serial number is in the 16mb on board flash memory - the intel chip on the computer sub-board.

You can get u-boot access by making up a serial cable. Signals are available on the 8 pin mini din on the outside of the MDI case. pin 1 goes to PC TX (MDI RX), pin 2 goes to PC RX (MDI TX). Pin 3 goes to ground. Then when you boot:

U-Boot 1.1.4 (Dec 21 2007 - 12:11:55) ETAS VCI (r13006)

U-Boot code: A3F00000 -> A3F218F0 BSS: -> A3F27524
RAM Configuration: TRITON 270 II
Bank #0: a0000000 64 MB
Bank #1: a4000000 64 MB
HW Configuration: (0x207) MDI VCI with SMSC9116
Found P30 Flash, unlocking all blocks: 130
Flash: 16 MB
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
$ help
? - alias for 'help'
askenv - get environment variables from stdin
autoscr - run script from memory
base - print or set address offset
bdinfo - print Board Info structure
boot - boot default, i.e., run 'bootcmd'
bootd - boot default, i.e., run 'bootcmd'
bootm - boot application image from memory
bootp - boot image via network using BootP/TFTP protocol
cmp - memory compare
coninfo - print console devices and information
cp - memory copy
crc32 - checksum calculation
dhcp - invoke DHCP client to obtain IP/boot params
echo - echo args to console
erase - erase FLASH memory
exit - exit script
flinfo - print FLASH memory information
flock - physical lock of Strataflash
funlock - physical unlock of Strataflash
go - start application at address 'addr'
help - print online help
iminfo - print header information for application image
imls - list all images found in flash
increnv - increment environment variables
itest - return true/false on integer compare
loadb - load binary file over serial line (kermit mode)
loads - load S-Record file over serial line
loop - infinite loop on address range
macaddr - display or store MAC address in Strataflash
mapadd - add a memory map item
mapdel - delete a memory map item
mapinfo - display the memory map information
md - memory display
mm - memory modify (auto-incrementing)
mmcinfo - get info on mmc(sd) card
mtest - simple RAM test
mw - memory write (fill)
nfs - boot image via network using NFS protocol
nm - memory modify (constant address)
ping - send ICMP ECHO_REQUEST to network host
pinit - PCMCIA sub-system
printenv- print environment variables
protect - enable or disable FLASH write protection
rarpboot- boot image via network using RARP/TFTP protocol
reset - Perform RESET of the CPU
run - run commands in an environment variable
saveenv - save environment variables to persistent storage
serialnum - display or store serial number in Strataflash
setenv - set environment variables
sleep - delay execution for some time
test - minimal test like /bin/sh
tftpboot- boot image via network using TFTP protocol
version - print monitor version

The problem is the serial number and MAC flash partitions are misaligned from the flash erase block boundaries, which forces them to mount read only. Because of this the update commands dont work

Code:

$ serialnum
Serial number: 1220-22129579
$ serialnum 1220-12345678
Error: start address not on sector boundary
Failed to read same serial number back from Strataflash

I think that if we mapped a memory partition at 0x00FE0000 with size 0x00020000 then we would be able to erase that partition and load a new one via ethernet / tftp. This 128k block would cover both the serial and mac paritions. Both these partitions have checksums which would need to be figured out and calculated.

What you have been editing is the equivalent of the MDI registry. Once the serial and mac are changed in flash then a re-flash of the device should put the new numbers in the registry and they should persist over device firmware updates. I expect duplicate mac addresses are as relevant as the serial number duplicates on your lan.

$ mapinfo
Name Location Size Type Source Guard
---- -------- ---- ---- ------ -----
boot 0x00000000 0x00040000 Flash bootargs Off
bootvars 0x00040000 0x00020000 Flash bootargs Off
linux1 0x00060000 0x00180000 Flash bootargs Off
initrd1 0x001e0000 0x00600000 Flash bootargs Off
linux2 0x007e0000 0x00180000 Flash bootargs Off
initrd2 0x00960000 0x00600000 Flash bootargs Off
linuxvars1 0x00f60000 0x00020000 Flash bootargs Off
linuxvars2 0x00f80000 0x00020000 Flash bootargs Off
serialnum 0x00ff0000 0x00008000 Flash bootargs Off
macaddress 0x00ff8000 0x00008000 Flash bootargs Off
zImage 0xa0008000 0x00200000 DRAM Initial Off
scratch 0xa2000000 0x00a00000 DRAM Initial Off
script 0xa2a00000 0x00100000 DRAM Initial Off
Stack 0xa3e9ff80 0x00020000 DRAM System On
GD 0xa3ebff80 0x00000080 DRAM System On
Heap 0xa3ec0000 0x00040000 DRAM System On
Text 0xa3f00000 0x000218f0 DRAM System On
BSS 0xa3f218f0 0x00005c34 DRAM System On

The sdcard is just the /usr/local/ portion of the firmware. The rest is in the 16mb flash.

Be careful, its super easy to brick your MDI with these tools.

Figured it out.

Mount the sdcard parition 1 under linux, and rename telnetd.sh-disabled to telnet.sh in /bin. While there I also edited the init script and added this near the start to make the prompt nicer:

export PS1='[\u@mdi \W]\$ '

Access u-boot (38400 baud, see previous post), and at the prompt type:

askenv setbootargsprimary

Please enter 'setbootargsprimary':run normalargs addinit addconsole addeth addprimary;setenv bootargs ${bootargs} mtdparts=flash0:256k(boot),128k(bootvars),1536k(linux1),6144k(initrd1),1536k(linux2),6144k(initrd2),128k(linuxvars1),128k(linuxvars2),32k@16320k(serialnum),32k(macaddress),128k@16256k(id);

boot

The MDI will boot and start a telnet server on its IP and have a new flash partition configured as /dev/mtd10 called 'id'. This will align with the erase block so can be updated. Check in /var/log/messages for the presence of 'id' without it being forced readonly.

Telnet in and rip a copy of mtd10 with dd, and send it to an ftp server you have setup on your lan.

[root@mdi ~]# cd /tmp
[root@mdi tmp]# dd if=/dev/mtd10 of=mtd10.img
256+0 records in
256+0 records out
[root@mdi tmp]# ls -l mtd10.img
-rw-r--r-- 1 root root 131072 Jan 1 00:07 mtd10.img
[root@mdi tmp]# ftpput -u <user> -p <pass> <ip> mtd10.img mtd10.img

Now load up mtd10.img on your pc in HxD or Hexworkshop. The serial is at 0x10000 with a crc32 checksum of 0x10000->0x17FFB at 17FFC (LSB).

MAC is at 18000 with a crc32 checksum 0x18000->0x1FFFB at 1FFFC.

Update both (just change the last couple of numbers), and use the calculate checksum feature of the hexeditor to calculate crc32 the sums of of the ranges and save the new sums in the bin (remember to enter them in LSB format).

Now pull the files back to the mdi, and update flash:

[root@mdi ~]# cd /tmp
[root@mdi tmp]# ftpget -u <user> -p <pass> <ip> mtd10-new.img mtd10-new.img
[root@mdi tmp]# cd /usr/local/mtd/
[root@mdi mtd]# ./flash_unlock /dev/mtd10
[root@mdi mtd]# ./flash_erase /dev/mtd10
Erase Total 1 Units
Performing Flash Erase of length 131072 at offset 0x0 done
[root@mdi mtd]# ./flashcp /tmp/mtd10-new.img /dev/mtd10
[root@mdi mtd]# dd if=/dev/mtd10 of=/tmp/mtd10-readback.img
256+0 records in
256+0 records out
[root@mdi mtd]# md5sum /tmp/mtd10-new.img /tmp/mtd10-readback.img
1a1f4fb7db878218c558b45c0db50c9f /tmp/mtd10-new.img
1a1f4fb7db878218c558b45c0db50c9f /tmp/mtd10-readback.img

Now reboot the MDI, and hold down the power button so it goes in to recovery mode. Use MDI manager to recover the device. Once completed it'll have the new serial and mac.

I expect that the cloners will find this thread and soon they wont all have the same serial anymore. But if you already have one then you can do this yourself, so long as your careful and make sure everything is going to plan and makes sense to you as you go.

Kudos to gmtools work
Well over my head, hope it works for someone

Wow!!!!! I don't have time at the moment to read all the details but that is amazing!!! So much more than I would be capable of, thanks!!!!! I'm printing this NOW to peruse and change our serial numbers using your instructions!!!!

I don't think the MDI manager or GM software looks at or cares about the MAC id.. We have had two clone MDI's running now for months with only my modification to the serial number in the SD card.. Course Once I change the serial number I will probably change the MAC id too..

Thanks again!!!!

having trouble with the crc32 checksum, your including the 1220-22129579 for the checksum and it's crc32??

when you calculate crc32 the sums of 0x10000 -> 17FFB I'm assuming you mean the crc of 0x10000 gets put into the location of 17FFC??

my crc calculations aren't anything close, lol.. Course this might be the first time I'm attempting anything crc related..

Its CRC32 in LSB byte order and my range was off by 1 in the first post (now fixed). Here is an example showing the clone serial/crc calculations.
   

Thanks a lot there gmtools, especially for the pic.. so it looks like am selecting the serial number and all the 0's from that to the beginning of the crc, that would be one of the attempts I did not try, lol.. everything is at the shop but I'll try it out again tomorrow..

btw, this misalignment that is causing the serialnum function to fail, Do you think this exists on genuine MDI's? I have an original if it would help to possibly repair this issue?? Granted it really only interferes with re-writing the serial number so far...

Yep thats right. Its the sum of the whole block minus the 4 byte CRC at the end. Its the standard for all the blocks in the MDI. CRC is much stronger than sum, where the null bytes would not have made a difference.

Yes, they have done it on purpose to prevent this sort of tampering. Embedded engineers mess with alignment often to make this sort of stuff hard. It half breaks many things. Its not the first time ive seen it. They would have had it aligned differently during development but then sent them out the door like this successfully confusing the cloners.

Well I logged into my work computer just because this has perked my interest.. I sent the file to my home computer and reworked the file to change the mac ID and serial number.. First I verified the CRC of the existing one's already there just so I could verify I was doing it right.. The way you re-wrote the instructions made it a lot easier for me to understand, thanks!!!

Soon as I get a chance I'll see if I can re-write that file back to the MDI and re-write the flash, see how it goes..

thanks again!!!