Database Users

Reversing IMEI-CHECK's Wizard Unlocker :)

Hey Folks,
After a long weekend of reversing I am about 95% done in reversing IMEI-CHECK's unlocker for the Wizard.
The application is protected by Themida which is in my view the leading protector on the market currently (yes better than execryptor).
The unlocker has Ring0 protection, Emulated API's, Resource Encryption + Lots more fun and games.
Now onto what I have found so far.
The GUI stuff:
Code:
set 1 0
set 5 ffffffff
set 2 0
set 6 000000
set 4 000000
progressbar 0 239 0 255 ffffff 100 0
shmsg 0 0 " . : | Wizard Unlock | : ."
info 1
shmsg 3 0 " ..detecting device.."
set 32 2
info 0
shmsg 4 0 " >>> Wizard found"
Is plain to see, but the evil work is well tucked away in a procedure which is pushed onto the VirtualMachine.
So I still need to fish that out (loooonnnng task)...
However the very most interesting part (I find) is the existance of a ROM inside the unlocker.
Now I am not sure if this is the bootloader/gsm rom however it certainly seems VERY interesting that it is included.
Download:
http://rapidshare.com/files/12763879/_00CC0000.mem
For those who wish to analyse it and let me know which it is and if anything has been altered.
It might well just be standard, who knows :S
The following tools are also 'picked up':
Filenames:
Code:
PORTMON.exe
SnoopyPro.exe
Device Monitor.exe
Window Titles:
Code:
Portmon Class
SnoopyPro
USB Monitor
Device Monitor
Serious Serious Kudos to the developer, Very impressive work indeed!
By making this, he has almost made himself a license to print cash.
Since he has NO terms about his programs what so ever then there is no legal problems with what I am doing to his application.
He is probably too scared of HTC anyway, since he is decompiling their firmwares in order to make the product. (Which is outlawed in HTC's terms)
Anyway....
Watch this space

Very interesting, would information gathered from the Wizard unlocker lead to cracking the Treo 750 unlocker? Or any other phone that imei-check supports for that matter?

Whiterat said:
After a long weekend of reversing I am about 95% done in reversing IMEI-CHECK's unlocker for the Wizard.
Click to expand...
Click to collapse
Great, will you disclose your findings? there was an earlier post about the unlocker for G4 wizards, here (see comment #36):
http://forum.xda-developers.com/showthread.php?t=284312
Whiterat said:
However the very most interesting part (I find) is the existance of a ROM inside the unlocker.
Now I am not sure if this is the bootloader/gsm rom however it certainly seems VERY interesting that it is included.
Click to expand...
Click to collapse
It seems that this is the patched SPL that is flashed on the first unlocking step, it is modified so that when it is told to flash an splash screen, it flashes the security area, overwriting the CID.
Whiterat said:
For those who wish to analyse it and let me know which it is and if anything has been altered.
It might well just be standard, who knows :S
Click to expand...
Click to collapse
I will load it at IDA and compare with a normal wizard SPL...
Whiterat said:
Serious Serious Kudos to the developer, Very impressive work indeed!
By making this, he has almost made himself a license to print cash.
Click to expand...
Click to collapse
Yes, the imei-check guys are doing great job with their unlockers... similar method is used in artemis unlocker too. They load a modified SPL in RAM and jump to its physical address from WinCE, this modified SPL shows the DOC ID in help of "set" command and allows flashing unsigned code, then they use obtained DOC ID info to patch the security area by sending a "fake" splash screen, same as in wizard unlocker.
Whiterat said:
Watch this space
Click to expand...
Click to collapse
I will

phoa not much point in me continuing!
You've got the whole lot there!
I'm a lover not a coder, I simply reverse in order to help others succeed.
Since you have all important info anyway, Not really going to be of much help here
P.S do you have any sigs for IDA or any scripts?
I dont like having to sift through manually as binary file......

Whiterat said:
phoa not much point in me continuing!
You've got the whole lot there!
Click to expand...
Click to collapse
Well I didn't want to discourage you on continuing the reversing process, I just pointed you to the thread where we discussed about the unlocking method a while ago...
I admire the fact that you reached that far only disassembling / debugging the binary, what we actually did to have the full process was capturing it with USB monitor; the unlocker can be tricked if you run the usb monitor process as one user, ant the unlocker as a different user, but imei-check seem to have corrected this 'bug' in newer unlockers.
Whiterat said:
Since you have all important info anyway, Not really going to be of much help here
Click to expand...
Click to collapse
We don't have _all_ the important info, we have the commands that the unlocker sends to the bootloader, but the data sent to flash the security area is actually different in every phone, so flashing what is sent in one phone to another phone will actually brick it.
I think it can be helpful if you manage to reverse the algorithm that the unlocker uses to generate the code which is flashed on the security area, this can't be done capturing usb traffic, this has to be reversed from the binary, and Themida is not easy to break as you sure have noticed
Whiterat said:
P.S do you have any sigs for IDA or any scripts?
I dont like having to sift through manually as binary file......
Click to expand...
Click to collapse
No sorry, i don't have any... I am not very used to IDA, started using it few months ago and still learning new things about it everytime I start it

Ah cool I will look into it a bit further
(Need to get a friend to code a tool to remove the junk code)
e.g
PUSH EAX
PUSH EDX
MOV EAX,2282
INC EAX
DEC EDX
POP EDX
POP EAX
Since it is popping those registers off the stack, its actually altered nothing
Themida is a cow, Because my friend didnt manage to make a start on the junk code remover (and I didnt realise there was a virtualised function) I just did each Import by hand (approx 4 hours lol)
Also rebuilt the OEP by hand too, not too hard since it was VC++6.
I have a G4 which I have unlocked with Imei-Calc (thus I have the key file, which I *think* might decrypt parts of the program, or possibly is part of an encrypted rom.)
3 Last things:
1. Can the G3/G4 chip be worked out by IMEI, i.e IMEI represents a date and the chips were only used after a certain date? or is this tool generic for G3/G4 ?
2. Do you have an SPL for 2.08.10
3. How can I dump my SPL (bearing in mind my only minisd has a full backup of my rom, Just in case crossbow gets a little ugly for my liking)
Ohh one last thing, kbdus.dll on Crossbow.....Is there a kbduk.dll as far as you know?
My Wizard has british keyboard and all the chars are shifted +1.....
Thats my next major task I think before continuing on this thing
Btw, To use the usb logger on newer versions of IMEI-CALC, just rename the exe and change the class name

Hi..Answer on the "Last Three Things"
1.) No one cannot identify G3/G4 with imei.If u lok carefully the place below yr battery u will find a"G4" written besides yr imei no.In G3, nothing is written.The most commeon way is to check IPL/SPL .001 in the end is G4.
2) Take a ROM which has 2.08 SPL. and use typho5.exe to dismantle the ROM parts.If ROM is release recently then you will find IPL/SPL for G3/G4 both.Chek the threads here..
3) As such crossbow ROM has no IPL/SPL..if u know what ROM u were using prior to that, u can apply above to dump yr ipl SPL..secondly you can do this with awizard1.3 beta.
I hope this helps

