Related
hi,
I need to create a shortcut to a file or folder using eVC++ 4.0, anybody knows how to do this??
Thaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaanx alot
Mohammad
It's very easy:
Just create a file (with lnk extension)
and write to it:
10#"my_app.exe" -launch
this is what it means:
10 - length of the string after #. This value doesn't have to be accurate because it is usually ignored.
"my_app.exe" - path and name of the target of the shortcut.
-launch - command line parameters (if you have any)
You can also add: ?incon.exe,0 to take an icon from another exe / dll
Thaaaaaaaaaaaaaaank you very very much,
but I need a small thing, could you please provide me with a complex example so I can understand all features supported for shortcuts.
Thank you again,
Mohammad
Mo.
A number of us have posted about the structure of the .lnk file.
Search against my username for the word completeness.
V
now, I searched and got how the thing works, but I have a problem with coding this stuff:
When I attemp to write to shortcut file like this:
strData.Format(_T("%d#\"%s\""),strFilename.GetLength(), element.strPathname);
ShortcutFile.Write(strData,strData.GetLength()*2);
The file is not written correctly, what I get is the data I wrote in the file with a square charecter after each letter like this:
#□4□0□"□\□S□t□o□r□a□g□e□ □C□a□r□d□\□M□y□P□r□o□g□r□a□m□.□E□x□e□"□
so how can I solve this? and does it relate to unicode?
That's because you are trying to write it in UNICODE. This adds zero to every byte.
You must use fopen, fprintf, fclose functions or just create an array of char and use FileWrite to create an ASCII text file.
Thanks levenum,
but isn't windows ce file system unicode based? if so, how can I use ASCII format to write unicode filenames?
Thanks alot
Mohammad
#include <Oleauto.h>
......
char convertUshortToChar(unsigned short in)
{
char con='\0';
VarI1FromUI2(in,&con);
return con;
}
and add Oleaut32.lib to the list of object/library moduals in you project settings.
just call that for each unicode character that you want to be ascii and write the result to file.
Two things:
a) The file system may be UNICODE, but shortcuts are ASCII text. Also ASCII functions like fopen are supported.
b) There is a much easier way to convert UNICODE to ASCII:
mbstowcs(unicodeStrBuffer, asciiStrBuffer);
OK, I did it, but I think that there is a problem with Windows mobile, and it is a big problem.
Till now, I beleive that you cannot create a shortcut to a unicode-named file, I failed to do that, File explorer was not successful, Resco Explorer was not better.
Worse, they do not tell you that you cant create the shortcut, they create the shortcut for you and when you try to open it they conclude that the path was not found!!.
Very bad huh?
Mohammad
I thought that all file names are in unicode?? Use my shortcut creator in GSMbeam file open dialog to try and make a shortcut to a file named like you said. If that shortcut dose not work send me the file in question and I will try and see whats going on.
Ok, I downloaded your program and tried to create a shortcut for an arabic-named file, simply it did not work.
I know its not a bug in ur program, its a bug in Windows Mobile, it is mainly a bug in the design itself, how does Micro$oft design windows mobile to be unicode based while non-ascii characters are not supported in the shell links, its really a shame.
You can be sure that this will happen with asian characters along with Farsi, Hebrew, Arabic and all non-ascii characters.
Programmatically, what happens is as follows:
1. A program converts a filename from unicode to ASCII to save it in the .lnk file.
2. If the file name contains non-ASCII characters, those will be converted to NULL character.
3. When the shell tries to resolve the link target it does not recognise the filename because some characters are NULL.
Thats what I found out!!
Take this file name for example (Arabic): 2مرحبا.mp3
Try to solve the issue, and please inform us whatever happens with you..
Best Regards,
Mohammad
So the problem is how to get the shell to read unicode in lnk files. I re-wrote a lnk file in unicode to see if it would work but it would not. There are a lot of non english ppc users, surely this problem has come up before?
As an experiment I also made shortcut to a folder using utf-8, I think that contains arabic characters and also the ascii characters. After removing some garbage that my editor put at the front of the lnk file worked fine. Try making a shortcut in notepad and saving it as a utf-8 file then rename it on your device but make sure there is no extra characters.
أنا قادر على أكل الزجاج و هذا لا يؤلمني. -- I think those characters are arabic and they are copied of a utf-8 table site so if the shell can read a utf-8 lnk that contains english letters then maybe it can do the arabic too.
Actually, non English UNICODE characters are translated in to extended ASCII codes (128 - 255). When the system needs to translate these codes back to UNICODE it relies on code page definitions in the wince.nls file.
If your locale is properly set to Arabic and you have a valid nls installed (ether you have Arabic ROM or some sort of Arabic language support installed) you should be able to reference Arabic file names using ASCII links.
So, can I depend on string conversion functions we discussed before in this topic to convert characters according to my code page?
I have an arabic ROM installed on my Wizard, it is the i-mate rom on O2 device, so the arabizer doesnt work well, may be because the serial number of the O2 device.
Anyway, I should invistigate this issue on my friend's JamIn device, and we should come up with a workaround for this wiered problem.
Regards all,
Mohammad
OK,
I have tried creating a shortcut on my friend's arabic-enabled JamIn device, the shortcut refers to arabic-named file and it worked good.
levenum, you are right, it depends on the code page on each device, so your device will not be able to create a shortcut to an arabic named file.
Mohammad
I was trying to cook a modded ROM for the i607, I was able to extract the nb0 from the bin file using cvrtbin & viewbin > then Mamaich's prepare_imgfs > viewimgfs > dump > modify/add/delete files > buildimgfs > makeimgfs and I know this is basically what you do with the Hermes ROM, however making it back to a BIN file has proven to be a "no go". I have tried splitrom.pl, rommaster, xipbin, etc, but I am afraid without the right utility this will not happen.
Does anybody know if there is a Tool to convert the cooked nb0 back into WMx B000F bin file? There is an old tool for Mobilpro xipbin.exe, however the block size and lenght of ROM does not match. Doing the splitting in sectors and retrieving the checksum manually is going to take a lifetime...
Just an idea: Could it be possible to use a blank CE.BIB with only the start and offset of the ROM and romimage from MS PB builder together with the nb0 file above?
Any good ideas are welcome.
I tried using romimage with no results
I tried to use Romimage from MS platform builder, and after many attempts I gave up. I basically used a minimal CE.BIB and the patched ROM (nb0) file as the source to be inserted. It creates the Run-time BIN file with 4K blocks where it should be making it 128Kb ones.
TO Do:
Try an HEX editor with macro or script capabilities, to perform the following process
1.- Strip the HEADER+RECORD section from the original FLASH file
2.- Strip all zeroes preceding the patched ROM (NB0) before the start point
3.- Cut the patched ROM in 128K chunks (about 500 pieces) called blocks or records
4.- Calculate the Checksum 32 of everyone of these chunks and annotate it
5.- Make the HEADER of the RECORD annotating (in little endian) : Start Address - Lenght(Block Size) - Checksum 32 for every record
6.- Join the HEADER to the respective record. Iterate this process until finished (some 500 times)
7.- Insert the above joined (HEADER+RECORD) section into the stripped flash file in step 1
8.- Here comes the scary part : flash the phone with this MOD (just the PDA section)
9.- If successful, make a program to automate steps 1 to 7
Wish me good luck...
On other comment: according to Texas Instruments, in the Code Composer Studio for OMAP processors, it can be connected to the phone via a COM port using HyperTerminal. Alternatively I think if we can flash the phone using this method and a ROM type NB0.... Perhaps no, as the flash program just connects to the phone using the Serial port qhen in Flash mode. This program also accepts img files, I tried to rename the nb0 file to img and didn't work. Does anybody know what these Samsung's img files are?
Is anybody interested on this matter? Please don't just read the post, start replying... If we really want to MOD this phone, being it the BlackJack i607 or the European i600, we need to start doing some Reverse Engineering..., the people at xda-developers had started this way to master the HTC and similars.
hey, i replied to your email. hope it will be helpful. especially if you give me a link to the image
cmonex said:
hey, i replied to your email. hope it will be helpful. especially if you give me a link to the image
Click to expand...
Click to collapse
Thank-you, however I haven't received your reply yet. I'll send you the link to the ROMS via private message .
Regards,
trinca
The modded ROM
Cmonex:
I have uploaded the modded ROM and is located at:
http://rapi*****/files/42779528/XXGD1_pda.nb0.html
******************W A R N I N G *********************
For everybody else following the thread, please be advised
this above file is a plain binary, it must be converted to a
MS WMx BIN format with a B000FF header before flashing any BJ.
Please do not attempt to flash your phone with it!
**************************************************
I haven't received your e-mail
cmonex said:
hey, i replied to your email. hope it will be helpful. especially if you give me a link to the image
Click to expand...
Click to collapse
Hi, Cmonex:
Can you please resubmit?
TKS
trinca
For those of you who would like to start cooking this ROM
I was able to extract the plain image using cvrtbin (MS tool that comes with visual studio) you may grab a copy from here:
http://www.toradex.com/colibri_downloads/Linux/linux_to_wince/?D=D
Then you will be able to use the common tools from xda-developers such as prepare_imgfs (with the switch -acer) from the WM5 kitchen made by itsme (first sticky in this forum) and so on.
Making the ROM back to the B000FF format is going to be the trouble... So far there is not an easy come back... yet!
There is also an excellent article on Mobilepro BIN roms made by cmonex, you can get a copy of that tutorial inside his Romtool package, get it from here:
http://hpcmonex.net/nec900/files/releases/romtoolpack.zip
Be informed the Mobilepro ROM is very different in the way the Runtime file is organized, however the tutorial is the best resource I have seen so far.
Besides, there are some really good tools inside that package
Best regards and start cooking!
trinca
Samsung i60x ROM: Extracting the OS payload from the Upgrader exe single file
The Upgrader program contains 3 payloads: Eboot, Phone and O/S. To extract the O/S payload follow this procedure:
1. Open the exe upgrader file using the Hex editor of your choice.
2. Locate the ASCII string B000F followed by 0x0A. The complete sequence you should look for is 0x4230303046460A. You should find 3 occurrences of the above string. Concentrate on the last one.
3. Copy from this start address all the way up to the string 0x060000EA3B, which is the start of the phone ROM.
4. Make sure your cut includes 12 trailing zeroes 0x000000000000 as they indicate the loader the end of the Runtime of the pda image.
5. Name your file ending with a bin extension. (i.e XXGD1_pda.bin)
6. Proceed with cvrtbin to extract the absolute (or plain) ROM image (ending in nb0.
7. You are ready to start cooking.
I was able to sucessfuly extract in this way the ROMS for i600 releases: XXGC6 and XXGD1 and for i607: UCGB4 and UCGD2.
How did I find out? I got the chance of getting the XXGC6 upgrade package, which included the eboot, phone and pda sections separated. Further reading in the forums indicated the B000FF is followed by 0x0A, the start address of the ROM (00000000) and the end address. From there it was easy to locate the payloads in the Upgrader single exe file.
Good luck extracting your ROMS.
Samsung i607 Service Manual
Below is the link for the SGH-i600 service manual URL. Does anybody have the service manual and/or schematics for the SGH-i607?
BIN B000FF runtime image file format
Does anybody have a detailed description of the arrangement of headers and records in this file format? The best reference I have found is this page:
http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=60&MAEULNO=23&no=242&page=1
Unfortunately I do not understand Korean...
hey, i again sent you an email. i'll quote it in PM too just to be sure.
btw, the rom tutorial that i wrote and that you linked to, fully details B000FF format. what is not clear about it?
The tutorial is right
There is nothing wrong with your tutorial, I had to use the HEX editor several times until I got that right.
cmonex said:
hey, i again sent you an email. i'll quote it in PM too just to be sure.
Click to expand...
Click to collapse
Do you know if isotherm may share the source code for xipbin? Do you have a way to contact him? I tried to contact him at hpcfactor with no results.
Trinca - ok, let's imagine you got all the needed files to B000F format. How do you plan flash it back to your i607?
Creating the B000FF Runtime image
After cooking the ROM...how to re-create the B000FF Runtime image back? That is the $1M.. question, I am still navigating uncharted waters...
Producing the Flashable runtime image back is what I am now concentrating on, as I see it there may be 4 possible ways:
1) Manually
-a) Splitting the nb0 file in [n] 128KB chunks (for a ~64MB image, there are over 500 x 128KB chunks)
-b) adding the chksum32 at the beginning of each chunk
-c) adding the address and offset to the beginning of the above.
-d) merging it all together
-e) adding B000FF, start address and offset at the beginning of the merged files
You can use an Hex editor with scripting properties such as 010Editor and write a script to accommodate a) thru e)
http://www.sweetscape.com/010editor/
Still a pain in the neck and the scripting language is similar to C, if you know this language it will be easy for you to automate the above. Still experimenting with it.
2) Using XIPBIN, made by somebody AKA isotherm, this utility will make a B000FF runtime file good for a HP/NEC mobilepro, the record length is made 0x40000 bytes long, different from 0x1FFE0 record length of the original ROM, according to cmonex, this should not be a problem provided the record is made of different length and has the right checksum per record, but I already have made several attempts and it does not work for me, when flashing the phone it gets stuck at the very beginning. You may research further here.
3) Modify xipbin and make it produce records 0x0001FFE0 bytes long, as the source code for this utility is not available, cmonex says isotherm had disappear. I am still hacking into this utility...
4) Create our own program using VC or VB, I may probably work on this one as well, as I get some time available.
I am attaching a copy of xipbin.exe, however if you have followed my instructions, you may probably have it already, please let me know of any success (or failure, we all learn from these ones too).
usage:
xipbin [myrom.nb0] [start address for myrom.nb0] [myrom.bin] [start address for myrom.bin]
For Samsung's B000FF ROMs the command will look like:
xipbin myrom.nb0 0 myrom.bin 0
myrom.bin is then recreated from scratch.
Also according to cmonex, you may do the following:
a) Get an original B000FF ROM
b) use cvrtbin.exe and obtain a nb0 ROM
c) use xipbin with this nb0 and re-create a runtime bin file.
d) apply again this cvrtbin utility to the re-created runtime bin file
e) compare the result with above b) step
f) If they match you may have a candidate procedure, if they don't do not attempt to flash the phone with the procedure above.
I will include the new viewbin and cvrtbin, which now works with start address 0 on this type of ROMs
Usage:
cvrtbin -r -a [start address] -l [length of ROM] -w [8, 16 or 32] [romfile.bin]
cvrtbin -r -a 0 -l [the length of your ROM] -W 32 [myrom.bin]
Good luck!
The format of MS BIN B000FF runtime image file
According to several sources I have consulted, including MS documentation and insights given by cmonex, plus heavy HEX editing sessions, this is my impression on how the B000FF Runtime image format looks like:
Byte------>--1--2--3--4--5--6--7--8--9--A--B--C--D--E--F
Record 0 -> 42-30-30-30-46-46-0A--<Strt add>--<ROM lgth> * * * * * * * * * * * (42-30-30-30-46-46 = B000FF in ASCII ; 0x0A = end of header B000FF)
Byte------>--1--2--3--4--5--6--7--8--9--A--B--C--<-----128KB of nb0 image------>
Record 1 ->--<Strt Add>--<Rec lgth>--<CHKSUM32>--<--Chunk Nbr 1 of nb0 image--->
Record 2 ->--<Strt Add>--<Rec lgth>--<CHKSUM32>--<--Chunk Nbr 2 of nb0 image--->
v - v
v - v
v - v
Record n-1>--<Strt Add>--<Rec lgth>--<CHKSUM32>--<---Last chunk of nb0 image--->
Last Rec-->-00-00-00-00-00-00-00-00-00-00-00-00 .* * * * * * * * * * * * * * * (The last record always ends with 12 bytes set to 0x0)
**************************************
Please note:
Record 0 and the last one are different
All data are encoded Little Endian!
**************************************
Using the command:
viewbin -r [myrom.bin]
Will give you the record content of your runtime image file.
Trinca - just ran viewbin on samsung i750 image. chunks sizes are not 128kb each. looks like chunks are actually files from ROM in XIP format (executable in place, it is usual PE files but missing reloc table and something else). I bet we should use file deleting/adding/injecting utility like romtools one for ROM image manipulation which reamins intact B000F header! I see no other way to recreate B000F.
Well, I guess your runtime differs from that on the i60x. In any case I know of a tool made by bepe the name of xipport, you can look at this thread and download it here:
http://forum.xda-developers.com/showthread.php?t=315030
The best thing I can recommend you to do, is to try to get the appropriate format of your runtime image.
trinca
unfortunately all version of xipport just crash with errors on my ROM dump.
ROm Dump
JugglerLKR:
Let's get acquainted with your procedure, and do not pretend to modify something, just to find out if the tools work:
a) Have you dumped the ROM from the phone or you just extracted it from the updater executable?
b) If you have just cut the ROM out of the executable, use the new cvrtbin posted before (which runs fine at start address 0)
c) Run Mamaich's prepare_imgfs, there are 3 possible options:
prepare_imgfs [yourROM.bin] will produce imgfs_raw_data.bin and imgfs_removed_data.bin
prepare_imgfs [yourROM.bin] -nosplit will produce imgfs_raw_data.bin and an empty imgfs_removed_data.bin
prepare_imgfs [yourROM.bin] -acer will produce imgfs_raw_data.bin and an empty imgfs_removed_data.bin, but this one is the only which has worked for the i60x
d) Now if you use viewimgfs then the dump directory will be created and the files will be extracted. It is only after this confirmation you may be assured the ROM extracted has the correct structure for manipulation. I got so much trouble using the old version of cvrtbin, that I am telling you to run these extra steps.
Now try to run the xipport tool on the above *.nb0 file. and tell us if you were successful. At this point if you are not able to run the xipport tool, then you may not have something usable. RomMaster and dumprom/dumpromx are also alternatives for working with xip modules, please remember all these tools are highly experimental and not bug-free!
trinca
With this tool you can lookup CodeSnippets on the Go! Just add them to the Access Database, convert it with the included tool "Code Snippet Creator" and copy it to your Device and start "Code Snippet Viewer"
The Viewer is Tested on my Stock HTC Kaiser - But it should run on any Touchscreen powered WM Device with netcfv2
Code:
Code Snippet Viewer v0.5.1
---
1. Copy the "Release" dir on your Windows Mobile Device with .NETcf2
2. Run "CodeSnippetViewer.exe" on Device
- Version 0.5.1
.Fix
- Version 0.5.0
.Release
Code:
Code Snippet Creator v0.5.0
---
1. Run "csviewer.exe" on Desktop PC
2. Press "Create Database" Button to create "CodeSnippets.txt"
3. Copy "CodeSnippets.txt" to your Device, where "CodeSnippetViewer.exe" is located
The Snippets are read out of the "CodeSnippets.mdb", feel free to add your Snippets there, and Post it on XDA-Developers
- Version 0.5.0
.Release
Download
http://www.scilor.com/codesnippets.html
If you have suggestions to improve this, just post it here!
Space Holder for additional things later on
WOW.. very interessting and helpfull Prog thank you
No Problem, if you have suggestions post it here
what is it for?
sorry for this question im just a newbie,
when i see it right r u german, so pm me pls in german if u can THX!
Ok I don't know exactly what this is for? I wish I did because it looks intriguing.
so what is it for now? can anybody describe it please?
You can create an Access Database for Code Snippets or other things you need to access on the go
then you can convert it and upload it to you phone
Website Added:
http://scilor.sc.funpic.de/codesnippets.html
i have tested your app. but it doesnt work. when i use your sample files, it works, but when i generate a new txt from my mdb, there is an error starting the app. ArgumentOutOfRangeException
here is my exported *.txt. I love this program. great work. i try to sync the mdb with a mysql db in the the net. so i can add new snippets online and sync them back to the device.... i have a cms on my website, where i have some modules which i can use for this. it works also with syntax highligtning (on the net) for some of the programming languages.
Thank you for your feedback, but I have the problem, that it doesnt works in the emulator anymore, I do not know why, it worked before xD
I'll If I can find teh problem.
NEW VERSION
Problem should be fixed!
many thx. i will try this @home, because i am now @work i will try to make an exporter with PHP for my online version to, when i have it done, i can mail them to you. this exporter should be easy to code. i can also make an importer, so that you can import a textfile.
the next idea could it be, that you mobile can add a new recordset with a new snippet, so the sync ist complete... but this only an idea by me...
Here you have the needed code for exporting from SQL to textfile (Routine from the Creator):
I have stripped it down just to show the important things
Code:
oRS.Open "SELECT * FROM CodeSnippets ORDER BY ProgrammingLanguage ASC, Category ASC, UnderCategory ASC", oConn, adOpenKeyset
oRS.MoveFirst
txtData = oRS.RecordCount & vbNewLine
For I = 1 To oRS.RecordCount
TempData = oRS.Fields("ID").Value & ">{.+.}<" & _
oRS.Fields("ProgrammingLanguage").Value & ">{.+.}<" & _
oRS.Fields("Category").Value & ">{.+.}<" & _
oRS.Fields("UnderCategory").Value & ">{.+.}<" & _
oRS.Fields("Snippet").Value
txtData = txtData & Replace(TempData, vbNewLine, ".>-NewLine-<.") & vbNewLine
'This Replaces all linebreaks in the Tempdata and attaches it to txtData and also adds a line break afterwards
oRS.MoveNext
DoEvents
Next
oRS.Close
oConn.Close
Call frmViewer.txt_WriteAll(PathTo & "CodeSnippets.txt", txtData)
Here Is a php I wrote from sketch without testing:
Code:
'Connect to the DB first
$newLine = '
';
'Sry that is a new line I do know if "\n" works instead
$SQLString = "SELECT * FROM CodeSnippets ORDER BY ProgrammingLanguage ASC, Category ASC, UnderCategory ASC";
if ($SQLAnswer = mysql_query($SQLString))
{
$txtData = mysql_num_rows($SQLAnswer).$newLine;
while($row = mysql_fetch_object($SQLAnswer))
{
$TempData = $row->ID.'>{.+.}<';
$TempData .= $row->ProgrammingLanguage.'>{.+.}<';
$TempData .= $row->Category.'>{.+.}<';
$TempData .= $row->UnderCategory.'>{.+.}<';
$TempData .= $row->Snippet;
$txtData .= $newLine.str_replace('.>-NewLine-<.', $newLine, $TempData).$newLine;
}
}
'Write $txtData to a File!
yes this should do the job. i will try it at the weekend. many thx
the rapidshare link show the old version. Can you please update the file or the link?
i have done the online version. there is a *.sql file included, this generates the needed MySQL tables. Also there is a slightly modified *.mdb. i have only modified the Formular.
next there are the needed php an html files for the webserver. the html file is a template, so anyone can modify it.
Update:
i have done some Additions. Included is now EditArea a OpenSource Syntax Highlightning Script. Also i have added a new version of the SQL table, since there is a new field "highlight", this is only for the JavaScript, this field will not be exported in any way.
Now you can manualy add a ProgrammingLanguage or Category by the textfield OR you can choose one from existing Selectbox.
The last time i have forgotten to say, that you must configure the MySQL connection in the common.php. have a look at the following block and put in the right values:
Code:
define("DATABASE_NAME","");
define("DATABASE_USER","");
define("DATABASE_PASSWORD","");
define("DATABASE_HOST","");
Sorry, made a mistake on my website, now it points to the new version
there is no new *.exe file in the zip :-( the directory contains only some txt files :-( please reupload the file.
Sry, here it is again.
Had a problem with my packer
I'm proud to present a new version of tgtool with repack support.
I want to tank cotulla (DES) and viperbjk (PSAS), without their work this would not be possible.
WARNING: THIS TOOL IS UNTESTED. NOBODY KNOWS WHAT WILL HAPPEN
WARNING: FLASHING A ROM CREATED WITH THIS TOOL CAN BRICK YOUR PHONE
WARNING: FLASHING A ROM CREATED WITH THIS TOOL MAY VOID WARRANTY
WARNING: YOU ARE ASSUMING FULL RESPONSIBILITY FROM USING THIS TOOL
WARNING: WARNING WARNING WARNING
if you use this tool you use it on your own risk, i am not responsible if anything bad happens but strongly hope YOU ARE responsible and know what you are doing
Da Mafia has flashed a rebuild but unmodified rom and phone works.
Da Mafia has did it again and again, because of him we know we are now close of having a custom ROM so a big THANK YOU for risking your phone for us.
Novembre5 has flashed a 6.5.5 ROM that didn't booted, he has successfully recovered the phone using pin method.
Changes:
1.3.20
- added -tg01
- added -t01a
1.3.19
- fixed bad unk0 in WMB3
- extra checks for -chk (partition signatures, length of rom, lenght of payload)
- repack/merge now automatically checks resulting rom
- added -dci to display catalog informations
1.3.18
- added repack support
Example to check a rom file:
Code:
tgtool -chk TG01WP_5005000176.tsw
Example decrypt a rom file:
Code:
tgtool -dec TG01WP_5005000176.tsw tg01.bin
Example to extract payload from rom file:
Code:
tgtool -sp tg01.bin tg01.os.payload
Example to insert a payload in a rom file:
Code:
tgtool -mp tg01.os.payload tg01.bin tg01-new.bin
OR
Code:
tgtool -mp tg01.os.payload tg01.bin tg01-new.tsw
Copy note:
It is required for whomever uses this software and releases a ROM created with it to distribute a copy of the software and this copy note with released rom so rom integrity can be checked.
It is required for whomever uses this software and releases a ROM created with it to state that this software is a key part in building that ROM and that the ROM could not have been created without it.
It is required for whomever uses this software and releases a ROM created with it to test the ROM and make sure it is working.
It is required to inform potential users that ROM created with this software can permanently and irremediably damage the phone.
This software is provided as it is without any warranty of any kind, express or implied, not even that it does anything useful.
best wishes
cedesmith
FLASHING AND RECOVERY
Don't use sddl+, use short pin method, as stepw(autor of sddl+) stated here "Now that entering SD download mode via shorting pins became public, SDDL+ is obsolete.". shorting pins is toshiba intended and tested mode to enter downloader mode and seams a little safer then sddl+.
There is info that short pin method accepts .bin files.
To skip language check (SD Downloading failed. varient is invalid!!) rename .tsw to .enc
To enter downloader mode bridge pin 1 and 3 and press reset. release reset and keep bridge for few seconds. DO NOT PRESS RESET AGAIN. check screen and see what happens.
Secure your battery with duct tape it can drop very easy. If you use short pin method it can drop while you turn phone with screen up. Since you will turn phone just after you reset it will be flashing bootloader and and phone will be bricked for ever.
read more and make sure you know what are you doing
picture is from 1st thread i found about short pin unfortunately i can remember where that is. if you can point me to it i would link it here.
during split of payload you will nice
Code:
Part 00 OS 00000273-0000078E (050F4000-0F98FFFF)
NOOPBlock 0017CA90-0018C210
NOOPBlock 004CD610-0056A210
NOOPBlock 0928E8D0-0A584210
NOOPBlock 0A6A5650-0A6AD000
this is because these blocks are filled with 0xFF, they have all data 0xFF, ecc 0xFF, sector number 0xFF and partition flag 0xFF.
i think that these blocks are to be ignored by download tool. the fact that SIM_SECURE catalog entry is all filled with 0xFF strengthens that belief.
if you follow my examples and you compare tg01.bin with tg01-new.bin you will notice that the files are almost identical.
they are not perfect equal because once dumped extra data like sector number and partition flag is lost and is no way to know if block is full of 0xFF or not to be flashed (NOOP).
i think that NOOP blocks are there because partitions start at flash block boundaries limit so there is some extra space in partition that is not used and does not mater what is in it so is not overwritten by flash process.
THIS IS ALL SUPPOSITION.
on merge content of original rom is preserved till WMB1 EXCEPT file header witch i assume is not flashed. in this header only catalog table entries for WMB1 WMB2 and WMB3 are modified.
i think that if rom will not boot short pin method may be able to flash original rom as part till OS is preserved.
-dec on new .tsw file and file compare with original to make sure they match till OS start 0x050F4000 in the example above
don't take chances unless you know what are you doing and you triple checked. this is untested stuff and may contain bugs
***reserved***
congratulations cedemish, we are very pround of you. I hope we all can start to develop ROM's properly. Thank you for all your effort!
Just one question, is there any way for testing the rom package like you tried to do in your first release?
yeaaahhhhhhhhhhh!!!.........
Do you think we can flash now costum roms??????
did someone try it??
arag0n85 said:
Just one question, is there any way for testing the rom package like you tried to do in your first release?
Click to expand...
Click to collapse
sure
Code:
tgtool -chk tg01-new.bin
TGTool v1.3.18 copyright(c) 2010 cedesmith
Checking tg01-new.bin has completed without warnings
but keep in mind that it checks only for things i know and i observed in official roms.
is no guarantee that will not brick the phone but if it fails it raises big question marks
Hamido123 said:
yeaaahhhhhhhhhhh!!!.........
Do you think we can flash now costum roms??????
did someone try it??
Click to expand...
Click to collapse
i hope we will have custom roms. i didn't have the guts to try it. i hope you don't either.
have patience and don't do something stupid
WOW, good work!
Yihaaa, soon we'll have cooked room, thanks to you!
suberb work done, hopefully donations will follow
Thanks cedesmith!
This is a milestone in the Rom development for our TG01.
We're now able to create custom Roms. And I'm sure, that someone will try this very soon and will tell us, that he flashed a WM6.5.3 without problems
I'll wait until hdubli creates a Rom. I trust him and he said, that he is sure, that he's able to boot WM6.5.3.
Hope you get more donations. I donated directly on the first day you placed the link in your signature. (ID: 7M1172384A419273S)
Best regards,
Manuel
I got one question cedesmith.
I can remind me that hdubli said, that we need to change the XIP also and not only the payload in order to get WM6.5.3 working.
But for me it seems, that it's only possible to customize the payload and then create a new .bin or .tsw file with your tool at the moment.
So don't we need to customize the XIP or is that the next step of your development?
Here's hdublis post: http://forum.xda-developers.com/showpost.php?p=5886393&postcount=111
Best regards!
Congratulations cdsmith!
Thank you very much cdsmith. I was missing a bit today but tomorrow I will try to make a ROM.
Some questions: The new payload length need to be identical with the original one or the packing process take care of it? If needed to be I can fill manually the rest with FF to be sure. Any way on the and of original payload there is a spare space with FF.
....the xip.bin is included in payload. Need first to be extracted, than ported and than injected in the final new payload (after SYS and OEM files was modified/excluded)...but it can hapen that the new ROM will boot also with old XIP, just then the version shown will be a mixture between the old and new one. And maybe some mallfunctions...but not necesary (I allready made in the begining of my cooking, ROMs for ASUS P552 in such a way......but after that I learn more)
...AND A BIG THANKS TO hdubli , I learned a lot from his ROMs
cedesmith said:
a word about short pins:
yesterday i updated to official uk rom and tried short pins method for it. it didn't work. sddl+ worked.
short pin checks the file as TG01_SDDL.exe from toshiba does so if OS does not boot and SD Downloader works you may bot be able to restore original rom.
i think is better not to use sddl+ to flash cooked roms as it seams it skips some checks. instead flash original IT debranded with sddl+ then flash unbranded cocked room with TG01_SDD or pins ( file should be named correctly ?)
All this info is for chefs/developers who are willing to test (and sacrifice phone) not for users. I strongly suggest that users don't use it.
i cannot stress enough how dangerous this is.
Click to expand...
Click to collapse
when shortcutting pins as far as I remember you need to rename the .tsw file in .enc in order to skip the language check.
payload contains WM partition table, boot partition, xip partition, imgfs partition, fat partition (user storage).
for me ImgfsToNb cut off fat partition from payload so roms will probably not boot as noware to save configuration files?
osnbtool seamed to put everything back together nicer.
my hopes are with hdubli right now as he previously announced he is willing to make a rom and to try it.
packing should take care of everything as is relays on info from partition table. there is no need to do anything manually. i was just explaining why a unmodified rebuilded rom is different from original a little.
main idea is that orriginal rom knew that extra FF are filling and no need to waste energy on write them to flash while tgtool does not.
at least is what i suppose.
@ABM30 and others: plz do not make and release a rom till someone test on a phone and we are sure it does not brick anything. ppl will download and flash without reading warning and we might end up with a lot of angry peoples.
cedesmith
congratuations for your work and the perfect result.
i think you deserve all the respect of us all, you are the real hero for us,becasuse you do so much for us and for this forum.
in compare I want to say I am disappointed for someone other,some people do much and say little,but some people do little and say so much.
cedesmith:Can you make a tgtool version for japanese rom .it has a tsd (toshiba docomo) file not tsw(toshiba worldwide) file? http://update.toshibamobile.com/update/t01a/wm65/T01A_to_SP50_wm65.exe or tell us what are the differences between them?The T01A users really want to flash English Rom but they can't do that....
this is great news,i may get a tg01 now and sell my x1.Do you think you can port a HTC leo Rom now
mr.mike said:
cedesmith:Can you make a tgtool version for japanese rom .it has a tsd (toshiba docomo) file not tsw(toshiba worldwide) file? http://update.toshibamobile.com/update/t01a/wm65/T01A_to_SP50_wm65.exe or tell us what are the differences between them?The T01A users really want to flash English Rom but they can't do that....
Click to expand...
Click to collapse
Hoping cedesmith can think about this, because many people use japanese tg01
hi cedesmith
thanks for tool, i cooked the rom..but when flash, the sd updater says "invalid file"
the cooked rom size is 234564kb and the original latest tg01 uk rom size is 253572kb
I checked with hex editor as well and the -chk oprion..cannot see anything differrent.
I just cooked the exisitng rom first, as it is to see it it boots or not.may be we miising header? because of size differrence ?
hdubli said:
hi cedesmith
thanks for tool, i cooked the rom..but when flash, the sd updater says "invalid file"
the cooked rom size is 234564kb and the original latest tg01 uk rom size is 253572kb
I checked with hex editor as well and the -chk oprion..cannot see anything differrent.
I just cooked the exisitng rom first, as it is to see it it boots or not.may be we miising header? because of size differrence ?
Click to expand...
Click to collapse
VOW, hdubli can my japanese tg01 can use your rom too? maybe I can test it in my device...
What is a B000FF file
The B000FF .BIN file is a format used in some windows mobile phones and in several Windows CE devices. It is a wrapper format used to write flash memory areas on the phone that allows to save space (unused memory areas are skipped) and to make flashing more "reliable" (trough checksum verification in the bootloader but in case of failure as you can imagine the "reliability" translates into a bricked phone). What those memory areas contain depends on the manufacturer that trough the bootloader decides where to write them; anything could be present in the files, even the bootloader itself or other sensitive areas that should not it's better to not mess with so when working with those files make sure you check what's inside. Tools like OSNBtool can help to identify the content of files because they find the OS.NB inside the BIN file and write separately the data that comes before and after it but remember that just like all the other current tools OSNBTool doesn't handle RESERVED REGIONS that are areas in the OS.NB that must stay in fixed positions so some of the content that ends up removed from the os.nb could be reserved regions content that must be put back in the file for it to work on the device.
The B000FF file format
The format is composed of the following two structures (and obviously the file data):
Code:
struct BIN_HEADER {
char[7] Signature; // B000FF\n signature
DWORD ImageStart; // Image Start
DWORD ImageLength; // Image Length
};
Code:
struct BIN_BLOCK {
DWORD Address; // Address where the block should be flashed
DWORD Size; // Size of the block that is being flashed
DWORD Checksum; // Checksum (CRC32) of the block data
};
The file starts with the header structure, followed by N number of block structures each one followed by the respective data of the block and a termination block composed of a block structure where address/size/checksum are set to 0. Note that some blocks can be missing and depending on the bootloader the region could be left untouched or erased (erased bytes could have any value, it depends on the type of memory (NAND erased bytes have FF value) and on the bootloader).
How to check the integrity of a B000FF file
Read the header, read the first block and check that its address equals ImageStart, check that the termination block is present and check that the last block before the termination block address equals the sum of [ImageStart]+[ImageLength].
How to convert a B000FF file to an absolute binary format file (NB0)
Allocate an empty file with the size of ImageLength and write each of the blocks' data inside at the absolute file position of [Block Address]-[ImageStart].
The missing blocks are usually empty areas (or at least that's what are in the files generated by microsoft tools) that could be ignored by the bootloader or erased (with the bytes values depending on the memory type and on the bootloader code) but in case you encounter them make sure you investigate what those missing belong to, it could be a fancy way for the manufacturer to leave some areas reserved for the phone or bootloader and should be left untouched when re-creating the file.
Current tools available to work with BIN files
CVRTBIN/VIEWBIN to convert the file to a "ROM" file (ABX/NB0/ROM memory image, call it how you want)
OSNBTOOL (suggested, because it lets you figure out what is in the file) that can do the following operationg:
split (-sp): finds the OS.NB inside the BIN and saves the OS.NB and the unrecognized data that comes before and after it
generate BIN (-2bin): converts a file to the BIN format and has two important switches, one to set the start address of the data and one to tell it to not write the header (so that you can example append other BIN data in front of it)
fix BIN header (-fixbinheader) scans the BIN file and adjusts the imagestart and imagelength according to the content
Sorry for my stupid question..
I want to ask about getting *.bin files (B000FF) or *.nb0 from an upgrade *.exe files
I usually can get the file *.bin or *.nb0 manually search for the signature of the *.bin or *.nb0 then cut upgrade *.exe files using a hex editor (discard unused)
or directly using the osnbtool.exe with -sp argument
but i can not get *.bin files or *.nb0 of this exe Upgrade:
Samsung Intrepid
My question, are the *.bin files or *.nb0 on inside the upgrade *.exe of samsung Intrepid is encrypted?
or upgrade *.exe remove the signature of the bin or *.nb0? so we can't get the *.bin or *.nb0 files?
Thank you in advance..
tj_style said:
Sorry for my stupid question..
I want to ask about getting *.bin files (B000FF) or *.nb0 from an upgrade *.exe files
I usually can get the file *.bin or *.nb0 manually search for the signature of the *.bin or *.nb0 then cut upgrade *.exe files using a hex editor (discard unused)
or directly using the osnbtool.exe with -sp argument
but i can not get *.bin files or *.nb0 of this exe Upgrade:
Samsung Intrepid
My question, are the *.bin files or *.nb0 on inside the upgrade *.exe of samsung Intrepid is encrypted?
or upgrade *.exe remove the signature of the bin or *.nb0? so we can't get the *.bin or *.nb0 files?
Thank you in advance..
Click to expand...
Click to collapse
It's not encrypted because the OS.NB starts at 0x529ED34 (actually 0x339000 bytes before, at 0x4F65D34, due to reserved regions but tools would have problems with those) and is in clear sight. After dumping the OS.NB you need to read every 2048 bytes and remove 64bytes of data or tools won't work with it. If you don't know how to do that I already dumped everything and I can upload the files. In case you want to find out more about the rest the ROM file format used by that phone has a "SMDHEAD1" header and starts at 0x987534.
airxtreme said:
It's not encrypted because the OS.NB starts at 0x529ED34 (actually 0x339000 bytes before, at 0x4F65D34, due to reserved regions but tools would have problems with those) and is in clear sight. After dumping the OS.NB you need to read every 2048 bytes and remove 64bytes of data or tools won't work with it. If you don't know how to do that I already dumped everything and I can upload the files. In case you want to find out more about the rest the ROM file format used by that phone has a "SMDHEAD1" header and starts at 0x987534.
Click to expand...
Click to collapse
Whoa.. thank you very much for your answer..
if i open with reshacker or 7zip instead hex editor, i look too the files, so i can extract only the ROM File.
but i always get error on getting imgfs and xip from the ROM file.
now i know as your reference, it must split the data and extra of os.nb.
now i can use the NBSplit.exe with argument -data 2048 -extra 64 right?
i never know about the "SMDHEAD1" ROM File Format, are that's new file format of ROM?
tj_style said:
Whoa.. thank you very much for your answer..
if i open with reshacker or 7zip instead hex editor, i look too the files, so i can extract only the ROM File.
but i always get error on getting imgfs and xip from the ROM file.
now i know as your reference, it must split the data and extra of os.nb.
now i can use the NBSplit.exe with argument -data 2048 -extra 64 right?
Click to expand...
Click to collapse
yes. I uploaded the correct os.nb file here in case you have issues (you have to use osnbtool -sp on it to remove the reserved regions)
tj_style said:
i never know about the "SMDHEAD1" ROM File Format, are that's new file format of ROM?
Click to expand...
Click to collapse
Probably, since it seems to use CHS addresses.
airxtreme said:
yes. I uploaded the correct os.nb file here in case you have issues (you have to use osnbtool -sp on it to remove the reserved regions)
Probably, since it seems to use CHS addresses.
Click to expand...
Click to collapse
Thank you very much for uploading the correct OS.NB..
i need this for reference om cooking my ROM..
keep posting about the structure of files that we used on cooking and all other stuff that we use on developing..
very help for newbie like me..
Thank you..
Hi,
I'm new here and an abolute newbie concerning ROM/NK.BIN etc. What I've done so far: created with tool DiskRW from my device the file SMFlash.img. What I now want is to convert this file into a BIN-file, that I can run in the Windows CE Emulator. But I don't know to accomplish this. Who can advise me how to do? TIA
jwoegerbauer said:
Hi,
I'm new here and an abolute newbie concerning ROM/NK.BIN etc. What I've done so far: created with tool DiskRW from my device the file SMFlash.img. What I now want is to convert this file into a BIN-file, that I can run in the Windows CE Emulator. But I don't know to accomplish this. Who can advise me how to do? TIA
Click to expand...
Click to collapse
You can not run a device specific ROM in the emulator. The emulator itself needs its own specific set of drivers for WM to even boot If that was possible, we wouldn't need phones to test custom ROMs on, we could just run them in the emulator ! Not that sweet though....
airxtreme said:
It's not encrypted because the OS.NB starts at 0x529ED34 (actually 0x339000 bytes before, at 0x4F65D34, due to reserved regions but tools would have problems with those) and is in clear sight. After dumping the OS.NB you need to read every 2048 bytes and remove 64bytes of data or tools won't work with it. If you don't know how to do that I already dumped everything and I can upload the files. In case you want to find out more about the rest the ROM file format used by that phone has a "SMDHEAD1" header and starts at 0x987534.
Click to expand...
Click to collapse
Hi airxtreme, can you help me with Gigabyte GSmart s1205 too?
the osnbtool and imgfs tools does not work on the flash.bin. Please point me to the right direction.
many thanks!