New project: Non-JTAG CFE replacement on the WRT54G v5

Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Broadcom SoC based Hardware
Goto page Previous  1, 2, 3, ... 27, 28, 29  Next
Author Message
ro-maniak
DD-WRT User


Joined: 07 Jun 2006
Posts: 365

PostPosted: Sun Jun 18, 2006 22:25    Post subject: Reply with quote
Same here, that would be shameless! I have to hear this from someone to whom it happened to believe it though, those are 2 different products and they cannot switch them like it does not matter! Evil or Very Mad
_________________
If you use DD-WRT, you HAVE to make a donation! See this topic too: http://www.dd-wrt.com/phpBB2/viewtopic.php?t=228
Sponsor
jhel
DD-WRT Novice


Joined: 18 Jun 2006
Posts: 1

PostPosted: Sun Jun 18, 2006 23:31    Post subject: Reply with quote
Great project: Please do proceed!, there are many users with v5 firmware who would love a simple way to load dd-wrt Is there any way to support this project?




Joined: 01 Jan 1970
Posts:

PostPosted: Mon Jun 19, 2006 1:43    Post subject: Reply with quote
BrainSlayer wrote:
standard vmlinux elf will work yes and stripping of the image is usefull too. keep me up to date with it. it would be a nice help. if you wrote a takeover image i will take this work to construct a real working dd-wrt based on the vxworks bootloader. any help is welcome since i'm busy with rb532 development in the last days


Great Wink. Thanks much for the answers.

I'll keep playing with this. I suppose I really should get some 'real' work done, but most likely I'll get obsessed with this project again tonight and try to finish it on up.




Joined: 01 Jan 1970
Posts:

PostPosted: Mon Jun 19, 2006 4:39    Post subject: image header format Reply with quote
Ok, I've done some work on documenting the image header format.

Since it has some file descriptors that are necessary to change, I figured I'd go ahead and initate work on defining the structure.

EDIT: I'll be constantly revising this definition for the next while. I've already identified more possible fields since I posted this. I don't to have to keep updating this post, so please see http://www.bitsum.com/openwiking/owbase/ow.asp?WRT54G5%5FCFE for the latest definition.

EDIT: UPDATED ON 6/23/06
Code:

////////////////////////////////////////////////////////////////
// Linksys VxWorks based firmware image format
// Author: Jeremy Collake (jeremy@bitsum.com)
// WARNING: Work In Progress. Mistakes and guesses are present.
//
// The firmware image header
//
//  Revisions:
// 
//     06/23/06     - Added BOOTROM_BOOTP_DATA_SIZE (at end of BSP).
//    06/22/06     - Identified TrailingFiles descriptors.
//                Added VX_FILE_ID_BOOTROM.BIN (1)
//                   Minor tweaks
//    06/21/06     - Put to use in code, found minor typos.
//                 - Several fixes
//    06/19/06     - Minor tweaks
//    06/18/06     - Quick draft
//       
// Basic format:
//
//    VxLinksysHeader
//      VxFileDescriptor array
//    File1
//    File2
//    File3
//    ....
// 
// NOTES: 
//
//  1. Files of pre-defined type ids are included in the firmware images
//  and indicate to the part of the flash they should be written.
//  For example, type 2 is vxworks.bin (the main OS). See
//   VX_FILE_ID_ definitions for a complete list.
//
//  2. Field sizes are for a 32-bit processor.
// 
//  3. Example field values are taken from version 1.00.9_US:
//  wrt54gv5_v6_fw_1.00.9_US_code.bin
//
//  4. Many fields are stored big endian and operated
//  on my endian neutral code.
//
//  5. The file descriptor sizes sum up like so:
//  1120664+183064+29432+28972+31280+33152+31644+30244 = 1488452
//  1488452 + 512 = 1488964
//
//  real file size is 1551880:
//
//  1551880 - 1488964 = 62916
//
//  The last 62916 (in the case of 1.00.9) is the
//  trailing parts/files, as indicated by the
//  TrailingFiles array of file descriptors.
//
//
//

/////////////////////////////////////////////////////////////////
// VxFileDescriptor
//
// file descriptor structure (array at end of VxLinksysHeader)
//  describes a file inside the firmware image
//
// fields are stored big endian, and should be read by
// endian neutral code.
//
typedef struct _VxFileDescriptor
{    
  unsigned long nFileId_BigEnd;     // file id (see below)
  unsigned long nFileSize_BigEnd;   
} VxFileDescriptor, *pVxFileDescriptor;

