News:

Registered a URL and setup a forum as the IPCam stuff really needed its own site vs my irregular blog posts about IPCam hacking at http://www.computersolutions.cn/blog

Author Topic: Looks Like Possibly MJPEG Netwave Type Firmware Builder/Extractor?  (Read 13482 times)

  • ***
December 05, 2012, 02:04:40 am
Edit: Since this post was originally posted. Detailed instructions on how to both access the IP Cameras using a serial interface as well as modify the IP Cameras WebUI using Windows based systems, have been created here:

http://www.openipcam.com/forum/index.php/topic,473.msg2577.html#msg2577

Maybe someone with more knowledge of Netwave MJPEG IP camera firmware here, can tell me what this can do and how it works?

The documentation is in Chinese, of course.

At face value it looks like it might be able to allow you to add your own .html files in the Web UI and maybe even more?

Also, It seems to allow building .bin files to upload but there are two .exe files and I am not sure what both of them can or cannot do. One is documented more than the other.

Because it contains Chinese characters, I can't unzip it using normal methods in Windows. But interestingly, I can click on the .zip file and access the files.

Hopefully someone here, can give me, more insight on all this can do.

It was too big to attach here, so here it is.

File: http://www.saveontelephonebills.com/camera/TOOLS.zip

Thanks.

Don
« Last Edit: January 09, 2013, 12:54:15 pm by TheUberOverLord »

  • No avatar
  • *****
December 06, 2012, 03:28:44 am
This are two windows (gui) tools that allow you to
a) pack a directory with the webui-structure to a the webui binary image  (makeupgaw2.exe)
b) append a romfs file with the webui to [wild guess] be able to flash romfs+webui in one go (editrom2.exe). But this would leave a too big partition size entry ...

I think with fostar you have a much more elaborate tool that can also unpack a webui file and (un)pack a firmware file from/to romfs and kernel
« Last Edit: December 06, 2012, 03:38:43 am by schufti »

  • ***
December 06, 2012, 10:47:47 am
This are two windows (gui) tools that allow you to
a) pack a directory with the webui-structure to a the webui binary image  (makeupgaw2.exe)
b) append a romfs file with the webui to [wild guess] be able to flash romfs+webui in one go (editrom2.exe). But this would leave a too big partition size entry ...

I think with fostar you have a much more elaborate tool that can also unpack a webui file and (un)pack a firmware file from/to romfs and kernel

Thanks.

Do you think it's possible to use the first tool, without the need to use the second tool to add 1 additional .htm file to the webui, leaving the other .htm webui files as is? By simply uploading the produced .bin file from the first tool, using the standard cameras interface to upload that .bin file that only contains 1 .htm file?

I am not clear on if you create a .bin file for upload to the camera, containing one .htm file which was produced by the first tool only. If it would remove/overlay the entire webui directory and the files that were in that webui directory and then simply leave the 1 .htm file in the webui directory or if it would simply add the 1 .htm file to the webui directory when the .bin file that only includes 1 .htm file for the webui directory is uploaded.

Additionally, what if the .htm file name was the same name as a file already in the webui directory? Would that file be replaced with the new .htm file leaving the other .htm files as is, in the webui directory?

My goal is to be able to add .htm files by using the first tool only, using the standard camera interface that comes with the camera to do the upload of this other .bin to any firmware version for the camera. Which would of course need to be done again after any normal firmware upgrade vs. making an entire special version of the webui firmware .bin file on a per firmware version basis that would require the entire webui directory and files in it, each time.

If this works. It would allow a person to remove my custom .htm files by simply re-installing the firmware version they had, when if needed. Going back to the default firmware version.

I am trying to avoid bricking a camera by simply trying it, before asking you other more knowledgeable and seasoned people who might know the answer and save me some grief. I don't currently have a USB interface setup on any camera to use any recovery methods yet. Working on that.

Don
« Last Edit: December 06, 2012, 11:22:27 am by TheUberOverLord »

  • No avatar
  • *****
December 06, 2012, 02:40:57 pm
no, you cannot add/modify single file via any means. You can only upload a full image containing the whole webui. You have to extract the existing webui to some working directory, make your changes, build the new webui image and upload it via the webui, the webcam tool, the method described here or via the bootloader.

  • ***
December 07, 2012, 11:44:34 am
no, you cannot add/modify single file via any means. You can only upload a full image containing the whole webui. You have to extract the existing webui to some working directory, make your changes, build the new webui image and upload it via the webui, the webcam tool, the method described here or via the bootloader.

Thanks again.

Any suggestions on maximum size to be aware of. It's a total 4M maximum limit, with this specific camera, including System and Web UI firmware, I think? Just don't know any way how to calculate maximum size limits, that I should be aware of when adding things to the Web UI firmware portion and/or how the size of the system firmware could impact the maximum size limit of the Web UI firmware.

Are there any easy methods to determine what memory a camera has as a maximum, so that maybe some cameras that are 2M vs. 4M memory would not try/allow to do this or that in that .bat file that the .bat file could use as a reference check, if doing so, would exceed a size?

Also, is it possible to use any native methods, that the camera OS already supports, as is, to write to a text file from JavaScript from one of the HTML files in the Web UI, so that the data will be retained by the camera after startup/reboot? If so, could that empty text file be stored in the Web UI firmware upload or would it require changes to the system firmware upload?

I am trying to wrap my head around the concept of the system firmware being broken down into 2 sections. Linux.zip and romfs.img files. Is one the Linux OS and the other the camera files, like camera runtime binaries, camera data files and cgi files and the like?

My first end goals, are to create additional features that can be appended to the Web UI software by people using a .bat file on Windows, with their current Web UI Firmware and having that .bat file copy files to a directory of where their current Web UI files have been extracted, then creating a new Web UI firmware version. Using as many automated methods as possible to do this. I will then try to support other Operating Systems as well, using whatever methods are required to do same.

Done right. It might even allow people to use the camera as a host for a mini web site server, without the need to use a web hosting service. if that mini web site was small and had text files which could be updated via the appended interface to make changes. Of course, it could not be all that fancy. But it might be enough for some. Of course. There would be no dot.com access. But people could use their ISP IP Address or DDNS interface for the camera, for this.

One example of many: I have seen people post in forums, that they want others to see their pets using their camera. Some don't have a formal web site or blog to host their camera as a web page for others. Many also don't want people to have the need or burden to use the standard camera interface that requires a logon, for others to see their camera.

It should be noted, that even when people do allow others to use the standard camera interface to login in order to see and/or access their cameras, that the Netwave based cameras, have a 4 formally logged in maximum limit at a time. Once 4 people are formally logged into the camera, all other formal logon requests will be denied or simply not responded to, by the camera. Including login requests by the camera owner. This is not the case with my Interface, because it does not formally login. It has no maximum limit. Of course the camera has a harder time to deal with many requests at the same time, but that would be the case using other methods as well.

I have done some testing already, adding my MJPEG Interface to the cameras Web UI, which also can be configured for auto-logon, if desired. Now these people can use the camera to host and feed that web page vs. using a web hosting service or formal website or blog, to do the same. They can also of course change the web page presented by the Interface using any graphics and format they desire by including anything like additional graphics in the new Web UI firmware version, if needed.

Here is a live demo, demonstrating this concept, using a camera with my MJPEG Interface now embedded in this cameras Web UI Firmware, where the camera is now providing and hosting this function, without the need to have a web site or blog or require a logon to the camera, to do so. You can try the link below using any Internet browser capable device, running on any Operating System, using any browser. From computers, tablets, phones and even some newer TVs that are full browser capable. It will work in all cases.

http://cam18372.topipcam.org:90/NewWorkingDemoOperator.htm

One nice feature about the above example is. While the above example is currently setup to auto-logon to the camera as an Operator User Level Id. If the password for the User Id being used in the above example, was changed in the camera. Then the above example would prompt for logon and not continue to use auto-logon, as it is now. Allowing you to use the above example as any User Level Id, if you knew the logon and password for that User Id.

This is a way to disable the above example instantly from using auto-logon, at anytime, as well as then being able to then use the above for Admin or Visitor functions and features based upon the User Level Id you then use when prompted to login. Since the Interface presents a different UI ("User Interface") based on the User Level of the User Id, logged in. The above example, now has an instant multi-purpose use.

Another thing you can do without the need to change anything in the Web UI firmware, once this Interface is embedded in the firmware, is to leave the password for the User Id as is, so that it continues to auto-logon, but change the User Id being used in the example, to a different User Level, in the camera.

You can see the different UI ("User Interface") presentations that are seen based on User Level of the User Id logged into the Interface, from left to right: Visitor, Operator and Admin here:

http://www.saveontelephonebills.com/camera/NewMulitDemoColum.htm

The Interface also support via configuration options, disabling any normal Operator controls you do not wish presented to Operator User Level Ids to any combination of controls you wish to allow.

Note: The timeout and zoom text and the click to get a copy link, in these demonstrations is not in the download of the Interface when you download your own copy. It's my attempt to limit usage of the demonstrations and to help people get a copy of the Interface, if they choose, after seeing the demonstrations.

Adding my MJPEG Interface, which is free by the way, to the camera Web UI added an additional 49KB ("It's a big HTML file, it has many configuration options") so the Web UI firmware size, in my case, for this camera, went from 901KB to 950KB.

The Interface does not grow or shrink in size to deal with the different User Level UI presentations, so 49KB is as small or big as it gets. You could also add different copies of the Interface, each having their own unique configuration options, each having their own unique HTML names, maybe some or one secret as well as some public, to your new Web UI firmware version.

I avoided, in the past using any fancy graphics in the Interface, because these cameras have so many different image file names, that it would not have been possible to assume that any specific image file was present in every Netwave based cameras Web UI firmware. This now is not an issue, since those graphics could now be included, in any newly created, firmware Web UI version. The only other option before, was to host any graphics on a web server for the Interface, for everyone who used it.

Since there are so many different flavors of the current Web UI for the Netwave type MJPEG cameras, using this Interface wont step on any of the other functions the person has, including their GUI presentation for their specific camera, but will allow extra common missing features, such as enabling sound detection, forbidden and FTP now schedules, just as some examples. These types of features, while supported by the cameras, generally are not accessible via the standard camera interfaces, that come with these cameras.

It should be noted that the above Interface used in the live demo, can do these things, listed above, as well as access your other cameras from the multi-device list from any browser, not just IE based browsers, when using it as an Admin Level User Id, so you would simply disable auto-logon in the configuration options and then the same link would prompt for logon when it was embedded in the cameras Web UI. Using a Visitor User Level Id, with the Interface and auto-logon would simply display your camera output, with no PTZ ("Pan/Tilt/Zoom") controls, without the need to logon as well.

Camera owners hopefully can see by this example, how easy this is to do, without a web hosting service and/or formal web sites or blogs and instead, use their cameras as their host and then simply use social media sites or send Email with links or post links, directly to the camera using their ISP IP Address or DDNS. Thanks to all the hard work everyone has put into exploring and creating the tools to access the cameras firmware.

The possibilities are endless really. It would also be extremely easy to have the camera host the ability to privately with prompting for logon or publicly using the auto-logon configuration feature to view multiple cameras as well. While I have yet to add a live demo in the camera Web UI for that. You can get an idea of how easy that would be by viewing this crude example as well, which is currently using 1 camera to represent 4 cameras ("Which could be any number of cameras") configured at 1 FPS ("Frame Per Second") which makes using the camera controls there, somewhat choppy and resolutions of 160*120. Which both, also can be configured in the Interface to be the values of your choice.

http://www.saveontelephonebills.com/camera/EmbedWebPageExample.htm

If needed by others. I can post step-by-step instructions of what I did using a Windows based system, to add my MJPEG Interface to the cameras Web UI firmware file. No changes of any kind were required to the Interface itself, besides simply setting whatever configuration options you wish. It was simply dropping the Interface HTML file in the extracted Web UI folder ("Create the Folder first so that win_fostarn can place the extracted files there") where the files, that were created by win_fostarn reside. Then again, using win_fostarn, to build a new Web UI firmware file and version and then uploading that new Web UI firmware file to the camera.

Again, thanks for your time on this. Also thanks for win_fostarn as well. Also thanks to everyone for all their hard work to be able to do all these things. Without all of that, none of this would be possible.

Don
« Last Edit: December 11, 2012, 12:09:30 pm by TheUberOverLord »

  • No avatar
  • *****
December 07, 2012, 06:43:48 pm
the linux.zip is only the OS-Kernel providing the basic OS funtions like open/close/read/write to a file, access a device via standard unix interface (/dev/...), schedule tasks, manage memory etc.

the romfs contains the "userland" binaries (OS-tools) like the shell (providing commands like ls, cp, mv,...) and finally the camera binary containing the webserver and the cgi interface.

unfortunately the whole system is based on a read only filesystem and the settings are directly written to the flash via the camera binary (that is closed source btw).

for 2MB devices the webui starts at 0x7F180000 and ends at 0x7F1EFFFF (447kB)
for 4MB devices the webui starts at 0x7F200000 and ends at 0x7F3fffff (2048kB)

  • ***
December 11, 2012, 11:47:26 am
the linux.zip is only the OS-Kernel providing the basic OS funtions like open/close/read/write to a file, access a device via standard unix interface (/dev/...), schedule tasks, manage memory etc.

the romfs contains the "userland" binaries (OS-tools) like the shell (providing commands like ls, cp, mv,...) and finally the camera binary containing the webserver and the cgi interface.

unfortunately the whole system is based on a read only filesystem and the settings are directly written to the flash via the camera binary (that is closed source btw).

for 2MB devices the webui starts at 0x7F180000 and ends at 0x7F1EFFFF (447kB)
for 4MB devices the webui starts at 0x7F200000 and ends at 0x7F3fffff (2048kB)

Thanks so much again.

I know that many of you, have interfaced to these cameras using a USB interface.

Has anyone installed Telnet or FTP in these cameras yet? I know it has been done with the H.264 cameras.

Also, would it make any common sense or even be possible to be able to use that same USB interface to allow a SD Memory card to be attached so that, as one example, alarm video could be recorded to it, much like the newer H.264 cameras support today.

Not sure how much extra space would be required in the firmware to support a feature like that and mount a SD memory card?

Example: If you had Telnet installed, in the camera, you would then be able to use the USB Interface as a "Goodies" container, for tools you created for the camera, that you could use from time to time.

I would assume one could then keep additional files on that SD card, so that one could enhance these camera by not worrying about options you might want the camera to support like FTP, Telnet and other things that may or may not fit in the formal camera firmware and be able to store those things on the SD card, and execute/launch those things from the SD card, when/if needed?

I do understand anything launched would still require memory in the camera to run.

Don
« Last Edit: December 11, 2012, 11:59:56 am by TheUberOverLord »

  • No avatar
  • *****
December 12, 2012, 05:19:26 am
hi,
yes, AFAICR there have been some experiments with integrating telnet and/or ftp in the romfs.

Unfortunately almost every single "feature" of the firmware is part of the ominous closed source camera binary. I'm not even sure if there are any massstorage drivers included in the kernel.

and yes, every started program consumes part of the scarce RAM in the cam (usually more than it's filesize).

  • No avatar
  • *****
December 28, 2012, 08:48:38 am
The h.264 camera's are ARM9 based, have much larger flash (16M typically), faster cpu etc., so are more suited for other things.

The arm7 based ones (eg the ones that look like the logo in the top left), have 2-4M flash, and limited cpu.
They're good for what they are though, especially for the price.

The kernel in the ARM7 ones typically includes MTD drivers, you can take a look at some of my forum posts on recompiling the kernel under 2.4 for what can be included. 

You have some GPIO available, i2c, and USB (if you decide to lose wifi), so some smaller stuff can be done.
Its tight, but you can do interesting things with them.





  • No avatar
  • *****
December 28, 2012, 08:52:36 am
Oh, and nice find on the packing tools.

I've often wondered what the factory people use in-house.

  • ***
January 09, 2013, 12:55:10 pm
Thanks.

Don