How to change BT Videophone1000 setting to work on my own PBX ?

[Chayd]

Hi Simon,

Not had much chance lately but I've not forgotten. Have made some PCBs to solder the chips onto and an adaptor board that will fit into a smartmedia reader to attempt to get data off these. I've been doing a bit of moonlighting so not much free time until recently. Going to try and see if the smartmedia readers work this evening. Also will have to see if I can find a way to repack all those files so that config files can be modified and then reloaded onto a phone.

Hope to have more for you later.

Chay

Hi,
I've read this thread with interest and you seem to have come a long way.
My requirement is rather simple though - to get the Videophone to work with BT Broadband Talk!
I'm familiar with this service and have set my Nokia VOIP client up to use it. I know it's not cheap but it's handy when your abroad to be able to Wifi VOIP call at a local rate to your house phone.
The problem I have with the Video Phone 1000 is that it simply can't make calls via this BT service, it seems that it can recieve them though. Has anyone else had this problem?
I called BT and the Indian chap said that there is an issue with the firmware and that no further firmware releases will be made. He said to get a refund on the phone or swap it to a video phone 2000! Can anyone help?

[Hiddenvision]

As the update firmware is no longer at the UPDATE url address I guess the Videophone cannot update itself. I am sure that people are still using the videophone units on BT.

I wonder if it is possible to spoof the DNS for the update site and have the videophone update locally with a copy of the update files on the hard disk or even via the web on another site.
The tools attached to the first couple of pages of this post will be able to point the update process to another location but I do not have an exact copy of the file structure.
There was a version file and a hash file if I remember right.
I have the original 0_5_5_30 Z file but I am sure someone reading will have the complete lot.

HV.

[Hiddenvision]

Hi All,
Just trying to set up a simulated update process,
Does anyone have all the files that were on the original update site.
Things like the Version.txt & dot hash files.
I have the main z file but lost the others.!
not 100% of the folder structure either, did it just use the one folder for all files /?



Hv.

[Nosilla99]

Hi guys

Sorry I have not been a round for a while but great to see the progress made, I am going to have plenty of time on my hands in about two weeks time due to redundancy so will be able to do some work on the firmware.

@Hv

The files all exist in a single directory, see PM.

NOS

[Hiddenvision]

Cheers Nos,
Done that...
Managed to Spoof the site and convinced the Videophone to attempt update.
it got to 60% then I pulled the plug so as not to actually do the update !
Hopefull it will be able to update an older version phone for use on BT.
I can also play around and see how important the hash files and version numbers are

Hv.

[mastermonkey]

Hi guys,

Being able to spoof the server and get the phone to upgrade itself seems like a great step forward. Have you had any further advances?

Can we edit the files that we think control the relevant bits, recompress them and stick them on the spoof server and see what happens or am I missing something?

I've got 2 brand new Videophone 1000s here still in their packaging from ebay (the 2nd time I've purchased these...last time selling the pair for £1 after failing to get them to work on SIP). I'd love to get them going!

Thanks

Simon

[Hiddenvision]

Hi Simon,

I did not go any further with the upgrade as I only have the one unit
and did not want to kill it yet.!

I originally looked at the upgrade process to overcome a problem,
so that the person I sold my original units to, could upgrade them for normal use on BT.

As I have no replacement, or original early version firmware dump to revert too,
I stopped the upgrade before it completed.

I do think that this process would correcty upgrade a VP1000 to the latest firmware.

I also noticed that it did not make any use of the hash files
but they may be checked after the file has completly dowloaded, I stopped at about 90%.

If anyone has confirmation that the update process will ask again if you want to update after the download then I would be happy to go 100% on the download, but if it updates without prompting then I will hold back still.


Spoofing the server was simple,
I simply edited my DNS section on my main hub.
If you cannot edit this or your hub does not support DNS entrys,
then use the DNS tool mentioned in the start of this thread.

I was lucky to still have a 2003 server in the corner so hosting the files was easy too.

I would guess that you can set up the personal web server from MS and then use that as the destination address.

If someone has a VP1000 and needs it up grading to 0_5_5_30.z
then I would be happy to try and assist in you trying !

Once we establish that the update process works this way,
then I guess it can be investigated if the files can be edited.

Hv.

[Hiddenvision]

Hey there Chyad,

Going back to your discovery about the zlib compression.

Do we have something that can recompress the final file to produce a final .z image.
I have written a RePack (and Unpack) pc application for the individual files but not sure how to +zlib+ the final file again.!!

I wanted to then see if I can change the files, repack them and then zlib the final file.
Then spoof the update !
If the update process is dumb then maybe it will take the changed SIP settings

just a thought.

Hv.

[Hiddenvision]

Ok found the zlib tools and can recompress the edited file back to original format.

Now I guess the Hash files are failing, or something else as the download completes
but then remains on the please wait screen:

Software Download Complete
Restarting videophone
Please wait.

It Restarts fine but not upgraded.

Sorry I should add that it does not restart itself,
I have to repower or press the GREEN button.
Pressing RED appears to go back one screen (100% downloaded) and then needs full repower

I even tried with the original files unchanged and it also stopped on the please wait screen.

So maybe not the hash files !

Ahhh...

I was hopeing that it would be simpler !

A few things noticed:
If the software (z) file is not available then the VP1000 will still say 100% download and please wait.
It does the same thing, even if you only have the single version file sitting there with nothing else.



Hv.

[Hiddenvision]

Next step then is to try and disassemble the running apps.
I see that the load files are also compresed.!


I shall ask who knows the format. ?
I shall also start to find out myself.!!

I would be guessing, but hopefully, the hash files are also created by some FREE PD libary.

After all, BT would have wanted to do most of it as cheep as possible without licences and if they used a free compressor then it may follow suit..

Hv.

[Hiddenvision]

OK I have wrapped up the little PC prog todo the following.

1: Uncompress, (original z file) Select z file in file list
2: Unpack, ( to show all files ) ** Select the Decompressed.zu file
3: RePack, ( der --- reverse of above.....) Select the files.txt file deep in the folders
4: ReCompress. (to make the final z file again) select the Packed.zu file
5: Rename the final Compressed.z file to what ever you want.

** sorry the Unpack routien takes up to 20secs on a slow machine.
Badly written code ! no excuse....
Sweet, but hey,, whats the rush anyway..?

Oh also when you start the application it will delete the 3 files created above if they exist.


Made a few changes, still cant get the phone to proceed after the download.
Any thoughts on these hash files ?

if you want the little app then blast me a PM and I shall pass you the link.
if your smart then you should be able to find it yourself.!!!

There is no help ! but with only 4 buttons you should not go wrong.


Current version 1.0.0.2


Hv.

[Hiddenvision]

Fixed the unpacking speed.!
Added more buttons, (still no help !)
Current Version 1.0.0.3

Hv.

[Chayd]

Hey Guys,

OMG! I've missed a ton of progress! I thought the thread had gone quiet, so I went off and spent time on outdoor activities (solar pool heater, growing some exotic plants and road trips). I'm going to have to sit down and catch up now Nice to hear things are trucking again!

Cheers,

Chay

[Chayd]

After looking through the .load files with a hex editor (I think I may have mentioned it earler) these appear to have been compressed with zlib, too, but there's a bootloader/decompression stub at the beginning of the file, so it's hard to know where the actual compressed header and data starts. I've tried using hexcmp (a side-by-side hex dumper that will show you differences between two binary files), but this still hasn't helped that much. I think looking into the actual binaries would be quite time-consuming, and wouldn't really make much sense unless we had an exact hardware layout, and the code for every aspect of the phone's operation, and Texas instruments DSP SDK. In theory we should be able to hardwire our own SIP server addresses into the config files and leave out update server URLs from them which would be much easier.

Cheers,

Chay

[mastermonkey]

Hi guys,

This all sounds very promising now! Hv's app sounds great and I think using that app plus hardwiring in your SIP server address would be a great solution. As you say Chay perhaps reverse engineering the interface is a bridge too far.

You're both working over my head but once you've got something that requires a guinea pig please let me know. I haven't actually unwrapped my two phones yet but I hope they're both old firmware.

Keep up the good work!!

Simon

[Hiddenvision]

Hey all,

Disasembly should not be a problem for me as that is what I do !
mis-spent youth reverse engineering mobile phone firmware.

I just wanted to try and find some 'back doors' and check the update process flow, by analising the loaders.

If we can manage to extract an uncompressed version of those 3 files then I can see if my talents still function.

I shall have a good look at the files again and see if I can spot the zlib file markers.
I may even write the app to take off a byte at a time and attempt to decompress !


I also think that the hash files need to be understood as the phone must check those after the z file is downloaded & before it actually commits to the update.

Anyone know a quick and dirty method to check what files this phone is accessing.
I thought I would have able to check in the 2003 server logs but I have not been able to discover anything.

if we can get to spoof this update process then I think we should be able to edit the required files and be done with all this messing around. All the info is in the config folder.
As mentioned I edited mine but it still fails to ACTUALLY update even with the files as original.
It may be possible that even the original files are being checked with the hash files and who know what they contain. They may even have a check for the actual IP address of BT servers or some other checks to ensure that the update cannot be spoofed.

Or NOT.....


Hv.

[Hiddenvision]

Actually we have two different versions of firmware I think so perhaps a comparrison of the loaders between the versions may give us a clue to the stub lenths. ( Ignore that statement we only have the one I think)

I did a full 1-65535 Port scan, both UDP and TCP, on the phone and only found 1 UDP port open. 5071

Also found some other odd info using a tool called NMAP .

It mentioned sling-box in the report.
I shall do it again soon and paste up the report.

Hv.

[Chayd]

To see what files the phone's looking for, you could use something like tcpdump (linux) or wireshark (linux/win32) in raw mode in your 2003 server so you can look for http GET/PUT headers, they should give you a clue. I would test but right now my phone's got its program flash chip out and soldered to custom made firmware extractor (this being the chip that I was unable to read due to that JTAG reader not supporting flash using the ONFI standard). I really want to get the data off this chip was that would presumably constitute some of the decompressed contents of the .load file(s).

C.

[Hiddenvision]

Just had a quick look at the .comp_load file.

If you chop off the first 0x84 bytes so that the files starts with 789CECBD it appears to decompress.

I tried a few other combinations and got zeros ! so perhaps the 789C is the Zlib header.
I shall have a bigger look later.
Hv.

[Hiddenvision]

Hey Chayd,
Do we have the timing protocol and command set for the chip you are trying to read ?

It would not be hard to wrap something simple into a PIC to do the basic read (I guess).
I have a ton of PIC dev boards so I could rig something with little effort.
The coding may take longer ! but not too much as 'C' is pretty quick to manipulate.



Hv.

[Chayd]

Awesome, nice work!

Just had a uick look at the .comp_load file.

If you chop off the first 0x84 bytes so that the files starts with 789CECBD it appears to decompress.

I tried a few other combinations and got zeros ! so perhaps the 789C is the Zlib header.
I shall have a bigger look later.
Hv.

Originally Posted by Hiddenvision

[Chayd]

Crumbs, its been a while, but IIRC it seems to conform to the ONFI standard, which in turn is used for the old smartmedia cards, I did make an adaptor to connect the chip to an SM card reader but no luck (although it may have been that particular reader didn't recognise it - will have to try with another reader). I also started building something to interface to an AVR micro, but got drawn outside by the nice weather

The datasheet for the chip in question is here:
http://www.hynix.com/datasheet/pdf/f...1M(Rev0.7).pdf

This may vary from phone to phone, but in general it's a 32Mb Flash.

The read protocol seems straightforward enough, and in theory a recent eprommer/flasher should be able to read it.

C.

Hey Chayd,
Do we have the timing protocol and command set for the chip you are trying to read ?

It would not be hard to wrap something simple into a PIC to do the basic read (I guess).

Hv.

Originally Posted by Hiddenvision

[Hiddenvision]

Cheers C.
I just found it myself here after I read some previous posts..
http://pdf1.alldatasheet.co.kr/datas...T49BV163A.html

Seems simple enough.
I shall see what I can wrap up in the next couple of days..

Hv.

[Chayd]

Cool, all the best of luck!

C.

Edit: Hang on.....Rewind <<. I've already managed to dump off that chip via JTAG. It's an Atmel 2Mb chip with the bootloader and possibly also the kernel binaries on, see earlier postings for an image
(if link has expired, let me know and I'll do a new one). This is what the DSP boots off, and is a regular address-and-data-bus type device. Just thought I'd save you some time there

The one we do want data off is the 32Mb one that uses a multiplexed bus which the DSP doesn't natively support (nor does the JTAG software), so I'd guess that the bootloader/kernel has some bit banging
code in there in order to be able to read it. As well as config info and operator-cusomisable content reside, I believe that this is also where the phonebook, captured images and other user data are stored, probably in some nice neat (possibly even open source) filesystem.

2nd Edit: I was just thinking - I wonder if your decompression idea would be able to extract the bootloader from that rom image?...will have to see!

[Hiddenvision]

Ahh that saves some finger work.
Now I gotta read another sheet.
Still looks simples'

The data sheet for the other device was
http://www.chipcatalog.com/Datasheet...EDF9974E25.htm
I just put that there for my refference I think it is the same as the one you pointed to earlier.


Just a thought,
I have tried to simply fudge the DNS for the btsip.xxx address to sipgates address.

The problem is the IP address for sipgate does not work.

I meen it works but I noticed on the homehub that if you use the IP and not the name it will not work.

I tried to enter the 'name' in the DNS window and it seems to only want an IP.
is there anyway to repoint the btsip.net to sipgate.co.uk rather than sipgates IP


I got the same problem when I tried to point the updates to my live website.
using the IP i get my ISP's default page,

I know it is not a good fix but I was just curious to see if it would actually work.

Is this an impossible task or have I just pressed the wrong buttons.?

Hv.

[Hiddenvision]

Hey C.

just so you know the program will only accept certain extensions for the 4 buttons.

Uncompress requires a .z extension
Unpack and Compress needs .zu extension
Pack needs .txt extension.

I have been making some changes so that if you select Show All files the it will ignore the extension for the uncompress but I hve not uploaded the new version yet.
I am sure you can simply rename the files for the mean time.

I shall wrap up some more bits over the weekend and upload a new version then.

Hv.

[Hiddenvision]

I had a quick look at the Vp1000.bin file you uploaded.
Found what could be a start ! perhaps 1 of many.

At the start of the first decompressed file we got

%g ticks.%g ticks.%.2f ticks.%g ticks.%g ticks.%.2f ticks.%g inst.%g inst.%.2f inst.%g inst.%g inst.%.2f inst

So this decompressing plan seems to be exposing more as I have never seen that before !.

first 789C header was at 0x13088 and I guess ended at the start of all the zeros.
Then there is another at 0xB27E7 and more !
Actually there was a few in between those two.

Cor this is rough.....
Taking a chainsaw to the file seems to give some results.

I should stop and refuel the motor.
it is late and the eyes feel like sandpaper.!

I shall see if I can search out and decompress more of the bin later if/when I awake.
I think I am going to have to try an understand this zlib compression and see how things are structured.

anyone done that already ???

Hv.

[Hiddenvision]

Done the update I mentioned.
Not added anything new as I shall dothat when I can think.

current version 1.0.0.4

Hv.

[Chayd]

Good to hear the updates, cheers.

I did look up the spec for zlib, trouble is that there's no real signature so to speak, I think a compressed section starts with 0x78, then some other variable bytes decribing, size of dictionary, then the dictionary itself, which I would guess are those blocks of bytes separated by 0x00s, and I think that was the point I reached before I went cross-eyed looking at all those numbers. There is a definite pattern to the compressed bits, bit I'll be damned if I can figure it out. Perhaps you'll have more luck being experienced in this sort of thing

Edit: I was thinking about your earlier brute-force idea where you'd move the start position one byte forward each time and keep feeding it through zlib until it works - that may be the easiest option. I'm out all day, but may take a look at it when I'm back this evening unless you've succeeded before then.

Good luck!!

C.