LINUX BOOTS at OPAL! Thanks to linwizard project!

Hi there,
I got Linux to boot at OPAL via linwizard project. Here are steps needed to get it work.
1) download image from:
http://tinderbox.x86.dev.gentoo.org/embedded/linwizard/gizard-20080602.tar.bz2
2) copy content of file to the microSD card
3) edit default txt and replace init=/linuxrc with init=/bin/sh
4) run haret and let it boot.
After a while you'll get to shell. No graphics.
Now you can attach microusb cable and connect it with your linux laptop (I recommend ubuntu)
and you will get usb0 interfece to start up.
Which IP to use to connect with OPAL I still must investigate.

Well ip connectivity now works:
ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>
Notas:/# ifconfig usb0 up 192.168.2.200 netmask 255.255.255.0
Listik:/usr/src/linux-2.6.27/Documentation# ping 192.168.2.202
PING 192.168.2.202 (192.168.2.202) 56(84) bytes of data.
64 bytes from 192.168.2.202: icmp_seq=1 ttl=64 time=2.95 ms
64 bytes from 192.168.2.202: icmp_seq=2 ttl=64 time=1.72 ms
And how to do it:
prolong "set CMDLINE" line with
ip=192.168.2.202:192.168.2.200:192.168.2.200pal:usb0
But in this image there doesn't seem to be any telnet/ssh server running. I will try cook image with ssh server support later

Download error
Were not able to re-upload

404 file not found error!!

http://tinderbox.x86.dev.gentoo.org/embedded/linwizard/
and open latest gizard-<date>.tar.bz2
or that I suppose.
The latest link should be http://tinderbox.x86.dev.gentoo.org/embedded/linwizard/gizard-20090703.tar.bz2

does this mean any chance of android working? anyone tried?

Hey,
I'm a new Opal user and I'm interested in getting *nix running on my device. I still haven't had the chance to mess around with this stuff but I'm excited to see this thread.
I was looking into the possibility of running Android on the Opal and it seems the closest thing is this thread bout running it on the Herald (it uses the same processor as the Opal).
I don't any experience in Linux porting so I thought I'd share this, in case anyone else is interested. And at the same time, I'll try to see if I can get something working based on what has been/is being done for other devices.
Sorry for the long post.

Hey Folks,
Any progress on getting Android on Opal? I am eagerly waiting to load one.
Kindly let me know, if this version of Linux when loaded, gives the UI.
Cheers'
Vijay
cijoml said:
Hi there
I got Linux to boot at OPAL via linwizard project. Here are steps needed to get it work.
1) download image from:
http://tinderbox.x86.dev.gentoo.org/embedded/linwizard/gizard-20080602.tar.bz2
2) copy content of file to the microSD card
3) edit default txt and replace init=/linuxrc with init=/bin/sh
4) run haret and let it boot.
After a while you'll get to shell. No graphics.
Now you can attach microusb cable and connect it with your linux laptop (I recommend ubuntu)
and you will get usb0 interfece to start up.
Which IP to use to connect with OPAL I still must investigate.
Click to expand...
Click to collapse

Android can boot on Opal
I have some good news, Android can boot on the Opal. This is just a proof of concept as it's missing tons of drivers and is completely useless.
Touchscreen and all keys except for the volume control (and obviously the reset button) are not working. So you basically can't do anything when you run it.
What I tried is the same as what's written in this thread about running Android on Gene. They're using the build made for the Herald/Wing (just as I was proposing in my last post) with customized initramfs and kernel.
You'll find all the necessary details in that thread. However, there's a newer build than the one mentioned there it's wing-linux-0.4pre2.cab. And the suitable kernel for that build is supposed to be the pre2 posted in this post but it didn't work on my Opal so I tried the older Gene kernel and it worked. The main difference between the two is bluetooth support, and that's obviously is of no use for us.
This doesn't effect the Windows rom, nor does it requires any special partitioning. Still it's best to have everything backed up before launching it, just in case.
This is the official site for the wing/herald build:
http://wing-linux.sf.net/
This thread on their forums about the Gene port will probably be of use to us:
http://sourceforge.net/apps/phpbb/wing-linux/viewtopic.php?f=4&t=4
I'm reading about the next steps but as I said before, I don't have any previous experience or knowledge about this type of things. If someone can give me hand, I would be more than grateful. At any rate, once I have better understanding of the concept I'll contact the people behind the Wing and the Gene ports.
P.S: If you do try to run this, keep in mind that this will take lots of time, specially for the first launch. And when you get an error saying something like "android sh: can't access tty" just ignore it and keep waiting. After a while you'll have a flashing "android" on the screen, and after some more waiting you'll reach the main screen.

Is this just THE BEGINNING
Sooper Stuff..!! So is this just THE BEGINNING??
How do we port the drivers and other required information in the build?
Cheers'
Vijay
www.msigeek.com

A Lil' help
I'm going through the Gene port thread here and on the Wing-linux sourceforge forums but I'm still a bit overwhelmed.
I would appreciate any help as I'm completely new to porting. I have some programming and linux knowledge but never attempted this type of things.
Click to expand...
Click to collapse
So am I.
Hmmm...
Right. Lets do it the way I did it.
1. Get the touchscreen working. Through HaRET, you must have got the GPIO interrupt whenever you pressed the touchscreen. You must have got two numbers corresponding to each press - a smaller number and a bigger number. The smaller number is the GPIO, and the larger number is, well, lets say a special GPIO value for the same pin.
Now checkout the Gene branch through git.
Goto /wing-linux/kernel/arch/arm/mach-omap1/board-htcherald.c
Scroll down to a block of code where you'll see the touchscreen code. Enter the smaller number in the .dav_gpio statement, and the IRQ number in the OMAP_GPIO_IRQ() statement below.
2. Follow the Kernel build instructions on the development section of the wing-linux wiki (the two make commands)
Copy the zImage into the linux folder on your SD card
Boot into wing-linux. The touchscreen should start working.
3. Now, hopefully, after the touchscreen's working, You would essentially just require two more buttons - the home button and the back button for minimum functionality. Everything else can be worked on by the touchscreen.
Then follow the instructions on the wing-linux forum (Page 2) to get the KEY(row,col) values of the keys on your handset. Hopefully you should get atleast a couple. Note down the corresponding keys and their KEY(r,c) values output.
4. Fire up board-htcherald.c again and goto the place where you have the KEY(r,c,KEY_blah) thing and replace the codes as per your obtained KEY(r,c,KEY_blah) values (The Home button is the one commented as Left Button)
5. That's all I can help you with as of now. I'm also figuring out a stable way of getting the DPad and the center select key to work, but It'll take some time.