// Note: VX_FILE_ID_BOOTROMBIN can not be combined with any other types
// of flash images. If it exists prior to other types, it will be the
// only area updated, and if it exists subsequent to other types it
// will not be flashed.
#define VX_FILE_ID_BOOTROMBIN 1
#define VX_FILE_ID_VXWORKSBIN 2
#define VX_FILE_ID_IGWHTMDAT 3
#define VX_FILE_ID_LANGPAK_EN 6



// the BOOTP storage area holds the
// serial number and boot string.
// It exists at the end of the BSP.
#define BOOTROM_BOOTP_DATA_SIZE 0x400
// hard coded bootrom size..
// shave off 0x400 bytes for reserved BOOTP area
// at the end of the bootrom.
#define BOOTROM_SIZE 327680-0x400

/////////////////////////////////////////////////////////////////
// VxLinksysHeader
//
//
#pragma pack(push)
#pragma pack(1)
typedef struct _VxLinksysHeader
{
  unsigned long nCodePattern;     // '5', 'V', 'G', 'W' = 'WGV5' 
  unsigned char cUnknown_4[4];
  unsigned char cYear;            // 0x06  (2 digit year?)
  unsigned char cMonth;           // 0x05 
  unsigned char cDay;             // 0x0C 
  unsigned char nProductVersion_0;   // 0x05
  unsigned char nMinorVersion_0;   // 0x90
  unsigned char cZUnknown_0D;
  unsigned char cImageFormatVersion[4];    // 'U2ND'
  unsigned char cZUnknown_12[238]; 
  //
  // offset 0x100  -- begining of an secondary header?
  // 
  // After this point, all integers are stored big endian
  // and should be read by endian neutral code
  // (that is, read as big endian).
  //
  unsigned char nProductVersion_1;   // 0x05   
  unsigned char nMinorVersion_1;     //0x90
  unsigned short nMajorVersion_1;    // 01
  unsigned char cZUnknown_104[2]; 
  unsigned short nHeaderSizeBigEnd;// 0x02, 0x00
  unsigned long nChecksumBigEnd;   // checksum, big endian (0x611697AE)
  unsigned char cZUnknown_10B[2]; 
  unsigned short nUnknown_10D;      // 0x00, 0x02
  // 0x110
  unsigned char cZUnknown_110[0x30];
  unsigned char cModelName[0x20];  // 'WRT54G'
  unsigned char cVendorName[0x20]; // 'LINKSYS'
  VxFileDescriptor TrailingFiles[8]; // parts of file that follow primary file descriptors                           
  VxFileDescriptor FileDescriptors[8]; // primary file descriptors, immediately follow header 
} VxLinksysHeader, *pVxLinksysHeader;
#pragma pack(pop)



And.. a log a serial messages of a flash of v1.00.9:

Code:

enter HttpClient_SendHeader
addr of pMPart.ucBuf 0x803841fe
++addr of pBuf 0x803841fe pCur 0x804ff19c
++ulLen: 1552286 ContentLen 1552286
pReq->ucFileName index.tri
MATCHED..
GetMPartBoundary: pTemp 0x80584823
ucExt = bin
pBuf 792[0x803842fe]: 0x35 0x56 0x47 0x57
Code Pattern=5VGW
code pattern success
GetMPartBoundary: pTemp 0x80584823
FILENAME = /fl/vxWorks.bin uiLen[0] = 1120664
File /fl/vxWorks.bin opened
pDatabuf[0x803844fe]: 0x7f 0x45 0x4c 0x46
lWriteCount = 102400  lRemain = 1120664, lOffset =0
lWriteCount = 102400  lRemain = 1018264, lOffset =102400
lWriteCount = 102400  lRemain = 915864, lOffset =204800
lWriteCount = 102400  lRemain = 813464, lOffset =307200
lWriteCount = 102400  lRemain = 711064, lOffset =409600
lWriteCount = 102400  lRemain = 608664, lOffset =512000
lWriteCount = 102400  lRemain = 506264, lOffset =614400
lWriteCount = 102400  lRemain = 403864, lOffset =716800
lWriteCount = 102400  lRemain = 301464, lOffset =819200
lWriteCount = 102400  lRemain = 199064, lOffset =921600
lWriteCount = 96664  lRemain = 96664, lOffset =1024000
FILENAME = /fl/igwhtm.dat uiLen[1] = 183064
File /fl/igwhtm.dat opened
pDatabuf[0x80495e96]: 0x54 0x52 0x4f 0x43
lWriteCount = 102400  lRemain = 183064, lOffset =0
lWriteCount = 80664  lRemain = 80664, lOffset =102400
FILENAME = /fl/langpak_en uiLen[2] = 29432
File /fl/langpak_en opened
pDatabuf[0x804c29ae]: 0x54 0x52 0x4f 0x43
lWriteCount = 29432  lRemain = 29432, lOffset =0
usBytesWritten = 17af9e, pReq->lInContentLen = 17af9e
 Up Load completed
strlen 43


Last edited by on Sat Jun 24, 2006 13:13; edited 2 times in total




Joined: 01 Jan 1970
Posts:

PostPosted: Mon Jun 19, 2006 6:41    Post subject: problems... Reply with quote
Checksum problems!

At closer look, it turns out the checksum wasn't so simple, as some have assumed.

If any file in the image, INCLUDING THE HEADER, is modified, the checksum fails. This means that some algorithm is used that excludes the specific checksum field.

I calculated the CRC32 of the area before what I assume to be the checksum field, that after the checksum field, and the rest of the file, and that of the merged contents of all three. Using both the results and 1's compliment of the results, I tried summing the values, and everything else I could think of. No luck.

We may have to diassemble the code in the bootstrap to derive the checksum algorithm. Unfortunately, I'm not proficient in MIPS assembly... so this will be a PITA for me, and take some considerable time.

Any ideas?

------

Also, more notes about the image format:

Code:

//  The file descriptor sizes sum up like so:
//  1120664+183064+29432+28972+31280+33152+31644+30244 = 1488452
//  1488452 + 512 = 1488964
//
//  real file size is 1551880:
//
//  1551880 - 1488964 = 62916
//
//  It turns out the last 62916 bytes are some a filesystem containing
//   compressed .js files. The header is 'TROC'.
//  They don't appear, at first glance anyway, to be the Linksys web UI.
//  Perhaps some built-in web UI for the bootstrap's upgrade?!?
//




Joined: 01 Jan 1970
Posts:

PostPosted: Mon Jun 19, 2006 7:17    Post subject: Reply with quote
jhel wrote:
Great project: Please do proceed!, there are many users with v5 firmware who would love a simple way to load dd-wrt Is there any way to support this project?


Let's hope that it ends up successful.. I need to finish it quickly, else this obsession is going to ruin my life .. or at least my income ;p. This has definitely been more work than I thought it'd be.

As far as suport, donating to Brainslayer/DD-WRT is always a good idea Wink.




Joined: 01 Jan 1970
Posts:

PostPosted: Tue Jun 20, 2006 12:21    Post subject: update.. Reply with quote
I've run through every common checksum algorithm and every concievable combination of the data, and haven't come up with a match on the checksum. I've written a tool to help me go through algorithms quickly and test various combinations of the header+image.

What I know:

1.) Nbd's cursory analysis was wrong. The checksum is NOT a simple 1s compliment of the CRC32 of everything after the header... nor any other type of checksum on only the data after the header.
2.) The checksum includes the header itself (with the checksum field excluded, or assumed to be a certain value, of course).
3.) The checksum includes the entire image, all the way to the end.
4.) Therefore, any byte modified anywhere causes a checksum violation.

What I need to do is debug the code and reverse the algorithm. This is painful and time consuming. In fact, since I have no JTAG debugger and the VxWorks BSP offers no real debugging support, I will need to run the code in an emulator, I think... if I can find a suitable emulator. I sure as hell am not going to write one.

This is major trouble, and a major pain. I'm going to keep working on this, but it is much more work than I would have ever imagined to derive this simple checksum algorithm.

I'll keep you updated...


Last edited by on Tue Jun 20, 2006 13:52; edited 1 time in total
Eko
DD-WRT Developer/Maintainer


Joined: 07 Jun 2006
Posts: 5772

PostPosted: Tue Jun 20, 2006 12:39    Post subject: Reply with quote
I'm sure you know this but anyway: v5 has "Management Mode for Firmware Recovery": (great way to flash take-over image when (if) it's done)
http://linksys.custhelp.com/cgi-bin/linksys.cfg/php/enduser/std_adp.php?p_faqid=3176

Skywave
DD-WRT Novice


Joined: 17 Jun 2006
Posts: 44

PostPosted: Tue Jun 20, 2006 13:19    Post subject: Reply with quote
I've email linksys and they've replied
Quote:

I ve asked my kolleagues and following my informations
you get missinformed.
If you sent in a WRT54GL you should receive the same product if it is on stock.
If its not on stock we will contact you to discuss another solution.
Thats at least the normal procedure.




Joined: 01 Jan 1970
Posts:

PostPosted: Tue Jun 20, 2006 13:45    Post subject: Reply with quote
Eko wrote:
I'm sure you know this but anyway: v5 has "Management Mode for Firmware Recovery": (great way to flash take-over image when (if) it's done)

Yep, that's what I've been using. Flashing through the Linksys firmware/kernel doesn't emit any serial messages, so Management Mode is preferrable for debugging. Both accept the same image format.

I would have never thought this would end up so much trouble. If I could just get this checksum figured out all will be done... <<sigh>>. I wish it had turned out as simple as what Nbd thought it was.

I think I may have found a MIPS emulator that'll work.. but we'll see. I can't afford to make this my full-time job, but this obsesison is killing me ;p.




Joined: 01 Jan 1970
Posts:

PostPosted: Wed Jun 21, 2006 4:32    Post subject: Dump of RAM - Workable disassembly of VxWorks BSP! Reply with quote
WORK ON CHECKSUM:

I've been forced reverse engineer the VxWorks BSP to derive the checksum algorithm. It turns out the VxWorks BSP is compressed on ROM. It has a small decompression stub which decompresses the main code into RAM nad executes it.

I dumped the entire contents of RAM and have IDA to begin to give me (with manual coaxing) a workable disassembly, including proper XREFs. Whoop!

Therefore, I think its just a matter of time before I have determined the checksum algorithm. Whehter I run out of time before its accomplished, I don't know.
wygamail
DD-WRT User


Joined: 06 Jun 2006
Posts: 132

PostPosted: Wed Jun 21, 2006 5:15    Post subject: Reply with quote
Keep up the hard work! Very Happy
_________________
DD-WRT<--Have you contributed to DD-WRT yet?




Joined: 01 Jan 1970
Posts:

PostPosted: Wed Jun 21, 2006 6:36    Post subject: SUCCESS!!! Reply with quote
I DID IT!!!!

I'VE DERIVED THE CHECKSUM ALGORITHM! As predicted, I made quick work of the diassembly and derived the algorithm in about 2 hours Wink.

WHOOPEE!!!

I'll post details soon. This means we're 100% moving forward.
Skywave
DD-WRT Novice


Joined: 17 Jun 2006
Posts: 44

PostPosted: Wed Jun 21, 2006 6:52    Post subject: Reply with quote
Great news!!!! Smile




Joined: 01 Jan 1970
Posts:

PostPosted: Wed Jun 21, 2006 8:21    Post subject: checksum algorithm documented... Reply with quote
I've completed preliminary documentation of the checksum algorithm.

http://www.bitsum.com/openwiking/owbase/ow.asp?WRT54G5%5FCFE

Excerpts:

The algorithm is, in English, the two's compliment of an endian neutral 32-bit checksum, starting at the beginning of the header and extending to the end of the image, with the checksum field in the header (@ 0x108) set to zero (or omitted).

Code:

/////////////////////////////////////////////////////////////
// Checksum_Linksys_WRT54Gv5_v6
//
// unsigned 32bit checksum of 32bit unsigned integer - endian neutral
//
unsigned long
Checksum_Linksys_WRT54Gv5_v6(unsigned long *pStart, unsigned long *pEnd)
{
  unsigned long nChecksum=0;
  while(pStart<pEnd)
  {       
    nChecksum+=big_endian_l(*pStart++);       
  }
  return ~(nChecksum-1); // return two's compliment
}


... If anything happens and I'm not able to complete this task, I hope someone can pick up where I left off since I've done much of the grub work.

If I have much trouble getting the VxWorks BSP to boot vmlinux, I may write the flash writing code in 'raw' form, meaning no OS, just a bit of code that does its job and reboots. We'll see which turns out beind easiest as research continues.

Jeremy


Last edited by on Wed Jun 21, 2006 17:04; edited 3 times in total
Goto page Previous  1, 2, 3, ... 27, 28, 29  Next Display posts from previous:    Page 2 of 29
Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Broadcom SoC based Hardware All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum