Mediagate MG-35 -- new firmware available

[pbarrette]

Hi mgcurious,

Thanks for the tip with skyeye. I was able to run the MG35 binaries on Skyeye v0.9.5 after repacking the ROMFS file that came with the Win32 package.

I was hoping that "upgrader" would take some basic command line options since they appear to be present in the program. However, if the command line options are there, I haven't been able to get any working.

The MG35 "upgrader" program appears to do an initial, low level probe of the flash memory before proceeding. Since the emulator doesn't provide the proper response, "upgrader" fails out.

It seems that I'm going to have to find some other way to deal with this. Perhaps I can build gdb for use on an ARM device and run upgrader in it. Then possibly NOP the calls to the flash probe, or at least get some assembler code out and try to decipher the CRC checking routines.

Either way, it doesn't appear to be an easy path ahead.

pb

[W4tch3r ‹•¿•›]

Hi pbarrette,
You've done some amazingly good work here. I have not joined the conversation earlier because I am a bit busy at work at the moment to give any real input. I did have a quick stab at disassembling upgrader though using idapro 4.9. I used your kit on a 1.44_English image to extract the cramfs file system. After reading about how to interpret cramfs file headers I found the Code Segment entry point to be at offset 0x50 (and the Data Segment starts at 0x109C0). After telling ida to start disassembling at offset 0x50, it did seem to give quite a sain dissassembly of the file (which I judge crudely by looking at how many entries it puts in the "Problems Window". Switch the analysis it to "big endian" and reanalyse, for example, gives you about 100 times the errors). Biggest problem is that although it can handle little endiam arm executables, and it finds all the strings in the data segment, the cross referencing is not working in the usual manner so its hard to find the references to the strings in the code. For example, you see this in the disassembly:

Text:0000069C LDR R1, =0xE80A0100
Text:000006A0 LDR R2, =0xC4090100
Text:000006A4 MOV R3, #0xCB ; '-'

and normally ida would tell you that 0xE80A0100 is a reference to a string. Now if you go and look at offset 0x00010AE8, you see it contains the string "[%d] %s: checksum : %lx". So basically the little endian format is confusing ida somewhat. The consequence of this is that it takes a bit of time to find references in the code to the strings in the data section (you have to manually do a slow "ASCII search" for the address bytes in reverse order).

So basically all I have to add at moment is that as far as your search for tools goes, I think idapro almost gets you there. I will try a bit more when I find some more time.

I did also try to use a multi polynomial crc utility on the boot.rom image without any luck (I tried multi polys and tried trimming bytes off the end too). I thought it may be worth searching for the table entries of common crc algorithms (in case they used a table based crc implementation). If there is a hit there then you can be sure of which poly was used, then it would be a matter of finding the data its used for. Another possibility is to search within the code for the number code size - 4 (or (size-4)/2 or (size-4)/4). That could be the number of iterations of the crc calc loop.

As far as 2 crc's goes, maybe 1 CRC for the bootloader itself and 1 for the linux+cramfs section?

W4tch3r ‹•¿•›

[fanchoor]

Hi guys,


Is there a way to play WMV video files on Media Gate-35? Most of my video file are WMV files and its pain to covert them all to other supported formats.

Can some one help please?

I have seen that MG-35N supports WMV so I think its possible to play WMV on MG-35 as well.


Thank you

[gunrunnerjohn]

I don't know of any way to play unsupported formats on the MG-35. That would obviously take firmware changes, something that's being discussed in this thread.

[Masoud]

Dear all
how can upgrade medaigate firmware with 10pin connector on mediagate PCB.

[fx57]

Great work pbarrette and W4tch3r!

I too would like to see ftpd running on my mg35 as an alternative to slow NDAS transfers.

I poked around a bit and maybe I can offer some useful info.

I tried disassembling upgrader with IDA and ran into the same address order problems. It appears the code is little endian but header values and addresses are big endian. Luckily the file contains a fixup table which points to all the addresses so you just need to reverse the byte order of these and then everything appears as it should in IDA. Also, the code address space seems to start at byte 0x40 of the file.

I still haven't found anything which looks like a CRC computation yet, but I'll keep looking. Its strange they have a full blown lex parser contained within upgrader, I have no idea why.

Here's the C program I used which fixes up the upgrader binary so you can load it properly in IDA. It reverses all the addresses and strips off the 0x40 byte header and the fixup table.

#include <stdio.h>

unsigned char buf[1000000];

unsigned int getval( unsigned char *p)
{
    return ((((((unsigned int)p[0] << 8) | (unsigned int)p[1]) << 8) | (unsigned int)p[2]) << 8) | (unsigned int)p[3];
}

