When generating the MD5 using -z index,name the tool would add the entry but
forgot to increase the file size, hence truncating the file.
Change-Id: Ibd3c594722ab46350cda60d158666fe34a96e922
When compressing, it is possible to tell the tool to add an entry to the MD5
file (index 1), it is still necessary to give an empty file for that index.
To do so, pass the option "-z idx,name" insteas of "-z idx". This will create
an entry of the form "size md5 name". For instance "-z 6,system.img".
When decompressing, if one passes "-z idx,name" instead of "-z idx", the tool
will decompress and check against the value in the MD5 file.
Change-Id: Ifb945f6121644ae9105265d2d83ce6067301c5b2
To decompress some output file(s), simply pass -z <idx> where idx is the index
of the file to decompress, starting from 0. For example
upgtool -e NW_WM_FW.UPG -o tmp/ -m nw-wm1a -z 6 -z 7
to decompress files 6 and 7. To compress file, use the same options:
upgtool -c NW_WM_FW.UPG -m nw-wm1a -z 2 script.sh md5sum.txt system.img
Change-Id: I1ef0b3e02c98e58154f1a959fb1ad70ad2ce6500
In order to avoid the crypto++ mess, the code uses the Windows Cryptography API,
which is standard. There is also some makefile magic to cross-compile:
make PREFIX=i686-w64-mingw32- EXE_EXT=.exe
I selected the option so that it should statically link supports libraries used
by gcc (slsj and libwinpthread).
Change-Id: Iaf07da23afe81ed217fb3921ce13367c5441514d
The new code supports reading and writing UPG files. I kept the old keysig
search code but it only supports the old format (the new format has too long
keys anyway). Since we now have to support two types of encryption(DES and AES),
I reorganized the crypto routines and clean-up some code.
Change-Id: Ie9be220ec2431ec6d0bd11699fa0493b62e1cec2
Split WM1A/WM1Z because they don't have the same KAS. On newer devices, the KAS
is actually 64 bytes, not 60. The strange thing is that "get_dnk_nvp kas" returns
60 bytes whereas "get_dnk_prop kas" returns 64, not sure why.
Change-Id: I944d3d838209ba58388439af0cdf5d7c74f1f7fc
At least newer devices support more NVP properties in a device-independent
numbering. Many are supported but I just added two useful ones
Change-Id: I57926de7f0dd364b46a57ca8d48a5c4d4f20402b
Seems like newer versions of mingw will sponteanously add a .exe suffix to
the output path if it doesn't have one, for example mingw-gcc -o scsitool bla
will actually create scsitool.exe and of course this breaks my release script.
Fix this by explicitely adding the .exe to avoid any problem
Change-Id: Ic8019b968b532b2ca612ba0c03977a96c22cee01
This is one of those fancy gold-plated devices. Of course it breaks my scripts
that were nicely expecting every device to start with NW.
Change-Id: I161320f620f65f4f92c2650d192b26a9831eeb9d
There is something weird going on: the Sony website has two different entries:
- NW-ZX300/NW-ZX300A/NW-A45/NW-A47/NW-A45HN/NW-A46HN
- NW-ZX300,NW-ZX300A update(20181004)/NW-ZX300G
with slightly different nvp entries, but it is impossible to tell whether
an NW-ZX300(A) belong to one or the other. Since the diff is very small,
I am adding this as nw-zx300g but treat all devices as nz-zx300 since the
destination node is the same and that is the main usage of the tool anyway.
Change-Id: I3dc2fdec52650f938d568bed578184f6bc43d130
If the model is not known (ie model ID in the database) but another device from
the same series is known, then the database information probably applies and
one can use the "force" option -s to tell the tool to ignore the model ID.
Automatically print such advice when the series can be guessed.
Change-Id: I6bcc7aa29693df8c3d7d8e709ece7cea650be717
Now print list of devices immediately even if the rest of the command line
is empty (ie 'scsitool -s ?' works, whereas before one would need an actual
device to even get a list). Add more information in the help_us command:
print kas, lyr and fpi.
Change-Id: Icfeeaeebe28c774a74ca54661357fafa25c3d114
