Netgem N8000 Firmware

The N8000 Series Netbox is delivered complete with Netgem's award winning embedded IPTV middleware software - NetgemTV. The STB comprises a double tuner, hard disk drive, UPnP Media Center and a Home Network connectivity, such as wireless 802.11n. With 25 years of successful innovation in Home technology and TV Streaming services, we are a Service Provider of connectivity and TV Content services for the 21st century Ultrafast Broadband homes. We focus our energy on always providing the best experience to consumers, offering via our Operators partners the most simple personalised.

  1. Netgem N8000 Firmware Downloads
  2. Netgem N8000 Firmware Updates
  3. Netgem N8000 Firmware Download
  4. Netgem N8000 Firmware Update
I record movies on TV, demux them (and cut out the commercials) through ProjectX - retaining the subtitles (utf-8), and then create mkv files through mkvmerge gui (most of the time). The problem comes when the audio is a 192 kbps file - the playback device I use makes the audio unpleasant - the sound kind of pulses instead of playing smoothly. I always select no compression on each track, but the end file always comes out smaller than the sum on the sizes of the original combined tracks. I do not know if the compression (?) is part of the problem or not, but I don't seem to be able to do anything to effect it.
It may be worth noting that if I take the exact same audio and video file and put them in a mpg (2) container, I can play it on the same playback device and everything sounds fine.
I think I would be happy to use Handbrake (if that's better). The audio seems to come out fine, however, the subtitles always come at as ASS, which my player doesn't seem to understand. I import the srt files into Handbrake, but I can't figure out a way to make them retain that format.
I'm sure there is much in this post that conveys my ignorance about video, but if anyone is willing to help, I'd greatly appreciate it.
Netgem n8000 firmware updatesI needed to detail what I found out about the upgrade.bin file and how. If you want to know the format, just jump to the end of this post. I'm going to detail how I figured out the format.
For hacking this, HxD is one of the best programs in the world. And free, too!!
I set it to view 16 bytes at a time, both ascii and hex. Programmers like alignment on powers of two, and this is a very common one.
Right away, I see filenames near the beginning. And appearing in a fixed pattern too. The pattern repeats itself every 0x40 (64) bytes. It appears to start at 0x20, so there's some sort of header we'll have to decipher before that. But lets finish with the file structure.
Obviously the filename starts at offset 0x8 in that file structure. All of them are 24 bytes or less, and everything else is zeroes. So that remainder could be reserved for longer filename, but we don't know that for sure. The first part would have to identify where in the upgrade.bin it is, and how long it is. So looking at the easiest one: ChangeNote.txt. This is the easiest because it is searchable text. So we look through the file and find the text at the end of the file. Going back from the end, we find that the text likely starts at position 0x024a2ff8 in the file. Looking at the bytes before the filename we have f8 2f 4a 02 f9 08 00 00. At this point, it's pretty obvious to me. That's a simple lo-byte/hi-byte storage of the position first as a dword (32 bit), and if we apply that same thing to the second dword it's 0x000008f9, or 2297 bytes. That appears to be the length of the file.
So now to look at the header bytes. Based on the format of the file size and location, let's look at this as a group of dwords.
There a dword for 8. There's 8 files. Probably the number of files.
Nothing else seems familiar.
Looking at the differences in hex between the R1 and R1.1 upgrade.bin files, I see a change in offset 0x08-0x0b and another one at 0x10. Nothing else in that header changes. So those could easily be two different checksums. So I use HxD to highlight from 0x220 to the end of the file and calculate the checksums. Nothing matches. Hmmm. The checksum might include the file names and sizes. So I highlight from 0x20 to the end of the file and select to calculate the checksums. Checksum-32 FB4B0c59, it's a match with the 3rd dword! Doublecheck with R1.1 and it's a match! Ok, that solves part of the problem. Now, what about this one byte change at 0x10...

Netgem N8000 Firmware Downloads

I change it in HxD and start DataInstaller.... The firmware package version number changed. So there we have it! Appears to be one word long that represents the number to the right of the decimal. Playing with the word at 0x0c, that appears to change the version to the left of the decimal.
Change the first dword and try to run. It says 'Upgrade.bin not firmware update package, please check it then try again!' Ok, so this is a magic number for identifying the file. Tried it with the second dword. Same thing. Tried it with the other unknowns dwords. No change. Hmmm, well that's all I can research for now. So this is the structure as I've decoded it so far. I've written a small C program to extract out the individual files.

Netgem N8000 Firmware Updates


struct Header {
dword magic1 = 0x075bcd15
dword magic2 = 0x00002710
dword checksum
dword majorversion
dword minorversion
dword unknown1 = 0x00080001
dword unknown2 = 0x00000003
dword NumberOfFiles
}

Netgem N8000 Firmware Download


struct FileList[8]

Netgem N8000 Firmware Update


{
dword offset
dword FileSize
char FileName[24]
char Unknown[32] // this may be part of the filename, but none of the upgrades use it yet so it's not guaranteed.
}
Checksum is calculated by adding all of the bytes together, tracking up to 32 bits (ignoring overflow).N8000
Super has indicated in the comments of 'fun with player' that inside the upgrade.bin file is a tarball of the first partition. This is actually embedded in the 'install.img' file that comes out of the upgrade.bin. You can find the start of the tarball by looking for it's magic number 'BZh9' which is at position 0x0854216 of the upgrade.bin file for R1 firmware, or 0x0674cc6 in the install.img file.
Here's the source code & executable for extracting out the 8 files in the upgrade.bin file. http://www.box.net/shared/3dn0szidjs
Whatever directory your current directory is when you run the executable is where the extracted files will end up. You specify the location of the upgrade.bin file on the command line.
For example:
split c:upgrade.bin
Edit: Something else I figured I'd mention. When you run the firmware installer, it extracts those 8 files to c:documents and settingsyourloginLocal SettingsTempDATA and so there is another easy way to get that. When it's done or you click cancel, it automatically delete those files.