[INFODUMP] Sonicwall TZ-170

Post new topic   Reply to topic    DD-WRT Forum Index -> Hardware DIY / Hardware Mods
Author Message
shadoxx
DD-WRT Novice


Joined: 28 Aug 2008
Posts: 3

PostPosted: Thu Jul 07, 2011 23:31    Post subject: [INFODUMP] Sonicwall TZ-170 Reply with quote
I've searched this forum (and consequently, the Internet) and it does not look as though much information exists about the Sonicwall TZ170. I'm here to change that! For about the past month I've been furiously working toward breaking into this little beast of a network appliance (64MB of RAM, 8MB Flash!) and this is the information that I have gleaned so far. Please note that this is a culmination of about a month's worth of work, on and off, and this is my first attempt at trying to organize the discourse that my harddrive has become. Here goes!

Chips
Code:
* Processor: SONICWALL 156-000022-00 [No Documentation as far as I can tell. MIPS]
* Flash    : TOSHIBA TC58FVM6T2AFT65 [8MB]
* RAM      : INFINEON HYB39S256160DTL-7 [x2, 64MB total]
* Switch   : BROADCOM BCM5325MA2KQM
* WAN      : BROADCOM BCM5221A4KPT
* OPT      : BROADCOM BCM5221A4KPT
* Console  : TEXAS INSTRUMENTS MAX3243C

Images
Console Cable Pinout
Hi-Res PCB Photo
Hi-Res PCB Photo w/Labels
Hi-Res PCB Photo w/Testpoints (Yellow Boxes)

Testpoints
Judging from labels on the PCB itself, I have documented the PCB testpoints as follows:
Code:
TP1 > VCC
TP2 > TST_CLK
TP3 > 3V3
TP4 > 1V8
TP5 > GND
TP6 > GND

Can't seem to find a TX or RX, but then again I'm not terribly familiar with serial communications either. Maybe I missed something?

Firmware Offsets
Code:
0x0000 > Section 1         [128 bytes]
  * [49 AF 08 12 30 2C 02 14] "Magic" header, 8 bytes. Found in all firmware images for TZ170
                               and one image for TZ-150.

0x0080 > Section 2         [640 bytes]

0x0300 > Section 3         [128 bytes]
  * 0x0300 - Always "SonicOS Standard" from what I can tell
  * 0x0320 - Firmware revision number, displayed verbatim in web interface
  * 0x0340 - Compiling machine name (?)
  * 0x0380 - Compiling user name (pseudo-confirmed)

0x03c0 > Section 4 [data]  [ to  EOF ]

Mystery Filesystem
I could almost write an entirely different post for all the time that I spent decoding this. Having very little prior experience with filesystems, it was definitely a learning adventure to say the least. I haven't been able to figure out how the device decides where this filesystem begins and where it ends, but I am 100% certain that I've decoded the FAT table for whatever filesystem this is. It's worth noting that when you do, however, find the beginning of the FAT table, from that address to the end of the firmware image is the entirety of the filesystem (checked and confirmed by myself on multiple firmware versions).

A FAT entry for this system looks as follows:
Code:
00 00 3E C6 00 00 25 68 00 00 86 7A 0D 65 76 65 6E 74 6C 69 73 74 2E 74 78 74 00
.  .  >  Æ  .  .  %  h  .  .  †  z  .  e  v  e  n  t  l  i  s  t  .  t  x  t  .

0x0000 - 0x0003 <> Location of file, offset from head of filesystem
0x0004 - 0x0007 <> Size of file in filesystem
0x0008 - 0x000B <> Size of file extracted and uncompressed/decrypted
         0x000C <> Length of filename text
0x000D - to length <> filename + null character

The head of the filesystem is calculated by finding the first entry in the FAT, and subtracting 4 bytes. The 4 bytes before the first entry indicate how many files are stored in the system. For instance, for firmware version 3.1.0.15, there are 511 files contained in the image (encrypted of course). If you do a hex search for 0x01ffh you will find two entries. The first is in the header, the second is about halfway to the end of the file. The second one is what we're looking at. From there, we know that immediately following this WORD value is the first entry in the FAT for "eventlist.txt". The end of the filesystem can be calculated using the first FAT entry. For the "footer" of this filesystem, there are 8 bytes (two WORD values), right before the offset indicated by the first FAT entry. I have as of right now been unable to figure out what these values are in relation to everything else. They're not a static signature as they vary slightly between firmware versions. However, from what I can tell the first 3 bytes are always [08h 78h 9Ch] (unconfirmed). Hope I haven't forgotten anything!

Firmware File Names/Versions
Code:
  * sw_tz170_s_eng_3.0.0.4.sig  - Version 3.0.0.4  - [ MD5: d3f1c4a1db420ce05cec01a4b822baae ]
  * sw_tz170_s_eng_3.1.0.15.sig - Version 3.1.0.15 - [ MD5: 25f33a66b98e530766b875b76b382370 ]
  * sw_tz170_s_eng_3.1.0.2.sig  - Version 3.1.0.2  - [ MD5: a2a66ddc1921cff321c16202d3c704dd ]

Miscellaneous Points of Note
* The system OS is DEFINITELY VxWorks based...probably.
* As of right now I can not get the TZ-170 to take any modified firmware image. This consisted of editing the "username" field in the header, to which the SonicWall cried out as it was not a "signed" firmware image.
* I have just ordered an RS-232 TTL converter, and as soon as that gets here I will be poking around on the board looking for a secondary UART port. There are some nice pin groupings on the PCB that I can't wait to probe!
* Figuring that I won't have any luck with the TTL converter, I will be trying to find the JTAG pinout of the processor, and hopefully I can dump something interesting/useful. Maybe I'll be able to sign those images! I'll be doing this with an Arduino, because I feel this affords me more flexibility when probing for pins. Plus, you know, Arduino!
* This took me an hour and a half to organize and write, but probably just a few minutes for you to read! :]

Requests/How You Can Help
My eventual goal is to port OpenWRT to this appliance, and hopefully this whole series of appliances! But as of right now I have hit a dead end. So if you have any ideas, experience, or hardware you'd like to contribute to this cause, please feel free to post/message me! Particularly, if you can shed any light onto how these images are encrypted/signed, I would be forever grateful. Also, you're wondering how you're supposed to obtain the firmware images listed above. There is a reason I have included the filename + the MD5 checksum. I'm not entirely sure, however, if Googling these files will return any results. If you would like me to send these images to you for reversing purposes, just message me. I have a nice little 7z archive will all three versions mentioned above sitting on my desktop. Lastly, thank you for taking the time to read this!

Revision Information
Code:
  * 07/07/2011 - Rev 02 - Added console cable pinout picture
  * 07/07/2011 - Rev 01 - Added testpoint image + text mapping
  * 07/06/2011 - Rev 00 - Initial writeup


Last edited by shadoxx on Fri Jul 08, 2011 3:24; edited 1 time in total
Sponsor
Dark_Shadow
DD-WRT Guru


Joined: 31 Aug 2009
Posts: 2448
Location: Third Rock from the Sun

PostPosted: Fri Jul 08, 2011 2:41    Post subject: Reply with quote
Just as reference, I have added a page for this device on my Wiki.

http://infodepot.wikia.com/wiki/Sonicwall_TZ-170

_________________
Peacock Thread-FAQ -- dd-wrt Wiki

Testing Multiple Routers -- Bootloader Collection Project -- My Wiki
graeme
DD-WRT Novice


Joined: 29 Jul 2011
Posts: 4

PostPosted: Fri Jul 29, 2011 10:45    Post subject: SonicOS Reply with quote
The sonicwall tz 180 and sonicwall pro 4100 I have both have firmware similar to the format you have posted. The data section starting at 0x3c0 has zlib stream magic bytes 0x789c and can be extracted from the firmware using the python script from here: http://blog.2of1.org/2011/03/03/decompressing-zlib-images/

The python code is:
Code:

#!/usr/bin/python
 
import zlib
import argparse
 
parser = argparse.ArgumentParser()
parser.add_argument('file', type=argparse.FileType('rb'))
parser.add_argument('offset', type=int, default=0)
args = parser.parse_args()
 
magic_list = [
               "\x08\x3c", "\x08\x7a", "\x08\xb8", "\x08\xf6",
               "\x18\x38", "\x18\x76", "\x18\xb4", "\x18\x72",
               "\x28\x34", "\x28\x72", "\x28\xb0", "\x28\xee",
               "\x38\x30", "\x38\x6e", "\x38\xac", "\x38\xea",
               "\x48\x2c", "\x48\x6a", "\x48\xa8", "\x48\xe6",
               "\x58\x28", "\x58\x66", "\x58\xa4", "\x58\xe2",
               "\x68\x24", "\x68\x62", "\x68\xbf", "\x68\xfd",
               "\x78\x01", "\x78\x5e", "\x78\x9c", "\x78\xda"
             ]
 
c_data = args.file.read()
 
done = 0
 
try:
  print zlib.decompress(c_data[args.offset:])
except:
  for m in reversed(magic_list):
    try:
      seek_offset = args.offset
 
      while 1:
        seek_offset += c_data[seek_offset:].index(m)
 
        if seek_offset >= 0:
          try:
            print zlib.decompress(c_data[seek_offset:])
            done = 1
            break
          except:
            seek_offset += 1
 
    except:
      pass
 
    if done:
      break
 
args.file.close()


called specifying the decimal offset of 969 (0x3c9).

This results in a vxWorks OS image which can be loaded in IDA.

So I think to load unsigned firmware (ie DD-WRT or modified SonicOS) the following will need to be true:
- boot loader checks the signature
- boot loader is in the firmware image (so it can be updated)
- boot loader is not itself signed (unlikely)
This would mean the boot loader could be patched to allow unsigned firmware.

There will most likely be other integrity checksum values in the header but they can be fixed up once the image has been disassembled in IDA and functionality reversed. This is how I have seen other compressed and signed firmware work - specifically Juniper ScreenOS.
shadoxx
DD-WRT Novice


Joined: 28 Aug 2008
Posts: 3

PostPosted: Tue Aug 02, 2011 2:25    Post subject: Reply with quote
This is so stupidly simple that I'm actually rather embarrassed that I didn't check this first. A case of me relying on the tools that I was using rather than common sense.

Do you happen to have the entry point that I can plug into IDA; also the proper MIPS architecture (I can't seem to figure it out). Much appreciated! Every day is one step closer!
graeme
DD-WRT Novice


Joined: 29 Jul 2011
Posts: 4

PostPosted: Tue Aug 09, 2011 9:05    Post subject: Reply with quote
I have been working on the 4100 which is x86 but I will have some time next week to take a look at the TZ180 which is MIPS to see if I can determine the loading address.

I'll keep you posted.
pfuender
DD-WRT Novice


Joined: 29 Aug 2011
Posts: 3

PostPosted: Mon Aug 29, 2011 10:01    Post subject: Reply with quote
That looks like a lot of fun! I've also been looking at the TZ180's in the past, but now that I have some soulmates, I think I'll have to invest some time again. Wink
It is very likely that the TZ180 is VxWorks based, since the TZ210 mentions also during the bootup 'Target Name: vxTarget', so yes, very very likely.
graeme
DD-WRT Novice


Joined: 29 Jul 2011
Posts: 4

PostPosted: Tue Aug 30, 2011 11:10    Post subject: Reply with quote
Seems the Sonicwall TZ180 uses a Nitrox Soho 220 MIPS 32 4K processor. This is a bi-endian processor (can be set to big or little endian).

But I am also struggling to find the entry point.

With the Sonicwall 4100 I can view the boot process and it states the loading address:

SonicROM Booting..........
Initializing FLASH
Loading Firmware
Uncompressing Firmware
Starting Firmware at 0x408000

SonicOS Bootining

The loading address can be found in the header of the 4100 firmware but when I look at the header of the TZ180 firmware this equivalent location does not see to make sense as a loading address:


4100 (Intel ELF executable format firmware)

07010000 500E6200 402C0900 CCA46C00 E0000700 00804000 -> loading address


TZ180 (MIPS unknown format)

3C081000 40886000 00000000 40806800 00000000 40088000 -> ????


Also I have been unable to get the console working on the TZ180 (working fine on the 4100). If anyone has a boot log from a TZ180 I would like to see it - or if anyone can tell me the serial settings / cable requirements for the TZ180 console that would be appreciated.
pfuender
DD-WRT Novice


Joined: 29 Aug 2011
Posts: 3

PostPosted: Tue Aug 30, 2011 11:33    Post subject: Reply with quote
graeme wrote:

Also I have been unable to get the console working on the TZ180 (working fine on the 4100). If anyone has a boot log from a TZ180 I would like to see it - or if anyone can tell me the serial settings / cable requirements for the TZ180 console that would be appreciated.

Well I've got a working console, but afaik the 4100 uses a real serial connector, whereas the TZ180 uses a RJ45 plug. Cisco console cables apparently don't work.. if you're interested, I can let you know which pin connects where..

anyway, here's the Part of the bootlog:
Quote:
SonicROM Booting..........
Initializing FLASH
Loading Firmware
Uncompressing Firmware
Starting
SonicOS Booting..........
Starting SonicSetup Watchdog
Initializing Buffer Zones


As you can see, there are no addresses mentioned in the bootlog Sad
graeme
DD-WRT Novice


Joined: 29 Jul 2011
Posts: 4

PostPosted: Tue Aug 30, 2011 23:56    Post subject: Reply with quote
Yes 4100 is proper serial and I have been trying a cisco rj45 - serial cable on the TZ 180....

Can you let me know the pin connects? That would be great as I do want to be able to see console messages.  Thanks!
penguintiz
DD-WRT Novice


Joined: 30 Apr 2012
Posts: 2

PostPosted: Mon Apr 30, 2012 23:51    Post subject: Sonicwall TZ 170 working? Reply with quote
Hi,
I read this thread with great interest.
I have 2 TZ 170's connected to each other with a VPN.
Do you have DD-WRT working on the TZ 170? We are thinking about replacing them but a full DD-WRT install would give us the benefit of more flexibility and newer firmware. Many features of sonicwall are pay for add ons (like client to site VPN). This option could extend the life of a device which is in perfect working order
Is DD-WRT an option?

Thanks

Dave
pfuender
DD-WRT Novice


Joined: 29 Aug 2011
Posts: 3

PostPosted: Tue May 01, 2012 9:31    Post subject: Reply with quote
Hi Dave,

Apparently there's no port yet for the TZ170's afaik..
Feel free to give us a hand to port it over Wink


Cheers
penguintiz
DD-WRT Novice


Joined: 30 Apr 2012
Posts: 2

PostPosted: Thu May 03, 2012 2:14    Post subject: Reply with quote
If I had the knowledge, I'd be happy to. Unfortunately, I have no programming background.
wayne716
DD-WRT Novice


Joined: 22 Jun 2012
Posts: 2

PostPosted: Fri Jun 22, 2012 20:23    Post subject: Sonicwall TZ170 G4 Enhanced Reply with quote
Hi, I have been following this thread for some time before registering and now joining in as a novice in the truest sense of the word.

I have a Sonicwall Gen 4 TZ-170 Enhanced and I agree with the previous posts on this thread. I am of the oppinion that the boot loader is part of the .sig image and on the tz170e the boot entry point is 0x80010000 and it is a VxWorks based embedded OS so what I have found echos shadoxx's findings. I am willing to help but will need help getting up to speed.
wayne716
DD-WRT Novice


Joined: 22 Jun 2012
Posts: 2

PostPosted: Fri Jun 22, 2012 21:04    Post subject: The CLI "Firmware" command Reply with quote
Does anyone have anything on the "firmware" command in the CLI on the TZ170? Maybe I am being too hopeful but I don't find anything on it.
shadoxx
DD-WRT Novice


Joined: 28 Aug 2008
Posts: 3

PostPosted: Fri Feb 05, 2016 23:11    Post subject: Reply with quote
Kind of picking back up on this. Reversing some TP-Link hardware and came across the following article:

http://www.nulltrace.org/2013/04/mips-bootstrapping.html

The section below might aid us in finding where the firmware gets loaded. When I get the hardware back in my possession I'll do a bit more probing:
Quote:
When power is applied to a processor and it comes out of reset, it fetches its first instruction from an address that is hardwired. This address is known as the "Boot Vector" or the "Reset Vector". The MIPS processors' boot vector is located at physical address 0x1FC00000. The MIPS processors have MMU enabled as soon as they are powered on. The MIPS core thus presents a virtual address of 0xBFC00000. The MMU translates this address to physical address of 0x1FC00000, the boot vector. This translation again is hardwired. Typically, a boot device is present at this address and responds to the read request of the processor2.
Display posts from previous:    Page 1 of 1
Post new topic   Reply to topic    DD-WRT Forum Index -> Hardware DIY / Hardware Mods 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 cannot attach files in this forum
You cannot download files in this forum