Related
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
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.
---
DISCLAIMER: THIS IS A REALLY GOOD WAY TO EFF UP YOUR KINDLE IF YOU DON'T KNOW WHAT YOU ARE DOING!!!
IF YOU DON'T KNOW WHAT ADB, PARTED, OR WHAT LINUX IS, YOU MIGHT WANT TO JUST CLICK THE BACK BUTTON!
---
Most that know Android, knows that it's just fancy UI and API on top of Linux, but it's still not quite Linux... But what if you want to run real Linux on your tablet?
Well, it's actually not that hard to do, but certainly not for n00bs...
Need to know: Linux, fastboot, adb, parted, etc.
You will also need the mkbootimg program, fastboot, working ADB, etc.
And a USB OTG adapter and working USB keyboard.
(this is assuming you already have modded your kindle with the usual FFF+TWRP 2.1+CM9)
The first step is to do a little repartitioning, so boot the Kindle into recovery, and run an 'adb shell'.
Then run 'parted'.
The idea here is to basically maintain the stock layout, while making room for linux...
Which can be done a few ways, the easy way would to just delete 'media', then recreate it much smaller (I did 1GB).
Then make one more new partition, using the remaining flash memory (should be a little over 4GB).
Making sure to reassign the name 'media' to partition 12, you can also name the new linux partition 'linux' or whatever, if you like.
After that, quit parted, and create the new FS on the new linux partition (mke2fs -Text4 /dev/block/mmcblk0p13, but you should know that already ).
Then reboot the tablet, get back into Android, it may or may not complain about the 'SDCARD' needing to be formatted, which should be done anyway, since it changed in size.
Do another 'adb shell', mount the new linux partition to a useful place, you can just mount over '/mnt' if you like, it won't hurt anything. Exit out of the shell.
Download this pre-built Debian rootfs I found:
http://rcn-ee.net/deb/rootfs/wheezy/
Unpack that file on your host machine, then use 'adb push' to copy the armel-rootfs tar to the Kindle's '/mnt'.
'adb shell' back into the kindle, and change to '/mnt' and untar the armel rootfs tar file... Maybe go to the bathroom, get a drink, get some fresh air or something, it'll take a little time to do it's thing.
After that's done, download my rc.local and 'adb push' that to '/mnt/etc' and make sure to ungzip it, and chmod is 0777 (or is it 0766, either should work lol).
http://www.mediafire.com/?gx46xxb4813n5ob
Then you can delete the rootfs tar file if you like, get out of '/mnt', and unmount it.
Linux is now installed, easy eh?
Now, download my kernel (acutally it's Hashcode's kernel, but with needed changes):
http://www.mediafire.com/?2lqex9j5bgws0b1 (Updated 6/11/2012)
Using mkbootimg:
'mkbootimg --kernel zImage --ramdisk /dev/zero --cmdline "root=179:XX" --base 0x80000000 -o boot.img'
Where XX is the partition that you put linux on (if following this exactly, should be 13), you should now be able to use /dev/mmcblk0pXX as well, if that doesn't work just use 179:XX.
Then using fastboot, boot the kernel package:
'fastboot boot boot.img'
While it says 'waiting for device...", reboot the Kindle and wait for it to download and boot the package.
Then wait for the linux login!
Plug in your favorite USB keyboard, a USB 1.1 one works best I've found.
The root password for that rootfs package is just 'root'.
-------------
Now, the fun part: Internet access, the hard way.
I'm still working out getting the WIFI modules working, so you'll have to use it tethered via USB... Which means no keyboard, but you can still log in by SSH.
In my kernel, instead of being an 'android' USB devices, it's a multifunction USB gadget with ethernet, serial port, and mass storage.
Mass storage works, but a little buggy sometimes.
Serial port seems broken for some reason.
Ethernet is what we're after.
Now the rc.local I made, in addition to enabling the video overlay (so there's a framebuffer console on the LCD), it also sets up the ethernet USB gadget.
I set the IP address to 192.168.5.1, which really should be out of the common IP range that most people use, but if it conflicts, then you can edit rc.local before you push it over above.
On your Linux host, with the Kindle plugged in, bring up the USB ethernet interface:
'ifconfig usb0 192.168.5.2 netmask 255.255.255.0'
After that, maybe try pinging the kindle (192.168.5.1), to make sure everything is working... If it is, you should have no problems connecting with SSH and logging in.
Once you can connect/login by SSH, you'll need to add your host machine as the default gateway ('route add default gw 192.168.5.2'), then edit '/etc/resolve.conf' and add a DNS server (add your ISP's DNS, or use 4.2.2.1).
After that, you should have internet access on the kindle side via SSH, and should be able to download/install your favorite Debian packages.
Oh, did I mention that you'll need a IP forwarding/NAT service running on your linux host too? I'll have to refer to linux manuals on how to do that, but if you can do all this, you should have no problems doing that.
I should also say that this CAN technically be done in windows as well, since all the needed programs are available in WIN32 bins, but you won't be able to get tethered network access working, because Microsoft doesn't support CDC ethernet devices.
Have fun!
OH! And X works fairly well with the omap3 video driver, just so long as you DON'T touch the screen, the touch screen driver currently crashes X on input.
So fair warning, make sure you know how to navigate X with just a keyboard, unless you have a OTG working hub and can use a keyboard and mouse, or have a wireless keyboard/mouse combo of some kind.
Update 6/11/2012:
Uploaded new kernel (link above), touch screen is now working, though no multitouch.
I have a boot loader with multiple boot options, http://www.mediafire.com/?l6aaqgsdkiksfw0
To use it, make a partition named "linuxboot", and flash your linux's boot.img created with the above instructions.
Still working on wifi.
Update 6/11/2012:
Ok, WIFI is working... Not sure why it wasn't before.
Here are the modules: http://www.mediafire.com/?139hold2a2l9vbl
Don't forget to run depmod.
You'll also have to copy the firmware from android system partition in /etc/firmware and copy it to Linux /lib/firmware
In case no one believes me, here's a console dump (typing blind of course, this was an early attempt with no LCD):
Code:
d.
.
Starting periodic command scheduler: crond.
FATAL: Could not load /lib/modules/3.0.21+/modules.dep: No such file or directory
Debian GNU/Linux 5.0 carrier tty1
carrier login: usb 1-1: new low speed USB device number 2 using musb-hdrc
usb 1-1: device v0b38 p0010 is not supported
input: HID 0b38:0010 as /devices/platform/omap/musb-omap2430/musb-hdrc/usb1/1-1/1-1:1.0/input/input4
generic-usb 0003:0B38:0010.0001: input: USB HID v1.10 Keyboard [HID 0b38:0010] on usb-musb-hdrc-1/input0
input: HID 0b38:0010 as /devices/platform/omap/musb-omap2430/musb-hdrc/usb1/1-1/1-1:1.1/input/input5
generic-usb 0003:0B38:0010.0002: input: USB HID v1.10 Device [HID 0b38:0010] on usb-musb-hdrc-1/input1
root
Password:
Last login: Sun May 27 21:55:28 UTC 2012 on tty1
Linux carrier 3.0.21+ #40 SMP PREEMPT Sun May 27 16:59:27 CDT 2012 armv7l
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
carrier:~# echo skdjfhnsdkjfshdsummit_bat_notifier_call val=41
summit_smb347 4-0006: summit_fsm_stateTransform:state : suspend(0) -> suspend(0) ; event : EVENT_BATTERY_NTC_NORMAL
kfjshdkjfshdfkjshdfkjsdhfkjsdhfkjsdhfkjshksdjfhskjdhfskjdhfsdkjfhsdkjfh > /dev/fb0
carrier:~# echo skdjfhnsdkjfshdkfjshdkjfshdfkjshdfkjsdhfkjsdhfkjsdhfkjshksdjfhskjdhfskjdhfsdkjfhsdkjfh > /dev/fb1
-bash: echo: write error: No such device
carrier:~# omap-rproc omap-rproc.1: rproc_loader_cont: failed to load ducati-m3.bin
cat /dev/vcs1 > /dumpp.txt
I was trying to get something to come up on the framebuffer, to no avail of course.
The backlight comes on, and it seems like it want to work, but there's nothing.
Are you talking about a true Debian dual-boot on our tablet? That could be really awesome .
Envoyé depuis mon Amazon Kindle Fire avec Tapatalk
Actually, yes.
It's mostly a matter of having a proper framebuffer console and telling the kernel to use a root instead of using the initrd to setup android.
If we could get a scripted bootloader, one that would give a customizable boot menu, you could easily boot whatever you wanted.
And what about it : http://thomaspolasek.blogspot.fr/2012/04/arch-linux-lxde-w-xorg-mouse-keyboard_16.html?m=1 ?
Envoyé depuis mon Amazon Kindle Fire avec Tapatalk
Well, I already got most of that working, chroot environment is easy.
I got the full Linux init going, no android at all... just no display.
seishuku said:
Well, I already got most of that working, chroot environment is easy.
I got the full Linux init going, no android at all... just no display.
Click to expand...
Click to collapse
Display might be tricky, as we are currently using the very latest graphics modules from TI. I'm not sure if you can use those in our current build.
That being said you could send a cat /proc/msg to a file during boot and that might contain your error.
Sent from my Amazon Kindle Fire using Tapatalk 2
Well I already have a working fbcon in android, but it seems the display just isn't being enabled in Linux.
I've tried "echo 1 > /sys/devices/omapdss/display0/enabled" to force it on, but nothing.
The back light is already on though...
I thought EXT2 was for really old linux distros.
Sent from my Kindle Fire using XDA
Not really, its just more compatible.
I could have made pretty much anything...
I read somewhere that SSDs should use EXT4.
i am really anxios to see this even though is only cmd line.
will the steps to get this going available even for SSH commands?
I really should hack together a wifi script to get some kind of network connection, would make working on it a little (lot) easier.
The idea here though is to basically have a full linux, to operate exactly like it would on a PC.
With a working framebuffer console, an X.org config can be made and X should work just fine with the touch screen too.
The end result, with just keyboard, should be a full blown linux system.
The real question is how long it would take to compile android for.. itself.
Sent from my Amazon Kindle Fire using Tapatalk 2
Hashcode said:
The real question is how long it would take to compile android for.. itself.
Sent from my Amazon Kindle Fire using Tapatalk 2
Click to expand...
Click to collapse
They can start reproducing them selves, isn't this how terminator started?
Sent from my LG-VM670 using Tapatalk
Hashcode said:
The real question is how long it would take to compile android for.. itself.
Sent from my Amazon Kindle Fire using Tapatalk 2
Click to expand...
Click to collapse
pbailey212 said:
They can start reproducing them selves, isn't this how terminator started?
Sent from my LG-VM670 using Tapatalk
Click to expand...
Click to collapse
This is really off topic but Hashcode's comment and pbaileys phone reminded me of a test project Drew (of Team Hydro) did where he chrooted ubuntu onto an LG-LS670 and compiled a kernel for it natively, took just under 3 hours.
I'm at a bit of a loss here... if I disable surfaceflinger, so I keep my android fb console, then if I disable the display and reenable it, I lose the console.
Also, in my initrd, I can remove everything except ueventd and still keep the console... so something ueventd (init) is doing to enable the console.
In Linux I can play with enabling/disabling the display, but nothing seems to provoke Linux to give me an actual console.
Sblood86 said:
This is really off topic but Hashcode's comment and pbaileys phone reminded me of a test project Drew (of Team Hydro) did where he chrooted ubuntu onto an LG-LS670 and compiled a kernel for it natively, took just under 3 hours.
Click to expand...
Click to collapse
On the vm670 legend has it, people have compliled whole roms in 30 minutes, with an optimus v, and Leslie Ann's build server
sent from my Nokia 5110
Aha! Got it!
http://www.youtube.com/watch?v=PXhnVP3lWLU
For whatever reason sysfs wasn't taking my commands.
Now I can work out some bugs and get X working.
I also switched the USB gadget from android to an Ethernet CDC, so I can SSH via USB while I get wifi working.
Edit-
Sorry about the super blurry video, my phone's camera is having "issues".
Ok, I've switched to the official Debian armel wheezy distro (basically just formatting my linux partition and untaring the distro), seems to have fixed a lot of problems... One being aptitude not working correctly (seen in the video).
I need to enable some kind of ip forwarding on my local linux install, so I can get a temp internet connection on the kindle via USB gadget ethernet cdc (ssh and http already works).
I finally found some time to inspect the NST board for a spare UART and the search was successful!
The serial port can be accessed on U2713, pin 2 is RX, pin 3 is TX, device node is /dev/ttyS1.
I use it with a 3.3V USB-to-UART adapter, but any voltage between 1.2 and 3.6 should be fine, thanks to the TI voltage-level translator TXB0104.
There is also a second uart connected to J151 (ttyS0), but that one has no voltage-level-translator and runs with 2V. (TX is on pin 9 of J151, no idea where RX is).
I'm still trying to redirect the boot console to ttyS1, i think i have to recompile uboot.
/edit:
Patching u-boot worked, I have the boot console on ttyS1.
Good job!
I wanted to look for this sometime, but you beat me to it.
ttyS0 is for the (cell phone) radio
ttyS1 is for the Bluetooth.
Could the connector place there be for JTAG?
Renate NST said:
Good job!
I wanted to look for this sometime, but you beat me to it.
Click to expand...
Click to collapse
I wanted to do this since my last failed kernel porting attempt. I hope it helps me debugging non succesfully booting configurations.
ttyS0 is for the (cell phone) radio
ttyS1 is for the Bluetooth.
Click to expand...
Click to collapse
Is that an actual android standard, or just some leftovers from the reference platform the nst and nook color are based on (the remains in the init.rc)?
Could the connector place there be for JTAG?
Click to expand...
Click to collapse
I think the JTAG is more probably on J151 together with ttyS0, than on U2713.
ttyS0 was the standard console, and it would make more sense that the J151 was used as debug-port.
mali100 said:
The serial port can be accessed on U2713, pin 2 is RX, pin 3 is TX, device node is /dev/ttyS1.
I use it with a 3.3V USB-to-UART adapter, but any voltage between 1.2 and 3.6 should be fine, thanks to the TI voltage-level translator TXB0104.
Click to expand...
Click to collapse
Mali,
My USB-to-UART adapter needs 3.3V (to set “upper voltage” level)
Could you help, where can I get in on Nook board?
Renate NST said:
ttyS0 is for the (cell phone) radio
ttyS1 is for the Bluetooth.
Click to expand...
Click to collapse
Do you know any devices that can be connected to this ports? It would be great to enable only Bluetooth or even cell phone.
ApokrifX said:
Mali,
My USB-to-UART adapter needs 3.3V (to set “upper voltage” level)
Could you help, where can I get in on Nook board?
Click to expand...
Click to collapse
You can use pin 1 of U2713, it's connected to VCCb on the TXB0104. Altough the voltage is disabled when the nook sleeps, but that shouldn't be a problem.
mali100 said:
You can use pin 1 of U2713, it's connected to VCCb on the TXB0104. Altough the voltage is disabled when the nook sleeps, but that shouldn't be a problem.
Click to expand...
Click to collapse
Ok... But it's gotta be 3.3V somewhere, right?
ApokrifX said:
Ok... But it's gotta be 3.3V somewhere, right?
Click to expand...
Click to collapse
Quick! Break the laws of physics and pull power from a penny!
I haven't had a driving need to use this until I tried an upgrade to 1.2 and got a boot loop.
There are various versions of u-boot.bin.
The easiest way to patch it is to simply search for ttyS0 and replace the two occurrences with ttyS1.
ttyS0 appears also in env.txt inside uRamdisk (and uRecRam).
I found a old fax that has the 10 pin connector that fits on the Nook.
I might try to put it on. For now I have the soldered wires.
In any case, the 1.2 boot loops and the last message is:
Code:
binder: 988:1039 transaction failed 29189
I've screwed with a lot of things on my Nook, but the "update" should have wiped about everything.
Just a short update:
I soldered in the connector successfully. It looks nice.
The level converter to standard 9 pin "RS-232" is simple and cheesy, 2 resistors and a transistor.
It works fine though. I can see the boot up.
After that I can switch to logcat over ADB over USB.
Here's a really poor photo of my setup.
My next cell phone must have auto-focus and macro mode.
Excellent setup, especially for the ribbon cable! It seems something nice its going to happen in the next days
Just a bit of an update.
If you want to do your own level shifting you've got access to two UARTs.
The MSP stuff is I2C to the MSP430 microprocessor that handles the touch screen.
You could eavesdrop on that and have a little multitouch pad.
I'm still trying to see which of the rest of the pins are for JTAG on U151.
The other 4 pins on U2713 are 3.3 level but don't come from the TXB0104 level shifter.
The JTAG stuff is apparently on the 22 pin, 0.5 mm pitch CON6.
The four side buttons are on CON6 too.
I've looked at this a bit and I've determined that using UART2 is a dead end.
The TXB0104 is neither powered nor enabled until late in the boot sequence.
Using the default UART1 is a much better choice.
Yes, you could modify things to use UART2 over UART1 but it's an uphill battle.
u-boot has a nice command interface where you can do lots of stuff (edited a bit):
Code:
Texas Instruments X-Loader 1.41 (Dec 7 2012 - 14:34:26)
Starting OS Bootloader from EMMC ...
U-Boot 1.1.4-carbon1.2_1.2.1.24^{} (Dec 7 2012 - 14:34:22)
OMAP3630-GP rev 2, CPU-OPP2 L3-165MHz
OMAP3621-Gossamer 1.2 Version + mDDR (Boot NAND)
DRAM: 256 MB
In: serial
Out: serial
Err: serial
Hardware arch: GOSSAMER rev: EVT3
Power button is not pressed
pmic watchdog time 0
Power Button Active
gossamer charger init
Booting from eMMC
OMAP36XX GOSSAMER # help
? - alias for 'help'
autoscr - run script from memory
base - print or set address offset
battery - gas gauge BQ27520 info
bdinfo - print Board Info structure
boot - boot default, i.e., run 'bootcmd'
bootd - boot default, i.e., run 'bootcmd'
bootm - boot application image from memory
calc - perform mathematical operation
charger - charger BQ24073 info
clock - Manage system clocks
cmp - memory compare
coninfo - print console devices and information
cp - memory copy
crc32 - checksum calculation
date - get/set/reset date & time
echo - echo args to console
epd tests dspon dspoff image1 image2
exit - exit script
fastboot- use USB Fastboot protocol
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls - list files in a directory (default /)
fatsave - save binary file to a dos filesystem
ggflash - flash bq27500 from .dffs script
go - start application at address 'addr'
gpio - set/display gpio pins
help - print online help
ibatck - used to track battery id
ibus - Select i2c Bus
icrc32 - checksum calculation
iloop - infinite loop on address range
imd - i2c memory display
iminfo - print header information for application image
imm - i2c memory modify (auto-incrementing)
imw - memory write (fill)
inm - memory modify (constant address)
iprobe - probe to discover valid I2C chip addresses
itest - return true/false on integer compare
loadb - load binary file over serial line (kermit mode)
loads - load S-Record file over serial line
loady - load binary file over serial line (ymodem mode)
loop - infinite loop on address range
md - memory display
mm - memory modify (auto-incrementing)
mmcinit - initialize mmc
mmc - Read/write/Erase mmc
mspflash- used to flash a new msp430 firmware file
mtest - simple RAM test
mw - memory write (fill)
nm - memory modify (constant address)
printenv- print environment variables
reset - Perform RESET of the CPU
run - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv - set environment variables
setenvmem - set environment variable from memory
sleep - delay execution for some time
test - minimal test like /bin/sh
version - print monitor version
OMAP36XX GOSSAMER #
Just adding the battery pinout to the diagram for completeness.
Excellent! I recently bought a JTAG (http://www.ebay.co.uk/itm/Altera-FP...al_Components_Supplies_ET&hash=item257fc5c582)
I will give it a go... is there anything you'd like me to do?
Cheers
Heres a quick hack to talk to uboot over UART2
Edit: all that's different is enabling the TXB0104 by setting gpio 37 high instead of low.
and redefining the uarts so 2 is used instead of 1.
includes the OP's patch so kernel logs show after boot also.
this second version fixes autoboot. UART2 gets a spurious byte which needs to be cleared otherwise autoboot never works.
This patch is meant to be applied without the first one, i put the uart numbers back to normal and just changed the index of which gets used for console.
I also enabled ^C checking for the case where bootdelay is zero, you can't lock yourself out of u-boot by messing with the env variables. ( Guess why I decided to do this?
NB: There is a third uart, uart3. one of the sets of pins it can be muxed onto are the usbhs0_data0 and 1 pins.
these go to the tps65921, which also has a uart mode , whereby we could have uart access over the usb pins without cracking the case.
droid phones had something similar, called emu-uart. i will look into this more when i get a nook with a working usb port.
I am a very happy owner of Huawei e8372h-153 that has firmware version 21.210.03.01.1080 and much less happy owner of similar device that has firmware version 21.333.03.00.00
I am looking to downgrade the 21.333.03.00.00 to 21.210.03.01.1080.
Is there a linux based way to dump firmware (and webui) from device 21.210 to file(s)? This would provide a backup before I start playing with these devices a little bit more...
Dumping the images is one important step in a backup procedure and restoring is as important There is more info available on that, but most solutions require Windows OS and a custom software. Is there a way to do it on linux using standard toolset (or optionally some custom tools, but these would need to have source code available for me to trust them).
I don't want to use images available on the network as I also can't trust them without verification and for that I would have to do lots of binwalking.
My initial goal is to replace/downgrade the firmware on the device 21.333 (and my ultimate goal is to get images that I can binwalk and learn from).
So far I have been able to explore these devices a bit
After connecting to USB device is shown (lsusb) as
12d1:1f01 Huawei Technologies Co., Ltd. E353/E3131 (Mass storage mode)
then two interesting devices appear /dev/sr0 (8MB mounted on /media/${USER}/MobileWiFi) and /dev/mmcblk0p1 (memory card partition mounted as /media/${USER}/1234-6789).
usb_modeswitch with option --huawei-alt-mode switches this device to
12d1:155e Huawei Technologies Co., Ltd. HUAWEI_MOBILE
then /dev/ttyUSB0, /dev/ttyUSB1 oraz /dev/ttyUSB2 appear in /dev (the first one allows for AT commands execution, function of the remaining TTYs is unclear to me, but I would love to find out soon)
usb_modeswitch with --huawei-new-mode option switches from device 12d1:1f01 to
12d1:14db Huawei Technologies Co., Ltd. E353/E3131
then only the memory card related devices appear and from what I understand the device is in hi-link mode (it is accessible from browser as 192.168.8.1)
after connecting with test pin number 2 connected to GND I get
12d1:1443 Huawei Technologies Co., Ltd. USB COM
here the device seems to be in boot mode (?) exposing only one TTY (/dev/ttyUSB0) that I have no clue how to use (as I want to avoid using any unverifiable software and Windows OS). BTW In this mode memory card partition also seems to be available.
My main question is: Where to search/explore from here to get dumps of firmware and webui partitions from the 21.210 device and restore from these (preferably also on 21.333 device -- fingers crossed).
Bonus question(s): Where one can learn more about the functionalities of /dev/ttyUSB1 and /dev/ttyUSB2 (in alt mode) and what is the /dev/sr0 (in storage mode) and how to use /dev/ttyUSB0 (in boot mode?
Any help/suggestions much appreciated
Below I include the output of the ^AAT^VERSION? command for both (21.210 and 21.333) devices
Code:
# DEVICE 21.210 (happy days)
^VERSION:BDT:Apr 13 2015, 19:43:32
^VERSION:EXTS:21.210.03.01.1080
^VERSION:INTS:21.210.03.01.1080
^VERSION:EXTD:WEBUI_17.100.09.02.1080
^VERSION:INTD:WEBUI_17.100.09.02.1080
^VERSION:EXTH:CL1E8372HM Ver.A
^VERSION:INTH:CL1E8372HM Ver.A
^VERSION:EXTU:E8372
^VERSION:INTU:E8372H-153
^VERSION:CFG:1005
^VERSION:PRL:
^VERSION:OEM:
^VERSION:INI:E8372hCUST-B01C00
Code:
# DEVICE 21.333 (devils' half)
^VERSION:BDT:Nov 13 2019, 09:37:21
^VERSION:EXTS:21.333.03.00.00
^VERSION:INTS:
^VERSION:EXTD:WEBUI_17.100.21.02.03_RE5
^VERSION:INTD:
^VERSION:EXTH:CL1E8372HM Ver.A
^VERSION:INTH:
^VERSION:EXTU:E8372
^VERSION:INTU:
^VERSION:CFG:1005
^VERSION:PRL:
^VERSION:OEM:
^VERSION:INI:E8372hCUST-B00C00
maybe @ValdikSS can provide any help or suggestions?
also see: https://www.sciencedirect.com/science/article/pii/S1742287613000479