int main ()
{
  FILE * pFile;
  int c;
  int n = 0;
  unsigned int table, relocs, offset, addr;
  int end;

  pFile = fopen("input.bin","rb");
  if (pFile==NULL) printf ("Error opening input.bin for reading");
  else
  {
     for (;;)
     {
        c = getc(pFile);
        if (c == EOF) break;
        buf[n++] = c;        
     }
     fclose(pFile);
  }

  end = table = getval(buf+0x1C);
  relocs = getval(buf+0x20);
  while( relocs--)
  {
     offset = getval(buf+table) + 0x40;
     addr = getval(buf + offset);
     printf("fixup entry %08x: offset %08x, addr %08x\n", table, offset, addr);
     memcpy( buf + offset, &addr, 4);
     table += 4;
  }

  pFile = fopen("output.bin","wb");
  if (pFile==NULL) printf ("Error opening output.bin for writing");
  else
  {
     char *p;
     for (p=buf+0x40; p < buf+end && p < buf+n; p++)
     {
        putc(*p, pFile);
     }
     fclose(pFile);
  }

}

[pbarrette]

Hi fx57,

Excellent work!

I wish someone would implement a proper bFLT FLIRT signature for Ida. That would really help out.

You may want to have a look at dvdplayer.bin as well. Since it's the main interface, it should also contain the initial stages of the upgrade process. I mean, something has to call upgrader and tell it what to do, right? I did notice some strings in there referencing upgrader.

I saw the lex references as well, but didn't know what to make of them. The header already contains the addresses to the firmware parts, so it doesn't need the parser to find them.

Perhaps if we can NOP out the calls to the flashmem probes we can get upgrader to calculate our CRC's for us.

In the mean time, I've been trying to figure out how to get Skyeye to boot the MG35's kernel. There's no ELF header on it, so I'm not quite sure how to deal with that.

I've also been having a preliminary look at the 10-pin header at J9. My multimeter says 3.3v on pins 1,2 and 6. Pin 4 looks like ground and pin3 is 1mohm (IIRC) from pin4. I'm still guessing it's a serial port, but I don't have a level shifter on hand and I don't want to fry the board.

pb

[gunrunnerjohn]

By all means, DON'T connect a serial port directly to that! There are a host of serial port level shifters that can be plugged together on a prototype board if you want to see if you can get a response out of the port. I've used the Sipex SP232A on a number of projects.

[fx57]

OK, here's what I came up with reversing the firmware upgrade file format. There are no CRC's, they are just checksums where you read the data as DWORDs and sum them up. All dword values are 4-byte little endian format.

000000: "UPGI" ascii
000004: "XM02" ascii
000008: 0x00010404 dword = version 1.44

00000C: "BOOT" ascii
000010: 0xB2756E63 dword = checksum of bootloader (sum of dwords)
000014: 0x00000000 dword =
000018: 0x00010420 dword = size of bootloader
00001C: bootloader data

01043C: "ROFS" ascii
010440: 0x16C8BFC6 dword = checksum of rom filesystem (sum of dwords)
010444: 0x00040000 dword = maybe the location it is stored at in flash memory?
010448: 0x002D8809 dword = size of rom filesystem
01044C: rom filesystem data (dword + linux kernel + cramfs)

2E8C55: EOF


The format of the rom filesystem data is:
01044C: 0x000E2809 dword = location in flash of cramfs
010450: start of linux.gz
0B2C55: start of cramfs.img


I still don't know for sure what causes the mg35 to decide a file is a firmware file. My guess is the "UPGI" text at the start of the file does it but I'm not ready yet to risk turning my mg35 into a brick trying to find out.

[fx57]

And the "C" program used to verify the checksums:

#include <stdio.h>

unsigned char buf[4000000];

int main ()
{
  FILE * pFile;
  int c;
  int n = 0;
  unsigned int table, relocs, offset, addr;
  int end;
  int i;
  unsigned int x=0;

  pFile = fopen("input.bin","rb");
  if (pFile==NULL) printf ("Error opening input.bin for reading");
  else
  {
     for (;;)
     {
        c = getc(pFile);
        if (c == EOF) break;
        buf[n++] = c;        
     }
     fclose(pFile);
  }

  printf("read %d bytes\n", n);

  for (i=0;i<n;)
  {
      unsigned int *d = (unsigned int *)(buf+i);

      if (buf[i] == 'U' && 
          buf[i+1] == 'P' &&
          buf[i+2] == 'G' &&
          buf[i+3] == 'I')
      {
            printf("UPGI at offset %x\n", i);
            i += 12;
            continue;
      }
      else
      {
            int c = d[3];
            int x = 0;
            for (c=0; c < d[3]; c++)
            {
		x += buf[i+16+c] << (8*(c&3));
            }
            printf("%c%c%c%c at offset %x, crc %x=%x, addr %x, size %x\n", buf[i],buf[i+1],buf[i+2],buf[i+3],i,d[1],x, 

d[2], d[3]);
            i += 16+d[3];
      }
  }


}