Thanks kshaurya!
(This guy right here is the one who fixed the kernel for Gene, I asked him for some pointers).
I don't want to take my device apart just yet (I usually do my best not take to dismantle anything that I haven't owned for at least 3 months unless absolutely necessary) and I couldn't find a place that states what touchscreen it uses. I'm just hoping that it's the same a tsc2046 as well. [Is there anyone without a warranty and/or willing to check for us?]
I'm gonna double check the values I got from the touchscreen as for some reason I seem to have to IRQ values, probably forgot to get rid of some spamming irq. And, at the same time, I'm currently setting up a VM as a building environment, my main boot is Intrepid 64 and there's no 'psyco' package for 64 machines.
If anyone else have some experience and wants to try this, refer to: http://www.handhelds.org/moin/moin.cgi/HaRET_20Documentation (using haret to get the GPIO and IRQ values needed).
And to:
http://sourceforge.net/apps/trac/wing-linux/wiki/Development (acquiring the source code from Wing Linux and how to build it).
And a quick question for anyone that tried booting Android on the Opal, what screen did you get when Android finally finished booting?

I don't want to take my device apart just yet
Click to expand...
Click to collapse
Huh? where did that come from? Wing Linux will not touch your WM.
I seem to have to IRQ values
Click to expand...
Click to collapse
Do you mean two? Well, that's exactly what you should get. Even if it's just one, enter that value in the code.
my main boot is Intrepid 64 and there's no 'psyco' package for 64 machines
Click to expand...
Click to collapse
Oh no. dont tell me that you are building the entire thing. all you need to do is build the KERNEL! Please! Don't go into building the whole thing from scratch. Use the make ARCH ARM commands given on that page.

kshaurya said:
Huh? where did that come from? Wing Linux will not touch your WM.
Click to expand...
Click to collapse
I mean to check the screen, in case it turned out to be different that what you have.
kshaurya said:
Do you mean two? Well, that's exactly what you should get. Even if it's just one, enter that value in the code.
Click to expand...
Click to collapse
Yeah, stupid typo.
I noticed now that one of them appears when I keep the screen 'touched' for a bit longer.
kshaurya said:
Oh no. dont tell me that you are building the entire thing. all you need to do is build the KERNEL! Please! Don't go into building the whole thing from scratch. Use the make ARCH ARM commands given on that page.
Click to expand...
Click to collapse
I'm not gonna build the complete thing. Seems like I got too exited and failed to notice that building the kernel only requires a cross-compile toolchain, te rest is for compiling the whole thing.
I'm not THIS stupid usually . Honestly!
Thanks again!

I'm not THIS stupid usually . Honestly!
Click to expand...
Click to collapse
Its pretty normal

Weird.
I've only changed the two touchscreen values and built the kenrel. It finished without any error but now it won't boot.
It gets stuck, even before the space allocation part, with this error: "sh: can't access tty; job control turned off". And then it displays a prompt.
I'll try modifying an older build, I'm pulling them from the repos at the moment.
After all, the pre2 kernel from Gene didn't boot on my device (although it got stuck later on).

Try doing a clean install - Remove the linux folder and try again.
Also, make sure that you're not forgetting to checkout the Gene branch.
Code:
git checkout Gene
Is your default.txt modified? And have you downloaded the modified initramfs.cpio?
check in the Gene forums for that.

