Downunder35m
- Downunder35m
- Posts: 4250
- Joined: Wed Oct 21, 2009 4:44 am
My TT Via experience
Tue May 29, 2012 3:12 am
I ordered myself a VIA160 to play with an in this thread I will post what I do to it.
Goal is to get a better understanding on the communication process between MyTT and the device.
Final goal to be able to access the device as we are used to for the older models - but that won't happen soon if at all.
Since enough info about the device itself can be found on the net I cut it down to the parts of interest.
Currently running on NC 10.052 with a 855 map.
Connecting to the PC only charges the device.
For a data connection the installation of MyTT is required as drivers are needed, in particular the RNDIS-over-USB host driver.
After a testinstall of MyTT in a sandbox the following files are installed:
In "the MyTomTom 3" the full MyTT software pack including DLL files and drivers for the Linux filesystem.
In the plugin section the DLL files for the device manager seem to be needed for accessing the device.
In the Resoures section the file "TT_root_sign_cert crt.dat" seems to be of interest.
Inside the Windows folder:
\System32\DriverStore
drvindex.dat
INFCACHE.1
infpub.dat
infstor.dat
infstrng.dat
\System32\CatRoot2
ebd.chk
ebd.log
ebd00647.log
ebd00648.log
folder "{127D0A1D-4EF2-11D1-8608-00C04FC295EE}"
catdb
folder "{F750E6C3-38EE-11D1-85E5-00C04FC295EE}"
catdb
Same name but different size/content for the two above files.
The only other interesting files are locate in the user folder under
AppData\LocalLow\Microsoft\CryptnetUrlCache\MetaData
Only one file with a cryptic filename
Later today I will do a real install to check for other files that might be created after installation.
Installed MyTT and noticed that the Via is being recognised by Windows now (at least judging by the sounds in the background), but it only works on a USB2 direct hub.
My Front ports are basically just an etension but no chance to use them.
As soon as the device connects it checks for updates, even without MyTT running.
Straight through the firewall and all...
Now as soon as I connect the device will download and install an update for the new Navcore.
Pretty weird and not nice that you are forced to update.
All logging attempts under Win failed so far as this stuff only seems to work in a Linux enviroment or a virtual box.
Since I don't like Linux I need to seek alternatives or find an easy way for a ready to go Linux system and a virual box.
Feel free to contibute your own findings or how you you access your new TT.
[Spoiler=Update2:]
Collected info's from all all over the net:
Special credits to the guys at Opentom!
I try to collect the things that are available so that there is one place with most of the available informations together.
Sadly it seems Cyph is giving up due to lack of support, so maybe someone talking french could invite him over?
[/Spoiler]
Goal is to get a better understanding on the communication process between MyTT and the device.
Final goal to be able to access the device as we are used to for the older models - but that won't happen soon if at all.
Since enough info about the device itself can be found on the net I cut it down to the parts of interest.
Currently running on NC 10.052 with a 855 map.
Connecting to the PC only charges the device.
For a data connection the installation of MyTT is required as drivers are needed, in particular the RNDIS-over-USB host driver.
After a testinstall of MyTT in a sandbox the following files are installed:
In "the MyTomTom 3" the full MyTT software pack including DLL files and drivers for the Linux filesystem.
In the plugin section the DLL files for the device manager seem to be needed for accessing the device.
In the Resoures section the file "TT_root_sign_cert crt.dat" seems to be of interest.
Inside the Windows folder:
\System32\DriverStore
drvindex.dat
INFCACHE.1
infpub.dat
infstor.dat
infstrng.dat
\System32\CatRoot2
ebd.chk
ebd.log
ebd00647.log
ebd00648.log
folder "{127D0A1D-4EF2-11D1-8608-00C04FC295EE}"
catdb
folder "{F750E6C3-38EE-11D1-85E5-00C04FC295EE}"
catdb
Same name but different size/content for the two above files.
The only other interesting files are locate in the user folder under
AppData\LocalLow\Microsoft\CryptnetUrlCache\MetaData
Only one file with a cryptic filename
Later today I will do a real install to check for other files that might be created after installation.
Installed MyTT and noticed that the Via is being recognised by Windows now (at least judging by the sounds in the background), but it only works on a USB2 direct hub.
My Front ports are basically just an etension but no chance to use them.
As soon as the device connects it checks for updates, even without MyTT running.
Straight through the firewall and all...
Now as soon as I connect the device will download and install an update for the new Navcore.
Pretty weird and not nice that you are forced to update.
All logging attempts under Win failed so far as this stuff only seems to work in a Linux enviroment or a virtual box.
Since I don't like Linux I need to seek alternatives or find an easy way for a ready to go Linux system and a virual box.
Feel free to contibute your own findings or how you you access your new TT.
Spoiler: Show
Update 1:]
Today I opened the VIA to check what's inside.
Nothing worth to say about as I could not find any obvious points for a SD or JTag connection.
But if you need to replace your battery:
Remove the windscreen mount, bend it over until it comes off.
Remove the little Torx screw that you find in the hole.
Now you need one of these plastic openers that you often get with the kits for mobile phones.
A small screwdriver could be used but will damage the case.
You have to pry the case apart - do so by moving the plastic tool around the front cover. It seems to work best starting at the top, than the sides. The bottom part comes apart when you lift the two parts.
Be careful as the cables are very short and easily damaged!
The small connectors are best removed with some needle point tweezers, they are very tight and you should not try to pull on the cables!
Push the white security holder for the screen ribbon away from the connector to release the cable, again be carefull not to damage it.
Now you can seperate the two halfs of the device.
Remove the screws for the circuit board and push the plastic hooks slightly out to remove the board.
The small antenna cable is not clued on and will come out without troubles.
Remove the battery connector and to get the board completely out.
The battery might be glued in pretty good or very weak, if it is too hard to get out you can use a hairdryer to warm up the battery and case but not too hot please.
Put the new battery in and reverse the steps.
If you have steady hands and don't want disconnect the ribbon cable you can try to leave it on and undo the circuit board with the screen attached - but this is not really recommended.
Today I opened the VIA to check what's inside.
Nothing worth to say about as I could not find any obvious points for a SD or JTag connection.
But if you need to replace your battery:
Remove the windscreen mount, bend it over until it comes off.
Remove the little Torx screw that you find in the hole.
Now you need one of these plastic openers that you often get with the kits for mobile phones.
A small screwdriver could be used but will damage the case.
You have to pry the case apart - do so by moving the plastic tool around the front cover. It seems to work best starting at the top, than the sides. The bottom part comes apart when you lift the two parts.
Be careful as the cables are very short and easily damaged!
The small connectors are best removed with some needle point tweezers, they are very tight and you should not try to pull on the cables!
Push the white security holder for the screen ribbon away from the connector to release the cable, again be carefull not to damage it.
Now you can seperate the two halfs of the device.
Remove the screws for the circuit board and push the plastic hooks slightly out to remove the board.
The small antenna cable is not clued on and will come out without troubles.
Remove the battery connector and to get the board completely out.
The battery might be glued in pretty good or very weak, if it is too hard to get out you can use a hairdryer to warm up the battery and case but not too hot please.
Put the new battery in and reverse the steps.
If you have steady hands and don't want disconnect the ribbon cable you can try to leave it on and undo the circuit board with the screen attached - but this is not really recommended.
[Spoiler=Update2:]
Collected info's from all all over the net:
Special credits to the guys at Opentom!
I try to collect the things that are available so that there is one place with most of the available informations together.
Spoiler: Show
about the firmware (Navcore)]
When you install MyTomTom at your PC in C:\Documents and Settings\User\Local Settings\Application Data\TomTom\HOME3\cache you have a file like "content1. This is an upgrade.
This file includes 20 extra bytes for every 100Kb of data. With this simple script I've managed to remove it and extract the files:
After running this, you can unpack it from linux by "cpio -i -d < dest.dat". You can check if all the files are OK by checking the SHA1SUMs included in the file called "files":
Then you can extract the squashed root file system with "unsquashfs" or mount it.
SSH Dropbear
When you connect TomTom to PC. We have another ethernet over usb. At this connection there is open 3 ports: - ftp/21 - ssh/22 - http/80
When you connect via ssh, it need authentication certificate. It is c:\Program Files\My TomTom3\Resources\TT_root_sign_cert crt.dat.
You can connect with your TomTom Start 20 by shh from linux. This file can be added as identity file to SSH via the -i switch. The passphrase for the connection is however unknown.
HTTP Server
I look deeper to http connection and i see that work only:
When you install MyTomTom at your PC in C:\Documents and Settings\User\Local Settings\Application Data\TomTom\HOME3\cache you have a file like "content1. This is an upgrade.
This file includes 20 extra bytes for every 100Kb of data. With this simple script I've managed to remove it and extract the files:
- Code:
#!/bin/bash
#clear content: removes the extra bytes from content1 so you can extract the
#content using cpio. The clear file is "dest.dat"
DEST=dest.dat
SOURCE=src.dat
TMP=tmp.dat
rm $DEST
rm $SOURCE
rm $TMP
#the 29 first byte are not included in the 100KB + 20B format
tail -c +29 content1 > $SOURCE
while [ -s $SOURCE ];
do
head -c 102400 $SOURCE >> $DEST
tail -c +102421 $SOURCE > $TMP
mv $TMP $SOURCE
ls -l *.dat
done;
After running this, you can unpack it from linux by "cpio -i -d < dest.dat". You can check if all the files are OK by checking the SHA1SUMs included in the file called "files":
- Code:
sha1sum -c files
Then you can extract the squashed root file system with "unsquashfs" or mount it.
SSH Dropbear
When you connect TomTom to PC. We have another ethernet over usb. At this connection there is open 3 ports: - ftp/21 - ssh/22 - http/80
When you connect via ssh, it need authentication certificate. It is c:\Program Files\My TomTom3\Resources\TT_root_sign_cert crt.dat.
You can connect with your TomTom Start 20 by shh from linux. This file can be added as identity file to SSH via the -i switch. The passphrase for the connection is however unknown.
HTTP Server
I look deeper to http connection and i see that work only:
- Code:
http://169.254.255.1/mpnd/status
http://169.254.255.1/mpnd/progress
http://169.254.255.1/mpnd/trigger
http://169.254.255.1/mpnd/logintoken
http://169.254.255.1/mpnd/assocpreconf
http://169.254.255.1/mpnd/settings
http://169.254.255.1/sa/hello
http://169.254.255.1/sa/goodbye
Spoiler: Show
Connecting to Linux]
When plugged into an Ubuntu 10:04 laptop, is identified as a usb based network interface (dwc_otg_pcd). The Linux desktop acquires an auto-configuration IP address, and the TomTom another on the same range. for example:
If usb0 interface doesn't show up in ifconfig output automatically, check that cdc_ether kernel module is loaded and try to run as root "ifconfig usb0 up" followed by "dhcpcd usb0" or "dhclient usb0". Afterwards ifconfig output should be similar to one provided above.
In this example the TomTom gets an IP address of 169.254.255.1. Portscanning the device shows the following:
Attempting an ssh connection reveals that the device uses authentication by key:
Apparently the publickey is contained in a file named "TT_root_sign_cert crt.dat" (Mac OS X) that can be found within MyTomTom's installation folder. This file can be added as identity file to SSH via the -i switch. The passphrase for the connection is however unknown.
When plugged into an Ubuntu 10:04 laptop, is identified as a usb based network interface (dwc_otg_pcd). The Linux desktop acquires an auto-configuration IP address, and the TomTom another on the same range. for example:
- Code:
usb0 Link encap:Ethernet HWaddr 02:04:06:08:0a:0c
inet addr:169.254.255.2 Bcast:169.254.255.3 Mask:255.255.255.252
inet6 addr: fe80::4:6ff:fe08:a0c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1069 errors:0 dropped:0 overruns:0 frame:0
TX packets:1155 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:46327 (46.3 KB) TX bytes:85155 (85.1 KB)
If usb0 interface doesn't show up in ifconfig output automatically, check that cdc_ether kernel module is loaded and try to run as root "ifconfig usb0 up" followed by "dhcpcd usb0" or "dhclient usb0". Afterwards ifconfig output should be similar to one provided above.
In this example the TomTom gets an IP address of 169.254.255.1. Portscanning the device shows the following:
- Code:
Starting Nmap 5.00 ( http://nmap.org ) at 2011-04-18 19:28 BST
Interesting ports on 169.254.255.1:
Not shown: 998 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
MAC Address: 02:01:02:03:04:05 (Unknown)
Nmap done: 1 IP address (1 host up) scanned in 1.51 seconds
Attempting an ssh connection reveals that the device uses authentication by key:
- Code:
desktop:~$ ssh [email protected]
Permission denied (publickey).
desktop:~$ ssh [email protected]
Permission denied (publickey).
Apparently the publickey is contained in a file named "TT_root_sign_cert crt.dat" (Mac OS X) that can be found within MyTomTom's installation folder. This file can be added as identity file to SSH via the -i switch. The passphrase for the connection is however unknown.
Spoiler: Show
Additional posting to the above]
Hi, I appreciate your work, but I have some comments and notes. First, to complete the list of opened ports, there is another port 3129 opened in the device. It's http/https proxy.
I'd advise you to stop bothering with vmware/windows combination (both sucks). Try ubuntu on USB or some other live distribution - it's much much better.
I think, the installed software doesn't have any kind of library for SSH, the certificate is IMHO only for SSL encryption - there is only one place in the TomTomSupporterProxy.dll, which uses this file - as a certificate for SSL using QtNetwork library.
Either there should be some communication to allow stealing of the correct certificate, or someone has to steal the certificate at TomTom's side.
Here's piece of dissassembled code of the TomTomSupporterProxy.dll
Hi, I appreciate your work, but I have some comments and notes. First, to complete the list of opened ports, there is another port 3129 opened in the device. It's http/https proxy.
I'd advise you to stop bothering with vmware/windows combination (both sucks). Try ubuntu on USB or some other live distribution - it's much much better.
I think, the installed software doesn't have any kind of library for SSH, the certificate is IMHO only for SSL encryption - there is only one place in the TomTomSupporterProxy.dll, which uses this file - as a certificate for SSL using QtNetwork library.
Either there should be some communication to allow stealing of the correct certificate, or someone has to steal the certificate at TomTom's side.
Here's piece of dissassembled code of the TomTomSupporterProxy.dll
- Code:
000164A4: 0x100170A4: EC in al, dx
000164A5: 0x100170A5: FF1534D40110 call dword near [M1001D434 {__imp__?sslConfiguration@QNetworkRequest@@QBE?AVQSslConfiguration@@XZ}]
000164AB: 0x100170AB: 6A02 push 0x00000002
000164AD: 0x100170AD: 8D4D10 lea ecx, [ebp+0x00000010]
000164B0: 0x100170B0: C645FC11 mov byte [ebp-0x00000004], 0x00000011
000164B4: 0x100170B4: FF1538D40110 call dword near [M1001D438 {__imp__?setProtocol@QSslConfiguration@@QAEXW4SslProtocol@QSsl@@@Z}]
000164BA: 0x100170BA: 6A01 push 0x00000001
000164BC: 0x100170BC: 8D4D10 lea ecx, [ebp+0x00000010]
000164BF: 0x100170BF: FF153CD40110 call dword near [M1001D43C {__imp__?setPeerVerifyMode@QSslConfiguration@@QAEXW4PeerVerifyMode@QSslSocket@@@Z}]
000164C5: 0x100170C5: 8D4DD4 lea ecx, [ebp-0x0000002C]
000164C8: 0x100170C8: 51 push ecx
000164C9: 0x100170C9: FF1530D50110 call dword near [M1001D530 {__imp__?GetResourcesPath@SystemConfig@@SA?AVQString@@XZ}]
000164CF: 0x100170CF: 6830F20110 push dword M1001F230 {"\TT_root_sign_cert crt.dat"}
000164D4: 0x100170D4: 50 push eax
000164D5: 0x100170D5: 8D55E4 lea edx, [ebp-0x0000001C]
000164D8: 0x100170D8: 52 push edx
000164D9: 0x100170D9: C645FC12 mov byte [ebp-0x00000004], 0x00000012
000164DD: 0x100170DD: E8DEE9FFFF call L10015AC0
000164E2: 0x100170E2: 83C410 add esp, byte 0x00000010
000164E5: 0x100170E5: 8B45D4 mov eax, [ebp-0x0000002C]
000164E8: 0x100170E8: C645FC14 mov byte [ebp-0x00000004], 0x00000014
000164EC: 0x100170EC: 83C9FF or ecx, 0x000000FF
000164EF: 0x100170EF: F00FC108 lock xadd [eax], ecx
000164F3: 0x100170F3: 7509 jnz L100170FE
L100170F5: // Refs:
000164F5: 0x100170F5: 8B55D4 mov edx, [ebp-0x0000002C]
000164F8: 0x100170F8: 52 push edx
000164F9: 0x100170F9: FFD3 call ebx
000164FB: 0x100170FB: 83C404 add esp, byte 0x00000004
L100170FE: // Refs: L100170F3
000164FE: 0x100170FE: 8D45E4 lea eax, [ebp-0x0000001C]
00016501: 0x10017101: 50 push eax
00016502: 0x10017102: 8D4DD0 lea ecx, [ebp-0x00000030]
00016505: 0x10017105: 51 push ecx
00016506: 0x10017106: FF15BCD00110 call dword near [M1001D0BC {__imp__?toNativeSeparators@QDir@@SA?AVQString@@ABV2@@Z}]
0001650C: 0x1001710C: 83C408 add esp, byte 0x00000008
0001650F: 0x1001710F: 50 push eax
00016510: 0x10017110: 8D4DBC lea ecx, [ebp-0x00000044]
00016513: 0x10017113: C645FC15 mov byte [ebp-0x00000004], 0x00000015
00016517: 0x10017117: FF1500D30110 call dword near [M1001D300 {__imp__??0QFile@@QAE@ABVQString@@@Z}]
0001651D: 0x1001711D: 8B55D0 mov edx, [ebp-0x00000030]
00016520: 0x10017120: C645FC17 mov byte [ebp-0x00000004], 0x00000017
00016524: 0x10017124: 83C8FF or eax, 0x000000FF
00016527: 0x10017127: F00FC102 lock xadd [edx], eax
0001652B: 0x1001712B: 7509 jnz L10017136
L1001712D: // Refs:
0001652D: 0x1001712D: 8B4DD0 mov ecx, [ebp-0x00000030]
00016530: 0x10017130: 51 push ecx
00016531: 0x10017131: FFD3 call ebx
00016533: 0x10017133: 83C404 add esp, byte 0x00000004
L10017136: // Refs: L1001712B
00016536: 0x10017136: 51 push ecx
00016537: 0x10017137: 8BC4 mov eax, esp
00016539: 0x10017139: 8D4DBC lea ecx, [ebp-0x00000044]
0001653C: 0x1001713C: 89650C mov [ebp+0x0000000C], esp
0001653F: 0x1001713F: C70001000000 mov dword [eax], 0x00000001
00016545: 0x10017145: FF15FCD20110 call dword near [M1001D2FC {__imp__?open@QFile@@UAE_NV?$QFlags@W4OpenModeFlag@QIODevice@@@@@Z}]
0001654B: 0x1001714B: 84C0 test al, al
0001654D: 0x1001714D: 757D jnz L100171CC
L1001714F: // Refs:
0001654F: 0x1001714F: A114D20110 mov eax, [M1001D214 {__imp__?shared_null@QListData@@2UData@1@A}]
00016554: 0x10017154: 89450C mov [ebp+0x0000000C], eax
00016557: 0x10017157: BA01000000 mov edx, 0x00000001
0001655C: 0x1001715C: F00FC110 lock xadd [eax], edx
00016560: 0x10017160: 6A00 push 0x00000000
00016562: 0x10017162: 8D45BC lea eax, [ebp-0x00000044]
00016565: 0x10017165: B318 mov bl, 0x00000018
00016567: 0x10017167: 50 push eax
00016568: 0x10017168: 8D4DCC lea ecx, [ebp-0x00000034]
0001656B: 0x1001716B: 885DFC mov [ebp-0x00000004], bl
0001656E: 0x1001716E: FF1540D40110 call dword near [M1001D440 {__imp__??0QSslCertificate@@QAE@PAVQIODevice@@W4EncodingFormat@QSsl@@@Z}]
00016574: 0x10017174: 8D4DBC lea ecx, [ebp-0x00000044]
00016577: 0x10017177: C645FC19 mov byte [ebp-0x00000004], 0x00000019
0001657B: 0x1001717B: FF15F4D20110 call dword near [M1001D2F4 {__imp__?close@QFile@@UAEXXZ}]
00016581: 0x10017181: 8D4DCC lea ecx, [ebp-0x00000034]
00016584: 0x10017184: 51 push ecx
00016585: 0x10017185: 8D4D0C lea ecx, [ebp+0x0000000C]
00016588: 0x10017188: E8F3F7FFFF call L10016980
0001658D: 0x1001718D: 8D550C lea edx, [ebp+0x0000000C]
00016590: 0x10017190: 52 push edx
00016591: 0x10017191: 8D4D10 lea ecx, [ebp+0x00000010]
00016594: 0x10017194: FF1544D40110 call dword near [M1001D444 {__imp__?setCaCertificates@QSslConfiguration@@QAEXABV?$QList@VQSslCertificate@@@@@Z}]
0001659A: 0x1001719A: 8D4DCC lea ecx, [ebp-0x00000034]
0001659D: 0x1001719D: 885DFC mov [ebp-0x00000004], bl
000165A0: 0x100171A0: FF155CD40110 call dword near [M1001D45C {__imp__??1QSslCertificate@@QAE@XZ}]
000165A6: 0x100171A6: 8B450C mov eax, [ebp+0x0000000C]
000165A9: 0x100171A9: C645FC17 mov byte [ebp-0x00000004], 0x00000017
000165AD: 0x100171AD: 85C0 test eax, eax
000165AF: 0x100171AF: 7415 jz L100171C6
L100171B1: // Refs:
000165B1: 0x100171B1: 83C9FF or ecx, 0x000000FF
000165B4: 0x100171B4: F00FC108 lock xadd [eax], ecx
Spoiler: Show
Translations from tomtomheaven about the Go1000 but problems are the same:]
A friend ... I was told that it was not bad shielded, but that nothing was impossible a few details:
1) the tomtom connects directly to the PC using the network 169.254.255.1 (tomtom) -> 169.254.255.2 (PC)
a few xml messages are exchanged at that time ... Hello, Id tomtom ... etc..
2) Obviously, the tomtom is coming and the resident program seems MyTomTom relay information on the website of TomTom (also for s announce) certificate,
secure connection, etc. ...
3) The tomtom check itself for possible update ... this way ... the status being relayed between machines via xml ... progress, processing ...
In other words, if you planned to see something through these exchanges http ... it's only ads, the status of progress ... etc., not very informative .. well ...
Trying to access tomtom directly to: ssh or scp or another ... the tomtom responds, of course,
but dropbear is configured so that only holders of the private key can connect ... (authorized_key only ) for the common man was just right to
RSA Key fingerprint is 69:40: bf: 99 ... and a permission denied (publickey) ... even after he should have the passphrase.
Hello,
I have been very recently a model VIA 125 and the problem of clamping MyTomTom is identical.
After some analysis I could find some parameters that are exchanged between the software and GPS MyTomTom.
However, I am quite interested in a list of certificates that nobody has talked on the web currently.
At the url: [Please Register or Login to download file]
It is an XML file containing all the device parameters (version, serial number) but also an extensive list of certificates (There are 22) in this form:
<Certificate id = "15e7406e-f8a4-47da-BF10-7506ae0b786a" certdata = "BQAAAFArBe64iHvg ....." /> (Truncated because too long)
Do you have an idea what these certificates could match?
A year after the release of these models, it is surprising that no one was more advanced on the subject.
Hello,
I share this information which I am sure you will make a difference:
This info for access to the file system TT Live 1005. I was able to decode the files Maj (ttpkg) downloaded from the site of TT. Example: the file "content1" MyTomTom downloaded on my computer is the file 00000000-0074-0011-0310-008604472528_system-update.ttpkg
This file looks like a tar or cpio, but if you try to do a cpio above it does not work because TT has garbage characters inserted inside it must remove before making a cpio to extract all files in this container. The solution is here: See the shell script at the bottom of the page: [Please Register or Login to download file]
Once you can execute without a bp to cpio and get the following files:
- Files
- Files.sig
- System-update_860447_bcm4760-current.ipk
- A folder "system-update_860447_bcm4760-current_data" containing:
rootfs.img.new
zImage
Now that the extraction is done, we must look at the file rootfs.img.new
The first 4 characters of this file are "hsqs" indicating that this is a squashfs file format.
To access the contents simply mount it on a Unix mount point with the following command:
mount-o loop-t squashfs rootfs.img.new / mnt
Then just browse to the folder / mnt to approach the holy grail. The hierarchy:
drwxr-xr-x 2 root root 2042 2012-02-13 12:22 bin
drwxr-xr-x 2 root root 3 2012-02-13 24:11 happy
drwxr-xr-x 2 root root 30 2012-02-13 12:22 dev
drwxr-xr-x 13 root root 1200 2012-02-13 12:22 etc
drwxr-xr-x 3 root root 30 2012-02-13 12:22 home
lrwxrwxrwx 1 root root 9 2012-02-13 12:22 init -> sbin / init
drwxr-xr-x 10 root root 4343 2012-02-13 12:22 lib
drwxr-xr-x 4 root root 42 2012-02-13 12:22 media
drwxr-xr-x 6 root root 77 2012-02-13 12:22 mnt
drwxr-xr-x 5 root root 60 2012-02-13 12:22 opt
drwxr-xr-x 2 root root 3 2012-02-13 24:11 proc
drwxr-xr-x 3 root root root 27 2012-02-13 12:22
drwxr-xr-x 2 root root 1875 2012-02-13 12:22 sbin
drwxr-xr-x 2 root root 3 2012-02-13 24:11 sys
drwxrwxrwt 2 root root 3 2012-02-13 12:11 tmp
drwxr-xr-x 4 root root 51 2012-02-13 12:22 usr
drwxr-xr-x 2 root root 3 2012-02-13 24:11 var
The contents of / etc / passwd for example gives us:
root :: 0:0: root :/ root :/ bin / sh
nobody: *: 99:65534: Nobody :/:
factory: *: 105:105: Factory user :/ home / factory :/ sbin / force_factory_mode
MPND: *: 106:106: Job manager :/:
sensord: *: 107:107: daemon :/ Sensor:
GPS: *: 1024:1024: GPS :/ content / gps
Bluetooth: *: 1025:1025: Bluetooth :/:
Browser: *: 1026:1026: IU browser :/ content / browser:
navcore: *: 1027:1027: Navcore :/ content / ttn:
webserver: *: 1028:1028: Web server :/ var / run / web:
vncserver: *: 1029:1029: VNC server :/:
graphicsd: *: 1030:1030: Daemon :/ Graphics:
revinetd: *: 1031:1031: Reverse :/ network daemon:
Details of all modules installed on the TT is placed in / usr / lib / opkg / status, indicates that:
Embedded processor in the TomTom Go Live 1005 is a BCM4760 home Broadband: [Please Register or Login to download file]
The SSH server: dropbear "SSH-2.0-dropbear_0.52". The ssh server is available for free download at TT at: @ [Please Register or Login to download file] 533054.tar.bz2
The embedded Linux is a version 2.6.28 for BCM4760
The web server is: Mongoose web server:
Ftp: obxftpd
Response from Cyph:
Not bad actually ...
While AC have long pass in / etc / passwd shadow ... are not really used, such as ... (in any case, this can give ideas to login ...)
After performing a port scan service it turns out that only 22 and 80 are visible.
22 for ssh
80 for http
I was interested in a feat ftp (the coup obexftpd) but it is grated since everything boils down to the ssh ...
I see a trail: attempt a feat of mongoose 3.1 ... there is clearly a BufferOverflow on a PUT ... that would execute arbitrary code.
It is not yet won to execute our own code ... but not despair ... (especially since the interest is just to bring you the plugins ... and THAT IT!)
We would have to talk a little in private tracks ... Any takers I am available on [email="[email protected]"][email protected][/email]
I searched a bit ... I like our friend searched as Anonymous
You can also unpack your files, it helps to understand the system.
rootfs.img.new would not be difficult to create, as said before: it is a compressed filesystem type squashfs.
What about other files around it?
File contents "files"
d6d371cb99337b06b0101598a760a91fcb610b87 system-update_890538_bcm4760-current_data/rootfs.img.new
cc868428833cf658c1a0d651d3a68d05bb2b750a system-update_890538_bcm4760-current_data/zImage
e3984cdb0a658808c82468ea25d9d6e71ecc835f update_890538_bcm4760-system-current.ipk
It therefore lists the files in the package, and obviously, there is already a first calculation:
What does
d6d371cb99337b06b0101598a760a91fcb610b87
?
I will say that it strongly resembles a calculation "digest" type SHA/SHA1.
I'm just guessing, of course.
The file Files.sig
Probably a signature file to ensure that does not change the file Files
No idea of ??his generation.
The file-system-update_890538_bcm4760 current.ipk
This is a tar.gz which itself contains three files
Control.tar.gz
Data.tar.gz
Debian-binary
Control the file is an ASCII file containing the following information:
Go, I go back.
I'll dig this:
var
tmp
sys
proc
content
usr
root
mnt
media
init ->sbin/init
home
dev
opt
sbin
etc
lib
bin
We begin by the webserver, some information was known, but some are quite fresh and have never been disclosed!
Looking in the file service_webserver.conf you find a lot of information about mount points made ??before launching the webserver (the one who answers when you load a POI file, cursor on your tomtom ...)
Already
the root directory of the webserver is / var / run /
Suddenly, everything under / var / run can potentially be accessed:
Here's everything I could find ...
/ Var / run / PCMI => [Please Register or Login to download file] = The main page that everyone knows
/ Var / run / dump => [Please Register or Login to download file] = page to get her screenshots
/ Var / run / personal => [Please Register or Login to download file] = page to see everything you have loaded the tomtom
/ Var / run / pcmi_tmp => [Please Register or Login to download file] = Mystery! (Let's not open up / tmp to the webserver), we'll dig this stuff ...
/ Var / run / gpslogs / => [Please Register or Login to download file] = It's all in the name logs and GPS, it does not seem to me that someone had referred
/ Var / run / cprid / => [Please Register or Login to download file] = Connection reset by peer, digging ... # Ensure There Is access to the the timestamp for the last upload CPR.
/ Var / run / factorydata => [Please Register or Login to download file] = information on your tomtom
I feel that this information will be taken over, after all ... it is for this.
What can we do with that in your opinion?
1178 January 15, 2011 tt_rootfs_dev_pubkey.dsa
1192 January 15, 2011 tt_rootfs_dev_privkey.dsa
1178 January 15, 2011 tt_loopfs_prod_pubkey.dsa
2576 January 15, 2011 tt_loopfs_prod_privkey.dsa.gpg
1178 January 15, 2011 tt_loopfs_dev_pubkey.dsa
1192 January 15, 2011 tt_loopfs_dev_privkey.dsa
1178 January 15, 2011 tt_kernel_prod_pubkey.dsa
1291 January 15, 2011 tt_kernel_prod_privkey.dsa
1178 January 15, 2011 tt_kernel_dev_pubkey.dsa
1192 January 15, 2011 tt_kernel_dev_privkey.dsa
1192 January 15, 2011 tt_factory_dev_privkey.dsa
given by a friend who wishes us well ... without telling me if we can do something.
> Gpg tt_loopfs_prod_privkey.dsa.gpg
gpg: encrypted with ELG-E key, ID 18BBCF3F
gpg: encrypted with ELG-E key, ID CD70EBC0
gpg: encrypted with 2048 bit key ELG-E, ID 76C5C5C6, created on 2009-11-26
"Axx Bxxxxxxxx <[email protected]>"
gpg: decryption failed: secret key not available
It is not forbidden to search for its culture? I just want to learn.
I tried with putty after conversion of key ...
Refused the server your keys.
I think these keys are used, but elsewhere.
Signatures of packages such ...
Furthermore, I confirm this:
dgst-openssl sha1 ./system-update_890538_bcm4760-current_data/rootfs.img.new
SHA1 (./system-update_890538_bcm4760-current_data/rootfs.img.new) = d6d371cb99337b06b0101598a760a91fcb610b87
Which means I can generate the files
I still find files.sig .... and and and ... Exactly ...
I think our key for this. I continue.
Well I obviously also a tool for signature:
Hop, I found another source on the signing:
+ 4 key ... always public
TT_pub_fd_dev.dsa
TT_pub_fd_prod.dsa
TT_pub_kern_dev.dsa
TT_pub_kern_prod.dsa
+ This (obviously for the Broadcom BCM4760)
dsa1024.pem
dsacert.pem
dsakey.pem
uboot
keys.inc
dsa-cert.txt
dsa-info.txt
A friend ... I was told that it was not bad shielded, but that nothing was impossible a few details:
1) the tomtom connects directly to the PC using the network 169.254.255.1 (tomtom) -> 169.254.255.2 (PC)
a few xml messages are exchanged at that time ... Hello, Id tomtom ... etc..
2) Obviously, the tomtom is coming and the resident program seems MyTomTom relay information on the website of TomTom (also for s announce) certificate,
secure connection, etc. ...
3) The tomtom check itself for possible update ... this way ... the status being relayed between machines via xml ... progress, processing ...
In other words, if you planned to see something through these exchanges http ... it's only ads, the status of progress ... etc., not very informative .. well ...
Trying to access tomtom directly to: ssh or scp or another ... the tomtom responds, of course,
but dropbear is configured so that only holders of the private key can connect ... (authorized_key only ) for the common man was just right to
RSA Key fingerprint is 69:40: bf: 99 ... and a permission denied (publickey) ... even after he should have the passphrase.
Hello,
I have been very recently a model VIA 125 and the problem of clamping MyTomTom is identical.
After some analysis I could find some parameters that are exchanged between the software and GPS MyTomTom.
However, I am quite interested in a list of certificates that nobody has talked on the web currently.
At the url: [Please Register or Login to download file]
It is an XML file containing all the device parameters (version, serial number) but also an extensive list of certificates (There are 22) in this form:
<Certificate id = "15e7406e-f8a4-47da-BF10-7506ae0b786a" certdata = "BQAAAFArBe64iHvg ....." /> (Truncated because too long)
Do you have an idea what these certificates could match?
A year after the release of these models, it is surprising that no one was more advanced on the subject.
Hello,
I share this information which I am sure you will make a difference:
This info for access to the file system TT Live 1005. I was able to decode the files Maj (ttpkg) downloaded from the site of TT. Example: the file "content1" MyTomTom downloaded on my computer is the file 00000000-0074-0011-0310-008604472528_system-update.ttpkg
This file looks like a tar or cpio, but if you try to do a cpio above it does not work because TT has garbage characters inserted inside it must remove before making a cpio to extract all files in this container. The solution is here: See the shell script at the bottom of the page: [Please Register or Login to download file]
Once you can execute without a bp to cpio and get the following files:
- Files
- Files.sig
- System-update_860447_bcm4760-current.ipk
- A folder "system-update_860447_bcm4760-current_data" containing:
rootfs.img.new
zImage
Now that the extraction is done, we must look at the file rootfs.img.new
The first 4 characters of this file are "hsqs" indicating that this is a squashfs file format.
To access the contents simply mount it on a Unix mount point with the following command:
mount-o loop-t squashfs rootfs.img.new / mnt
Then just browse to the folder / mnt to approach the holy grail. The hierarchy:
drwxr-xr-x 2 root root 2042 2012-02-13 12:22 bin
drwxr-xr-x 2 root root 3 2012-02-13 24:11 happy
drwxr-xr-x 2 root root 30 2012-02-13 12:22 dev
drwxr-xr-x 13 root root 1200 2012-02-13 12:22 etc
drwxr-xr-x 3 root root 30 2012-02-13 12:22 home
lrwxrwxrwx 1 root root 9 2012-02-13 12:22 init -> sbin / init
drwxr-xr-x 10 root root 4343 2012-02-13 12:22 lib
drwxr-xr-x 4 root root 42 2012-02-13 12:22 media
drwxr-xr-x 6 root root 77 2012-02-13 12:22 mnt
drwxr-xr-x 5 root root 60 2012-02-13 12:22 opt
drwxr-xr-x 2 root root 3 2012-02-13 24:11 proc
drwxr-xr-x 3 root root root 27 2012-02-13 12:22
drwxr-xr-x 2 root root 1875 2012-02-13 12:22 sbin
drwxr-xr-x 2 root root 3 2012-02-13 24:11 sys
drwxrwxrwt 2 root root 3 2012-02-13 12:11 tmp
drwxr-xr-x 4 root root 51 2012-02-13 12:22 usr
drwxr-xr-x 2 root root 3 2012-02-13 24:11 var
The contents of / etc / passwd for example gives us:
root :: 0:0: root :/ root :/ bin / sh
nobody: *: 99:65534: Nobody :/:
factory: *: 105:105: Factory user :/ home / factory :/ sbin / force_factory_mode
MPND: *: 106:106: Job manager :/:
sensord: *: 107:107: daemon :/ Sensor:
GPS: *: 1024:1024: GPS :/ content / gps
Bluetooth: *: 1025:1025: Bluetooth :/:
Browser: *: 1026:1026: IU browser :/ content / browser:
navcore: *: 1027:1027: Navcore :/ content / ttn:
webserver: *: 1028:1028: Web server :/ var / run / web:
vncserver: *: 1029:1029: VNC server :/:
graphicsd: *: 1030:1030: Daemon :/ Graphics:
revinetd: *: 1031:1031: Reverse :/ network daemon:
Details of all modules installed on the TT is placed in / usr / lib / opkg / status, indicates that:
Embedded processor in the TomTom Go Live 1005 is a BCM4760 home Broadband: [Please Register or Login to download file]
The SSH server: dropbear "SSH-2.0-dropbear_0.52". The ssh server is available for free download at TT at: @ [Please Register or Login to download file] 533054.tar.bz2
The embedded Linux is a version 2.6.28 for BCM4760
The web server is: Mongoose web server:
Ftp: obxftpd
Response from Cyph:
Not bad actually ...
While AC have long pass in / etc / passwd shadow ... are not really used, such as ... (in any case, this can give ideas to login ...)
After performing a port scan service it turns out that only 22 and 80 are visible.
22 for ssh
80 for http
I was interested in a feat ftp (the coup obexftpd) but it is grated since everything boils down to the ssh ...
I see a trail: attempt a feat of mongoose 3.1 ... there is clearly a BufferOverflow on a PUT ... that would execute arbitrary code.
It is not yet won to execute our own code ... but not despair ... (especially since the interest is just to bring you the plugins ... and THAT IT!)
We would have to talk a little in private tracks ... Any takers I am available on [email="[email protected]"][email protected][/email]
I searched a bit ... I like our friend searched as Anonymous
You can also unpack your files, it helps to understand the system.
rootfs.img.new would not be difficult to create, as said before: it is a compressed filesystem type squashfs.
What about other files around it?
File contents "files"
d6d371cb99337b06b0101598a760a91fcb610b87 system-update_890538_bcm4760-current_data/rootfs.img.new
cc868428833cf658c1a0d651d3a68d05bb2b750a system-update_890538_bcm4760-current_data/zImage
e3984cdb0a658808c82468ea25d9d6e71ecc835f update_890538_bcm4760-system-current.ipk
It therefore lists the files in the package, and obviously, there is already a first calculation:
What does
d6d371cb99337b06b0101598a760a91fcb610b87
?
I will say that it strongly resembles a calculation "digest" type SHA/SHA1.
I'm just guessing, of course.
The file Files.sig
Probably a signature file to ensure that does not change the file Files
No idea of ??his generation.
The file-system-update_890538_bcm4760 current.ipk
This is a tar.gz which itself contains three files
Control.tar.gz
Data.tar.gz
Debian-binary
Control the file is an ASCII file containing the following information:
- Code:
Package: system-update
Version: 890538
Architecture: bcm4760-current
Maintainer: support.tomtom.com
Section: base
Source: rootfs / / depot-open/mcl/branch/navx10.2/branch/baarn/branch/rennes/main / ... @ 890538; riaf-mcl-navx10-2-stimpy-nlbld13; root @ nl- bld-13.intra.local; Wed, March 21, 2012 11:51:49 0100; Linux nl-bld-2.6.18-13.intra.local 274.el5 # 1 SMP Fri Jul 8 5:36:59 p.m. EDT 2011 x86_64 x86_64 x86_64 GNU / Linux gcc version 4.3.3 (TomTom CipherWizardry 2009q1_203-474426)
Priority: major
Description: System update
TT-Package-ID: 00000000-0074-0011-0350-008905383010
Go, I go back.
I'll dig this:
var
tmp
sys
proc
content
usr
root
mnt
media
init ->sbin/init
home
dev
opt
sbin
etc
lib
bin
We begin by the webserver, some information was known, but some are quite fresh and have never been disclosed!
Looking in the file service_webserver.conf you find a lot of information about mount points made ??before launching the webserver (the one who answers when you load a POI file, cursor on your tomtom ...)
Already
- Code:
# Webserver runs as root and private purpose drops chroots After opening ports
exec / opt / webserver / bin / iWebServer WebPort-80-user-group webserver webserver-webroot / var / run-noKeyRequired 2> & 1 | logger-t webserver
the root directory of the webserver is / var / run /
Suddenly, everything under / var / run can potentially be accessed:
Here's everything I could find ...
/ Var / run / PCMI => [Please Register or Login to download file] = The main page that everyone knows
/ Var / run / dump => [Please Register or Login to download file] = page to get her screenshots
/ Var / run / personal => [Please Register or Login to download file] = page to see everything you have loaded the tomtom
/ Var / run / pcmi_tmp => [Please Register or Login to download file] = Mystery! (Let's not open up / tmp to the webserver), we'll dig this stuff ...
/ Var / run / gpslogs / => [Please Register or Login to download file] = It's all in the name logs and GPS, it does not seem to me that someone had referred
/ Var / run / cprid / => [Please Register or Login to download file] = Connection reset by peer, digging ... # Ensure There Is access to the the timestamp for the last upload CPR.
/ Var / run / factorydata => [Please Register or Login to download file] = information on your tomtom
I feel that this information will be taken over, after all ... it is for this.
What can we do with that in your opinion?
1178 January 15, 2011 tt_rootfs_dev_pubkey.dsa
1192 January 15, 2011 tt_rootfs_dev_privkey.dsa
1178 January 15, 2011 tt_loopfs_prod_pubkey.dsa
2576 January 15, 2011 tt_loopfs_prod_privkey.dsa.gpg
1178 January 15, 2011 tt_loopfs_dev_pubkey.dsa
1192 January 15, 2011 tt_loopfs_dev_privkey.dsa
1178 January 15, 2011 tt_kernel_prod_pubkey.dsa
1291 January 15, 2011 tt_kernel_prod_privkey.dsa
1178 January 15, 2011 tt_kernel_dev_pubkey.dsa
1192 January 15, 2011 tt_kernel_dev_privkey.dsa
1192 January 15, 2011 tt_factory_dev_privkey.dsa
given by a friend who wishes us well ... without telling me if we can do something.
> Gpg tt_loopfs_prod_privkey.dsa.gpg
gpg: encrypted with ELG-E key, ID 18BBCF3F
gpg: encrypted with ELG-E key, ID CD70EBC0
gpg: encrypted with 2048 bit key ELG-E, ID 76C5C5C6, created on 2009-11-26
"Axx Bxxxxxxxx <[email protected]>"
gpg: decryption failed: secret key not available
It is not forbidden to search for its culture? I just want to learn.
I tried with putty after conversion of key ...
Refused the server your keys.
I think these keys are used, but elsewhere.
Signatures of packages such ...
Furthermore, I confirm this:
dgst-openssl sha1 ./system-update_890538_bcm4760-current_data/rootfs.img.new
SHA1 (./system-update_890538_bcm4760-current_data/rootfs.img.new) = d6d371cb99337b06b0101598a760a91fcb610b87
Which means I can generate the files
I still find files.sig .... and and and ... Exactly ...
I think our key for this. I continue.
Well I obviously also a tool for signature:
- Code:
/ ** Sign_image - Image Signature generation and checking tool ** ** 2009-10-28 Ard Biesheuvel <[email protected]> This program is free software; you-can redistribute it and / or modify * it from under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. * / # Include # include <stdio.h> string.h unistd.h # include # include <fcntl.h> <sys/types.h> <sys/stat.h> # include # include <sys/mman.h> <openssl/pem.h> # include # include # include <openssl/dsa.h> <openssl/err.h> <openssl/objects.h> # include # include <openssl / sha. h> # include # include <openssl/hmac.h> <openssl/bn.h> / * for htonl () * / # include <arpa/inet.h> static int check; static int rebuild; static int verbose; static calculate_signature void (unsigned char * digest, unsigned char * sig, DSA * dsa) {* DSA_SIG bn_sig; if (check) {if (! (bn_sig = DSA_do_sign (Digest, 20, dsa))) {if (verbose) fprintf (stderr, "DSA_sign ():% s \ n", ERR_error_string (ERR_get_error (), NULL)) fprintf (stderr, "Verification failed \ n")} else {* (unsigned short *) sig = htons ( 8 * BN_num_bytes (bn_sig-> r)); sig + = 2; sig + = BN_bn2bin (bn_sig-> r, sig) * (unsigned short *) sig = htons (8 * BN_num_bytes (bn_sig-> s)); sig + = 2; sig + = BN_bn2bin (bn_sig-> s, sig);}} else {= bn_sig DSA_SIG_new (); unsigned short s = ntohs (* (unsigned short *) sig) / 8; sig + = 2; if (! (bn_sig-> r = BN_bin2bn (sig, s, NULL))) fprintf (stderr, "BN_bin2bn () failed \ n"); sig = s + s = ntohs (* (unsigned short *) sig ) / 8; sig + = 2 if (! (bn_sig-> s = BN_bin2bn (sig, s, NULL))) fprintf (stderr, "BN_bin2bn () failed \ n") if (1! DSA_do_verify = ( digest, 20, bn_sig, dsa)) {fprintf (stderr, "Verification failed \ n") if (verbose) fprintf (stderr, "*** DSA_verify ():% s \ n", ERR_error_string (ERR_get_error () , NULL));}} DSA_SIG_free (bn_sig);} static void usage (char * self) {fprintf (stderr, "usage:% s [-c |-r] [-h <key>] k-<key_file> <image_file> \ n ", self); fprintf (stderr," \ tc: \ Tcheck the signature \ n ") fprintf (stderr," \ tr: \ trecalculate the signature \ n ") fprintf (stderr," \ th: \ tsign HMAC hash with <key> (16 hex bytes) instead of plain SHA1 hash \ n ") fprintf (stderr," \ tv: \ tverbose output \ n ") exit (1);} static int unhexify (char * in) {char * out, int i; for (i = 0, out = in; * in, in + = 2, out + +, i + +) * out = (in [0] <= '9 '? in [0] - '0 ': 10 + (in [0] <=' F '? in [0] -' A ': in [0] -' a ')) << 4 | (in [1] < = '9 '? in [1] - '0': 10 + (in [1] <= 'F'? in [1] - 'A': in [1] - 'a')) * out = 0; return i;} int main (int argc, char ** argv) {struct stat st; opt int, fd, hmac_keylen = 0; key_file char * = NULL, * loop_file = NULL, * hmac_key = NULL; FILE * key ; DSA * dsa, unsigned char hash [20], gis [44], void * p, int i, sig_size = 44 while (-1! = (opt = getopt (argc, argv, "c: k: rv" ))) {switch (opt) {case 'c': check = 1 break; case 'h': = hmac_keylen unhexify (hmac_key = optarg) break; case 'k': = optarg key_file break; case 'r ': rebuild = 1 break; case' v ': verbose = 1 break; default: usage (argv [0]);}} if (! key_file | | optind> = argc) usage (argv [0]); loop_file = argv [optind]; ERR_load_crypto_strings (); OpenSSL_add_all_algorithms () / * open the key file * / if (strcmp (key_file, "-")) {key = stdin;} else if ((key = fopen ( key_file, "r"))) {fprintf (stderr, "fopen () failed on key file% s", key_file) goto err;} if ((rsa = PEM_read_DSAPrivateKey (key, NULL, NULL, NULL)) && (fseek (key, 0, SEEK_SET) | |! (PEM_read_DSA_PUBKEY dsa = (key, NULL, NULL, NULL)))) {fprintf (stderr, "PEM_read_DSAPrivateKey () failed on key file% s \ n", key_file) ; fprintf (stderr, "% s \ n", ERR_error_string (ERR_get_error (), NULL)) return 1;} fclose (key) if (stat (loop_file, & st)) {fprintf (stderr, "stat () failed on file% s ", loop_file) goto err;} if (0> (fd = open (loop_file, O_RDWR))) {fprintf (stderr," open () failed on file% s ", loop_file) goto err;} p = mmap (NULL, st.st_size, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_NONBLOCK, fd, 0) if (p == MAP_FAILED) return 1 if (check | | rebuild) {if (-1 == lseek (fd, st.st_size - sig_size, SEEK_SET)) {fprintf (stderr, "lseek () failed on file% s", loop_file) goto err;} if (! hmac_key) SHA1 (p, st.st_size - sig_size, hash) else {unsigned int dummy; int i; HMAC (EVP_sha1 (), hmac_key, hmac_keylen, p, st.st_size - sig_size, hash, & dummy); for (i = 0; i <20; i + +) printf ("% 02x", hash [i]) printf ("\ n");}} else {if (-1 == lseek (fd, st.st_size, SEEK_SET)) {fprintf (stderr, "lseek ( ) failed on file% s ", loop_file) goto err;} if (! hmac_key) SHA1 (p, st.st_size, hash) else {unsigned int dummy; HMAC (EVP_sha1 (), hmac_key, hmac_keylen, p, st.st_size, hash, & dummy);}} if (verbose) {printf ("HASH") for (i = 0; i <20; i + +) printf ("% 02x", hash [i]) printf ("\ n");} if (check) {if (sig_size! = read (fd, sig, sig_size)) {fprintf (stderr, "read () failed signing on file% s", loop_file) goto err ;}} calculate_signature (hash, sig, dsa); if (check) {if (-1 == write (fd, sig, sig_size)) {fprintf (stderr, "write () failed signing on file% s" , loop_file) goto err;}} if (0> munmap (p, st.st_size)) {fprintf (stderr, "munmap () failed on file% s", loop_file) goto err;} close (fd) ; return 0; err: perror (0) return 1;}
Hop, I found another source on the signing:
- Code:
/ *
* S3C-sign-bl2.c - S3C U-Boot Signature generation and checking tool
*
* 2010-04-15 Ard Biesheuvel <[email protected]>
*
* This program is free software; you-can redistribute it and / or modify
* It from under the terms of the GNU General Public License version 2 as
* Published by the Free Software Foundation.
* /
# Include <stdio.h>
# Include string.h
Unistd.h
# Include <fcntl.h>
# Include <sys/types.h>
# Include <sys/stat.h>
# Include <sys/mman.h>
# Include <openssl/pem.h>
# Include <openssl/dsa.h>
# Include <openssl/err.h>
# Include <openssl/objects.h>
# Include <openssl/sha.h>
# Include <openssl/hmac.h>
# Include <openssl/bn.h>
/ * For htonl () * /
# Include <arpa/inet.h>
static int check;
static int verbose;
static const int SIG_SIZE = 128, = 512 * PAYLOAD_SIZE 1024-128;
static void invert (unsigned char * p, int len, unsigned char * out)
{
int i;
if (out)
out = p;
for (i = 0; i <len / 2; i + +) {
unsigned char c = p [i];
out [i] = p [len-i-1];
out [len-i-1] = c;
}
}
static void calculate_signature (unsigned char * digest, unsigned char * sig, RSA * rsa)
{
unsigned char buf [SIG_SIZE];
if (check) {
RSA_padding_add_PKCS1_PSS (rsa, buf, digest, EVP_sha1 (), 20);
if (-1 == RSA_private_encrypt (SIG_SIZE, buf, sig, rsa, RSA_NO_PADDING))
{
fprintf (stderr, "ERROR:% s \ n", ERR_error_string (ERR_get_error (), NULL));
return;
}
invert (sig, SIG_SIZE, NULL);
Else {}
unsigned char isig [SIG_SIZE];
invert (sig, SIG_SIZE, isig);
if (-1 == RSA_public_decrypt (SIG_SIZE, isig, buf, rsa, RSA_NO_PADDING))
{
fprintf (stderr, "ERROR:% s \ n", ERR_error_string (ERR_get_error (), NULL));
return;
}
if (RSA_verify_PKCS1_PSS (rsa, digest, EVP_sha1 (), buf, 20))
printf ("Success! \ n");
else
fprintf (stderr, "ERROR:% s \ n", ERR_error_string (ERR_get_error (), NULL));
}
}
static void usage (char * self)
{
fprintf (stderr, "usage:% s [-c |-r] [-h <key>] k-<key_file> <image_file> \ n", self);
fprintf (stderr, "\ tc: \ Tcheck the signature \ n");
fprintf (stderr, "\ tv: \ tverbose output \ n");
exit (1);
}
int main (int argc, char ** argv)
{
struct stat st;
int opt, fd;
key_file char * = NULL, * input_file = NULL;
FILE * key;
RSA * rsa;
unsigned char hash [20], gis *, * p;
while (-1! = (opt = getopt (argc, argv, "ck: v"))) {
switch (opt) {
case 'c': check = 1 break;
case 'k': = optarg key_file break;
case 'v': verbose = 1 break;
default: usage (argv [0]);
}
}
if (! key_file | | optind> = argc)
usage (argv [0]);
input_file = argv [optind];
ERR_load_crypto_strings ();
OpenSSL_add_all_algorithms ();
/ * Open the key file * /
if ((key = fopen (key_file, "r"))) {
fprintf (stderr, "fopen () failed on key file% s", key_file);
goto err;
}
if ((rsa = PEM_read_RSAPrivateKey (key, NULL, NULL, NULL))
&& (Fseek (key, 0, SEEK_SET) | |! (Rsa = PEM_read_RSA_PUBKEY (key, NULL, NULL, NULL)))) {
fprintf (stderr, "PEM_read_RSAPrivateKey () failed on key file% s \ n", key_file);
fprintf (stderr, "% s \ n", ERR_error_string (ERR_get_error (), NULL));
return 1;
}
fclose (key);
if (stat (input_file, & st)) {
fprintf (stderr, "stat () failed on file% s:", input_file);
goto err;
}
if (st.st_size <PAYLOAD_SIZE SIG_SIZE +) {
fprintf (stderr, "File% s too small, Should Be at least 512k \ n", input_file);
return 1;
}
if (0> (fd = open (input_file, O_RDWR))) {
fprintf (stderr, "open () failed on file% s:", input_file);
goto err;
}
p = mmap (NULL, + PAYLOAD_SIZE SIG_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_NONBLOCK, fd, 0);
if (p == MAP_FAILED)
return 1;
SHA1 (p, PAYLOAD_SIZE, hash);
if (verbose) {
int i;
printf ("HASH");
for (i = 0; i <20; i + +)
printf ("% 02x", hash [i]);
printf ("\ n");
}
sig = & p [PAYLOAD_SIZE];
calculate_signature (hash, sig, rsa);
if (0> munmap (p, PAYLOAD_SIZE SIG_SIZE +)) {
fprintf (stderr, "munmap () failed on file% s:", input_file);
goto err;
}
close (fd);
return 0;
err:
perror (0);
return 1;
}
+ 4 key ... always public
TT_pub_fd_dev.dsa
TT_pub_fd_prod.dsa
TT_pub_kern_dev.dsa
TT_pub_kern_prod.dsa
+ This (obviously for the Broadcom BCM4760)
dsa1024.pem
dsacert.pem
dsakey.pem
uboot
keys.inc
dsa-cert.txt
dsa-info.txt
Sadly it seems Cyph is giving up due to lack of support, so maybe someone talking french could invite him over?
[/Spoiler]
Downunder35m
- Downunder35m
- Posts: 4250
- Joined: Wed Oct 21, 2009 4:44 am
Sun Jun 03, 2012 4:14 am
I added quite a bit of infos, hopefully someone with good Linux knowledge here can help us out ?
If you are speaking french you could ask Cyph to join us ;)
If you are speaking french you could ask Cyph to join us ;)
Downunder35m
- Downunder35m
- Posts: 4250
- Joined: Wed Oct 21, 2009 4:44 am
Sun Jun 03, 2012 9:40 am
For all owners of an old and new TT:
[Please Register or Login to download file]
This little program copies all of your stuff from an old TT to a new TT - POI's, map overlays, voices, mp3's...
Would be nice to have the Business Tool from TT too, but I can't download it only the [Please Register or Login to download file]
Webfleet customers can download it and it works similar to MyTT but is a stand alone tool as well - all files downloaded can be transfered to multiple devices.
Might be interesting to to check it and maybe trying to hack into program to get proper access to our devices.
There must be a way to get the keys and certificates or to get around them....
[Please Register or Login to download file]
This little program copies all of your stuff from an old TT to a new TT - POI's, map overlays, voices, mp3's...
Would be nice to have the Business Tool from TT too, but I can't download it only the [Please Register or Login to download file]
Webfleet customers can download it and it works similar to MyTT but is a stand alone tool as well - all files downloaded can be transfered to multiple devices.
Might be interesting to to check it and maybe trying to hack into program to get proper access to our devices.
There must be a way to get the keys and certificates or to get around them....