[davei1]

For anyone interested...
I bought one of the XIMETA empty NetDisk Enclosures that sell for under $100 that also use NDAS...I believe these have the NDAS processor that the MG-35 lacks...I'm planning on buying either a 500 or 750MB drive when the prices come down more...In the interim I took the drive out of the MG-35 with all my music and video and backups, etc. and put it in the NetDisk enclosure...Registered the NetDisk as a NDAS device with the ID and Write Key and did some testing with file transfers...The NetDisk enclosure using NDAS for file transfers is approximately 3 to 4 times faster than the MG-35 transfers using NDAS...I also tested watching .VOB files from the Netdisk (shared out) through the MG-35 and all played without any glitches (100baseT network)...I'm going to leave it in this configuration until I get a big drive...Only thing I'll want to change is add a fan to the NetDisk enclosure (Like I did my MG-35)...

[pbarrette]

Hi fx57,

I took the plunge.

Your checksum code works great!

This is what I did:
1 - Compiled your code with cygwin.
2 - Split out the MG35-144-eng firmware to the 3 component parts.
3 - Used FSExtractor to add files to the cramfs.img
4 - Merged the components back together (copy /b).
5 - Changed "0x010448:" to reflect (Linux.gz+Cramfs.img+4).
6 - Ran your code against the new firmware image.
7 - Changed the checksum at "010440:" to the one calculated with your code.
8 - Upgraded the firmware on my MG35.

I stole some bits from the KiSS firmware project to add to the cramfs filesystem. Specifically, I took "/bin/ftpd", "/bin/busybox" (renamed to busyb) and "/etc/passwd". I also modified /etc/sashrc to start "/bin/ftpd &" and "/bin/busyb telnetd &".

The only bad news is that ftpd and telnetd don't seem to have started up. I should probably also add "/etc/services" in there as well. Actually, I should probably cross compile a new busybox and ftpd and use that.

But.. The very good news is that your code works great and we can now start modding the firmware for these things!

Thanks for your excellent work.

pb

[teddystacker]

Guys,

This is really really great news,a huge thank you to you both for your superb work..

At this point I have not managed to find anyone who can do us some graphics for a better GUI.so I may post a request in the main forum and a couple of similar forums pointing to this thread to try and attarct someone that can help..

@PB,Would you be papared to host any new "beta" firmwares yourself? or do you think it might be a better idea to create a Yahoo group to host files etc,this may avoid and bandwidth or legal issues?. If so, I am papred to create and mange this for us - at least then i can contribute something...

Let me know your thoughts...

[pbarrette]

Hi Teddy,

Honestly, I'm not concerned in the least about "legal issues" coming from a company that is blatantly stealing GPL'ed work and reselling it without offering source code.

Bandwidth, however, may be an issue. I have a lot to spare at the moment, but I don't know what the expected load would be for custom firmware images. So it's probably best to start a yahoo group.

I think we need to redo the firmware tools so others can create their own firmware images more easily and with a minimum of risk.

I plan on making a checksum creator / injector in C# soon. I also have a few other utilities I've written while trying to figure out the "CRC" problem that would probably be useful for other purposes. For instance, I used the classless.hasher library to create a multi-crc generator with custom CRC polynomial support.

In the short term, I'm thinking of a simple program that will accept a Mediagate firmware image. It should then extract the cramfs image and allow you to edit it to suit your needs. Then the program would replace the original cramfs with the new one. Finally, it would update the size in the bootloader and change the checksums to build the new firmware. Additionally, it could change the firmware version number as well.

pb

[pjelar]

I'd be interested in creating images for this box. I've also got a friend who could create the graphics for the interface, I've been annoyed for a long time with the fact that it doesn't really do what I want it to do. Anyone gonna create a mailing list?

[teddystacker]

@pjelar

Great news that you can help with NEW graphics to improve the interface..


I am going to create a Yahoo group that will also act a a mailing list and a files distro..

Can you extract the graphics that need to be altered yourself ?(details on how todo this was posted by PB a week or two back) , or would you like me to email them to you?

I guess they would all need to be the same size and colour depth that the originals were , but maybe you could check that with PB..

Will be at the beach tomorrow , so will be a couple of days until its up and running..

[alangsk]

If this could be done to the MG-35, could it possibly be done to the MG-350HD? I know the MG-35 needs to happen first, but I am just curious.

[W4tch3r ‹•¿•›]

Spectacular work guys (esp pb, fx57). Very impressive, congratulations. Flirt sig as pb suggests would be great. FX57, is it possible to run your byte reversal code as an IDA script (IDC file)? I would like to know also pb how far you can push Skyeye. It would be nice to develop a test environment so any risk to the MG35 can be left as late as possible in the process,
W4tch3r ‹•¿•›

[ru*]

Hi teddystacker,
I'm Pjlars friend, could you post the require files here or email me the files so i can edit the files as necessary.

Also does any one know if its possible to change the way the system displays files and also its ability to play files in a working manner?

Ru.

[gadgetmind]

I'll join the yahoo group as soon as it's created.

Maybe we can handle distributing firmware via **********? This would handle the 1st rush as everyone grabs it, and then older stuff can be archived elsewhere.

My main gripes with the MG-35 are -
1) Pretty bad handling of divx/xvid - it's great with some files but has bad lip sync and/or jerky performance with others. I tend to use autogk to re-encode some files (virtua dub won't handle a fair few) I doubt we can fix this.
2) It takes ages to drill down to my content. I have to tell it I want network content (no HD i my unit), then wait for a list of servers, then go to the right server, then the right share - it must take a good minute before we get to where we need to be.

Dunno how (2) could be addressed as I guess the current applications are all closed source. But maybe my samba share could be mounted somewhere where the MG-35 would see it immediately? I'm not sure how samba (or even the HD mounting) is currently done.

Ian

[fx57]

Maybe getting a simple shell running on the MG35 is a good first step?

http://www.gooddvdstuff.com/kissdvd/...pic.php?t=1527

[jayeazy]

Hello Guys,

Been away for a while, and it seems a lot has been done.
Looks good, what is done, and can be done.
Can't wait for the possibility to customize the MG35.

It looks like the SASHRC script in the /etc folder is the startup script of the system.
Can't wait to be able to login to the mediagate, and try to mod to unit.

Keep on going guys ;-)

Jelte

[teddystacker]

Ok,

Have been having a think about files distro for Beta firmware - ********** good idea.. also is Rapishare,I have a Rapishare premium account,so as well as posting any Beta firmware to the Yahoo group that I plan to create , I can also post a Rapidshare link both here and at the Yahoo Group,so people can download directly without any hosting problems.Yahoo groups only have 20 gig storage,so wont be able to archive that much there,thus Rapid and ********** will be useful.Rapidshare link NEVER expire,so wil provide a good archive..

For Those of you wishing to do some artwork for a new GUI for the MG 35 , here is a Rapidshare link for the unpacked Mg-35 Firmware.The one here is the latest Korean 1.4.5 f/w that PB suggest we use..
As you will see I have left the complate file structure intact,as the graphic files are located inside many different folders.Most appear to be in jpg and png format.I presume (might be a good idea to check with PB) that any replacement files you create will have to be the exact same file size and colour Depth.

http://rapidshare.de/files/26124381/...R.DIR.rar.html

I will make time to create the Yahoo MG-35 Fimware mod Group tomorow , and will post details here as soon as I have done it..

[pbarrette]

Hi Teddy,

At this point, it's probably a good idea to keep the images at the same color depth. I'd have to take a closer look at the images and compare them to what I see on screen, but I think there may be a transparent color involved for some of the images. So that's something to check for as well.

As I said before, the PNG format seems to be a little odd. IrfanView does not recognize them, but Photoshop has no problems. The MG35 is using libpng to display the PNG images. This should mean that we have a lot of flexibility as far as color depth and compression.

The modified images can be any size, but due to limited flash memory, smaller is better.

In the meantime, I've made a program which can verify the checksums of MG35 firmware images and create a patched output file. The utility can be found here. It only supports MG35 images at the moment, but I plan on supporting MG25 and MG350 firmware images in the near future. Right now, it will detect MG25 and MG350 images and give a "Not supported" message. Again, this program uses the .NET framework.

To create your own custom firmware images using Windows, download the following tools:
1 - MGFWExtract
2 - FSExtractor
3 - MgCheck

You then need to perform the following steps:
1 - Use the MGFWExtract package to split out the firmware image.
2 - Use FSExtractor to edit the Cramfs image.
3 - Join the parts back together: copy /b boot.rom+linux.gz+cramfs.img NewFirmware
4 - Run "MgCheck -p" against the new firmware image to patch it.

The resulting "NewFirmware.fix" file can then be renamed to ".upgrade" and flashed to the MG35.

Of course, the standard disclaimer follows...

You can kill your MG35 if you don't know what you are doing. Don't delete any files in the Cramfs.img file if you don't know what they do. Don't edit any of the files if you don't know what they do.

I have successfully flashed a modded firmware image using this process, but I could have killed my box just as easily.

pb

[EmuMannen]

Originally Posted by malore82

I'm attempting to use 10.4 as my file server and was wondering if anyone else has gotten it to work and/or could elaborate on the said process above. I know the MG-35 works via the Network because I can get it to access a shared volume with XP S2 -- but am having no luck with OS X. Of course, the provided documentation is completely mum on the issue.

I had some problems getting my MG-35 to work with SMB under Linux preserving the opportunity to have security = user. This is how I solved the problem (the example is for one share holding your private files, requiring username and password and the other one is a public share granting all users read and write access). You will also need to create a samba user called “guest” (command: smbpasswd -a username), use any password if your not allowed to create a new user with an empty password and reset the password to null (command: smbpasswd -n username):

File: /etc/samba/smb.conf

[global]
workgroup = YOUR_WORKGROUP_NAME
netbios name = YOUR_SERVER_NAME
passdb backend = tdbsam
security = user
encrypt passwords = true
guest account = guest
null passwords = yes
socket options = TCP_NODELAY

[Private]
comment = Private files on server
path = /path/to/privte/files
read only = no
valid users = your_user_account

[Public]
comment = Public files on server
path = /path/to/public/files
invalid users = root
guest ok = yes
public = yes
writeable = yes

[EmuMannen]

Originally Posted by batman1056

what is the difference between Al tec and freecom? my box says freecom medaiplayer 35,
On their site last firmware is 1.4.3 so I haev tried to use the Al Tec firmware and the device can not see the file!

I got a Freecom Network Media Player-35 myself. I haven’t upgraded the firmware (yet, it came with the latest Freecom version 1.4.3). The Freecom unit should be equal to the Media Gate MG-35 based on readings on other Scandinavian HT-boards. There are examples of successfully using the Media Gate firmware on Freecom units. This is only based on what I have read on other boards and I haven’t tried it my self yet.

Ps. I have got the impression that the Freecom unit is the same as the Media Gate MG-35, just sold in Europe by Freecom under another name, but I could be wrong…

[EmuMannen]

Originally Posted by pbarrette

Hi Batman1056,
Freecom is the exception. If you have a Freecom MG-35 clone, you can email their support with your serial number and MAC address and they will email you back with the DeviceID and Write Key at no charge. This is one of the main reasons I got the Freecom.

I got the MAC, DeviceID and Write Key on a sticker on the bottom of my Freecom Network Media Player-35. They are labeled: MAC, ID, KEY (the sticker is also mentioned in the user’s manual). So check the bottom of your unit for a separate sticker with NDAS information...

[EmuMannen]

I just returned to AVS and as usual looking for something interesting. The latest development in this thread really got me going! pbarrette, just want you to know that I am reading all your posts with great interest and enthusiasm. Thanks a lot for all your hard work and I am really looking forward to some serious hacking of this unit (I got a Freecom myself). I am not an ARM hacker my self but I do code for a living and I got some really nice resources at work. Please let me know if you need any help. I don’t got much time at hand (running a family with small kids) but I guess that I could contribute in the GUI/gfx area. I just love working with HMI and Photoshop. Just let me know if you need any custom gfx for this unit…

[dodonov1]

Originally Posted by pbarrette

...There are ports for telnetd and ftpd, but I haven't yet seen an smbd for uClinux.
pb

Hi pbarrette and all

Many thanks for your great work on cracking open this firmware. I'm reading this mailing list with great interest. I just came across this product last weeked, and the only reason I haven't purchased it yet is the lack of a samba server running on it. If you get this working, you'll have sold another MG-35 for Freecom :-).

I'm an embedded s/w developer but alas don't yet have enough experience to contribute any help at this stage. However, I noticed your comment about getting smbd running on uClinux. It occurred to me that, as far as I know, the Linksys NSLU-2 has an ARM (XScale)-based CPU running uClinux and features a samba server. That might be another useful source of code and utilities.

Thanks, and good luck with the next steps.
-Dan

[pbarrette]

Hi Dan,

The real breakthrough came from fx57 by finding the checksumming logic.

I think that the XScale CPU's have an MMU and thus can use fork(). We would have to find a port for smbd that uses vfork() instead. There is probably a patch out there somewhere, but I'm taking it one step at a time.

pb