Already tried the clean install, no dice. The default.txt is untouched and I'm using the modified intramfs. What happened this time is different from what happens using the original one, it's not asking me to specify the partition size but instead it's waiting for a command. I could probably ssh via usb but I have no clue how that might help.
And I've already checked out the Gene branch from the beginning.
I've tried compiling the kernel for pre1 (after changing the screen values) from SVN and it did boot (both using the cabs for pre1 and pre2) but no touch screen yet. All in all, I'm guessing that there's too much hardware difference here.
And the button for lowering volumes didn't work either, it seems like whatever you changed for getting it to work on Gene is the same as what we need here, but I'll think about that later.
I only have two ideas left:
- Trying to go back to a more stable build (with lesser features and lesser possibilities for errors). Maybe 0.3.
- Trying to create some kind of hybrid kernel using this alongside the HTC Vogue build as it probably has closer hardware to the Opal (obviously, I'm talking about everything beside the MSM7500 400MHz processor that it has). I'm hoping it won't get to this cause I'm definitely under qualified for that at the time being.

What happened this time is different from what happens using the original one, it's not asking me to specify the partition size but instead it's waiting for a command.
Click to expand...
Click to collapse
Could you post a screenshot?
I've tried compiling the kernel for pre1 (after changing the screen values)
Click to expand...
Click to collapse
I'm assuming you mean the touchscreen values? Try interchanging and see.
Trying to go back to a more stable build
Click to expand...
Click to collapse
I wouldn't recommend that. Defeats the whole purpose.
Why don't you try getting in touch with darkstar?

kshaurya said:
Could you post a screenshot?
Click to expand...
Click to collapse
A friend borrowed my digital camera, I tried my laptop's webcam but the text it too blurry. Couldn't fix it using gimp either. So here's exactly what's showing on the screen:
Code:
mdir: Cannot creat directory `/mnt' : File exists
modprbe: could not parse modules.dep
initramfs: Creating device nodes:
initramfs: Loading /initrd.d/10-initfs.sh module
initramfs: Loading /initrd.d/30-wingboot.sh module
Selected:
ROOT_DEVICE=/dev/
CMDLINE=debug quiet psplash=false loglevel=7 init=/sbin/init console=tty0 video=omapfb:accel fbcon=rotate:3 4 root=/dev/
initramfs: Loading /initrd.d/80-loopboot.sh module
initramfs: Loading /initrd.d/85-blockboot.sh module
booting from: /dev/
mount: Mounting /dev/ on /mnt failed: Invalid argument
Unable to mount rootfs device
sh: can't access tty; job control turned off
/ $
And after the prompt, on the same line, there's a flashing '_' waiting for input.
Using the original zImage (from the pre2 cab) it's right around here that the screen clears and the Wing Linux installation script kicks in.
kshaurya said:
I'm assuming you mean the touchscreen values? Try interchanging and see.
Click to expand...
Click to collapse
Will try that next.
kshaurya said:
I wouldn't recommend that. Defeats the whole purpose.
Click to expand...
Click to collapse
I meant it as just a temporary test to till the cause of the incompatibility is figured out. With less things that could go wrong, it'll be easier to locate the ones that are going wrong.
kshaurya said:
Why don't you try getting in touch with darkstar?
Click to expand...
Click to collapse
You're right. I should post a thread on the project's forums asking for his help.

How to verify ROM backup of SMT5600?

The SMT5600 is app unlocked and, I think, Super CID (via lokiwiz02_173 but how verify?) but no ROM changes as of yet as I want to make a backup of the original ROM before proceeding further.
After problems getting a term program to work (now using nueTTYConsole on Vista) I am able to get what appear to be complete ROM backups.
Procedure summary:
WinHex zero fill 64MB SD
USB bootloader SMT5600 with 64MB SD
r2sd all (via nueTTYConsole-12-v0.1-spackr)
SD back to PC [no to format query]
psdread E: 0 31328768 ipl.bin (using itsutl050119)
Status messages from the r2sd all command appear to be good and complete but no two backups, using the exact same procedure, are ever identical when binary compared with WinMerge. Size is, of course, the same but WinMerge always reports 'two' differences in what seems to be the same general area of the images: The first is very near the front of the image (WinMerge reports as 'lines', line 3) and the other at the very tail end.
Is that normal (maybe because TIME, or some other dynamic variable, changes or scratch storage?), is there a better backup procedure, and how can I verify the backups are good before I flash a new one and forever lose the original?
Thanks in advance for any enlightenment offered.

To check if it works - just restore the backups before doing anything else.
Follow the whole procedure (including psdread and - after reformatting the card - psdwrite again) to restore your device via the card. As a first try leave out the device external activities and restore immediately afterwards from the card just written.
For me it works well (on the SDA 2 - where no official update exists, a Hurricane device - but this generic handling is identical afaik) and the difference in the backups are normal.
Mind that the size of the read/write to card includes the bootsector, so don't miss the last 512 bytes. As far I remember there were two different size readings with two methods to verify the image size. The r2sd size is smaller than the size of bytes different to null on card.
To check for SuperCID enter "info 2" in the terminalprogram, it should report HTCSuperCID at the end.

tobbbie said:
To check if it works - just restore the backups before doing anything else.
Follow the whole procedure (including psdread and - after reformatting the card - psdwrite again) to restore your device via the card. As a first try leave out the device external activities and restore immediately afterwards from the card just written.
Click to expand...
Click to collapse
Thanks for the reply
Yes, I thought about doing a test restore, but, considering the problems I'd already had, wasn't sure if it might do something like not mention there being a 'problem' till it was half way through, leaving me with a scrambled ROM.
I take it you're saying it'll checksum first and no even start if things don't look good?
tobbbie said:
For me it works well (on the SDA 2 - where no official update exists, a Hurricane device - but this generic handling is identical afaik) and the difference in the backups are normal.
Mind that the size of the read/write to card includes the bootsector, so don't miss the last 512 bytes. As far I remember there were two different size readings with two methods to verify the image size. The r2sd size is smaller than the size of bytes different to null on card.
Click to expand...
Click to collapse
Hmm. I saw the confusion about SMT5600 image size but I'm not sure what you're saying here about the bootsector and "different to null."
Speaking of which, what would be wrong with just making a 64M save and, ok, you've save a pile of extraneous 0's along with it but, so what? Might be irritating if I were putting it on rapidshare but for a personal backup is there any down side to it?
tobbbie said:
To check for SuperCID enter "info 2" in the terminalprogram, it should report HTCSuperCID at the end.
Click to expand...
Click to collapse
Thanks. Good to know.
Something apparently went wrong somewhere because I didn't get that report but I'll try again.

The r2sd is a command that HTC has implemented in the SPL (Secondary Program Loader). I am not aware of checksums or other safety measures - it will as I noticed following the procedure detect if there is an image on the card, which type of image and if you want to restore.
The difference in size is that r2sd reports one size "x" after the image was taken, but if you count the bytes until when the card shows the zeros you will notice that this offset on card is 512 bytes larger than the r2sd reported size. So when using psdread you have to take the larger size. Indeed it is no problem to write more to the file and restore more as well with psdwrite. The restore procedure in the SPL will anyway know how much to restore - it just needs to find ALL bytes, including the last 512
I think there is no risk attached to the procedure, go ahead!
The only danger is if something goes wrong with the IPL (Initial Program Loader) or SPL because they open the door to the device handling.
Sadly you MUST deal with SPL to upgrade to WM5+ afaik, so be very sure to select the right IPL and SPL that matches your device HW (OMAP 730, 750 or 850) and intended OS Version. Also take care not to enter any command in the SPL except the ones you are supposed to enter - it may kill your device as well. Do never use "format all" or "doctest" - you have a brick then.

tobbbie said:
The r2sd is a command that HTC has implemented in the SPL (Secondary Program Loader). I am not aware of checksums or other safety measures - it will as I noticed following the procedure detect if there is an image on the card, which type of image and if you want to restore.
Click to expand...
Click to collapse
Well, I am certainly no expert on this thing but r2sd spits out a wealth of information, including checksums, and I was sort of guessing based on what I'd do if I'd made it. Just that, if you're going to calculate them, it seems a shame to not use them. But, hey, I've seen stranger things done.
tobbbie said:
The difference in size is that r2sd reports one size "x" after the image was taken, but if you count the bytes until when the card shows the zeros you will notice that this offset on card is 512 bytes larger than the r2sd reported size. So when using psdread you have to take the larger size. Indeed it is no problem to write more to the file and restore more as well with psdwrite. The restore procedure in the SPL will anyway know how much to restore - it just needs to find ALL bytes, including the last 512
Click to expand...
Click to collapse
Oh, OK. I wasn't going by r2sd. I opened it up in WinHex, found the end of data, and compared that to the size mentioned on "Backup your Typhoon ROM - WinMo @ MoDaCo." The 'corrected' number there matched well enough.
But now that I think of it, I did that because I *did* look at r2sd and it seemed too small. So you've explained it. Good.
tobbbie said:
I think there is no risk attached to the procedure, go ahead!
Click to expand...
Click to collapse
How can there be no risk if it doesn't check anything?
tobbbie said:
The only danger is if something goes wrong with the IPL (Initial Program Loader) or SPL because they open the door to the device handling.
Click to expand...
Click to collapse
Oh, I think I see what you mean. You're suggesting that if I've cut the ROM image short then only that part will fail but the loader should still be good so I could recover by burning another (good) ROM image.
Well, perhaps, but that would mean I don't have a valid backup and couldn't make one since it would be trashed in the bad flash. Or so it seems to me.
tobbbie said:
Sadly you MUST deal with SPL to upgrade to WM5+ afaik, so be very sure to select the right IPL and SPL that matches your device HW (OMAP 730, 750 or 850) and intended OS Version. Also take care not to enter any command in the SPL except the ones you are supposed to enter - it may kill your device as well. Do never use "format all" or "doctest" - you have a brick then.
Click to expand...
Click to collapse
I was thinking of going straight to WM6.x per
karhoe.net/guide-upgrading-htc-feelertyphoonamadeus-to-windows-mobile-6-update-september-06-2008.html
which involves changing the loader first via Patched_RUU
Do you think going to WM5 first is a safer procedure?

I said I was not aware of any checking - but as I have not written the SPL, I simply do not know it. You are right that reporting stuff like this makes it highly probable that upon restore a check on the image should be done before restoring. Try it out, if you like
WM5 or WM6 does not make a difference what the SPL is concerned. Afaik you have to use the same anyway. The device is tight in memory anyway, so don't expect miracles.
Go ahead, either dare it or leave it...

tobbbie said:
I said I was not aware of any checking - but as I have not written the SPL, I simply do not know it. You are right that reporting stuff like this makes it highly probable that upon restore a check on the image should be done before restoring. Try it out, if you like
Click to expand...
Click to collapse
Hehe. Yeah.
I was sort of hoping someone else had already stepped off that cliff and could tell me what the ground was like before I dove in
tobbbie said:
WM5 or WM6 does not make a difference what the SPL is concerned. Afaik you have to use the same anyway. The device is tight in memory anyway, so don't expect miracles.
Go ahead, either dare it or leave it...
Click to expand...
Click to collapse
The primary aim was to get bluetooth a2dp but the incentive may have diminshed, depending on how another project works out.
Thanks again for the help.

I would not bet on A2DP - I have it in the Tornado and the CPU use is much higher due to additional compression on the BT interface. Player + BT overhead is getting to average above 80% CPU (depending no the settings, but for good quality is like this) - it will also drain your battery much faster.
The Typhoon, Hurricane and Tornado have identical good analog Audio capabilities (I measured them with RMAA - see www.rightmark.org) and make a perfect music player as they are.
If your device is SuperCID you can take any other Typhoon ROM - you must just be sure that r2sd will save your bootloader + OS if you want to go back to WM2k3. I have done this already on my Amadeus (and went back to WM2k3) and this can still serve as a nice musicplayer.

tobbbie said:
I would not bet on A2DP - I have it in the Tornado and the CPU use is much higher due to additional compression on the BT interface. Player + BT overhead is getting to average above 80% CPU (depending no the settings, but for good quality is like this) - it will also drain your battery much faster.
The Typhoon, Hurricane and Tornado have identical good analog Audio capabilities (I measured them with RMAA - see www.rightmark.org) and make a perfect music player as they are.
If your device is SuperCID you can take any other Typhoon ROM - you must just be sure that r2sd will save your bootloader + OS if you want to go back to WM2k3. I have done this already on my Amadeus (and went back to WM2k3) and this can still serve as a nice musicplayer.
Click to expand...
Click to collapse
I admire people who can make these flash things work because it never does for me. I've now got an SMT5600 that will do nothing but display a rainbow boot screen and error out regardless of what ROM I try.
That's why I didn't try this till I had a new phone.

Hey that thread has a long history - what happened in the meantime?
3 colour screen does not mean the device is dead yet. You still have a bootloader that works and this is the thing to start from in any case.
What do the lines tell in the 3 color bars?
Did you already upload the changed SPL (I think it was 1.09) that allows to flash ROMs of WM5 or WM6 on that original WM2k3 device? If so, the you need to revert back to old SPL first before you can upload the original ROMs again.

tobbbie said:
Hey that thread has a long history - what happened in the meantime?
Click to expand...
Click to collapse
I put it on hold pending a new phone and other things cropped up.
Frankly, I had 2003 pretty well tricked out with SmartToolkit and gStart.
tobbbie said:
3 colour screen does not mean the device is dead yet. You still have a bootloader that works and this is the thing to start from in any case. What do the lines tell in the 3 color bars?
Click to expand...
Click to collapse
I swear it wasn't a troll but no sooner than I posted it wouldn't flash I managed a flash and I'm not sure why this worked when the others failed.
I was trying to verify the hard spl, getting info, etc. To make that easier I turned 'ui' on during boot and, just for chuckles expecting nothing, I tried flash again. You know, the definition of 'insanity'. Low and hold the dern thing flew.
As far as I know nothing was different other than 'ui' on. Same tools, same wm6.5 bin file, etc.
tobbbie said:
Did you already upload the changed SPL (I think it was 1.09) that allows to flash ROMs of WM5 or WM6 on that original WM2k3 device? If so, the you need to revert back to old SPL first before you can upload the original ROMs again.
Click to expand...
Click to collapse
You have no idea how helpful mentioning "1.09" is. The SPL flash program opines something like changing to v 5.000 but that number shows up no where and no where does it tell you to look for '1.09'. There are other confusions, like saying the existing device was 'Orlando' (I think it was), but I guess that's moot now.
Anyway, it's now running WM6.5 and I have a new toy to fiddle with inbetween playing with Android on my Tilt 2.
Thank you for the help.

Glad it worked now
The older (wm2k3) devices could only be updated with a binary transfer protocol (the .BIN file - which can be confused with other ".bin" in the scope of cooking in general). To enable the reception of the MTTY command "l" (for Load) and the execution of the related actions, the SPL must be in "UI" (User Interface) mode - this is the key for further flashing - and it must be mentioned in all such upgrade manuals. Also mind that other terminal programs (like TerraTerm) have not implemented that protocol. So only MTTY works for that purpose! As I am struggling currently with porting a Tornado ROM to the Hurricane I have come quite deep into that topic recently.
Are you having the WM65 from aleut now on the device? I think it is very tight on RAM now, so what are the memory key-data from settings->about after a reboot? You should repeat that with the standard home screen (Windows default) which is less memory greedy.
The way back to WM2k3 is not so easy as you must replace the SPL with the original one first before you can get back to the original OS. Whenever you mess with SPL it is a potentially dangerous action as failure doing that right will result in a bricked device.

tobbbie said:
Glad it worked now
The older (wm2k3) devices could only be updated with a binary transfer protocol (the .BIN file - which can be confused with other ".bin" in the scope of cooking in general). To enable the reception of the MTTY command "l" (for Load) and the execution of the related actions, the SPL must be in "UI" (User Interface) mode - this is the key for further flashing - and it must be mentioned in all such upgrade manuals. Also mind that other terminal programs (like TerraTerm) have not implemented that protocol. So only MTTY works for that purpose! As I am struggling currently with porting a Tornado ROM to the Hurricane I have come quite deep into that topic recently.
Click to expand...
Click to collapse
So I discovered after missing the little '0' in the instructions.
tobbbie said:
Are you having the WM65 from aleut now on the device? I think it is very tight on RAM now, so what are the memory key-data from settings->about after a reboot? You should repeat that with the standard home screen (Windows default) which is less memory greedy.
Click to expand...
Click to collapse
Yes, I originally flashed Aleuts 6.5 but I've since reflashed with his 6.1.
tobbbie said:
The way back to WM2k3 is not so easy as you must replace the SPL with the original one first before you can get back to the original OS. Whenever you mess with SPL it is a potentially dangerous action as failure doing that right will result in a bricked device.
Click to expand...
Click to collapse
Yep, flashing SPL is the most vulnerable but I don't think I'll be going back to 2003. Although, I might try WM5 if that has more free memory.
With most things I plan on using installed there's 8.5Meg free at boot and while that sounds laughable by today's standards there's only 22Meg total for a more impressive sounding '38% free' Although, as soon as you touch the thing almost half of that is gone.

[REF] Help for Bricked Phones - TG01 Users, Be Aware!

Flashing different custom ROMs, some of us, sooner or later, are meeting ONE TERRIBLE PROBLEM - device getting bricked... Unfortunately, might happend...
With new developments of feropont we are getting, finally, updated (in the meaning of ballanced and smooth "relationship" between hardware and software) device. He, certanly, done jobs, Toshiba supposed to do before releasing the device.
... And it is real pain - inability to enjoy using such improved device...
As a members of xda-developers community, we become pretty skillsful resolving different problems - we have huge support over here - this is one of the reasons for opening this thread - to get help, and help others. Again - everyone of us can meet the problem.
I am a hard user of Windows Mobile from early years when Dell Axim just came to public. TG01 - my last device, in which I found full functional Pocket PC and pretty developed cell phone - all in one , and with my accurate attitude in using my "toy" I did not expect to fall victim of software glitch... But it happened!
My particular problem is really unusual – I cannot flash ANY custom made ROM (even earliest – see pere’s ROM table), But I am ABLE to flash any official ROM (!?)
We discussed the problem with feropont, he found it pretty unusual - I am inviting you to open discussion here, in one place, related to most common problems TG01 Users can meet… and hope, I'll find solution for my problem, as well.
Following, I would like to provide with links to previous answers to came across problems – all about TG01. (send me links – you consider helpful – will post them here in a first page).
Two brick variants from mirolg
Short Pins Illustration from kevinpwhite
TG01 Downloader TG01 Driver TGTool contains TG Tool
Smart Quote:
fxdjacentyfxd said:
1) always check .tsw file in prg directory via tgtool.exe software
2) from time to time I execute chkdsk utility to check SD card.
Only after point 1) and 2) I start sdll+ uploader.
Regards
fxdjacentyfxd
Click to expand...
Click to collapse
Another try...
Pere's TG01 Cooked ROMS' Table

eskyt said:
My particular problem is really unusual – I cannot flash ANY custom made ROM (even earliest – see pere’s ROM table), But I am ABLE to flash any official ROM (!?)
We discussed the problem with feropont, he found it pretty unusual - I am inviting you to open discussion here, in one place, related to most common problems TG01 Users can meet… and hope, I'll find solution for my problem, as well.
Click to expand...
Click to collapse
Hi.
What method of flashing You used to utlize ?
I can confirm only that using 3-pin metods ( as always I say - absolutely do not use this method if You really do not have to. ) should be involved only for official roms . Someone will say not true. I say I had always problems to flash custom roms utilizing this method so always, I repeat always, flash only any official rom this way. Never have had any problems with official roms but always problems with custom roms including "terrible" messages like "NAND flash error". Maybe flashing custom roms this method cause such big problems in the future ? It seems to be service mode not normal flashing mode so who knows what wrong can wait for us if rom is not official.
Anyway utilizing sdll+ software seems to be ok both for official and custom roms.
I have not had any slightest problem with it.
Sometimes people are gilty themselves. Flash strange custem roms with God knows where custom bootloaders and it is enough. For example, Nokser has bricked His tg01 and only JTAG can help him. Too much experiments with unknown matter and disaster is ready. Many people tried His last rom and who knows whether they are next candidactes to have unresolved problems with their tg01s.
Regards
fxdjacentyfxd

Flashing any device always has a risk attached, whether that be a Toshiba TG01 or a pc motherboard bios, still as long as procedures for flashing are followed correctly nobody should have many problems, but obviously bad things can happen, how many motherboards have died on a bios flash for example?
Flashing TG01 is no more risky than flashing other devices, however what you flash it with is the area where risk becomes involved.

I think what is needed is a tool for HTC devices called 'task 29' basically when we flasg custom ROMs over and over again, some roms are bigger than others etc, so they dont overwrite all system files, therefore, old system files from the previous ROM is left in the new ROM. this corrupts the phone, therefore you expeirience bugs. We need a tool like task 29.
but personally i dont/ havent faced any of these problems... *touch wood*

Thank yo guys!
To fxdjacentyfxd - thank you for sharing thougts.
I am exactly an example of "next candidacte" - I always was extremly carefull and used sdll+ only. I even did not know how to use3 pin method (feropont, many thanks him, instructed me).
I guess, (really just guess), my problem came from corrupted .tsw file - you know, we can see full sized file on memory card, when (factually) copying process was interrupted...
This is the riddle - what "changed" in the boot area, that compel my device to accept officials ROMs only (and only through 3 pin method), when customs (through sdll+) stopping it on Toshiba logo...
To olyloh6696 - yes, feropont had mentioned this future in privet correspondence - would be good to have it!
To (InsertNameHere) - "obviously bad things can happen" - supposed to be motto of this thread

eskyt said:
To fxdjacentyfxd - thank you for sharing thougts.
I am exactly an example of "next candidacte" - I always was extremly carefull and used sdll+ only. I even did not know how to use3 pin method (feropont, many thanks him, instructed me).
I guess, (really just guess), my problem came from corrupted .tsw file - you know, we can see full sized file on memory card, when (factually) copying process was interrupted...
This is the riddle - what "changed" in the boot area, that compel my device to accept officials ROMs only (and only through 3 pin method), when customs (through sdll+) stopping it on Toshiba logo...
Click to expand...
Click to collapse
Accordingly to what You wrote about corrupted .tsw file I forgot to mention that after every copy of new .tsw to prg directory on SD card I :
1) always check .tsw file in prg directory via tgtool.exe software
2) from time to time I execute chkdsk utility to check SD card.
Only after point 1) and 2) I start sdll+ uploader.
Regards
fxdjacentyfxd

fxdjacentyfxd said:
B] always [/B] check .tsw file in prg directory via tgtool.exe software
Click to expand...
Click to collapse
That is smart! Did not know it before. Hope, other users will take it into consideration...

eskyt said:
That is smart! Did not know it before. Hope, other user will take it into consideration...
Click to expand...
Click to collapse
Reading posts about bricked tg01s I got to conclusion that some bricks were really becuase of corrupted .tsw or logical errors on SD card. So I have always thought it is worthy to waste 1 minute to check .tsw in prg directory than irreversibly bricked tg01.
P.S. Your case is really very, very strange. To "damage" bootloader it accepts only official roms.... I can not belive in it. Must be other explanation.
Regards
fxdjacentyfxd

fxdjacentyfxd said:
Must be other explanation.
Click to expand...
Click to collapse
... - and I am trying to find solution...

i agree with olyloh6696's opinions
when we flashed roms so many times,maybe our phone's NAND flash appear some bad blocks.it's really like the problems in HTC phones.
Maybe use Tgdownloader flash an Official rom will helpfull with this problem.
Anyway,when we cook roms,tgtool always check if there's any error in our custom rom,and we just make changes in OS partition,didn't change/edit anything with the Bootloader or Radio.So i must say the most possibility that brickes our phone should be the Flashing Progress.

eskyt said:
This is the riddle - what "changed" in the boot area, that compel my device to accept officials ROMs only (and only through 3 pin method), when customs (through sdll+) stopping it on Toshiba logo...
Click to expand...
Click to collapse
It is similar I wrote in my first post. Typically ( I am not going to check more ) I am not able to flash rom via 3-pin method if rom is not official. It seems I have always had this feature. I had maybe free "bricks" since I have tg01 , because of my experiments with drivers and so that to flash any good rom via 3-pin it had to be always official rom ! Fortunately sdl++ works fine for any rom.
Did You flash many custom roms ? Maybe one of them is "this one" and it is worthy to find out which it is.
On the other hand as I remember tgdownloader has feature to upload different areas of the rom separately ( boot area too ).
Maybe someone brave could upload this method boot area ? If it works You could upload Your boot area too.
I know, it is hardcore
Regards
fxdjacentyfxd

ffboy2009 said:
i agree with olyloh6696's opinions
when we flashed roms so many times,maybe our phone's NAND flash appear some bad blocks.it's really like the problems in HTC phones.
Maybe use Tgdownloader flash an Official rom will helpfull with this problem.
Anyway,when we cook roms,tgtool always check if there's any error in our custom rom,and we just make changes in OS partition,didn't change/edit anything with the Bootloader or Radio.So i must say the most possibility that brickes our phone should be the Flashing Progress.
Click to expand...
Click to collapse
yes, as no tool exist, the best method for us is for every ROM flash:
1) Hard Reset Current ROM
2) Flash Stock ROM
3) Hard Reset Stock ROM
4) Flash New ROM
5) Hard Reset
You could even go as far as Reflashing the same ROM over the same ROM again to eliminate further errors.
This is the recommended precedure to follow, however I usaully miss out steps 1,2,3.

My bootloader is dead and i don't have a solution...
Maybe one... bay Riff Box

Nokser said:
My bootloader is dead and i don't have a solution...
Maybe one... bay Riff Box
Click to expand...
Click to collapse
Well, I remember wonderfull times when any bootloaders were in OTP ROM or EPROM. None possibility to "kill" the device. Today is to be cheap, easy, universal and we pay for it.
Regards
fxdjacentyfxd

fxdjacentyfxd said:
Today is to be cheap, easy, universal and we pay for it.
Click to expand...
Click to collapse
...So true.
By explanation of feropont official ROM supposed to "zap" like kind of bad blocs in a flash memory (if any exist...), but, as we can see on my example Toshiba is "writing" every thing above of exist information without "cleaning" inside flash like task29 HTC is doing... He also mentioned that problems, mostly, becoming not in a boot area, but later, on the level of (qoute) "kernel initialization, xip..." - I am not prepared enough technically to discuss this llevel, but it is seems for me like I will stay with Malaysian ROM for ever...

eskyt said:
...So true.
By explanation of feropont official ROM supposed to "zap" like kind of bad blocs in a flash memory (if any exist...), but, as we can see on my example Toshiba is "writing" every thing above of exist information without "cleaning" inside flash like task29 HTC is doing... He also mentioned that problems, mostly, becoming not in a boot area, but later, on the level of (qoute) "kernel initialization, xip..." - I am not prepared enough technically to discuss this llevel, but it is seems for me like I will stay with Malaysian ROM for ever...
Click to expand...
Click to collapse
The main trouble is that the TG01 really does not make a general cleaning of flash Task 29 by analogy HTC devices. Judging from the descriptions of problems, bootloader is absolutely not damaged, it allows you to upload the whole flash ROM is not just any official ROM. The problems begin during kernel initialization XIP at the first boot device on any custom ROM. Every chef in the community TG01 anyway does not collect the full XIP, all cut-ins debuggers and encryption (kd.dll hd.dll mencfilt and etc). Unfortunately I have no time but first and foremost I would like to cook a custom ROM with the full original XIP, that would finally remove the issues in which there were bad blocks of flash in the kernel XIP or OS.nb.
Thx

feropont said:
The main trouble is that the TG01 really does not make a general cleaning of flash Task 29 by analogy HTC devices. Judging from the descriptions of problems, bootloader is absolutely not damaged, it allows you to upload the whole flash ROM is not just any official ROM. The problems begin during kernel initialization XIP at the first boot device on any custom ROM. Every chef in the community TG01 anyway does not collect the full XIP, all cut-ins debuggers and encryption (kd.dll hd.dll mencfilt and etc). Unfortunately I have no time but first and foremost I would like to cook a custom ROM with the full original XIP, that would finally remove the issues in which there were bad blocks of flash in the kernel XIP or OS.nb.
Thx
Click to expand...
Click to collapse
Thanks feropont.
Very interesting. You mean that if I cook my rom not removing any .dll from original XIP I will have more "safe" rom. Have any of mentioned dll's like for debug any influence on rom speed ( can be switched on-off after flashing ) ?
Bootloder part seems to be possible be overwritten too in some cases. Example, Noksers works.
Regards
fxdjacentyfxd

fxdjacentyfxd said:
Thanks feropont.
Bootloder part seems to be possible be overwritten too in some cases. Example, Noksers works.
Regards
fxdjacentyfxd
Click to expand...
Click to collapse
Unfortunately I can disappoint you, this is not an example of a new bootloader, and the result work of a new OEM, in particular, changed the entrance to the bootloader. Bootloader by definition can not be in OS.nb, he placed in the common part of the file .TSW who all mistakenly called RADIO, and if elementary compared Hex, the differences are almost no. Located in the very first sectors and is called MIBIB_BOOT.
Code:
*** MIBIB_BOOT Region Info ***
Region 0: "MIBI " start: 0 size: 80 r-size: 32 Ver: 0x0000 SubVer: 0x0000
Region 1: "SIM_ " start: 80 size: 48 r-size: 0 Ver: 0x0000 SubVer: 0x0000
Region 2: "FSBL " start: 128 size: 32 r-size: 24 Ver: 0x0000 SubVer: 0x0000
Region 3: "OSBL " start: 160 size: 32 r-size: 24 Ver: 0x0000 SubVer: 0x0000
Thx

feropont said:
Unfortunately I can disappoint you, this is not an example of a new bootloader, and the result work of a new OEM, in particular, changed the entrance to the bootloader. Bootloader by definition can not be in OS.nb, he placed in the common part of the file .TSW who all mistakenly called RADIO, and if elementary compared Hex, the differences are almost no. Located in the very first sectors and is called MIBIB_BOOT.
Click to expand...
Click to collapse
I have always thought , this device starts as typical ( known from microprocessors equpipped with boot section ) always from bootloader part but other circumstances decides whether after power up bootloder:
1) boot the system and "jump" to it
2) do other action like flash upload - check 3-pin condition or condition forced by sdll+ software
That is why I do not understand why Nokser can have completely dead device and not damaged bootloader.
Regards
fxdjacentyfxd

Since moving to Android I noticed most roms come with an md5 to check against the downloaded copy before flashing, just in case there is any corruption. Maybe a good idea to take a similar approach with tg01 roms.
I don't own my th anymore but flashed it in excess of 100 times using both sddl+ and 3 pins and never had any problems.
Sent from my Desire HD using XDA App

[Need help] Lenovo Yoga Tablet 2 830L BIOS Dump

Hello, I accidentally flashed my device on PVT Board with DVT firmware. Naturally, the tablet is no longer power on. Send me please a correct PVT dump for programmer. In advance, thank you very much.

attached... there's a risc processor inside the SoC that has anti-theft and firmware tpm technology so be careful at what you feed in your programmer

Thank you very much. But, if not difficult, write what exact tablet was this dump and how programmer.

crosstech said:
Thank you very much. But, if not difficult, write what exact tablet was this dump and how programmer.
Click to expand...
Click to collapse
it's not a dump, is the original firmware from Lenovo for 830 and 1050 models
do you have a hw programmer and if so what model? or you intent on buying one

All a little different. I passed the tablet to the service center and the master could not find a dump for the BIOS chip. All I know about the programmer, is the fact that it should support the flash mode at 1.8 volts.
However, plans to buy the programmer, if necessary.

crosstech said:
All a little different. I passed the tablet to the service center and the master could not find a dump for the BIOS chip. All I know about the programmer, is the fact that it should support the flash mode at 1.8 volts. However, plans to buy the programmer, if necessary.
Click to expand...
Click to collapse
he can use the file i attached, it was already used by many to restore their bios (with my restore kitkat bios tool for the 830-1050 models)
if he does in circuit programming he should leave the battery on and do a programming cycle, afterwards remove the battery connector then reconnect and now he can program (this is needed so that the processor hangs completely, the first time the programming will fail because the processor is still accessing at random times the bios together with the programmer, and the bios will have a bricked firmare, but after that if he removes then plugs back the battery then the processor will hang completely and this time programming will succeed
the thing is not only about the programmer but about your expertise in doing the job, the components are small and you will need the specific smd tools, a special connector that might not even connect as it was in my case due to the placement of the ic, so i had to solder very thin wires on the spi, all in all it's a risky job and you must have the know-how to do it. i am not discouraging you, just trying to say that if you have comeone who did this kind of stuff before let him do it.

Thank you very much for your advice. I will look for the wizard, if I don't, I will try myself. Although I had this experience only with laptops.

please help i also need to flash the bios as my 830LC wont turn on after OTA.

nsxt99 said:
please help i also need to flash the bios as my 830LC wont turn on after OTA.
Click to expand...
Click to collapse
could anyone tell how to differentiate PVT & DVT board?
i tear down my 830LC & found the bios contain in a 25Q64FW chip whereby its support by my RT809F programmer.

nsxt99 said:
could anyone tell how to differentiate PVT & DVT board?
i tear down my 830LC & found the bios contain in a 25Q64FW chip whereby its support by my RT809F programmer.
Click to expand...
Click to collapse
there are no PVT or DVT boards, those are manufacturing stages (PVT being the ready to ship one, while DVT is only used in factory). you can use the file in the zip i attached a few posts above.
is the programmer capable of programming at 1.8V? the FW and DW chips from WinBond are working at 1.8V nominal Vcc (with a peak transitory absolute maximum voltage of Vcc+1V = 2.8V) if it is a 3.3V programmer could cause issues (can work but it can also cause problems)

Hi,
Could anyone please re-post the BIOS file that ionioni attached before? Thanks so much!

find the attachment of BIOS file you want
serepok said:
Hi,
Could anyone please re-post the BIOS file that ionioni attached before? Thanks so much!
Click to expand...
Click to collapse
here attached
if need more help then attach pics with problem description.
Regards

Thank you so much @KAASHP

will this bios work on 1050? how do we apply it?

Thanks for your

Sage said:
will this bios work on 1050? how do we apply it?
Click to expand...
Click to collapse
This works for Lenovo Yoga 830 series. Also may be work on 1050 variant.
you can try it for your device probably it will not brick your device.
reply here if you succeed. good luck :good: