yashsingh1/xdaforums huggingface dataset:
[JASJAR, XDA Exec, MDA Pro Software Upgrading] orb3000:
First thing is to read the Wiki here:

http://wiki.xda-developers.com/index.php?pagename=Uni_Stuck_Bootloader_Serial

Second enjoy your Uni

Third please vote!
[JASJAR, XDA Exec, MDA Pro Software Upgrading] rapboy23:
nothing

problem unknown device .usb dont recognize :( ım trying uniexitbootloader .exe cannot run open port fail
[JASJAR, XDA Exec, MDA Pro Software Upgrading] paulorosa:
Sorry I think you have a broken device....

I have one also...

I put the bat in uni, and red light go on (some times) and then off...

after this no lights , no green no red...

No bootloader

and connecting to PC, says unrecognized device....

So It's broken.. The only way I thonk is try to flash the FPGA chip... or maybe via SDCARD...
[JASJAR, XDA Exec, MDA Pro Software Upgrading] rapboy23:
whats fgpa chip?

:(sdcard install rom how? and ı havent jtag .my jasjar blank screen always and when connect to pc recognize unknown device xp .ım searching wiggler jtag cable? ı need eboot for jasjar .:( ı m trying bootloader mode power-backlight -reset nothing -*- reset nothing power-reset coldreset nothing all .what must ı do? sdcard rom install how and try flash fpga chip ?
[General Questions and Answers] Andrewwelton:
I've updated to NFSFANS WM6.5 ROM. Just wondering if theres a way i mess arouind with the registry or something and make it so that when i go to the music tab, it will launch S2P instead of WMP?

Is there a way to do this?
[General Questions and Answers] nir36:
has been tried before. i think there was no success there.
[Touch Diamond, MDA Compact IV ROM Development] bluefaces:
Hello Folks, I am trying to search for the removal on Unsigned HardSPL 1.40 OliNex and not finding any search results for the removal?

Would appreciate any help as I am planning to sell my device HTC Diamond?

Thanks in advance.
[Touch Diamond, MDA Compact IV ROM Development] criszz:
stock SPLs here >>> http://xdaforums.com/showthread.php?t=400950&page=4
[XPERIA X1 General] reybrujo92:
Hi, im searching for the touchflo from rodium for the manila, but i have only found a touchflo wich is for diamond and it seens bad, all the rhodium projects of this web are in english roms,... the touchflo i think it es multilanguage and im looking for a spanish version, tnahx
[XPERIA X1 General] duikeend:
use the search function it's already posted.

http://xdaforums.com/showthread.php?t=493531
[XPERIA X1 General] reybrujo92:
i dont uderstand how to instlla it at xperia
[XPERIA X1 General] duikeend:
Just read it i have already installed on my X1i.
[XPERIA X1 General] reybrujo92:
i instalkl it , but in the menus and things, there is not for example phone, it says id_phone or things like this...
[XPERIA X1 General] bunnyying:
I have installed but has some problem

the res. is not 480 x 800 ,it just 480 x 640

isn't this problem can be solve????
[XPERIA X1 General] fdmedia:
Yes, is this TouchFlo from Rhodium fully suiteable for X1?
[XPERIA X1 General] X4B4R4S:
This TouchFlo not work fine to X1 because is make for Diamond...

Diamond = VGA

X1 = QVGA
[XPERIA X1 General] dogans:
lol no. X1 = WVGA.
[XPERIA X1 General] reybrujo92:
Thath the problem, i have luck and i known that 5 person are workin in a spansih rom with rhodium for xperia... ^^
[XPERIA X1 General] GameEmperor:
But, Rhodium is WVGA same as X1. So, It will be works on X1.
[G1 Android Development] hoang_q_trung:
i accidently installed an rc30 version of a theme when i have rc33 and now my phone is stuck at the tmobile g1 screen? is there a way around this or am i screwed now?
[G1 Android Development] jaiholmes:
Youre going to either get someone else's g1 or a sd card reader and flash rc33 again to the sd card
[Windows Mobile Development and Hacking General] xdadevc:
This is not stricty a phone question.. but I don't give hope.

I'm looking for a way to change the "screen timings" in the driver of a Windows CE Core 5.0 device (perhaps hack it some way).

The problem is that this is a sample gps unit from a chinese marketer that is displaying on a 480x234 wide screen via some sort of analog interface with an input of 320x240 (native quarter vga). As you guess the result looks very bad, and I am hoping that changing the timing to 480x234 will be enough to the analog sync circuit to pick it up.

Any ideas?

xdadevc
[G1 Android Development] MartinFick:
Has anyone thought about implementing password protection to the G1's adb interface? If someone finds (steals) your phone, it' seems like they can get easy access to your data using adb if it is enabled? Instead of forcing the default to adb-debug disabled, it seems like requiring a password would be more useful?

I realize that this might be risky since it might prevent recovery when the password is forgotten, but at that point, there is still the "wipe all my data" unlock method right?

Without this, I find it hard to trust any sensitive data to my phone (since I do not want to toggle adb on/off constantly).
[G1 Android Development] Perrosky:
I agree with you any one who find our g1 or steal it, can find easy in the internet how to use adb, or they can even find out how you can do a wipe if you turn the phone off and start the phone using Home+Power button. And they will be good to go to use the G1. I hope someone can add a password protection to this 2 options.
[G1 Android Development] MartinFick:
I guess it might be nice to add a password option to the "wipe" option, but that seems like it would sorta defeat the purpose then, wouldn't it?

I am more concerned about my data than the device itself. If someone steals my phone and they can't use it, it doesn't really help me. But, if I can at least prevent them from reading my data... I envision using my phone as a secure token to access various logins at some point (anyone want to code that up? :). So, I just want to ensure that they cannot get any keys/passwords on it.

The other problem with preventing someone from wiping it is, "what do you do if you forget your own password"? I would prefer to let the thief use the phone (without my data) than to potentially brick the phone for myself. Lastly, locking it permanently off to thieves would not be a deterrent to theft unless every phone did it since they would not know about it until they stole your phone!

I am surprised that the "serious" hackers have not implemented adb protection yet, have they?
[G1 Android Development] xile6:
Yea its kinda a good and bad thing tho. Look at it like this .

You put the password on your phone to stop people from doing anything to it, then you forgot your password, how do you get back in? You cant. Unless you have a way around that which if you have a way around that the thief would to.

The only thing i would like is to be able to protect files so if you lost your phone someone wouldn't be able to get into it without wiping the phone.
[G1 Android Development] Perrosky:
I agree with you and at the same time don't (right now I don't put personal files in my sd for that very reason if I lost the phone anyone can see what I have on the sd) regarding to the password I guess that it will be up to the people if you know that you forget passwords just don't use it I personally use 2 password 1 for forum 6 letter something simple and easy to remember, and one for (very important stuffs) 12 characteres letters and numbers. Plus I thing that everyone in that will be using this are people to frequent this forum wich I don't think they tend to forget passwords.
[G1 Android Development] lbcoder:
In order to gain access to program data (not applicable to sdcard), you still need to be either root, or to possess the userid of the particular program whose data you're trying to gain access to. Use of one of those secure-root password prompt programs will give you the ability to limit root access since the 'su' command will fail without the password being entered in the GUI.

This is not absolute though, since you can still boot on a recovery image, backup, and extract. Without actually encrypting the storage, there is no way to absolutely protect your data, and with a mobile device, the encryption/decryption overhead will take up too much CPU time to be practical. It could, however, be implemented on a program-by-program basis or on a data-but-not-program basis, i.e. encrypt /data/data, or /data/data-enc might be a better idea - leave data for user-programs encrypted, but system-services unencrypted, and mount the encrypted partition on screen unlock (i.e. password unlock). LUKS would be great for this. Allowing optional encryption for SD-card and allowing multiple SD-card partitions to be mounted (i.e. one encrypted, one not) would be ideal.
[G1 Android Development] MartinFick:
Well, perhaps the bootloader should get a password also? Would having both an adp and a bootloader passwords secure things completely?
[G1 Android Development] lbcoder:
Of course not. Bootloader passwords are virtually useless. All they do is stop you from booting, they do nothing at all to protect your data except from a real amateur, the likes of whom wouldn't be able to get your data off the thing even WITH root access.

As long as there is unencrypted data stored on the device, it definitely can be read off.
[G1 Android Development] MartinFick:
Could you please explain why you believe that a bootloader password would not work?

In other words, if a user is locked out from performing commands via the screen without the appropriate gesture, locked out from using adb without a password, and they cannot boot into the recovery image (or access NVRAM with fastboot) without a password, how can they access data on the internal NVRAM? I am not saying they can't (I don't know), I am asking what method you think they could use? Can the NVRAM be easily removed and plugged into another device and read? Are there other boot methods that I am not aware of (likely, I am fairly new to this) that would allow them to access the data? Or, are you just assuming that there is a method that an intelligent cracker could use?
[G1 Android Development] lbcoder:
1) you can use fastboot to boot off a recovery image file that is NOT ON THE PHONE,

2) you can connect directly to the chip and read its contents.

etc.

Keep in mind the way that bootloader passwords work; the password is NOT embedded in the bootloader - that would be stupid since you risk bricking the device every time you change the password. A password protected bootloader will access some configuration file that will have the details of the password. Fastboot would (and must) come before this stage.
[G1 Android Development] MartinFick:
It seems like you are pretty much just repeating/rewording the weaknesses already pointed out? I am not trying to be rude, if you do have some extra info, or there is something subtle that I am missing, please accept my apologies.

Specifically:

#1 should be assumed to be prevented by the bootloader password, no? Is there any reason you think this would not be effective?

As for #2, I was already asking if the NVRAM could easily be removed from the HTC? Do you have any useful info on this, on what it would take to do it? I assume this would require surface mount de-soldering?

My personal threat model would assume that my data is less valuable to a thief than my phone is. While I would prefer my data to not be easily acquired by a thief, I have nothing so secret that I would expect a thief to specifically steal my phone for it. Therefor, I assume that a thief has no incentive to destroy my phone (which he is in possession of and can use) just to get at my data. Of course, if there is an easy method to get my data (there currently are easy software methods), I would expect a thief to do so. I am hoping to close those easy software methods. If there are easy hardware methods, such as unplugging a chip or sdcard and simply inserting it into another phone, well, then perhaps the software holes are not worth plugging. But, any hardware hacks involving soldering (especially surface mount soldering) the phone are beyond my desire to foil.

Again, that is my personal objective, I understand if you do not share it. Can you think of any additional info that might be valuable with this in mind?

Thanks!
[G1 Android Development] lbcoder:
No, bootloader password won't help you here, and I already explained why.

Sure, thats one way. The other way is by whatever mechanism HTC uses to initially write the bootloader to the device. I haven't looked, but there is probably a jtag port or something similar on it somewhere.

Unfortunately, even if it were possible, securing it against that possibility isn't going to help you since the thief doesn't know that its worthless to him. He'll steal it anyways, and then garbage it when it turns out to be useless to him.
[G1 Android Development] MartinFick:
Uh, no you didn't. You rambled on about the password being in some config file and therefore assumed that it would not be possible or desirable to actually implement a proper bootloader password. I do not accept this criticism, people reflash their bootloaders all the time and it is up to them to determine the level of "brick risk" they want. Perhaps you don't like it, that doesn't make things impossible.

As for putting the password in a config file somewhere, it is not the only solution, one could easily create a separate tiny partition just for the password if you did not want to put FS reading code into the bootloader. (That was your point, right? That the bootloader is simple and cannot read a filesystem?) Surely the bootloader knows how to read partitions, or how would it be able to boot the kernel? With this you could reduce most "brick risk" by providing a "boot from external kernel for recovery after wiping the partitions" option.

And, finally, perhaps there is some other minimal byte storage on the HTC Dream where a password could be easily stored? Something analogous to the CMOS of a PC, something the bootloader could easily read/write to change the password?

Valid concern, easy for someone with the right tools, and some very specialized expertise perhaps. I would be plenty happy to foil all thiefs who do not own such tools or have such knowledge, I believe those are the ones likely to steal my phone.

Why is not going to help me? If he can't get my data (easily without desoldering), it helps me. I agree and already pointed out that it would not be a deterrent. Nowhere in my objective did deterrence come up.

You make some good points, points that are worthy of serious consideration for anyone attempting to implement this, but I would say that your points hardly make it impossible, in fact, they illustrate very well what a designer would need to consider! Thanks! :)
[G1 Android Development] lbcoder:
I never said that *anything* was impossible. I simply pointed out that IF the password was compiled into the bootloader, then THAT would be extremely dangerous since rather than trying out a tried and true bootloader, every change of password would be a serious brick-risk.

Regarding partition vs file, there is no difference. A partition *IS* a file in a very simple filesystem -- that which we refer to as a "partition table". As such, the risk is identical. I certainly did not suggest that a bootloader is incapable of reading a filesystem, the reverse is in fact, and MUST be true, since if the bootloader couldn't read the filesystem, then how is it to load something that is stored on said filesystem? The point is that if the filesystem were in some manner corrupted, overwritten, updated, etc., then so is your ability to boot the system PERMANENTLY, unless you maintain fastboot prior to the password, in which case it is trivial to boot off a different system image anyways, or unless you go to hardware level to unbrick the device, the same approach, of course, could be used by someone else to gain access.

Oh, and when you say "My personal threat model would assume that my data is less valuable to a thief than my phone is.", that suggests that your priorities are hardware first and then data.

I still say that the most feasible approach to this is selective encryption. Keep the important data from being accessed and not worry about the hardware, since there is no technical way to make it undesirable to a thief except, of course, to make it real ugly. Pack the thing into an old-style Palm case. Take a look into LUKS. It could *definitely* be made to work and is probably easier than you think. What you would have to do is first install support for it at the system level (that might require that you rebuild the kernel), encrypt a partition on the SDCARD with it, and link password, mount, and unmount into the lock screen. Once thats done, you just move and symlink important data onto the encrypted partition. For that matter, you don't even need to automate it with the lock screen, you can just write an app to password, mount, and unmount, or even run it from the terminal. Yes, this is just a linux device. This approach is barely more than trivial.
[G1 Android Development] MartinFick:
Sorry, the sentence below sounded like you were implying that it is was impossible.

No, it suggests that those are the priorties of the thief. I don't believe a thief would steal my phone for its data. I accept that it can be stolen easily or that I might simply leave it on a table in a restaurant or something. At that point I would simply prefer that no one be able to easily snoop my personal affairs. Currently it is VERY easy. I had adb access to my phone before even using the screen, (I needed to register via wifi), it really is simple, it takes little expertise.

Call it what you will, I was giving you the benefit of the doubt.

Many bootloaders do not understand the filesystem they load from, they simply get a pre-created list of the disk blocks to load a kernel from and then load them and execute them.

For someone who seems to understand things well, you seem to willingly miss important points already mentioned:

You encryption points are well taken, they probably would be simple to implement, however they would likely have a significant performance impact.
[G1 Android Development] lbcoder:
Only if you're encrypting everything (i.e. programs). There is no reason to encrypt everything -- just encrypt the data you want to protect. There is no reason to bother encrypting apps that you install or the operating system since this is all available elsewhere. If you have private documents, emails, etc., keep those encrypted. The performance impact will be negligible since these files will be fairly small.
[Touch Pro, Fuze Themes and Apps] babyhughhef:
First I would like to say thanks to everyone on this site I have found helpful info on everything so far....

The problem I am having is as follows, I use my phone for almost everything, as I am sure most of y'all do too. But I also use it for everything in my car, I only have a A2DP stero in the car, no cd etc etc... I stream all my music thru the phone (AT&T Fuze) run TomTom etc... the problem I am having that I didn't have with the Tilt is that when I press the next/back etc buttons it automaticlay brings WiMP to the front and hides TomTom, or other Media Players I may be using. This is really annoying, I mean going 75mph down the highway I can't just reach up there and click close everytime n the switch back to TomTom.... any help would be much appriciated.....
[Touch Pro, Fuze Themes and Apps] ftdn2006:
bump bump bump

I hate the way media player hijacks my bluetooth a2dp headphones when I want to use it with pocket music or coreplayer
[Touch Pro, Fuze Themes and Apps] baboola:
pocket music has a plugin that overrides wmp's ad2p control. found this through dr. google

http://www.conduits.com/products/player/plugins.asp
[Touch Pro, Fuze Themes and Apps] kfd19:
I am having the same exact problem. It is extremely frustrating! This is the only thing i have not been able to fix on my Fuze and it is driving me nuts! I have tried the stock ATT rom, various cooked roms, and am currently using HTC rom 5.05.405.1 WWE with radio 1.11.25.01. I have also tried multiple BT Stereo devices including Moto T505 and Gold Lantern mbsh-c3.2 having same results on both. However, i have noticed that occasionly it will function correctly allowing me to play/pause prev/next without tomtom losing focus. This is completely random and i am unable to reinact this on demand. If you find out anything else, please let me know.
[Touch Pro, Fuze Themes and Apps] Peerkelala:
Also having this problem

Also having this problem.

I'm using "A2DP Toggle" in combination with "auto a2dp manager" to auto connect my HTC touch HD to my car stereo. This works fine.

Then, in a perfect world I would like to start pocket player instead of media player when i press "next" on my car stereo.

Then once I've started tomtom and I press next again to go to the next track TomTom should stay on top. Or even better show my pocket player playlist for 5 seconds and return to tomtom.
[Touch Pro, Fuze Themes and Apps] CLYGOR2003:
Donwload: Conduits WMP Plugin Adapter 2.31

After installing, check the "Intercept WMP" and "HTC WMP" boxes on the Menu > More > Options > Plugins > WM Adapter > Configure screen.
[Touch Pro, Fuze Themes and Apps] dgaud007:
This is what you want:

http://xdaforums.com/showthread.php?t=545737

Capt. T's BT driver! Works for me!
[Touch Diamond, MDA Compact IV ROM Development] p.brazauskas:
Hi,

I'am new here, an my phone is also new for me :)

Question is witch Radio is best for my country, or my provider? I live in Lithuania, and my provider is Bite GSM.

My phone is stock:

Rom: 1.37.414.3 WWE

Rom date: 07/02/08

Radio: 1.00.25.03

Protocol: 52.26a.25.09H

As I understand, new Radio could inprove a little my batery life? Or I'am wrong?

Thanks in advance.
[Touch Diamond, MDA Compact IV ROM Development] band27:
You are right, with the right radio you can definitely improve your battery life. However, your question of which radio is the best for your country can't be answered by any of us here on the forum. The answer to your question will ultimately come from you because radios are dependent on location. Even if I lived in the same country as you, it still wouldn't help.

Bottom line is to try them and see which you like best based on your observations. If you look at this thread below, the polls will tell you which are the more popular ones. That's where I started from.

http://xdaforums.com/showthread.php?t=470306
[Touch Diamond, MDA Compact IV ROM Development] p.brazauskas:
Bottom line is to try them and see which you like best based on your observations. If you look at this thread below, the polls will tell you which are the more popular ones. That's where I started from.

http://xdaforums.com/showthread.php?t=470306[/QUOTE]

Thanks, for advice
[Touch Diamond, MDA Compact IV ROM Development] band27:
Make sure you Hard SPL your device before you flash your device.
[Touch Diamond, MDA Compact IV ROM Development] p.brazauskas:
I have to read more about that :)

What other tweaks you recoment for a beginer like to imruve my phone?
[Touch Diamond, MDA Compact IV ROM Development] band27:
Always good to have the basic tweaking tool:

Config. 3.3 Tool

Diamond Tweak is also good. I will let you search for that one.....:p
[Touch Diamond, MDA Compact IV ROM Development] liamhere:
no such thing as best for country...

only way to find out whats best for you is to get flashing

other members have pointed you where to go....good luck

thread closed.
[General Questions and Answers] Xcloud1990:
Hi, i don't know if this is the right place, if not, forgive me!

I'm looking for a COOKED ROM for the eten glofiish..possibly in italian!

If you know where I can find one, please post some link below..

Thank you!!;)
[General Questions and Answers] the-equinoxe:
There is a nice e-ten forum: http://eten-users.eu

They have plenty of nice e-ten ROMs.

(you may even recognise some user-names there ;) )
[General Questions and Answers] Xcloud1990:
Thank you equinoxe, there are lots of roms in the forum you said me, but no one for M810..