Anyone know of a micro USB to RS232 Serial adapter?
or for that matter if the Epic can be used in USB Host mode?
My goal, is the be able to use my Epic 4G to run a terminal link to some control boards using ZiLog Z8F processors, I work a job as a field technician on energy management controls. Currently I lug a net book around to flash and terminal into the controls.
If I could do the same without having to drag my net book with the rest of my tools, that would be incredibly awesome for me, I'm always trying to find ways to minimalism the amount of gear I have to carry from my truck to the boiler room.
Thanks
The only thing I have seen that comes close to what you are asking is this thread in the dev section: http://forum.xda-developers.com/showthread.php?t=833373
I dont have any information other than the link, but thought I would at least point it out.
Thanks, at least now I know where to ask questions and pick peoples brains!
If you could find the appropriate cord and drive it from your epic.
I used this back in the day (not from a phone) when I lacked a RS232 port on my devices...
I have seen adapters that would likely drop the usb to micro easily enough but.. thats the least of the difficulty
http://www.newegg.com/Product/Product.aspx?Item=N82E16812999081&nm_mc=OTC-Froogle&cm_mmc=OTC-Froogle-_-Mac+-+Accessories-_-KEYSPAN-_-12999081
really not sure if it could even make this work from an epic, lacking any readily available drivers though.
thesals said:
Anyone know of a micro USB to RS232 Serial adapter?
or for that matter if the Epic can be used in USB Host mode?
Click to expand...
Click to collapse
If you can relax your requirement for USB, then use IOGear RS-232 Bluetooth Serial Adapter (model GBS301). I use this along with the app BlueTerm on the market. Works for all of my RS232 needs.
Greg
http://www.bb-elec.com/
Might be worth a shot. I didn't see anything looking quick, but I know they have lots of different options and if all else fails custom build components as well.
A USB serial adapter won't work with the stock rom (or any custom rom not implementing usb host/otg).
In theory, it's possible to repurpose the usb port's pins as gnd, txd, rxd, and a resistor of specific value that tells the phone to electrically route their signals to pins on the SOC chip with txd & rxd functions at nonstandard voltage levels, but I'm not aware of anyone who's literally gotten it to work on the Epic, yet.
Note that serial via this method has *nothing* to do with usb; it's just temporarily repurposing the pins & connector for serial use.
Sent from my SPH-D700 using XDA App
I would normally coordinate this with some of the devs on IRC but I don't have access to it at the moment.
Obviously a lot of work is going into a Gingerbread kernel bringup from the posted Samsung sources, and last I heard on IRC before leaving my house was that some devs were having issues getting kernels to boot.
Now, the chip on our phones that handles USB has a UART mode, where the data pins on the USB connector get routed to a serial port instead of to USB.
I have a bunch of MicroUSB breakout adapters on order from Sparkfun now (http://www.sparkfun.com/products/10031) and will be picking up a few 150k precision resistors (150k is the value for UART mode) on Saturday most likely.
My questions:
1) Will this be useful to the other kernel devs for debugging?
2) Do our kernels even output anything to the serial port that the FSA9280 routes to, or is this bootloader-only?
Obviously the specific answer for our device is unknown since I don't think anyone has tried it, but has putting a 150k resistor on ID resulted in being able to get the kernel console on the serial port on GalaxyS devices? If it works on them it should work on ours.
No clue unless you try. ;-) Would make things easier if the kernel did get compiled with serial console though I would imagine.
LinuxBozo said:
No clue unless you try. ;-) Would make things easier if the kernel did get compiled with serial console though I would imagine.
Click to expand...
Click to collapse
I'll start working this once the parts arrive - will see how the Froyo kernels behave then we can try to migrate it to GB if anyone is still having issues then.
Of course it could all become OBE.
Entropy512 said:
I would normally coordinate this with some of the devs on IRC but I don't have access to it at the moment.
Obviously a lot of work is going into a Gingerbread kernel bringup from the posted Samsung sources, and last I heard on IRC before leaving my house was that some devs were having issues getting kernels to boot.
Now, the chip on our phones that handles USB has a UART mode, where the data pins on the USB connector get routed to a serial port instead of to USB.
I have a bunch of MicroUSB breakout adapters on order from Sparkfun now (http://www.sparkfun.com/products/10031) and will be picking up a few 150k precision resistors (150k is the value for UART mode) on Saturday most likely.
My questions:
1) Will this be useful to the other kernel devs for debugging?
2) Do our kernels even output anything to the serial port that the FSA9280 routes to, or is this bootloader-only?
Obviously the specific answer for our device is unknown since I don't think anyone has tried it, but has putting a 150k resistor on ID resulted in being able to get the kernel console on the serial port on GalaxyS devices? If it works on them it should work on ours.
Click to expand...
Click to collapse
Ithink it would be pretty cool if you could break out to a proprietary apple connector. house it so you can adapt to any music dock that normally uses an ipod or iphone. That way we have integrated power and music out.
adam outler used the uart in a project and was hoping to find a way to unbrick without a jtag even with bad bootloaders. i have an arduino board like the one he used and could build his jig, i dont know much about kernels or c programming but if i can help figure anything out or if adams work (i havent kept up) was successful and we want an unbrick service for botched bootloaders and param.ifs let me know.
I'm using this board in a AOA project and everything is working fine, however it is not charging.
On this board, there are two regulators, one for main power to the PIC rated for 500mA and a second for USB rated for 1A. When I connect the tablet to the board, I measure only 500mA going to the tablet.
I contacted the company and they assured me that the 1A regulator is connected to the USB power. The suggested that I check if there is a setting for the tablet that would allow it use the extra power that is available??? Apparently they had a similar issue with another tablet and they made this tweak and it worked fine???
I realize that I would get better results with using the adapter included in the box, but I would still like to be able to have a tablet that doesn't die when I'm using this board.
I did find this post which is for the Galaxy Tab 10.1, more specifically DefQoN_BE response, but when I went looking, I could not find anything that looked remotely related to what they suggested.
Any tips on the matter is greatly appreciated and I will be sure to keep this post updated on any progress I make.
Currently running: Fire OS 7.3.2.1 - Fire HD 10 (2021 - 11th gen)
I think anything is possible. I don't want to hear that Fire OS 7 is "unrootable". Nonsense!
I also don't see many threads for this generation of the device on here, which is why I opted to make this thread.
But seriously, I want to try and tackle this crazy complex puzzle. Fire Toolbox is amazing and really improves the performance of the tablet. But I just want more. Would anyone have any tips on how to start brainstorming and planning how to find any vulnerabilities within the device/software? Are there certain files on the device I have to look in? Maybe running some scripts or doing some programming? I really wanna see what I can contribute but I just have no clue where to start.
I guess it would be helpful to mention what my personal end goal with this tablet is:
Unlock bootloader
Root
Install custom roms (upgrading Android version)
Any feedback/ideas/brainstorming/thoughts of any kind would be much appreciated!
How about HD8 plus latest edition android 11 12th gen? Google Play having issues installing. Tried manually as well as fire toolbox 29.2.
nsfxpython said:
Currently running: Fire OS 7.3.2.1 - Fire HD 10 (2021 - 11th gen)
I think anything is possible. I don't want to hear that Fire OS 7 is "unrootable". Nonsense!
I also don't see many threads for this generation of the device on here, which is why I opted to make this thread.
But seriously, I want to try and tackle this crazy complex puzzle. Fire Toolbox is amazing and really improves the performance of the tablet. But I just want more. Would anyone have any tips on how to start brainstorming and planning how to find any vulnerabilities within the device/software? Are there certain files on the device I have to look in? Maybe running some scripts or doing some programming? I really wanna see what I can contribute but I just have no clue where to start.
I guess it would be helpful to mention what my personal end goal with this tablet is:
Unlock bootloader
Root
Install custom roms (upgrading Android version)
Any feedback/ideas/brainstorming/thoughts of any kind would be much appreciated!
Click to expand...
Click to collapse
Sorry to burst your bubble of illusion, but it's practically impossible. The latest unlocking methods (amonet, kamakiri) exploited bootrom to achieve arbitrary RW of the eMMC. However, as you may well know, Amazon has disabled bootrom on their newer devices (or even on the 'older' ones, with OTA updates - that's called blowing fuses -). Considering the conditions presented, the chances of unlocking the new devices are minimal if not nil.
If you really want to do some research to find something useful, find an exploit in the preloader, which is still accessible. Another thing that could be useful is a root shell (even if it is temporary). That requires you to find some exploit that fits your kernel (which is probably new, considering the Android version).
That said, don't expect this to be a piece of cake.
A temp root shell should be possible via the waiting game. We could watch the still opensource upstream android OS code for possible kernel exploits. Then just find a way to run a found exploit in a fire hd before amazon rolls a patch OTA. Fire OS is highly customized, but obviously is still android in there somewhere.
The Android platform certs got leaked somewhere and are being used to sign malware as per this issue on the chromium bug tracker: https://bugs.chromium.org/p/apvi/issues/detail?id=100
It might be possible to spoof an application's signature to be that of the android uid using whatever those certs are to gain root access. Probably just grasping at straws here though.
loocool2 said:
The Android platform certs got leaked somewhere and are being used to sign malware as per this issue on the chromium bug tracker: https://bugs.chromium.org/p/apvi/issues/detail?id=100
It might be possible to spoof an application's signature to be that of the android uid using whatever those certs are to gain root access. Probably just grasping at straws here though.
Click to expand...
Click to collapse
Smart idea! MediaTek is also affected.
Now only a public key-list is needed to run apps on system level.
Fire OS 8.3.1.1 gives elevated access to system apps via USB debugging; see here. likely another Amazon mistake - too bad its never been released on Fire HD 10.
Isn't there something about taking it apart and shorting the motherboard somewhere like the old psp battery.
Brettroth said:
Isn't there something about taking it apart and shorting the motherboard somewhere like the old psp battery.
Click to expand...
Click to collapse
Unlikely, i assume the motherboard got updated with last iterration of the 11th gen fire lineup
I don’t know the significance of this, but I was playing around with some old equipment that I had laying around and ran across something interesting. I don’t have the time or knowledge to do anything with it however…
I plugged one of these usbc converted into my HD 8 2020 and 2022. https://a.co/d/bRtoBPw
I then plugged in a uart cable that I had built for a different project. Which is essentially the nexus debug cable with a male USB end instead of a headphone jack. ( https://wiki.postmarketos.org/wiki/File:Nexus-debug-cable.png )
I did try the headphone jack, but there is no output from there.
Looking at the output during boot up it sure looks like uart to me, I can’t seem to get the baud right - I tried everything that minicom has without success.
Long story short, I’m pretty sure there’s uart hidden in the USB c connector on the HD 8 2020 and 2022 devices.
Reverse-anastomosis said:
I don’t know the significance of this, but I was playing around with some old equipment that I had laying around and ran across something interesting. I don’t have the time or knowledge to do anything with it however…
I plugged one of these usbc converted into my HD 8 2020 and 2022. https://a.co/d/bRtoBPw
I then plugged in a uart cable that I had built for a different project. Which is essentially the nexus debug cable with a male USB end instead of a headphone jack. ( https://wiki.postmarketos.org/wiki/File:Nexus-debug-cable.png )
I did try the headphone jack, but there is no output from there.
Looking at the output during boot up it sure looks like uart to me, I can’t seem to get the baud right - I tried everything that minicom has without success.
Long story short, I’m pretty sure there’s uart hidden in the USB c connector on the HD 8 2020 and 2022 devices.
Click to expand...
Click to collapse
Update:
I think that what I was seeing was probably just garbage from the USB OTG adapter that I was using. That would explain why I couldn't get the baud rate right.
I built a cable that should have worked the same way, without using the adapter, and got nothing back from the device.
MTK devices usually don't use the ID resistor method on their debug cables, but I did try that as well with various resistances - without success.
If I could figure out what multiplexer these devices use, I might be able to get somewhere, but as it stands, I think it is a dead end. If they left UART open on the device, it could lead to a root solution - and it doesn't appear that this has been investigated.
The boards on both the 2020 and the 2022 have pads marked RXD and TXD, I tried connecting directly to these without any success, so they must be turned off. I attempted to turn UART on via fastboot, but any OEM commands I tried were locked (not surprising)
If anyone has a USB C breakout like what is used for Google debugging; it would be interesting to see if it did anything. I don't have one, and don't really need one.
If anyone has any other ideas, I am willing to use my devices for testing. The 2020 model is pretty beat up by my kids, and it won't break my heart if I kill it. I got a pretty rocking deal on the 2022 model, I'd rather not brick it, but am willing to take some risk.
Reverse-anastomosis said:
Update:
I think that what I was seeing was probably just garbage from the USB OTG adapter that I was using. That would explain why I couldn't get the baud rate right.
I built a cable that should have worked the same way, without using the adapter, and got nothing back from the device.
MTK devices usually don't use the ID resistor method on their debug cables, but I did try that as well with various resistances - without success.
If I could figure out what multiplexer these devices use, I might be able to get somewhere, but as it stands, I think it is a dead end. If they left UART open on the device, it could lead to a root solution - and it doesn't appear that this has been investigated.
The boards on both the 2020 and the 2022 have pads marked RXD and TXD, I tried connecting directly to these without any success, so they must be turned off. I attempted to turn UART on via fastboot, but any OEM commands I tried were locked (not surprising)
If anyone has a USB C breakout like what is used for Google debugging; it would be interesting to see if it did anything. I don't have one, and don't really need one.
If anyone has any other ideas, I am willing to use my devices for testing. The 2020 model is pretty beat up by my kids, and it won't break my heart if I kill it. I got a pretty rocking deal on the 2022 model, I'd rather not brick it, but am willing to take some risk.
Click to expand...
Click to collapse
Double Update:
I couldn't accept my failure - so I decided I had to sacrifice the 2020. I tore into it - and spent an unreasonable amount of time getting to know it with my multimeter. I stuck my probe where few have probed before!
I found an area around the main chip with an interesting bit of shielding and though to myself - you sneaky old amazon...what are you hiding here?
I found a nice little row of 4 pins...which have a hardwire connection to the USB-C port - on pin #3, or #6 depending on which direction you count from - and ground.
I am now 100% certain that the UART to USBC connection exists. I don't own a cable that outputs that pin - and unpowered my USBC-USBA OTG adapter does not output that pin - I assume that when it is powered with the resistors there must be enough crossover somewhere to see that a signal exists, it is just too corrupted to understand by the time it hits my serial/USB adapter.
I did throw my multimeter on the visible TXD testpoint on another 2020 device, and it did show some rapidly shifting voltage up to 1.8 volts during boot - so I assume I must have damaged the other one when I was soldering my jumper to it, so it must be outputting something. Also, there are RX0 and TX0 on the back of the logic board - when I get my replacement testing board I will investigate those for anything interesting before I fry it with random components(see below)
I plan on purchasing a USBC cable with all of the pin wires, and hooking it up to see if we can get rx and tx - Maybe Console? I can't tell for sure, but it looks like the same row of pins are present on the 2022 model, so this probably translates to that device as well.
Also, of interest, there is a post here on XDA of a person who got their hands on an onyx development device. There is a small component present on that device, as well as the one in the FCC auth photos, that is conspicuously missing on our production devices - It appears that it was soldered on, and then removed(on the production devices). There is also a cable connector that has been removed - I couldn't find anything too interesting, other than some oscillating voltage up to 1.8V, so maybe another UART? This applies to the 2022 model as well.
As near as I can tell - the missing component that I am interested in, is a diode, although I can't identify what kind exactly. The pins don't ohm out to anywhere that I can tell, but the upper pin does draw down my multimeter - as if it is grounded, but the pin is not ground. The lower pin seems to be leaking just a little bit of power - up to around 1.8 volts before resetting.
Just thought vomiting here - but I wonder if this component is essential to accessing BROM and bypassing the efuses that prevent one from entering BROM via short (Which BTW I am pretty sure I shorted every test point on the logic board, some do nothing, some return you to preloader, and some just completely prevent powerup (like CLK). I didn't find any that caused a brick that wasn't fixed by battery disconnect.
I plan on purchasing another 2020 board to test my diode theory on. If anyone has a vulnerable 2018 HD8 and a non-vulnerable 2018 HD8 it would be interesting to see if we could find the same cluster of components on their logic boards to compare.
Part of the reason that I am so interested in the missing diode, is that this component cluster appears largely unchanged from the 2020 model to the 2022 model of the HD8, and if it does lead somewhere interesting, it would be a pretty easy hardware mod - as far as such things go.
I attached some images below with the interesting stuff circled.
Reverse-anastomosis said:
Double Update:
I couldn't accept my failure - so I decided I had to sacrifice the 2020. I tore into it - and spent an unreasonable amount of time getting to know it with my multimeter. I stuck my probe where few have probed before!
I found an area around the main chip with an interesting bit of shielding and though to myself - you sneaky old amazon...what are you hiding here?
I found a nice little row of 4 pins...which have a hardwire connection to the USB-C port - on pin #3, or #6 depending on which direction you count from - and ground.
I am now 100% certain that the UART to USBC connection exists. I don't own a cable that outputs that pin - and unpowered my USBC-USBA OTG adapter does not output that pin - I assume that when it is powered with the resistors there must be enough crossover somewhere to see that a signal exists, it is just too corrupted to understand by the time it hits my serial/USB adapter.
I did throw my multimeter on the visible TXD testpoint on another 2020 device, and it did show some rapidly shifting voltage up to 1.8 volts during boot - so I assume I must have damaged the other one when I was soldering my jumper to it, so it must be outputting something. Also, there are RX0 and TX0 on the back of the logic board - when I get my replacement testing board I will investigate those for anything interesting before I fry it with random components(see below)
I plan on purchasing a USBC cable with all of the pin wires, and hooking it up to see if we can get rx and tx - Maybe Console? I can't tell for sure, but it looks like the same row of pins are present on the 2022 model, so this probably translates to that device as well.
Also, of interest, there is a post here on XDA of a person who got their hands on an onyx development device. There is a small component present on that device, as well as the one in the FCC auth photos, that is conspicuously missing on our production devices - It appears that it was soldered on, and then removed(on the production devices). There is also a cable connector that has been removed - I couldn't find anything too interesting, other than some oscillating voltage up to 1.8V, so maybe another UART? This applies to the 2022 model as well.
As near as I can tell - the missing component that I am interested in, is a diode, although I can't identify what kind exactly. The pins don't ohm out to anywhere that I can tell, but the upper pin does draw down my multimeter - as if it is grounded, but the pin is not ground. The lower pin seems to be leaking just a little bit of power - up to around 1.8 volts before resetting.
Just thought vomiting here - but I wonder if this component is essential to accessing BROM and bypassing the efuses that prevent one from entering BROM via short (Which BTW I am pretty sure I shorted every test point on the logic board, some do nothing, some return you to preloader, and some just completely prevent powerup (like CLK). I didn't find any that caused a brick that wasn't fixed by battery disconnect.
I plan on purchasing another 2020 board to test my diode theory on. If anyone has a vulnerable 2018 HD8 and a non-vulnerable 2018 HD8 it would be interesting to see if we could find the same cluster of components on their logic boards to compare.
Part of the reason that I am so interested in the missing diode, is that this component cluster appears largely unchanged from the 2020 model to the 2022 model of the HD8, and if it does lead somewhere interesting, it would be a pretty easy hardware mod - as far as such things go.
I attached some images below with the interesting stuff circled.
Click to expand...
Click to collapse
Wow, any more updates to this? I don't know much about finding these kinds of exploits via hardware but this "uart" that you mention is able to possibly give root access? I'm intrigued....
nsfxpython said:
Wow, any more updates to this? I don't know much about finding these kinds of exploits via hardware but this "uart" that you mention is able to possibly give root access? I'm intrigued....
Click to expand...
Click to collapse
Not really - you can follow my progress over on my other thread. I am going to post an update today.
Hardware UART information
I have been playing with my 2018, 2020 and 2022 HD 8's, and made a few interesting discoveries. I had been posting in another thread, but it seems to be pretty dead, and I think this stuff is interesting enough to warrant its own thread. 1...
forum.xda-developers.com