Database Users

AT-Commands?

Hi there,
maybe not a XDA specific Question but maybe s.o. could still help me.
I've got a SIEMENS emem ES75 GSM Modem wich I wanted to use as a SMS receiver for my Party next month (receive sms and project them onto a wall )
But I have some trouble controlling it using the AT-Commandset.
For example: the AT+GMM Command which should give me the name of the Manufacturer) Sometimes AT+ Commands are working, sometimes not.
As it works, I printed out the current settings using AT&V:
Code:
ACTIVE PROFILE:
E0 Q0 V1 X4 &C1 &D2 &S0 \Q0 \V1
S0:000 S3:013 S4:010 S5:008 S6:000 S7:060 S8:000 S10:002 S18:000
+CR: 0
+CRC: 0
+CMGF: 1
+CSDH: 0
+CNMI: 0,0,0,0,1
+ICF: 3
+IFC: 0,0
+ILRR: 0
+IPR: 115200
+CMEE: 0
^SMGO: 0,0
+CSMS: 0,1,1,1
^SACM: 0,"000000","FFFFFF"
^SLCC: 0
^SCKS: 0,1
^SSET: 0
+CREG: 0,1
+CLIP: 0,2
+CAOC: 0
+COPS: "T-MOBILE D"
+CGSMS: 3
Remember: it says "CURRENT PROFILE"
Then I used the AT&V Command when it did not work:
Code:
Current Settings............
E0 H0 Q0 V1
&C0 &D0 &P1 &R0 &S0
S00=000 S01=000 S02=043 S03=013 S04=010 S05=008 S06=000 S07=030
S08=000 S09=000 S10=000 S11=000 S12=050 S13=000 S14=000 S15=000
S16=000 S17=000 S18=000 S19=000 S20=000 S21=000 S22=000 S23=000
S24=000 S25=005 S26=001 S27=000 S28=000 S29=000 S30=000 S31=000
S32=000 S33=001 S34=000 S35=000 S36=000
#0 :
#1 :
#2 :
#3 :
#4 :
#5 :
#6 :
#7 :
#8 :
#9 :
Why does it output the "CURRENT SETTING" instead of the "CURRENT PROFILE"? And why can't I read the SMS? With this Setting it does not accept most of the AT+(..) commands. (AT+GMM, ...)
I sniffed the serial port communication from working applications and used the same commands and init-strings, but nothing
Any advice?

Nothing?

[APP] Samba Server for Android

APP development page has moved to http://forum.xda-developers.com/and...esharing-server-android-t2803452/post53869540
This thread is kept fir reference as it contains valuable information for manual modifications.

hey there I was lookin for similar feature , its not exactly the sme well it is , but anyways , Estrong Explorer does the job for what you are tryin to do , ( ESexplorer) free inmarket . as long as phone is reg on network it will access your share

Hi, I just got Samba server (2.2.12) working on my HTC Hero. The daemons smbd+nmbd take up just under 4Mb memory when running (and opening a shared folder on the phone from a computer on the network will launch another smbd daemon, which is about 2.5Mb).
The main problem I'm having is slow xfer rates - seems to max out at 600 - 700Kb/s. Its the same if i SCP files though, so I dont think its a problem is with samba specifically...
I can provide a tarball with the files if you want to try it out (install & configuration is through a root shell, its all pretty basic at the moment).
- Jimmy

By all means, I'd like to try it on my Nexus. Just finished a thread about changing Nexus One's hostname from default "localhost", and understood that besides my router, I can't do much with it on Windows network w/o DNS
Please post the files & instructions.

Have attached a zip file containing the samba files + README.txt with basic install instructions. Access the phone shared folder via Windows network browsing, or with \\IPaddress of the phone.
** See a later post by me in this thread that has a newer version of Samba attached which includes automated install/uninstall script.

Hi,
I've checked the most recent version and the one before it, on Nexus.
Both exhibit the same behavior.
1) When trying to unzip to SD card, everything's ok and the default file attributes are preserved. When extracting to /data/local, no matter which way is used, "executable" attributes aren't preserved - only RW attributes. chmod +rwx samba/bin/* doesn't help, and when trying to execute "samba-rc start" via Terminal on the phone, it shows: "ash: can't find samba-rc" (I'm using ash). Using "su samba-rc start" also doesn't help, it shows "permission denied".
2) Trying to execute smbpasswd - it asks for a new password and confirmation, and crashes with segmentation fault.
3) Trying to execute samba-rc from ADB SHELL didn't throw any error messages, but it didn't work either.

I've tried both running from the phone's terminal emulator and by adb shell (I don't open the shell continuously, I run each command separately - adb shell "command", this way I can dump the output to PC by adding > in the end).
/data/local/samba/bin/nmbd -i -d 99
Looks like it's working, both from phone's terminal emulator and from adb shell. I see the Nexus being discovered by Windows 7 workstation on network scan (I've personalized the name - read my thread in Nexus development section on how to do that). nmbd_log attached, to check that everything's ok.
/data/local/samba/bin/smbd -i -d 99
Here the things start getting more interesting.
1) If I try to connect, after some time the smbd stops by itself - looks like after 5 failed attempts the server auto-stops itself. That's not a good behavior, especially considering that while Windows prompts you for username and password to connect, it also keeps trying to auto-connect using the default username (that's where 5 attempts come from). The server shouldn't stop itself. smbd_log1 attached.
2) If I write the user on time, smbd crashes while trying to compare passwords. smbd_log2 attached.
All the logs are zipped.

Thanks for the info Jack.
With the shell script, can you try running it like:
sh -c "/data/local/samba/bin/samba-rc restart"
if that still doesnt work, as a further test, open two root sessions via adb shell, in one run the nmbd command, in the other run the smbd (both with same options as before) then try browsing again from your computer.
Note: dont let your phone go into sleep mode (keep the screen active so the display stays on).
- JC

I had a chance to play with both versions some more.
1) using su and no shell (not running ash) I can run samba-rc, and it executes correctly. Both processes (nmbd and smbd) show up in ps. To achieve that, I needed to chmod +rwx /samba/bin/* after unzipping.
2) nmbd works well, and the phone shows up on Windows network.
3) It still doesn't allow logging into it, and I believe the problem lies in smbpasswd executable, which still shows erroneous behavior:
Tried to login using default user bogan: "network resource not available" message coming from Windows upon entering login credentials. Phone stays on the network and can be accessed again, but login is still impossible.
Tried to change default user's password: smbpasswd asks for new password twice (without asking for the old one - which is wrong behavior!) and crashes with segmentation fault.
Tried removing /samba/private/smbpasswd file and creating a new one, using smbpasswd -add username. Worked, but no password was asked for the user.
Tried to change password for new username. The same as before - asked for new password twice, then crashed with segmentation fault.
When tried to login with the new user, it didn't show "network resource not available", but it kept asking for password (the dialog where username is already there, and only the password needs to be retyped). I didn't know the default password that smbpasswd creates, if any. Tried nothing, tried several basic options (root, same as username, etc), none worked.
I believe the problem might be smbpasswd not working correctly on Android 2.1.

ich started samba via chroot debian. i can read and write the filesystem.. except mapped /sdcard... i cannot delete files... any ideas how to set permissions? the user is 1000 and group is 1015

Played some more with it, and I can definitely point at authentication as the source of the problems. I got it to work. Not too well - because it lacks any security whatsoever - but at least it works.
First, about the problems:
When mistyping the password one of the times, smbpasswd shows correct error message and gracefully exits.
When doing everything correctly, it crashes - but writes /private/smbpasswd file before that.
I've tried to run it with debug level = 9, it showed lots of info when starting, and after changing passwords - just the regular "Segmentation fault" crash.
in smb.conf, setting password encryption = off causes the Windows to throw "this user isn't authorized to login from this station" error instead of asking for username.
But, how I got things to work?
Well, since I was certain that it's the authentication mechanisms that prevent it from working, I prevented those authentication mechanisms from functioning. At first I wanted to ask Jimmy for a test version that would ignore user/password checking, but then I thought that I might do it in smb.conf file. So here is what I did:
[global]
security = SHARE # instead of USER
[sdcard]
guest ok = yes # instead of no
With these settings, I get no password prompts and Samba works! I see SD card share, and can copy to/from it.
Notes:
* The main script (samba-rc) works well in killing all the smbd processes on stop/restart.
* Server still runs when the phone is in sleep mode, just much slower.
Jimmy, could you please test smbpasswd compilation to find out why it crashes on 2.1 (I'm running Cyanogen 5.0.6)? Once it's done, I believe that this will work anywhere.
Also, something could probably be done to make it speed up CPU / network on demand when the phone is sleeping, or to prevent the phone from sleeping while it's running - and a GUI can be made for controlling it, since it'll be fully functional.

can you delete from the sdcard share?

DocMAX said:
can you delete from the sdcard share?
Click to expand...
Click to collapse
Yes, tried and deleted a directory with files.

Hi Jack,
Nice work with your testing
I'd like to take a look at all the file permissions samba unzip'd with and compare them to what they should be - could you post output of
ls -laR /data/local/samba​
smbpasswd probs: could you delete /data/local/samba/private/smbpasswd and add a user with bin/smpasswd using '-a' rather than '-add', like
/data/local/samba/bin/smbpasswd -a jack​
then re-enable authentication in the config file and see how it goes?
I'll see what the options might be for the sleep mode network speed slow down (I do want to package it all up with GUI config and control options etc eventually, i suspect the sleep mode stuff will be easier to control this way too).
- JC

DocMAX said:
ich started samba via chroot debian. i can read and write the filesystem.. except mapped /sdcard... i cannot delete files... any ideas how to set permissions? the user is 1000 and group is 1015
Click to expand...
Click to collapse
So you're doing a chroot to somewhere else on the phone filesystem before starting samba, if i understand correctly?
Have you tested it without chroot to see if the problem still happens? Is there any indication of a permission problem reported in /data/local/samba/var/log.smbd ?
Is 1000 / 1015 the user/group of the files on the sdcard you are trying to delete, or the user / group you've set in samba.conf?
- JC

JimmyChingala said:
Hi Jack,
Nice work with your testing
Click to expand...
Click to collapse
Thanks
JimmyChingala said:
I'd like to take a look at all the file permissions samba unzip'd with and compare them to what they should be - could you post output of
ls -laR /data/local/samba​
Click to expand...
Click to collapse
Please remember that I've changed the /bin/* permissions from 666 to 777, and it shows in the list below.
Here:
/data/local/samba:
drwxrwxrwx 1 root root 2048 May 17 00:20 .
drwxrwx--x 1 shell shell 2048 May 17 00:20 ..
-rw-rw-rw- 1 root root 4178 May 17 00:20 README.txt
drwxrwxrwx 1 root root 2048 May 17 00:20 bin
drwxrwxrwx 1 root root 2048 May 24 17:05 lib
drwxrwxrwx 1 root root 2048 May 19 20:10 private
drwxrwxrwx 1 root root 2048 May 17 00:23 var
/data/local/samba/bin:
drwxrwxrwx 1 root root 2048 May 17 00:20 .
drwxrwxrwx 1 root root 2048 May 17 00:20 ..
-rwxrwxrwx 1 root root 457952 May 17 00:20 killsamba
-rwxrwxrwx 1 root root 870592 May 17 00:20 nmbd
-rwxrwxrwx 1 root root 396 May 17 00:20 samba-rc
-rwxrwxrwx 1 root root 1839404 May 17 00:20 smbd
-rwxrwxrwx 1 root root 948992 May 17 00:20 smbpasswd
/data/local/samba/lib:
drwxrwxrwx 1 root root 2048 May 24 17:05 .
drwxrwxrwx 1 root root 2048 May 17 00:20 ..
drwxrwxrwx 1 root root 2048 May 17 00:20 codepages
----rwxr-x 1 root root 708 May 24 17:05 smb.conf
/data/local/samba/lib/codepages:
drwxrwxrwx 1 root root 2048 May 17 00:20 .
drwxrwxrwx 1 root root 2048 May 24 17:05 ..
-rw-rw-rw- 1 root root 588 May 17 00:20 codepage.1125
-rw-rw-rw- 1 root root 140 May 17 00:20 codepage.1251
-rw-rw-rw- 1 root root 196 May 17 00:20 codepage.437
-rw-rw-rw- 1 root root 148 May 17 00:20 codepage.737
-rw-rw-rw- 1 root root 388 May 17 00:20 codepage.775
-rw-rw-rw- 1 root root 132 May 17 00:20 codepage.850
-rw-rw-rw- 1 root root 172 May 17 00:20 codepage.852
-rw-rw-rw- 1 root root 132 May 17 00:20 codepage.857
-rw-rw-rw- 1 root root 460 May 17 00:20 codepage.861
-rw-rw-rw- 1 root root 588 May 17 00:20 codepage.866
-rw-rw-rw- 1 root root 8 May 17 00:20 codepage.932
-rw-rw-rw- 1 root root 8 May 17 00:20 codepage.936
-rw-rw-rw- 1 root root 8 May 17 00:20 codepage.949
-rw-rw-rw- 1 root root 8 May 17 00:20 codepage.950
-rw-rw-rw- 1 root root 131614 May 17 00:20 unicode_map.1125
-rw-rw-rw- 1 root root 131614 May 17 00:20 unicode_map.1251
-rw-rw-rw- 1 root root 131614 May 17 00:20 unicode_map.437
-rw-rw-rw- 1 root root 131614 May 17 00:20 unicode_map.737
-rw-rw-rw- 1 root root 131614 May 17 00:20 unicode_map.775
-rw-rw-rw- 1 root root 131614 May 17 00:20 unicode_map.850
-rw-rw-rw- 1 root root 131614 May 17 00:20 unicode_map.852
-rw-rw-rw- 1 root root 131614 May 17 00:20 unicode_map.857
-rw-rw-rw- 1 root root 131614 May 17 00:20 unicode_map.861
-rw-rw-rw- 1 root root 131614 May 17 00:20 unicode_map.866
-rw-rw-rw- 1 root root 262174 May 17 00:20 unicode_map.932
-rw-rw-rw- 1 root root 262174 May 17 00:20 unicode_map.936
-rw-rw-rw- 1 root root 262174 May 17 00:20 unicode_map.949
-rw-rw-rw- 1 root root 262174 May 17 00:20 unicode_map.950
-rw-rw-rw- 1 root root 131614 May 17 00:20 unicode_map.ISO8859-1
-rw-rw-rw- 1 root root 131614 May 17 00:20 unicode_map.ISO8859-13
-rw-rw-rw- 1 root root 131614 May 17 00:20 unicode_map.ISO8859-15
-rw-rw-rw- 1 root root 131614 May 17 00:20 unicode_map.ISO8859-2
-rw-rw-rw- 1 root root 131614 May 17 00:20 unicode_map.ISO8859-5
-rw-rw-rw- 1 root root 131614 May 17 00:20 unicode_map.ISO8859-7
-rw-rw-rw- 1 root root 131614 May 17 00:20 unicode_map.ISO8859-9
-rw-rw-rw- 1 root root 131614 May 17 00:20 unicode_map.KOI8-R
-rw-rw-rw- 1 root root 131614 May 17 00:20 unicode_map.KOI8-U
/data/local/samba/private:
drwxrwxrwx 1 root root 2048 May 19 20:10 .
drwxrwxrwx 1 root root 2048 May 17 00:20 ..
-rw------- 1 root root 8192 May 26 14:08 secrets.tdb
-rw------- 1 root root 101 May 19 20:10 smbpasswd
/data/local/samba/var:
drwxrwxrwx 1 root root 2048 May 17 00:23 .
drwxrwxrwx 1 root root 2048 May 17 00:20 ..
drwxrwxrwx 1 root root 2048 May 26 14:08 locks
-rw-r--r-- 1 root root 23957 May 26 14:08 log.nmbd
-rw-r--r-- 1 root root 37485 May 26 14:08 log.smbd
drwxrwxrwx 1 root root 2048 May 17 00:20 tmp
/data/local/samba/var/locks:
drwxrwxrwx 1 root root 2048 May 26 14:08 .
drwxrwxrwx 1 root root 2048 May 17 00:23 ..
-rw-r--r-- 1 root root 696 May 24 18:06 brlock.tdb
-rw-r--r-- 1 root root 154 May 24 18:06 browse.dat
-rw-r--r-- 1 root root 8192 May 26 14:08 connections.tdb
-rw-r--r-- 1 root root 696 May 24 18:06 locking.tdb
-rw------- 1 root root 696 May 26 14:08 messages.tdb
-rw-r--r-- 1 root root 20 May 26 14:08 nmbd.pid
-rw------- 1 root root 8192 May 24 18:06 ntdrivers.tdb
-rw------- 1 root root 696 May 24 18:06 ntforms.tdb
-rw------- 1 root root 8192 May 24 18:06 ntprinters.tdb
-rw------- 1 root root 8192 May 24 18:06 printing.tdb
-rw------- 1 root root 8192 May 24 18:06 share_info.tdb
-rw-r--r-- 1 root root 20 May 26 14:08 smbd.pid
-rw-r--r-- 1 root root 16384 May 24 18:08 unexpected.tdb
/data/local/samba/var/tmp:
drwxrwxrwx 1 root root 2048 May 17 00:20 .
drwxrwxrwx 1 root root 2048 May 17 00:23 ..
JimmyChingala said:
smbpasswd probs: could you delete /data/local/samba/private/smbpasswd and add a user with bin/smpasswd using '-a' rather than '-add', like
/data/local/samba/bin/smbpasswd -a jack​then re-enable authentication in the config file and see how it goes?
Click to expand...
Click to collapse
Did so. It didn't work, but it helped me better understand one more symptom.
1) When adding with "-a", it accepted the new password and didn't crash.
2) I still couldn't login with the user.
3) I tried using debug options ("-i -d 99") and got it exiting after login attempts (login still failed).
4) I created a Samba user with the same name as Windows user, and tried to log in. This time it searched and found the password, but then crashed with the following error (this is the end of the log file):
[000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
[010] 00 00 00 00 00 00 00 00 51 97 2D 64 E2 C4 1E 10 ........ Q.-d....
[020] C2 C0 E9 19 DB 64 5B 98 01 01 00 00 00 00 00 00 .....d[. ........
[030] 0F A7 B4 B3 DF FD CA 01 D0 DE 19 BB 42 22 52 CA ........ ....B"R.
[040] 00 00 00 00 02 00 12 00 57 00 4F 00 52 00 4B 00 ........ W.O.R.K.
[050] 47 00 52 00 4F 00 55 00 50 00 00 00 00 00 00 00 G.R.O.U. P.......
[060] 00 00 4B 69 73 75 6C 79 61 00 4B 69 73 75 6C 79 ..Kisuly a.Kisuly
[070] 61 2D 50 43 00 00 00 a-PC...
switch message SMBsesssetupX (pid 1988)
created /data/local/samba/var/tmp/SMBsesssetupX.8.req len 220
setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0
change_to_root_user: now uid=(0,0) gid=(0,0)
passlen1=24, passlen2=74
Domain=[Kisulya-PC] NativeOS=[] NativeLanMan=[]
sesssetupX:name=[Kisulya]
lp_file_list_changed()
file /data/local/samba/lib/smb.conf -> /data/local/samba/lib/smb.conf last mod_time: Thu May 27 20:36:57 2010
pass_check: Checking password for user kisulya (l=74)
NT Password did not match for user 'kisulya'!
Defaulting to Lanman password for kisulya
pdb_getsampwnam: search by name: kisulya
startsmbfilepwent_internal: opening file /data/local/samba/private/smbpasswd
getsmbfilepwent: returning passwd entry for user jack, uid 0
getsmbfilepwent: returning passwd entry for user kisulya, uid 0
endsmbfilepwent_internal: closed password file.
pdb_getsampwnam: found by name: kisulya
===============================================================
INTERNAL ERROR: Signal 11 in pid 1988 (2.2.12 Android build (JimmyChingala))
Please read the file BUGS.txt in the distribution
===============================================================
PANIC: internal error
I guess I'll ask you for a debug version of the build, that logs every step in the password checking under debug mode. "Signal 11" isn't too clear

Hi Jack, your file permissions look mostly ok - ive assembled the sambaArchive differently now, should hopefully avoid the permission probs you saw.
Tracked down the cause of smbd crashing in debug mode too, so we should be able to get some proper debug info about whats happening to authentication.
The bin/smbpasswd segfaults are fixed - adding/removing users, changing passwords seems to work ok.
Have attached the updated archive sambaAndroid-0.3.zip to my other post in this thread.
- JC

Great work, Jimmy. Tested, and everything looks functional.
Adding user works.
Removing user works.
Authentication works - also tested with non-default user.
Things left:
Auto-detect local network interface on start / on install.
Prevent slowdown in sleep mode.
Thanks a lot for making it work!

Damn, just got home and tested on my system. I guess it was too fast to declare it's fully functional.
Jimmy, I suppose you're testing it on Windows XP? Because it definitely works on XP, as I wrote earlier. But the problem is that once I start using Windows 7, the authentication mechanism changes somehow (my guess, it also could be the protocol - I didn't save the logs so I didn't note the difference, and I don't have XP at home) - and I can't login anymore. I've logged the server output and it looks like no matter what username is provided - Win7 uses its current logged in user to connect to the sharing device (user-level login to the system before logging in to the share itself - this is how Samba is configured), which ultimately results in login failure.
I'll record a successful XP log and an unsuccessful Win7 log tomorrow and post them, but I'm not sure that something can be deduced from them, since they just show different passwords (and Win7 log also shows server exiting when trying to log in with correct user/password, something that doesn't happen on XP - but at least this time it's graceful logged exit, thanks to your fix).
I suggest you test logging in from Vista or Win7 machine with a username that isn't the logged in Windows user.

Thanks for your testing and feedback, Jack!
I'm testing with Vista and XP - no Win7 yet.
A couple of things to double check:
- If the phone has been in sleep mode for an extended period, or wifi switched off, then on again, and if a "samba-rc restart" has not been done, strange auth problems will happen. (This shouldnt be a problem if using the dhcp hook script to auto-restart samba).
- Cached session credentials on the client or server can also play havoc with authentication - check "net use" in a cmd shell on your Win client to see if there is cached session info for the phone, and if there is, do a "net use /delete \\phoneIP\IPC$" to delete it. (On the server side, cached information is deleted each time the samba is started).
Manually running "/data/local/samba/bin/samba-rc restart" in adb or ssh root shell on your phone (when not in sleep mode) should fix the above two issues on the server side.
Otherwise take a look at
http://www.builderau.com.au/blogs/codemonkeybusiness/viewblogpost.htm?p=339270746
And see what your 'LAN Manager authentication level' defaults to. On my Vista system, its already set to "Send LM & NTLM - use NTLMv2 session security if negotiated". I dont remember changing this, I think it was the default on my Vista install - maybe i did change it, up late and half asleep one night .
Anyway, samba2 doesnt support NTLMv2 authentication but i think the workaround in the above URL will address this - if its the problem.. (I'm already working on porting a version of Samba3 that has NTLMv2 auth, but the code is significantly different that i cand just edit the same files and change the same blocks of code ).
- JC

Nexus 7 APX Ubuntu Gentoo(uclibc/dietlibc) TWRP bricked sbk sbcheck sbdetect

Reflashing Nexus 7 in APX mode, Ubuntu, Gentoo(uclibc/dietlibc), TWRP, hard bricked , sbkdetect , sbkcheck , sbk key
At the begining it was a word and the word was 2 bytes and half-nibble.
I have
Nexus 7 (bootloader unlocked), TWRP installed, and Ubuntu installed with
fastboot erase boot
fastboot flash boot raring-preinstalled-desktop-armhf+nexus7.bootimg
fastboot erase userdata
fastboot flash userdata raring-preinstalled-desktop-armhf+nexus7.img
fastboot reboot
At the beginning it was fully operational ubuntu.
I wanted to compile gentoo with optimized flags and libs - uclibc/dietlibc and to compare benchmarks with ubuntu and android.
Before experimenting I maked full backup of all partitions.
dd if=/dev/mmcblk0p1 bs=8M | nc -l -p 777
and from computer nc 192.168.0.4 777 > p1
I did the same command for p2, p3, p4, p5, p6, p7, p8, p9, boot1, boot0.
And I backuped /dev/mmcblk0 , which contained all those partitions.
I wanted to understand how it structured on the tablet.
In the process of experimenting first sectors from 0 to 64 was zeroed.
I tried to restore the device in APX mode.
Info about device:
On the box:
Nexus7 ASUS 1B/T30L/16/1G/V , CSSN:015d3248bb080218, SN:CBOKBC595625
Model ME370T , Made in China
[greped from dmesg]
Tegra Revision: A03 SKU: 0x83 CPU Process: 2 Core Process: 0
I checked most of the messages from the forum related to reflashing and restoring
soft/hard bricked tablets.
I tried to restore the device with sdk for Tegra3(for Nexus7) from developer site - developer.nvidia.com.
I registered and got SDK - Tegra Android DEveloper Pack 2.0 for windows. Then I tried to run it.
Several big files was created (there are look like files in nakasi-xxx-firmare-xxx) ,
and process stoped at moment of flashing.
Then I tried to reflash the device under linux.
usb-device
T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 20 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=0955 ProdID=7330 Rev=01.03
S: Manufacturer=NVIDIA Corp.
S: Product=APX
C: #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=32mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
The easiest way to prepare the device is running
"udevadm monitor" and pressing and holding the button/buttons until You'll see the message
"add" from udevadm.
I founded that the device in my situation, started with any of following combinations
PwrUp/PwrUp+Vol_+/PwrUp+Vol_.
You can check it with
usb-device | egrep "NVIDIA|APX"
I tried to run different nvflash programs and found working one:
Nvflash v1.8.90246 / 1197539 Bytes / md5sum
d0f1fdada0508d77906d89098ad60091 nvflash
I tried
nvflash --rawdevicewrite 0 64 0_64.dat --bl bl --go
to restore zeroed sectors. It not working without correct sbk key.
I sniffed usb data with wireshark for different sbk keys and found this:
Then device is powering
GET DESCRIPTOR / Data / A.P.X
GET DESCRIPTOR / Data / N v i d i a C o r p 0x2e 0x00
SET CONFIGURATION Request
SET CONFIGURATION Response
URB_BULK in
URB_BULK out / Leftover Capture Data / 180208bb48325d01 // this is CSSN from end to beginning
URB_BULK out / Leftover Capture Data / 1028 Bytes -- generated by nvflash using some func(CSSN)
0x04 0x04 0x00 0x00 and 16 bytes and rest is 0x00
URB_BULK in 0x04 0x00 0x00 0x00
URB_BULK out / Leftover Capture Data / 4096 Bytes
When I tried different sbk keys, I got different answers from the device - those 4096 bytes
of leftover_captured_data. I realized then after checking ONE wrong sbk key , I needed to reboot the device (power off/power on).
And I received next messages:
rcm version 0X4
Command send failed (usb write failed)
You can check URB status in wireshark after running nvflash.
If key is wrong , You'll get "Broken pipe" EPIPE.
I tried
nvflash --format_all --go
in the hope that I do not needed sbk key. In
www_patentmaps_com/topic/Handling_of_secure_storage_key_in_always_on_domain_1.html developers told that
In some cases You do not need to know sbk key for reflashing the device .
And I tried manual decryption
# trying to check if decryption is correct with some generated sbk keys
#
#0xF0D1E800 0x74DB0700 0x7C20E402 0x9839F903
openssl aes-128-cbc -K F0D1E80074DB07007C20E4029839F903 -iv 0 -d -in bct.enc -out bct.dcr -nopad
# incorrect sbk key 0xF0D1E80074DB07007C20E4029839F903
bct.dcr suppouse to look like bct structure
if You need to find more info about manual decryption check showthread.php?t=1698560
even if You have correct decrypted buffer and encrypted buffer , AES are not susceptible to
known-plaintext attacks.
Solution 0 ) Send it to ASUS (read the warranty before)
( in my case i still need that sbk key for deleveloping purpose and I hope
that key will be added to sdk)
Solution 1 ) The are couple of algorithms of generating sbk key from CSSN
usualy it a simple formula and we need to guess that constants
Solution 2 ) Reverse engineering of usb protocol.
Part of the code in the device, that responsible for usb protocol can be vulnerable.
ASUS BIOS developers is good, but a chance exist.
This is a new device on the market. My guess - that part of code can be common for
many models - they just recompile that for different models.
This joke for that developers:
If constructors will build the houses , like programers writing the
programs, then the first flying woodpecker will destroy the civilization.
For now, I am checking algorithms of generation of sbk key.
[ I still looking for any infos about generation sbk from CSSN ]
[ I trying to restore formula of generation sbk key from nvflash that I have ]
[ You can help me with posting every nvflash that you have ]
I tried sbkcheck but I get segmentation fault // solution - found the proper
libusb or better ask sbkcheck.c from author and recompile it.
if You can't get sbkcheck.c then analyze sbkcheck
readelf -a ./sbkcheck > sbkcheck._
objdump -d ./sbkcheck > sbkcheck.dump
./sbkcheck: file format elf32-i386
[cutted]
8048d25: a1 84 a4 04 08 mov 0x804a484,%eax
8048d2a: 89 c2 mov %eax,%edx
8048d2c: b8 41 8f 04 08 mov $0x8048f41,%eax [ offset 0x0000f41 in ./sbkcheck ] Error in bulk transfer
8048d31: 89 54 24 0c mov %edx,0xc(%esp)
8048d35: c7 44 24 08 17 00 00 movl $0x17,0x8(%esp)
8048d3c: 00
8048d3d: c7 44 24 04 01 00 00 movl $0x1,0x4(%esp)
8048d44: 00
8048d45: 89 04 24 mov %eax,(%esp)
8048d48: e8 4b fa ff ff call 8048798 <[email protected]>
8048d4d: b8 ff ff ff ff mov $0xffffffff,%eax
8048d52: eb 70 jmp 8048dc4 <main+0x35a>
8048d54: c7 44 24 04 00 00 00 movl $0x0,0x4(%esp)
8048d5b: 00
8048d5c: 8b 44 24 64 mov 0x64(%esp),%eax
8048d60: 89 04 24 mov %eax,(%esp)
8048d63: e8 70 fa ff ff call 80487d8 <[email protected]>
8048d68: 8b 44 24 4c mov 0x4c(%esp),%eax
8048d6c: 3d 01 00 02 00 cmp $0x20001,%eax !!!!! if $0x20001 getted from device !!!!
8048d71: 75 0e jne 8048d81 <main+0x317>
8048d73: c7 04 24 6b 8f 04 08 movl $0x8048f6b,(%esp) [ offset 0x0000f6b in ./sbkcheck ] Detected SBKv2
8048d7a: e8 39 fa ff ff call 80487b8 <[email protected]>
8048d7f: eb 1a jmp 8048d9b <main+0x331>
8048d81: c7 04 24 7a 8f 04 08 movl $0x8048f7a,(%esp) [ offset 0x0000f7a in ./sbkcheck ] Detected SBKv1
8048d88: e8 2b fa ff ff call 80487b8 <[email protected]>
[cutted]
I wanted to find the difference between sbkv1 and sbkv2 and sbkv3.
And I still looking for sources of sbkcheck.c and Sbkdetect.c or latest
sbkcheck/Sbkdetect
I found some info about tegrarcm () - for reflashing with u-boot bootloader but
It does not supported locked devices with an encrypted boot key, only
open devices such as the ventana, cardhu, or dalmore reference boards.
git://nv-tegra.nvidia.com/tools/tegrarcm.git
and good infos at
http_download_nvidia_com/tegra-public-appnotes
developer_download_nvidia_com/tegra
I found patents info:
www_patentmaps_com/topic/Handling_of_secure_storage_key_in_always_on_domain_1.html
Handling of secure storage key in always on domain
and this pdf www_sourceconference_com/publications/bos12pubs/android-modding-source.pdf
SBK of a Tegra device is leaked or predictable
P.S. Sorry for my bad bad English

Forgive my ignorance but what is this?

sgt. meow said:
Forgive my ignorance but what is this?
Click to expand...
Click to collapse
I think he/she is saying he/she wrote some length of zeros to /dev/block/mmcblk0 and is now in possession of a N7 brick.
The rest of it is sort of stream-of-conciousness documentation of efforts to figure out how to rescue it from that situation.
Scary thing is I understand most of what he/she is saying. Quite a bit of effort put in to this, actually.
I hope she/he succeeds. If there is anyone else working on cracking APX/nvflash/tegrarcm, they are doing so silently... so I am happy to see that someone is trying.

After relating the OP with your post, I seem to understand almost half of the post. But nvflash, sbk keys and algorithms are all but a haze to me.

I understood what you meant. It's the devvy bits regarding nvflash that frazzled me. I really do hope you succeed in your attempts.

I am on the same boat as Sgt. Meow, but you mentioned doing a back up of all the partitions. In what format did you do this? Using what? It sounds like you got NVflash to work or at least do something. If that is the case and your backup is a .img then you should be able to push that to mmcblk0p0 and have a working device again.
Sent from my LG-P999 using xda premium

I backuped from running ubuntu.
I added the command to my first message.
And I still retranslating the message to "normal English"
I think You can do it from TWRP.

I still looking for latest sbkcheck.c , Sbkdetect.c
or executable sbkcheck/Sbkdetect

www_cs_tcu_edu/people/professors/publications/sbk-tmc-2008.PDF
We need to find bivariate l-degree polynomial, like in case of Acer Iconia A500 (tegra2)

Impact(repercussion) of moonlight on lamb's testicles in a shadow

@ OP
You should not break the 10 post barrier like this. You can try helping others in other forums. That way you can earn some Thanks too (not that it should matter anyway). Please take it into consideration. That being said, I wish you all the best with your project and hope you succeed.
sgt. meow

Another very helpful info
www.google.com/patents/us20090204803.pdf

plus
http://www.google.com/patents/us20090204803

Ok, so since you used dd to make an image of your chip, you should be able to use NVflash to write that back to mmcblk0. I don't know that reflashing the entire chip has ever been done, but reflashing individual partitions via NVflash has been done and is a great way to de-brick.
Sent from my LG-P999 using xda premium

Волк said:
Ok, so since you used dd to make an image of your chip, you should be able to use NVflash to write that back to mmcblk0. I don't know that reflashing the entire chip has ever been done, but reflashing individual partitions via NVflash has been done and is a great way to de-brick.
Click to expand...
Click to collapse
Someone has reported doing this successfully for a N7?
Link please! (To my knowledge the successes with nvflash and the Asus TF2xx have not been reproduced on the N7)

Волк said:
Ok, so since you used dd to make an image of your chip, you should be able to use NVflash to write that back to mmcblk0. I don't know that reflashing the entire chip has ever been done, but reflashing individual partitions via NVflash has been done and is a great way to de-brick.
Sent from my LG-P999 using xda premium
Click to expand...
Click to collapse
I can restore from backup, when I'll get sbk

As bftb0 said, how can you even use nvflash on the N7's? Can I use the dd command on a working N7 that has CM 10.1 and twrp in apx mode to save the boot partition or the bootloader and also get the sbk?
Is there really any way to retrieve the sbk on a working N7 to date? So far I think everyone has been unsuccessful, and I have posted on several threads about on how to restore by other methods such as jtag? I think even with jtag if I could access it on the mainboard and be able to use it, I would still need complex script/software. I don't think anyone is ever going to be able to figure out how to get nvflash to work on our devices!!

androidfr33k said:
Can I use the dd command on a working N7 that has CM 10.1 and twrp in apx mode to save the boot partition or the bootloader and also get the sbk?
Click to expand...
Click to collapse
osm0sis has a thread / script in these (XDA N7) forums which allows altering lock state of an individual tablet by capturing/writing the bootloader partition using dd as you describe. But the catch is that every device performs this operation in a unique manner combining the sbk with a device serial# to uniquely encrypt/sign the boot loader - so you can not capture it from a working tablet and write it to a different (bricked) tablet.
Also, the sbk is not stored in flash memory - the flash memory is considered to be "untrusted media" by the processor. (That's what the patent documents that the OP provided links to describe)

bftb0 said:
osm0sis has a thread / script in these (XDA N7) forums which allows altering lock state of an individual tablet by capturing/writing the bootloader partition using dd as you describe. But the catch is that every device performs this operation in a unique manner combining the sbk with a device serial# to uniquely encrypt/sign the boot loader - so you can not capture it from a working tablet and write it to a different (bricked) tablet.
Also, the sbk is not stored in flash memory - the flash memory is considered to be "untrusted media" by the processor. (That's what the patent documents that the OP provided links to describe)
Click to expand...
Click to collapse
Can I capture it on my working tablet to use if I brick my tablet (same tablet)? If so then that is a great tool!!

androidfr33k said:
Can I capture it on my working tablet to use if I brick my tablet (same tablet)? If so then that is a great tool!!
Click to expand...
Click to collapse
Yes you may capture it, No it is not for brickings (due to chicken-vs-egg issues).
http://forum.xda-developers.com/showthread.php?t=2068207
The purpose of it is primarily to allow unlocking/relocking of the bootloader without wiping the user data partition.
Since it does this by writing the appropriate partition from a booted kernel (either OS or recovery), it clearly is not for "bootloader got messed up" bricks.
I mentioned it in the context of this thread (it's a little off-topic) because the devs involved had noticed in the course of their work that the binary blob of data for the bootloader is uniquely encrypted for each tablet. This is consistent with the process shown in the (.pdf) Patent filings that the OP provided.
I haven't tried it yet, so I can't vouch for it, but others have (but note the thread date, too - probably before v4.18 boot loader - I also don't know if that is significant or not). Doing this is on my "to do list", though.

[REF] GT-I9305 hardware hacking

Dear Hardware Hackers, Geeks and Modders,
it always takes some time for me to switch over to a "new" device
Recently i bought a GT-I9305 for cheap, to be more exactely bought two; a broken and a working one.
Anyway, as always i need to disassemble my toys, see what's inside and investigate how things work out on the hardware base.
To follow my descriptions and findings in this thread it is recommended to grab the service manual, e.g. at cpkb.org.
As usual there are already many technical threads covering some of the hardware issues.
It's time to put some light on the unknown details here.
Starting a few weeks ago there'd been some time for reverse engineering, study documents, read posts and draw some conclusions.
I hope you'll enjoy my discoveries and give some feedback.
It might take some time though to write down everything even more detailed and get it little bit structured to post it here.
SD-card mode or complete brick recovery by re-write internal bootloader:
The sboot bootloader is capable to start from external SD-card as well and detects the media it has been started from.
To re-write the bootloader in the internal eMMC, we need an external boot media and block the internal boot process at power up.
The SD-card needs a special structure with the sboot binary right in place.
There's already a detailed thread about this procedure (see the reference links below).
Anyway, as you might have read elsewhere, replacing KNOX bootloader with an older one will not work.
The first time a KNOX bootloader is installed on the device,
some hardware protected blocks on the eMMC become active to meet the requirements of the KNOX function.
This process could not be reverted by simply overwrite the sboot section.
We need other tools for this. This might be covered later.
Prevent booting from internal eMMC by blocking MMC_CMD:
GT-I9300:
eMMC44_CH4: MMC_CMD is blocked by shorting the pull-up resistor R313
GT-I9305:
eMMC44_CH4: MMC_CMD is blocked by shorting the pull-up resistor R634
Please refer to the service manual for the correct position of the components.
Bootloader recovery will need some proof of concept, to be 100% certain that it works in the same way, as it does on GT-I9300.
SD-card booting by changing the CPU boot mode (permanently):
The boot code is set at power up by reading the logic level at special IO pins (XOM6:0).
These logic levels are set by a bunch of resistors and could be tweaked.
The boot modes for Exynos 4412 known so far:
Code:
XOM[5:1] : 1st device : 2nd device
5b'00010 : SDMMC_CH2 : USB
5b'00011 : eMMC43_CH0 : USB
5b'00100 : eMMC44_CH4 : USB
5b'10011 : eMMC43_CH0 : SDMMC_CH2
5b'10100 : eMMC44_CH4 : SDMMC_CH2
GT-I9305 (default, might need some approval by reading the registers):
Code:
XOM[5:1]
5b'10100 : eMMC44_CH4 : SDMMC_CH2
XOM0 : R612 10K PU
XOM1 : R614 100K PD
XOM2 : R615 100K PD
XOM3 : R609 10K PU
XOM4 : R616 100K PD
XOM5 : R610 10K PU
XOM6 : R617 100K PD
GT-I9305 (SD-card boot mode, needs testing!!!):
Code:
XOM[5:1]
5b'00010 : SDMMC_CH2 : USB
XOM0 : R612 10K PU (no change here)
XOM1 : R614 100K PD (no change here)
XOM2 : R615 10K PU (changed from PD to PU)
XOM3 : R609 100K PD (changed from PU to PD)
XOM4 : R616 100K PD (no change here)
XOM5 : R610 100K PD (changed from PU to PD)
XOM6 : R617 100K PD (no change here)
This relationship had been partly reverse engineered and concluded from other designs.
May need some approval though.
Same here, external booting from SD-card will need some proof of concept, to be 100% certain that it works without flaws.
There's a uncertainty concerning standard sboot, to allow a complete boot into system level (e.g. recovery) using a non default boot mode.
Maybe the code is bound to the device (internal eMMC only) in some way, or external SD-card is not fully supported as boot media.
Anyway, it is straight forward to build up a SD-card for testing.
The kernel boot parameter and parts of recovery image will need some tweaks to use the right device to boot from.
Direct access to Exynos 4412 debug UART:
The debug UART is permanently accessible on connector HDC401 (no need to block the USB port for this feature).
AP_TXD : HCD401, pin 11 (LVTTL 1.8V)
AP_RXD : HCD401, pin 17 (LVTTL 1.8V)
Please refer to the service manual for the position of connector HCD401.
These signals are fully tested and working.
The best would be to get the counter part of Panasonic AXE620124AW1 for a direct connection,
but this parts seems tobe hard to find.
As an alternative you'll need some very fine soldering iron and some tiny wires.
This way you could solder the wires directly to the pins of the connector.
You'll need some 1.8V level converter (+ USB UART) as already to be found in many projects.
Set up your terminal to 8N1 at 115200Bit/s and there you go.
E.g. enter S-Boot command line by hitting enter at boot up:
Code:
PMIC rev = PASS2(4)
cardtype: 0x00000007
SB_MMC_HS_52MHZ_1_8V_3V_IO
mmc->card_caps: 0x00000311
mmc->host_caps: 0x00000311
mmc_initialize: mmc->capacity = 30777344
Samsung S-Boot 4.0-1153417 for GT-I9305 (May 29 2013 - 17:22:39)
EXYNOS4412(EVT 1.1) / 2047MB / 15028MB / Rev 2 / I9305XXBME3
initialize_ddi_data: usable! (0:0x0)
PARAM ENV VERSION: v1.0..
init_fuelgauge: fuelgauge power ok
get_battery_detect: battery is missed
init_fuelgauge: battery is not detected, vcell(3858), soc(59)
init_fuelgauge: POR status
fuelgauge_por: POR start: vcell(3858), vfocv(3871), soc(59)
fuelgauge_por: update SDI M0 parameter
fuelgauge_por: RCOMP(0x0063), TEMPCO(0x0930)
fuelgauge_por: POR finish: vcell(3856), vfocv(3901), soc(55)
get_table_soc: vcell(3855) is caculated to t-soc(62.486)
init_fuelgauge: start: vcell(3855), vfocv(3898), soc(55), table soc(62)
init_fuelgauge: finish: vcell(3855), vfocv(3898), soc(55), table soc(62)
init_microusb_ic: MUIC: CONTROL1:0x00
init_microusb_ic: MUIC: CONTROL1:0x00
init_microusb_ic: MUIC: CONTROL2:0x3b
init_microusb_ic: MUIC: CONTROL2:0x3b
PMIC_ID = 0x02
PMIC_IRQSRC = 0x00
PMIC_STATUS1 = 0x10
PMIC_STATUS2 = 0x00
PMIC_PWRON = 0x02
PMIC_IRQ1 = 0x0c
PMIC_IRQ2 = 0x00
s5p_check_keypad: 0x0
s5p_check_reboot_mode: INFORM3 = 0 ... skip
s5p_check_upload: MAGIC(0xc0c0c0c0), RST_STAT(0x10000)
microusb_get_attached_device: STATUS1:0x38, 2:0x00
s5p_check_download: 0
microusb_get_attached_device: STATUS1:0x38, 2:0x00
check_pm_status: chargable jig, LPM boot
AST_CHARGING..
cmu_div:1, div:7, src_clk:800000000, pixel_clk:57153600
s6e8ax0_read_id :: retry: 1
s6e8ax0_read_id :: 0xd1
<start_checksum:373>CHECKSUM_HEADER_SECTOR :4096
<start_checksum:375>offset:50, size:6296
<start_checksum:379>CHECKSUM_HEADER_INFO : NeedChecksum:0 PartNo:20
Not Need Movinand Checksum
Movinand Checksum Confirmation Pass
autoboot aborted..
S-BOOT #
S-BOOT # help
Following commands are supported:
* chipinfo
* help
* log
* reset
* boot
* load_kernel
* printenv
* setenv
* saveenv
* findenv
* checksum_need
* usb
* upload
* keyread
* readadc
* usb_read
* usb_write
* sdcard
* mmcdtest
* fuelgauge
To get commands help, Type "help <command>"
S-BOOT #
That's it by now!
Consider this as a starter, i'll try to add, correct or change some things from time to time and i hope it's human readable
Please give me some feedback or tell me your thoughts
I will add pics as soon as possible and further details if there's some interest.
I will also give some credits soon, because some of these findings are based on information from the curious around here
Credits:
AdamOutler
E:V:A
References:
GT-I9300 hard-brick-fix
http://forum.xda-developers.com/galaxy-s3/general/galaxy-s-iii-gt-i9300-hard-brick-fix-t1916796
Totally Revolutionary SDCard Bootloader For Galaxy S III
http://forum.xda-developers.com/galaxy-s3/general/totally-revolutionary-sdcard-bootloader-t2061437
Port SDCard Recovery to Other Exynos4412 Devices
http://forum.xda-developers.com/showthread.php?p=34732948
Knox reset
http://forum.xda-developers.com/showthread.php?t=2504258
eMMC sudden death research
http://forum.xda-developers.com/showthread.php?t=2096045
NOTE:
I am not responsible for any damaged devices.
The technical information may need some verification by experiments!
It would be nice to add a remark and refer to this post, if you use the pics and information from this thread :highfive:
Cheers,
scholbert

technical info, datasheets... stuff
eMMC function, structure and usage
1. Basic info
The onboard eMMC is the mass storage of our device.
There's much more under the hood, than you might expect and notice during normal usage within the OS.
The area we may access from within Android OS is called USER area (all partitions belong to this area).
This part could be easily accessed and you may back up all data of this area to a disk image.
Apart from that, the eMMC is used as secure boot media.
On some of the ICS kernels there was a block device called /dev/mmcblk0boot0 (protected by ro-flag).
This device node is missing on most of the S3 devices and hence it is not possible to access this part.
Anyway, it is hidden area where Samsung placed the bootloader and stuff, the BOOT area.
If you are using still ICS bootloader it consists of at least 2 parts:
2MB area for BL1 (s-boot+TZSW+ddi-data)
2MB area for BL2 (not used, zeroed out)
If you upgraded to JB/KK bootloder another part is setup up and configured:
RPMB (KNOX counter, etc.)
I found no information about the size, but it's a multiple of 128K and may be set up between 128-512K.
Once activated the information stored in this area is controlled by internal security mechanism of eMMC.
Only trusted code is granted access and even worse, from a users sight it acts like OTP memory.
To get some info about the eMMC built in your device the sysfs entries are a good place to start.
We could grep the type of device form here, e.g. the eMMC in my GT-I9305 gives this output:
Code:
# cd /sys/class/block/mmcblk0/device
# cat name
MAG4FB
# cat manfid
0x000015
# cut -b 19,20 cid
f7 // this is the firmware revision in hex
# cat date
09/2012
See the datasheet attached (this is the exact part)
2. EFI partition and GPT
The first block of USER area of starts with traditional MBR.
Next block starts with the header for the EFI partition which is the base container for all other parts.
Code:
[SIZE="2"]45 46 49 20 50 41 52 54 Signature "EFI PART"
00 00 01 00 GPT version 1.0
00 02 00 00 header size 512 Bytes
5B DF 6D 84 CRC32 of header
00 00 00 00 reserved
01 00 00 00 00 00 00 00 Current LBA (location of this header copy)
FF 9F D5 01 00 00 00 00 Backup LBA (location of the other header copy)
22 00 00 00 00 00 00 00 First usable LBA for partitions (primary partition table last LBA + 1)
DE 9F D5 01 00 00 00 00 Last usable LBA (secondary partition table first LBA - 1)
41 4E 44 52 4F 49 44 20 4D 4D 43 20 44 49 53 4B ANDROID MMC DISK
02 00 00 00 00 00 00 00 Starting LBA of array of partition entries (always 2 in primary copy)
80 00 00 00 Number of partition entries in array
80 00 00 00 Size of a single partition entry (usually 128)
28 53 B2 A4 CRC32 of partition array
00 00 00 00[/SIZE]
The rest of this block is the GPT.
Reference:
http://en.wikipedia.org/wiki/GUID_Partition_Table
Other useful reading:
http://forum.xda-developers.com/showpost.php?p=31254495
3. PIT
This is another essential part of the USER area of eMMC and defines all partitions used by the OS.
Here's the definition of the internal structure:
Code:
[SIZE="2"]typedef int __s32;
typedef unsigned int __u32;
#define PARTITION_MAGIC 0x12349876
typedef struct _partition_header {
__u32 dwMagic; /* MAGIC CODE */
__s32 nCount; /* PARTITION (OneNAND + MOVINAND) */
/* PIT Option. */
__s32 dummy[5];
} __attribute__((packed)) partition_header;
typedef struct _partition_info {
__s32 nBinType; /* BINARY_TYPE_ (AP or CP?) */
__s32 nDevType; /* PARTITION_DEV_TYPE_ */
__s32 nID; /* PARTITION ID */
__s32 nAttribute; /* PARTITION_ATTR_ */
__s32 nUpdateAttr; /* PARTITION_UPDATE_ATTR_ */
__u32 dwBlkSize; /* BLOCK SIZE / OFFSET IN BLOCKS */
__u32 dwBlkLen; /* BLOCK LENGTH */
__u32 dwOffset; /* FILE OFFSET (obsolete) */
__u32 dwFileSize; /* FILE SIZE (obsolete) */
char szName[32]; /* PARTITION NAME */
char szFileName[32]; /* FILE NAME */
char szDeltaName[32]; /* DELTA FILE NAME FOR BOOTLOADER FOTA */
} __attribute__((packed)) partition_info;[/SIZE]
Example:
Code:
[SIZE="2"]BOOTLOADER:
00 00 00 00 nBinType; /* BINARY_TYPE_ (AP or CP?) */
02 00 00 00 nDevType; /* PARTITION_DEV_TYPE_ */
50 00 00 00 nID; /* PARTITION ID */
02 00 00 00 nAttribute; /* PARTITION_ATTR_ */
01 00 00 00 nUpdateAttr; /* PARTITION_UPDATE_ATTR_ */
00 00 00 00 dwBlkSize; /* BLOCK SIZE / BLOCK OFFSET */
C6 06 00 00 dwBlkLen; /* BLOCK LENGTH */
00 00 00 00 dwOffset; /* FILE OFFSET (in TAR) */
00 00 00 00 dwFileSize; /* FILE SIZE */
szName[32]; /* PARTITION NAME */
42 4F 4F 54 4C 4F 41 44 45 52 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
szFileName[32]; /* FILE NAME */
73 62 6F 6F 74 2E 62 69 6E 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
szDeltaName[32]; /* DELTA FILE NAME FOR BOOTLOADER FOTA */
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[/SIZE]
4. Complete partition table (GT-I9305)
Code:
[SIZE="2"]Block Size = 0x200
BOOT AREA:
Partition Image Name OFFSET LEN in BLK LEN OS Partition Physical Partition
BOOTLOADER sboot.bin 0x00000000 0x06C6 0x000D8C00 0x50 0x50
TZSW tz.img 0x000D8C00 0x0138 0x00027000 0x51 0x51
DDI-DATA (DATA) - 0x000FFC00 0x0001 0x00000200
USER AREA:
Partition Name Image Name OFFSET LEN in BLK LEN OS Partition Physical Partition
eMMC MBR (MBR) - 0x00000000 0x0001 0x00000200
EFI PART (GPT) - 0x00000200 0x0001 0x00000200
PIT m3.pit 0x00004400 0x0010 0x00002000 0x46 0x46
MD5HDR md5.img 0x00006400 0x0800 0x00100000 0x47 0x47
BOTA0 - 0x00400000 0x2000 0x00400000 0p1 0x01
BOTA1 - 0x00800000 0x2000 0x00400000 0p2 0x02
EFS efs.img 0x00C00000 0xA000 0x01400000 0p3 0x03
m9kefs1 m9kefs1.bin 0x02000000 0x2000 0x00400000 0p4 0x04
m9kefs2 m9kefs2.bin 0x02400000 0x2000 0x00400000 0p5 0x05
m9kefs3 m9kefs3.bin 0x02800000 0x2000 0x00400000 0p6 0x06
PARAM param.bin 0x02C00000 0x4000 0x00800000 0p7 0x07
BOOT boot.img 0x03400000 0x4000 0x00800000 0p8 0x08
RECOVERY recovery.img 0x03C00000 0x4000 0x00800000 0p9 0x09
RADIO modem.bin 0x04400000 0x2c000 0x05800000 0p10 0x0A
TOMBTONES tombstones.img 0x09C00000 0x80000 0x10000000 0p11 0x0B
CACHE cache.img 0x19C00000 0x200000 0x40000000 0p12 0x0C
SYSTEM system.img 0x59C00000 0x300000 0x60000000 0p13 0x0D
HIDDEN hidden.img 0xB9C00000 0x118000 0x23000000 0p14 0x0E
OTA - 0xDCC00000 0x4000 0x00800000 0p15 0x0F
USERDATA userdata.img 0xDD400000 0x0000 0p16 0x10
[/SIZE]
5. DDI-DATA
In the hidden boot0 partition the values like the flash count are stored.
Triangle away is able to modify this data.
It's stored at 0x000FFC00 on the boot0 partition of emmc.
Code:
struct ddi_data {
int magic; // must be 0x12340012
int custom_flash_count;
int odin_count;
int binary_type; // 0 = samsung official, 1 = custom, 2 = "Unknown"
char model_name[16];
int rom_type; // this is the first 4 bytes of the decrypted 16 bytes
in the param partition. 0xFF000000 = samsung, 0xEE000000 = custom }
For details please refer to this post:
http://forum.xda-developers.com/showthread.php?p=28953690#post28953690
Further useful reading:
http://wiki.cyanogenmod.org/w/EMMC_Bugs
Thesis:
Remove KNOX bit by eMMC low level format command:
With KNOX activation at booloader level, there's an area which stores the KNOX bit information called RPMB.
During research of the eMMC sudden death, some firmware files for the eMMC controller had been reverse engineered and some of the custom commands had been discovered.
Read this and follow ups:
http://forum.xda-developers.com/showpost.php?p=49548099&postcount=121
By changing the boot mode and boot up completely from SD-card into special recovery, it might be possible to send this command with a tool called mmc-utils:
https://github.com/BenGardiner/mmc-utils
Because this will wipe out everything, it would be a great adventure and you'll need a proper backup of all significant parts from the internal eMMC. Otherwise device specific parameters will be lost forever.
See this remark as a reference as well:
http://forum.xda-developers.com/showpost.php?p=51297844&postcount=135
I'll spent some time to think about a useful SD-card layout... :laugh:
TBC
scholbert

All this looks knowledgeable
How are you at ROM/Kernel building?

Hi f0xy!
f0xy said:
All this looks knowledgeable
Click to expand...
Click to collapse
Thanks for this feedback!
I know these experiments are only for the fearless with good eyes.
For the average user there's no need to hack boot mode or stuff, unless there's some evil bricked device
I guess folks need pix
f0xy said:
How are you at ROM/Kernel building?
Click to expand...
Click to collapse
Depends...
On a hobbyist level i build many kernels, tweaked drivers and kernel code for personal use over the years.
Little less if we speak about building ROMs.
I might help out on some issues, but don't count on me for bigger projects.
Time is always lacking and often i'm too lazy to clean up the code for git
Cheers,
scholbert

Hi,
just added the complete partition table for GT-I9305 and some other stuff in the second post...
I try to sum up facts floating around as well and put it in the context of GT-I9305, so some info here is no breaking news
Anyway, enjoy the tech ride!
Regards,
scholbert

@mad_ady I seen your post in boeffla, some info here may be of help? Or maybe the @op can provide some help for you?
Regards

Thanks for the references. It helped me better understand where the partitioning information is kept. I didn't know our devices (I own a GT-9300) had a MBR/GPT table. I wonder, do other (non-samsung) devices use similar partitioning schemes? Or are there also other ways of keeping the partition layout that are in use?

Hi mad_ady!
mad_ady said:
Thanks for the references. It helped me better understand where the partitioning information is kept. I didn't know our devices (I own a GT-9300) had a MBR/GPT table. I wonder, do other (non-samsung) devices use similar partitioning schemes? Or are there also other ways of keeping the partition layout that are in use?
Click to expand...
Click to collapse
Yeah i guess other devices with onboard eMMC use GPT tables as well.
Though it is not completely clear at which level these are accessed.
I assume that the bootloader or even kernel is able to read this table during start up and is also aware of the sizes and boundaries.
The PIT table plays another role in this game.
AFAIK this is the reference for Odin/Heimdall and should match GPT boundaries.
Some experts are needed to confirm this or i'll have to dig a little deeper myself
Regards,
scholbert

Hi there,
i made a comparison between the cmdline passed to the kernel by "old" and "new" bootloaders.
Just started some investigation to fix "offline charging" with KK stock running on devices which still got the old bootloader.
Here's the default cmdline "old" vs. "new":
Code:
[SIZE="2"]JB 4.1.2 (I9305XXBME3) KK 4.4.4 (I9305XXUFNJ1)
console=ram console=ram
loglevel=4 loglevel=4
androidboot.baseband=mdm androidboot.baseband=mdm
sec_debug.level=0 sec_debug.level=0
sec_watchdog.sec_pet=5 sec_watchdog.sec_pet=5
androidboot.debug_level=0x4f4c androidboot.debug_level=0x4f4c
[email protected] [email protected]
- [email protected]
- [email protected]
s3cfb.bootloaderfb=0x5ec00000 s3cfb.bootloaderfb=0x5ec00000
lcdtype=96 lcdtype=96
consoleblank=0 consoleblank=0
lpcharge=0 -
lpj=3981312 lpj=3981312
vmalloc=144m vmalloc=176m
oops=panic oops=panic
pmic_info=67 pmic_info=67
cordon=<32-Byte hash value> cordon=<32-Byte hash value>
- connie=GT-I9305_OPEN_EUR_<32-Byte hash value>
androidboot.emmc_checksum=3 androidboot.emmc_checksum=3
- androidboot.boot_salescode=
- androidboot.odin_download=1
androidboot.bootloader=I9305XXBME3 androidboot.bootloader=I9305XXUFNJ1
- androidboot.selinux=enforcing
- androidboot.warranty_bit=1
- androidboot.sec_atd.tty=/dev/ttySAC2
androidboot.serialno=<16-Byte serial> androidboot.serialno=<16-Byte serial>
snd_soc_core.pmdown_time=1000 snd_soc_core.pmdown_time=1000[/SIZE]
As you might see there's the keyword lpcharge, which is not present on the "new" bootloaders.
On the new bootloaders there's the additional parameter android.bootmode=charger, if you start up with a charger plugged in.
On KK stock some proprietary binaries identify this keyword to activate offline charging.
Some kernel drivers (battery) react to this string as well and there's a patch already.
There'd been some attempts to fix this in initial ramdisk by hi-jacking cmdline present in /proc/cmdline and replace lpcharge=1 with android.bootmode=charger .
My first idea was, to make use of a similar function at kernel level and append android.bootmode=charger to the "old" bootloader cmdline, if lpcharge is set to 1 (similar to a conditional CONFIG_CMDLINE_EXTEND function).
The kernel itself will put this in /proc/cmdline afterwards and user space tools will be satisfied.
Some years ago i tweaked some kernel code for Archos tablets, which made use of custom ATAG keys to hand over some device specific parameters. Maybe i'll get something out of it
For my personal reference:
http://forum.xda-developers.com/galaxy-tab-3/general/kitkat-t31x-t2892792/post55863790#post55863790
TBC
Cheers,
scholbert

Hello.
Thanx for your Thread. For some summary about I9300 and I9305.
:good:
Please I need some input for my low brain...
I'm playing with I9300 and Tizen RD-PQ stuff...
My questions.
How to dump whole mmcblk0 ? Without direct eMMC Hardware...
Maximum 11 GB I can dump in internal sdcard...
http://forum.xda-developers.com/showpost.php?p=59503847&postcount=14
If I try to dump to external SD... I can only dump 4 GB...
RD-PQ sboot seems to work with I9300...
RD-PQ dump shows uboot at address 0x10000 and Tizen PIT is at 0x8000...
Tizen 32 MB dump for study...
http://forum.xda-developers.com/showpost.php?p=55514573&postcount=36
My theory... sboot is maybe at end of eMMC...
I can only check if I dump whole eMMC...
Thanx for every input.
Best Regards

The 4GB is a FAT32 limitation. You can try to format your external SD to ext3 or you can try to mount (via CIFS/NFS) a remote storage on which to dump.
Or, you can dump the device in blocks, starting with a specific offset and having a specific length:
http://superuser.com/questions/3807...m-the-specified-offset-but-not-dd-bs-1-skip-n

Hi!
adfree said:
My questions.
How to dump whole mmcblk0 ? Without direct eMMC Hardware...
Maximum 11 GB I can dump in internal sdcard...
http://forum.xda-developers.com/showpost.php?p=59503847&postcount=14
If I try to dump to external SD... I can only dump 4 GB...
Click to expand...
Click to collapse
See mad_ady's comment:
mad_ady said:
The 4GB is a FAT32 limitation. You can try to format your external SD to ext3 or you can try to mount (via CIFS/NFS) a remote storage on which to dump.
Or, you can dump the device in blocks, starting with a specific offset and having a specific length:
http://superuser.com/questions/3807...m-the-specified-offset-but-not-dd-bs-1-skip-n
Click to expand...
Click to collapse
From kernel level it is only possible to dump user area (unless you use a specific kernel with mmcblk0boot0 and mmcblk0boot1 enabled).
Read again this quote form my second post:
The area we may access from within Android OS is called USER area (all partitions belong to this area).
This part could be easily accessed and you may back up all data of this area to a disk image.
Apart from that, the eMMC is used as secure boot media.
On some of the ICS kernels there was a block device called /dev/mmcblk0boot0 (protected by ro-flag).
This device node is missing on most of the S3 devices and hence it is not possible to access this part.
Anyway, it is hidden area where Samsung placed the bootloader and stuff, the BOOT area.
If you are using still ICS bootloader it consists of at least 2 parts:
2MB area for BL1 (s-boot+TZSW+ddi-data)
2MB area for BL2 (not used, zeroed out)
Click to expand...
Click to collapse
adfree said:
RD-PQ sboot seems to work with I9300...
RD-PQ dump shows uboot at address 0x10000 and Tizen PIT is at 0x8000...
Tizen 32 MB dump for study...
http://forum.xda-developers.com/showpost.php?p=55514573&postcount=36
Click to expand...
Click to collapse
Interesting geek stuff... did you made any progress here, e.g. booting with RD-PQ?
adfree said:
My theory... sboot is maybe at end of eMMC...
I can only check if I dump whole eMMC...
Click to expand...
Click to collapse
Nope... it's at the very start of eMMC in a seperate area, normally hidden from user (see my comments above).
See datasheet attached, maybe this helps to understand how eMMC works.
EDIT:
Found the exact part which is soldered on my GT-I9305 mainboard.
See second post for reference as well:
http://forum.xda-developers.com/showpost.php?p=56747098&postcount=2
I'll leave this older datasheet her as well... this is at least a similar part.
Good luck and best regards,
scholbert

Interesting geek stuff... did you made any progress here, e.g. booting with RD-PQ?
Click to expand...
Click to collapse
I have problems to check my progress... because broken/damaged Display...
I see only black...
In Android I can use ADB stuff to see something...
Writing 32 MB RD-PQ dump not kill I9300... (no idea if this could kill IMEI, EFS or other Security stuff)
But I can't see where it hangs or if something is on Display...
Writing only s-boot-mmc.bin (200 KB sboot) from RD-PQ...
I have no idea yet, how to check if really written or ignored by I9300 sboot...
Code:
getprop ro.bootloader
Gives no anwser...
And this feature looks like Kernel related stuff...
Example why I am unsure if 200 KB sboot is accepted...
In I9300 you can find easily string ODIN in sboot...
But in RD-PQ is no ODIN text string... then why my I9300 works without problems with Odin...
I need some time to buy cheap working Display...
So I can see "visual effects" on Display...
1 goal would be this:
SDCARD MODE
COPY BINARY FROm SDCARD..
COPY BINARY TO EMMC..
SDCARD DOWNLOAD COMPLETED.
Click to expand...
Click to collapse
In Tizen world it seems mandatory to restore uboot... it contain the THOR string for THOR Downloader...
https://lists.tizen.org/pipermail/general/2013-November/002707.html
For me it is not clear enough... if RD-PQ sboot loads uboot...
sboot AND uboot is executed...
OR it is or feature...
Only uboot could be enough to executed...
About dump mmcblk0...
Code:
dd if=/dev/block/mmcblk0 skip=0 count=10000000 of=/sdcard/dump_v1.bin
dd if=/dev/block/mmcblk0 skip=10000000 count=10000000 of=/sdcard/dump_v2.bin
dd if=/dev/block/mmcblk0 skip=20000000 of=/sdcard/dump_v3.bin
This seems to work... but last 1 is again 11 GB + big...
It starts after with beginning...
I need proper count value... need some time and calculator...
I hope next week I have working Display for my testdevice...
Best Regards

eMMC hacking.... SD card boot... remove KNOX bootloader... finally?
Hi again,
i'd like to refer to a software package which seems to have leaked from a service center or similar some time ago.
Please refer to this thread, which explains how to revive hard bricked S3 devices and other Exynos devices:
http://forum.xda-developers.com/galaxy-s3/general/samsung-s3-i9300-note2-n7100-i9500-s4-t2647558
I found this package at several other places in the web as well, and it might be useful for some smart experiments :angel:
Here's what i got from it...
S3 repair contains a test suite for low level tests and tasks to setup up S3 from scratch.
You'll have to prepare a MicroSD card with a low-level tool (similar to dd command in linux).
The write script gives an idea about the offsets used on the SD card (multiples of 512 bytes), so i translated those to hex values:
emmc_auto.sbl.bin:1:499OFF: 0x00000200 LEN: 0x0003e600
E4412_S.TN.bl1.bin:9500:16OFF: 0x004a3800 LEN: 0x00002000
S5E4412_asb.bin:20000:40000OFF: 0x009c4000 LEN: 0x01388000
asb.ramfs:80000:97000OFF: 0x02710000 LEN: 0x02f5d000
From what i got by investigating the hex data of these binaries, the functions should be:
- emmc_auto.sbl.bin -> a bootloader suitable to start from SD card only
- E4412_S.TN.bl1.bin -> trustzone binary which sets up this part of the SoC for SD card boot
- S5E4412_asb.bin -> a standalone tool and testsuite compiled as a ready to run binary (no elf format here!)
- asb.ramfs -> a proprietary RMFS formatted ramdisk which carries some test files (e.g. test pattern, test videos, etc.)
A quite interesting piece of code is the S5E4412_asb.bin file.
So grepping some strings in this binary file gave this section, which is responsible for
vendor boot size change with CMD62 (refer to the eMMC datasheet as well) and seems to restore the bootloaders:
Code:
0x093DB6 0x2B APP STEP] Step 1. BL Download Address Set
0x093DE6 0x2D APP STEP] Step 2. DRAM Download Address Set
0x0943CA 0x0A NA,\NA0\NA
0x0943D6 0x0A NA$\NA(\NA
0x0943FE 0x2D APP STEP] CMD 0xEFAC62EC : RESPONSE 0x%08x %
0x094432 0x2B APP STEP] CMD 0xCBAEA7 : RESPONSE 0x%08x %
0x094462 0x32 APP STEP] Boot Partition Size : RESPONSE 0x%08x %
0x09449A 0x32 APP STEP] RPMB Partition Size : RESPONSE 0x%08x %
0x09472A 0x24 APP STEP] CMD 6 : RESPONSE 0x%08x %
0x094756 0x2B APP STEP] BL1 & BL2 loading Address : 0x%x
0x094786 0x2C APP STEP] Dram Image loading Address : 0x%x
0x0947B6 0x34 APP STEP] BL1 & BL2 compare address for Read : 0x%x
0x0947EE 0x35 APP STEP] Dram Image compare address for Read : 0x%x
As user Oranav pointed out in the eMMC sudden death research thread, there might be commands
which should initiate low level formatting of the eMMC chip:
CMD62 (ARG: 0xEFAC62EC)
CMD62 (ARG: 0xFAC0021)
This might probably delete all the chip metadata (incl. wear leveling state and bad block info)
and if these commands are correct, it will also reset KNOX counters and stuff.
In other words this is a full factory wipe of eMMC cells.
These are some snippets in S5E4412_ASB.bin located at:
0x8A41C0:
Code:
A5 A2 04 00
80 22 06 00
EC 62 AC EF = CMD62 (ARG: 0xEFAC62EC)
00 00 04 12
31 0C 62 00
71 1F 04 00
AB C2 9E FF
5A 7B B6 F0
83 68 AE 0F
CD 12 04 00
21 00 AC 0F = CMD62 (ARG: 0xFAC0021)
EE CC DE 00
A9 40 35 FF
BD AE 33 F1
80 97 72 00
1D 28 04 00
...and again at:
0x8C43F0
Code:
2D A2 04 00
CD A4 04 00
80 22 06 00
EC 62 AC EF = CMD62 (ARG: 0xEFAC62EC)
00 00 04 12
31 0C 62 00
AB C2 9E FF
5A 7B B6 F0
9F 1B 04 00
83 68 AE 0F
47 0F 04 00
21 00 AC 0F = CMD62 (ARG: 0xFAC0021)
EE CC DE 00
A9 40 35 FF
BD AE 33 F1
80 97 72 00
This could be some approval for the usage of these commands at least, because these sections are pure ARM assembly and seem to be associated with eMMC low level setup.
I'll have to find out some offsets for this machine code to try a disassembly.
Maybe this will lighten things up even more.
EDIT:
BTW, found one of the main return addresses which is at 0x40008000 (physical address at the beginning of DRAM). Let's see if this is correct.
EDIT2:
Bingo... just had a look in my boot logs i once grepped during UART session:
Starting kernel at 0x40008000...
Conclusion:
The ASB test suite (S5E4412_asb.bin) is booted/started at the same offset as the linux kernel does.
Let's see what this may give us
Another thing to mention is, that included in S5E4412_asb.bin there's a M0 test bootloader (GT-I9300).
Have a look at offset 0x08d8fe8 inside the binary
So in the end i wonder, if someone has ever used this "Service" card together with a real UART connection to the board.
Apart from the automated test and setup process, my guess is, that there should be some command line or some kind of a test menu which may give alternative choices to proceed certain tasks.
P.S.: Maybe it's hard to understand what i like to point out here... but imagine we use the following:
- emmc_auto.sbl.bin -> a bootloader suitable to start from SD card only
- E4412_S.TN.bl1.bin -> trustzone binary which sets up this part of the SoC for SD card boot
- recovery.img -> kernel + recovery to start completely from SD card (eMMC not touched here!!!)
P.P.S: Let's see if the SD card boot files look for a signature here.....
Stay tuned!
scholbert

... further experiments
Hi,
i made further progress with my attempts to boot my GT-I9305 completely from external MicroSD.
As proposed in my last post i prepared a card with the following commands:
Code:
echo "Exynos4412 FWBL1+BL2"
dd if=./emmc_auto.sbl.bin of=/dev/sda bs=512 seek=1
echo "Exynos4412 TZSW"
dd if=./E4412_S.TN.bl1.bin of=/dev/sda bs=512 seek=9500
Next is to prepare the board.
You'll need Anyway JIG or a dedicated UART connection as described in my first post.
To block access to internal eMMC the resistor R634 on the GT-I9305 mainboard got shorted.
Insert the MicroSD with the proprietary boot files into the socket.
Connect to a terminal and attach supply voltage of 3.8-4.0V to the battery connector.
Press the power button and hold it.
Here's the output so far:
Code:
TN default
<OK>
<OK>
[DVFS] INT(1) : 0
DRAM Type : LPDDR2 16G
[DVFS] MIF(3) : 0
[EPLL][VPLL][CLK_DIV] OK
<OK>
[LOCK SW/HW]ARM:0/0 INT:0/0 G3D:0/0 MIF:0/0 SHIFT:0/0
[DVFS] ARM(0) : 5
[DVFS] INT(1) : 0
[DVFS] G3D(2) : 0
[DVFS] MIF(3) : 0
[SD_INIT
SDMMC_HighSpeed:DONE]
SD_READ: 20000 20000 0x40008000 -> 422650 usec
<OK>
Inp32(uAddr) : 0x0
LINUX Bootingøq!ñ¥¡Õ
At this point there are no further outputs, as there's nothing to be executed.
Like known from the sboot, hitting enter on your terminal from the very beginning gives a commandline interface.
Unfortunately, it seems that the watchdog is not stopped at this point and maybe the PMIC is not fully initialized.
This leads to repeated resets.
Anyway if you're fast enough, you may get this command list from the proprietary bootloader:
Code:
BL>help
CMD LIST
LOG
WAIT
USB
GET
JUMP
RUN
RUN2
INIT
INIT2
DMC
CLK
DVFS
ASV
DVFSQA
EMA
PMIC
SD
EMMC
ZIP
ABB
RESET
DUMP
MEMCPY
MEMCMP
MEMSET
OUTP32
INP32
SETBITS
GETBITS
COPYRUN
MEMCPY_RUN
PATTERN
BOOT
CTA
ASB
COM
HELP
H
TEST
TN
<OK>
BL>
Some of these commands play an important role for starting up the ASB test suite if present.
These command are included in BL2 and they seem to be interpreted by ASB:
Code:
TN M0|PMIC
INIT2 3|init2|TEST
EMMC
0x10020800 1|TEST RUN
I started to mod these, but as far as i did not start the ASB image yet there's nothing to observe.
By looking at other logs from brick recoveries, i found a relationship between the first output of ASB and these commands.
My idea is that by changing these we could influence the behaviour of the ASB code for educational purpose.
As described above, without parts of ASB the PMIC seems not to be fully initialized,
because i found out that you need to hold the power button to keep the board alive.
This is little strange, as i am pretty sure that this was not the case in the begining, but maybe i'm wrong.
Anyway as far as i observed it, the board starts normally from internal eMMC after my experiments had finished.
At least nothing indicates that something got damaged...
Just to check out what happens i put a raw recovery image at position 20000 (0x9c4000) on the card.
This is the beginning of kernel code.
Afterwards i started a new terminal session and i saw that the first command of kernel code got printed,
but unfortunately after the bootcode jumps to this code there's no further output.
Something is still missing.
Could be something obvious (e.g. missing TAGS at 0x40000100) or could be not.
Maybe it would be a good idea to compile a version of u-boot and try again.
Let's see
scholbert

....grrrr
Hi again!
First of all, nice to see that at least two guys follow my binary surgery.
Second, i must admit that the platform is not that responsive as i first thought.
Due to all this signing stuff, it is easy to break something and CPU simply stops executing code.
So for now there's nothing, than further logging outputs from the console.
1. I removed some of the start up commands from BL2, which leaves TN M0|PMIC & INIT2 3|init2|TEST for ASB code.
This is what i got then:
Code:
TN default
<OK>
<OK>
[DVFS] INT(1) : 0
DRAM Type : LPDDR2 16G
[DVFS] MIF(3) : 0
[EPLL][VPLL][CLK_DIV] OK
<OK>
[CHIPID] E4412 EVT1.1
LOTID WNO X Y IDS HPM ASV_GRP FUSE SHIFT
[LOG]N571A 18 201 195 22 22 8 -1 100000 80
There's no auto booting anymore at this point.
2. I put anything back, apart from the RUN command.
During this test i used a modified ASB binary with sboot from I9305XXALI4 put in the right place.
Unfortunately the output stops after "FW Booting"
The device kept being powered though. Which is a good thing from my guess.
Here's the log:
Code:
TN default
<OK>
<OK>
[DVFS] INT(1) : 0
DRAM Type : LPDDR2 16G
[DVFS] MIF(3) : 0
[EPLL][VPLL][CLK_DIV] OK
<OK>
[LOCK SW/HW]ARM:0/0 INT:0/0 G3D:0/0 MIF:0/0 SHIFT:0/0
[DVFS] ARM(0) : 5
[DVFS] INT(1) : 0
[DVFS] G3D(2) : 0
[DVFS] MIF(3) : 0
[SD_INIT
SDMMC_HighSpeed:DONE]
SD_READ: 20000 20000 0x40008000 -> 422818 usec
<OK>
Inp32(uAddr) : 0xea00007e
FW Booting
Right now it's a bit to early for further conclusions, but maybe the signing stuff got broken at some point in both cases.
It could also be that some of the signatures is especially for GT-I9300, or in other words the CPU on GT-I9305 uses a different key set.
That's it by now, but i won't give up yet
Cheers,
scholbert

Wow, that's one of the most insightful threads about 4412 I've seen for a while.
Replying here on OP's PM for further reference:
* At LenovoK860 uboot sources:
These seem to contain private keys for some batch of 4412 - that's the first time I see private signing keys of any Exynos to leak. Previous leaks were just wild security-dropping bootloader stages signed with private keys, but no keys included.
These keys can either match batch customized for Lenovo or match all 4412 (Exynos4 public key hash fuses, in theory, meant to be factory/OEM customizable) - I'd say the latter since neither GS3 or any common device built on S5PC2xx I've seen was expected to have any grade of real security, so probably neither Lenovo or Samsung cared to customize any of Exynoses used around.
There is a way to check it by comparing dumps from 0x10100000 area between GS3 and LenovoK860 CPUs (I'm uncertain, as I'm really rusty). Probably there's also other way by comparing Lenovo stage1 public keys with GS3 0x1010_0000 dumps, considering how pubkey is validated against these bits (no idea, don't remember).
* At My and Adam's tries:
We were quite succesfull in running UBoot on I9300 and GalaxyCam GC100.
What we couldn't achieve was kernel booting - Exynos4 kernels require TZSW to be fully operating and communicating with it. I couldn't get it to load up properly.
There's quite of history of our tries under https://github.com/Rebell/exynos4_uboot/commits/master
Another option is, of course, disabling TZSW support in kernel and not booting it at all - it doesn't seem to work out-of-the-box either, and would make impossible to boot any non-modded kernels.
AFAIR (and boy, was it while ago), referenced sources were building and fusing to the SD card flawelessly and supporting both fastboot and UART terminal with most (all?) of the commands working (yes, it can do raw R/W to eMMC and whatnot in SVC mode without TrustZone supervisor interfering, because it's not loaded at all yet). Just kernel wouldn't boot. I'd say you should give it a try (if you didn't already).
The crucial part we used there was FWBL1 (there https://github.com/Rebell/exynos4_uboot/tree/master/sd_fuse) - first, already signed, stage of bootloader hat's doing nothing but loading another stage of bootloader without any security (kudos to Odroid).
We couldn't find any equivalent of signed FWBL1 for Exynos4210 (GS2 CPU) that would allow us booting eMMC hardbricked GS2 devices.
* At ASB:
First time I hear of it. Never seen this stuff before.

... just an update
Hi,
it's been a while now that i found some time to fiddle around with one of my i9305 mainboards.
In the meantime there'd been some nice conversation via PM with Rebellos as well.
u-boot on Galaxy S3
Find the sources here:
https://github.com/Rebell/exynos4_uboot
So i finally gave it a try, jumped on his work and compiled a version of u-boot for Galaxy S3 devices.
As a prerequisite you'll have to block eMMC and to make it short...
It just works!!!
Attached you'll find a log from external sdcard boot.
Maybe i'll do some tweaks in the near future, e.g. remove the annoying "pmic_s5m8767_init" messages,
as there is no such device on our S3.
s-boot for Tizen on Galaxy S3
On the Tizen Wiki (https://wiki.tizen.org/wiki/Flash_Tizen_2.2.1_Image_to_Reference_Device)
there's a link to a tar with image files (Tizen_RD-PQ_System_20131107_1.tar), which contains a s-boot file.
Unfortunately the signature of BL1 inside the s-boot image seems not fit the mass production units.
In other words no boot message here at all... at least while trying to boot from sdcard.
mass production sboot on external SD-card
On the other hand the mass production units sboot images are ready to boot from sdcard as well.
Find the second log attached below.
The error messages are normal, because i blocked eMMC all the time, to prevent bricking during my experiments.
security key validation
As you'll see in the logs i dumped the region at 0x10100000 for the security key values.
Here's a snippet of the secure boot function header in the u-boot sources:
Code:
#define MAX_EFUSE_DATA_LEN 16
typedef struct
{
unsigned char rsa_n[128]; /* RSA Modulus N */
unsigned char rsa_e[4]; /* RSA Public Exponent E */
} RawRSAPublicKey;
typedef struct
{
RawRSAPublicKey rsaPubKey; /* RSA PublicKey */
unsigned char signedData[20]; /* HMAC Value of RSA PublicKey */
} PubKeyInfo;
/* Secure Boot Context */
typedef struct
{
RawRSAPublicKey stage2PubKey; /* Stage2 RSA Public Key */
unsigned char code_SignedData[128]; /* RSA Signature Value */
PubKeyInfo pubKeyInfo; /* Stage1 RSA PublicKey and it's HMAC value */
unsigned char func_ptr_BaseAddr[48]; /* Function pointer of iROM's secure boot function */
unsigned char test_eFuse[MAX_EFUSE_DATA_LEN];
unsigned char reservedData[36];
} SecureBoot_CTX;
If i assume S3 still uses V1.1 security with 1024Bit RSA (BL1.bin is 8192Byte) the efuse key would be 128Bit, which results in 4 registers with 32Bit length.
Exported to a hex dat file this is 16Byte of Hex data.
Dump at 0x10100000 gives:
Code:
10100000: 0d19a391 2a0502af 1576987a 212121bc .......*z.v..!!!
We'll have to re-arrange the bytes for little endian order:
Code:
91a3190d af02052a 7a987615 bc212121
... use a hex-editor and put these into a file named: eFuseData.dat
Next i took codesigner_v21 and tried to validate stock BL1 files if they match.
codesigner_v21 -v1.1 <BL1.bin> <eFuseData.dat> -VERIFY
Unfortunately no succes yet... signature verification always failed.
This is a mistery, because the position of the key should be correct and i used valid bootloader files as well.
Anyway this had been only a proof of concept if we got the right tool and the right efuse values.
TBC
Cheers,
scholbert

@scholbert
Please, need collection of GT-I9305 Bootloader....
Something like this:
http://forum.xda-developers.com/galaxy-s3/general/guide-extract-bootloader-make-flashable-t2864264
http://forum.xda-developers.com/galaxy-s3/general/ref-galaxy-s3-stock-kernel-bootloaders-t2189063
For now I was only able to find
RESTORE_BOOTLOADER_I9305XXALI4.zip
http://forum.xda-developers.com/showpost.php?p=32760677&postcount=1
I need few more for stupid tests.
For now my test GT-I9300 PCB is able to start this sboot.bin from GT-I9305... with tweezer.
sboot.bin is copied successfully... but not start in "normal mode"...
Here I can see other method... sboot.bin is not copied to eMMC but fully executed from eMMC, with Boot menu:
http://forum.xda-developers.com/showpost.php?p=64664423&postcount=278
I will check if GT-I9305 has similar Bootloader and if it will executed on my GT-I9300 test PCBs.
Thanx in advance.
Best Regards

I found this:
I9305XXUFNL1-DBT.zip
Here is sboot.bin from GT-I9305 inside... I have attached.
Search for text String THOR... you can find:
Code:
- Thor is connected!
This could mean... I9305 is Tizen enebled... not only this...
Chance to play with U-Boot.
Tried on I9300 with no luck...
Volume + or Volume - do nothing... maybe Hardware Keys different...
I hope to find something working for my I9300...
Btw.
First time I saw THOR string also in Note 4 N910C:
http://forum.xda-developers.com/showpost.php?p=64663039&postcount=65
Best Regards

[TOOL] Newflasher (xperia command line flasher)

Disclaimer:
newflasher tool was made for testing and educational purposes, ME is not responsible for what you do on/with your device using newflasher, you must agree that you using newflasher on your own risk, I am not responsible if you brick your device or anything else!
How to use:
OPTIONAL STEP 1:
- if you have missing flash driver just double click exe and confirm driver extraction, an exe will become available, run it and install driver.
OPTIONAL STEP 2:
- this step is optional, this step dump trim area, you can do this and keep those file somewhere on your pc in case you hard brick your device so give it to servicians to repair your phone.
STEP 1:
- Download right firmware for your device using XperiFirm tool, put newflasher.exe into firmware dir created by XperiFirm tool. Before you double click newflasher.exe do in mind something, newflasher tool is programed to flash everything found in the same dir!!! So tool flash all .ta files, all .sin files, boot delivery (whole boot folder), partition.zip, in short all files found in dir! If you no want to flash something just move file which you no want to flash OUT OF FOLDER! Partition.zip .sin files can be flashed only if you extract partition.zip into newly created folder called partition!
STEP 2:
- To start flashing phone put your phone into flash mode, double click newflasher.exe and wait wait wait until your device gets flashed, thats it. Look into log to see if something goes wrong! If all right you are done. If not post your log so I can look!
SOME MORE THINGS:
"You do not need to unlock bootloader or to root the phone if you want to flash a stock firmware from XperiFirm.
There are no files in the stock firmware that need to be deleted. Prompts will ask you to skip some files.
Feel free to press N to every prompt since:
- TA dumping it's not related with DRM keys.
- Flash persist_* files only if you know what you are doing, since you will lose your attest keys. Backup persist partition.
If you need the firmware on both A and B slot use fastboot commands to choose the inactive partion and re-flash."
Happy flashing!
Supported platforms:
- Newflasher is working on Windows, Linux, Android and Darwin, just chose right newflasher binary. With Android version you can flash phone by using another phone!
Changelog:
- version 1: Sorry a lot of work is done in pre pre alpha version and I can't count every changes, just folow development process about version 1, a lot of work is done before it started working. One esential change was done to tool improvement and it is described in one of the my posts related to moving function "erase:" to the section before function "flash:", it is realy improvement and more safer than in time when it was at the start of flashing routine.
- version v2 (15.Aug.2017)
Implemented free disk space safety check, it was missing and danger in case flashing process gets interupted because of the lack of the free disk space needed for sin extractions and temporary files. I have also include GordonGate flash driver prompt so in case somebody have missing flash drivers, simple need to double click exe and folow drivers archive extraction procedure, later need to install these drivers trought Windos device mannager. Also I have implemented an realy pre pre alpha version of the maybe non working trim (why maybe? Because I don't own xzp so can't test) area dump routine, in case it is working we can dump some esentials trim area units from device (probably not a full dump as like it was on every oldest xperia models - no permissions for dumping drm key unit)
- version v3 (23.09.2017)
Some more security checks, it's now a bit safer than v2
- version v4 (21.10.2017)
Updated trim area dumper, now it stores log to the trimarea.log but dump is now in .ta format and writen to the 01.ta and 02.ta
- version v5 (22.10.2017)
Updated trim area dumper, add progress meter, fix y-n prompt (thanks @pbarrette)
- version v6 (22.10.2017)
Updated trim area dumper
- version v7 (23.10.2017)
Updated trim area dumper, newflasher redesigned a bit, fix new partitioning for Oreo
- version v8 (24.10.2017)
Fix trim area dumper
- version v9 & v10 (25.10.2017)
Workaorunds on trim area dumper
- version v11 (07.04.2018)
Support for 2018 devices
- version v12 (29.04.2018)
Try fix doublefree bug/crash (most noticed on Linux 64 bit binary)
- version v13 (01.05.2018)
Fix doublefree bug/crash by removing dynamic allocation from function get_reply
- version v14 & v15 (12.06.2019)
Sony XPeria 1 support added.
- version v16 (16.06.2019)
LUN0 detection optimized.
- version v17 (24.06.2019)
LUN0 detection bug fixed.
- version v18 (10.08.2019)
Untested fix for https://forum.xda-developers.com/cr...wflasher-xperia-command-line-t3619426/page105
Using builtin mkdir instead of calling it trought system call
- version v19 (08.10.2019)
Implemented prompt for flashing persist partition; print skipped .sin files
- version v20 (13.12.2019)
implemented prompt for flashing bootloader,bluetooth,dsp,modem,rdimage to booth a,b slots
- version v21 (29.06.2020)
implemented battery level status check before flashing, flashing bootloader,bluetooth,dsp,modem,rdimage to booth a,b slots is mandatory now and is flashed by default right now, more info, try fix previously reported isue on sync and powerdown command reported 2-3 years ago so I have disabled it and now enabled for test, implemented Macos support (curently need to be tested! If you have plan to test please flash only cache.sin DO NOT flash the rest because of safety for your device!)
- version v22 (30.06.2020)
trying to fix battery capacity retrieval
- version v23 (04.07.2020)
removed battery capacity retrieval (not going to work that way), fix trim area dump file name, new gordongate drivers
- version v24 (04.07.2020)
new feature - now you can run newflasher from script or console with your own command, e.g. newflasher getvar:Emmc-info , I didn't tested all the list of commands, if you do it share them with us!
- version v25 (09.07.2020)
New trim area dump tool, with this change trim area dump is created in 3 secconds. Do in mind this not dump protected units like drm key...etc! Some changes in scripting feature from v24
- version v26 (10.07.2020)
Added 4 diferent reboot modes, reboot to android, reboot to fastboot, reboot to bootloader, power off
- version v27 (11.07.2020) (not yet released)
Workaround in mac libusb
- version v28 (12.07.2020)
Workaround to sync response bug; Fully implemented support for Mac. I'm tested myself on mac 10.14 but confirmed working on mac 10.15 too
- version v29 (12.07.2020)
Mac proper libusb deinitialisation
- version v30 (13.07.2020)
Preparation for Debian packaging; I'm noticed that hex modified arm64 fake pie binary is not working so its now compiled with ndk and its true pie binary now
- version v31 (14.07.2020)
Fix cosmetic bug https://forum.xda-developers.com/showpost.php?p=83056693&postcount=1212 which might confuse somebody
- version 32, not yet released
- version 33 (30.07.2020)
Allow bootloader unlocking with newflasher; Try fix sync response bug for win and darwin too
- version 34 (08.08.2020)
Added support for 32bit sized trim area units (as trim area api changed in xperia mark 2 line) (not yet released because of bug)
- version 35 (08.08.2020)
Updated support for 32bit sized trim area units (as trim area api changed in xperia mark 2 line); Move trim area dumps out of root folder so it not get acidentaly flashed, dumps is now inside folder tadump
- version 36 (27.08.2020)
Some improvements and and possible bug fixes
- version 37 (09.12.2020)
Added support for Xperia 5 II with emmc instead of ufs (not working)
- version 38 (10.12.2020)
Fixed impropper implementation from v37
- version 39 (13.12.2020)
Since mark 2 devices protocol is changed a bit and on some devices OKAY reply is not in separated usb poacket, instead it is merged with data packet, added support for it
- version 40 (03.01.2021)
Temporary solution for determining partition 0 sin file caused by two diferent emmc csd info we found recently on mark 2 devices
- version 41 (03.01.2021)
Removed temporary solution from version 41 so right lun0 sin file get flashed and seccond lun0 get skipped or booth skipped if lun0 sin file do not match device storage size
- version 42 (11.03.2021)
Fix bug in flashing booth slots when current slot is A, thanks to @chrisrg for discovering bug!
- version 43 (12.06.2021)
Support for Mark 3 devices
- version 44 (19.06.2021)
Fully Mark III device implementation
- version 45 (20.06.2021)
Implemented battery level check and prompt user to take a risk and continue flashing or stop flasing if battery level is less than 15 percent
- version 46 (08.07.2021)
Fix problem with filenames which contain "_other", it need to be always flashed to the diferent slot
- version 47 (15.07.2021)
Removed prompt for persist.sin flashing, now its by default skip. Implemented bootloader log retrieval at the end of flashing for better understanding when something goes wrong. Implemented firmware log history retrieval for those who want to know history of the flashed firmwares
- version 48 (19.07.2021)
Flash bootloader,bluetooth,dsp,modem,rdimage to booth slots only on a,b devices
- version 49 (31.07.2021)
Support for XQ-BT41
- version 50 (12.08.2021)
Workin progress on asynchronous usb to make it more like synchronous, added progress bar during send-receive usb packets and more logging. Increased usb timeout to 2 minute. Trying fix sync command at the end of flashing as reported here -> https://github.com/munjeni/newflasher/issues/42
- version 51 (12.08.2021)
Fix empry line printed while receiving usb packets, thanks @elukyan
- version 52 (01.10.2021)
Implemented userprompt for keeping userdata, thanks @OhayouBaka for figuring out! Removed bootloader log retrieval
- version 53, 54, 55 (20.0822022)
Fix trimarea dumper crash on big endian machines, update building makefiles
Credits:
- without @tanipat and his pc companion debug logs this tool will never be possible! Thank you a lot for your time providing me logs! (by the influence of others, He was disappointed me with last post, but I still appreciate his help and can't forget it)
- without @thrash001 who helped testing our tool I never be continue building our tool since I don't have device for testing, thanks mate!
- didn't forgot @beenoliu, thanks mate for testing!
- thanks to @porphyry for testing linux version!
- thanks to @Snow_Basinger for providing sniff log from 2018 device and for testing on his 2018 device
- thanks to @frantisheq for testing newflasher on his 2018 device and for notify about doublefree bug
- thanks to @serajr for providing me some logs which helped me to figure out some things related to 2018 devices
- thanks to @noelex for helping in Xperia 1 implementation
- thanks to @Meloferz for testing on his xperia 1 mark II
- thanks to github contributors, testers and reporters: vog, noelex, TheSaltedFish, solarxraft, pbarrette, MartinX3, kholk
- thanks to Chirayu Desai for tracking addition to Debian and thanks to vog for initiating all that
- thanks to @elukyan for testing and providing me usb sniff logs for mark 3 devices imlementation, thank you so much
Common errors and how to solve:
https://forum.xda-developers.com/t/tool-newflasher-xperia-command-line-flasher.3619426/post-72610228
Source code:
https://github.com/munjeni/newflasher

let me start for you and report

here my log..
Code:
--------------------------------------------------------
newflasher.exe by Munjeni @ 2017
--------------------------------------------------------
Device path: \\?\usb#vid_0fce&pid_b00b#5&15c311e1&0&2#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
Class Description: USB-Controller
Device Instance Id: USB\VID_0FCE&PID_B00B\5&15C311E1&0&2
ERROR: TIMEOUT: failed with error code 997 as follows:
▄berlappender E/A-Vorgang wird verarbeitet.
- Error writing command!
Drücken Sie eine beliebige Taste . . .

Common errors and what you need to do:
ERROR: TIMEOUT: failed with error code 997 as follows:
Overlapped I/O operation is in progress.
FIX --------> https://forum.xda-developers.com/t/tool-newflasher-xperia-command-line-flasher.3619426/post-84603931
Error, didn't got signature OKAY reply! Got reply: FAILFailed to verify cms
FIX---------> Make sure to flash right rom model e.g. if your device is SO-01L you need to flash rom model SO-01L or e.g. your phone is H8314 you need to flash rom H8314 ... etc, otherwise you might hardbrick your phone!
Bootloop caused by rooback protection e.g. by flashing an OLD rom over NEWER one e.g. you have android 11 and want back to android 10 that will bootloop your phone if your phone have rollback protection
https://forum.xda-developers.com/t/...-xq-at51-with-flashtool.4119707/post-84509417
in short explanation your bootloader need to be unlocked. Than by relocking bootloader rollback index (rollback protection) is reset to zero. Than you can flash oldest rom because index in that case is zero so you won't get bootloop related to rollback protection.
It was confirmed working:
https://forum.xda-developers.com/t/...-xq-at51-with-flashtool.4119707/post-84637803
https://forum.xda-developers.com/t/...-xq-at51-with-flashtool.4119707/post-84673613
If neither help you to solve problem you should read boot log to get idea, use this command line option for newflasher:
newflasher Read-TA:2:2050

what I got
--------------------------------------------------------
newflasher.exe by Munjeni @ 2017
--------------------------------------------------------
Device path: \\?\usb#vid_0fce&pid_b00b#6&3a757eec&0&1#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
Class Description: Universal Serial Bus controllers
Device Instance Id: USB\VID_0FCE&PID_B00B\6&3A757EEC&0&1
ERROR: GetOverlapped_in_Result: failed with error code 31 as follows:
A device attached to the system is not functioning.
- Error reaply! Device didn't replied with OKAY or DATA
Press any key to continue . . .
wait for others to report

Hm, you successfully wrote command but error on reaply Lets see new version is out

Today I have free time for development, I don't know when I will get free time again, so guys if you hurry to have flasher I am here and waiting. I do not have 2017 device model so I can't test, so can't continue development without your tests

Driver is the right.
here the next:
Code:
--------------------------------------------------------
newflasher.exe by Munjeni @ 2017
--------------------------------------------------------
Device path: \\?\usb#vid_0fce&pid_b00b#5&15c311e1&0&2#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
Class Description: USB-Controller
Device Instance Id: USB\VID_0FCE&PID_B00B\5&15C311E1&0&2
ERROR: TIMEOUT: failed with error code 997 as follows:
▄berlappender E/A-Vorgang wird verarbeitet.
- Successfully write 0x0 bytes to handle.
- Error writing command!
Drücken Sie eine beliebige Taste . . .

Strange! Maybe run as admin is need?

It would be great if tanipat debug newflasher with monitoring studio so I can compare whats going on? New version is out again.
Edit:
Curent version is safe so you no need to care for brick! Tool currently nothing write to internal mem! I will tell when it is ready for flashing! Now its just pre pre alpha version, only read from phone

in the windows devicemanager is it correct as "SOMC Flash Device"
the next one:
Code:
--------------------------------------------------------
newflasher.exe by Munjeni @ 2017
--------------------------------------------------------
Device path: \\?\usb#vid_0fce&pid_b00b#5&15c311e1&0&2#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
Class Description: USB-Controller
Device Instance Id: USB\VID_0FCE&PID_B00B\5&15C311E1&0&2
ERROR: TIMEOUT: failed with error code 997 as follows:
▄berlappender E/A-Vorgang wird verarbeitet.
- Error write! Need nBytes: 0x18 but done: 0x0
- Error writing command!
Drücken Sie eine beliebige Taste . . .

Can you right click on .exe and run as admin?

the same
Code:
--------------------------------------------------------
newflasher.exe by Munjeni @ 2017
--------------------------------------------------------
Device path: \\?\usb#vid_0fce&pid_b00b#5&15c311e1&0&2#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
Class Description: USB-Controller
Device Instance Id: USB\VID_0FCE&PID_B00B\5&15C311E1&0&2
ERROR: TIMEOUT: failed with error code 997 as follows:
▄berlappender E/A-Vorgang wird verarbeitet.
- Error write! Need nBytes: 0x18 but done: 0x0
- Error writing command!
Drücken Sie eine beliebige Taste . . .
---------- Post added at 08:42 PM ---------- Previous post was at 08:41 PM ----------
Code:
--------------------------------------------------------
newflasher.exe by Munjeni @ 2017
--------------------------------------------------------
Device path: \\?\usb#vid_0fce&pid_b00b#5&15c311e1&0&2#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
Class Description: USB-Controller
Device Instance Id: USB\VID_0FCE&PID_B00B\5&15C311E1&0&2
- Successfully write 0x18 bytes to handle.
- Successfully read 0xd bytes from handle.
Raw input [0xD]:
00000000 4F 4B 41 59 31 30 34 38 35 37 36 30 30 OKAY104857600
get_reaply:[0xD]:
00000000 4F 4B 41 59 31 30 34 38 35 37 36 30 30 OKAY104857600
- Successfully write 0xe bytes to handle.
- Successfully read 0x9 bytes from handle.
Raw input [0x9]:
00000000 4F 4B 41 59 47 38 31 34 31 OKAYG8141
get_reaply:[0x9]:
00000000 4F 4B 41 59 47 38 31 34 31 OKAYG8141
- Successfully write 0xe bytes to handle.
ERROR: GetOverlapped_in_Result: failed with error code 31 as follows:
Ein an das System angeschlossenes Gerõt funktioniert nicht.
- Successfully read 0x0 bytes from handle.
Raw input [0x0]:
- Error reaply: less than 4!
Drücken Sie eine beliebige Taste . . .
Sorry, i must disconnect the device for the next start

Thanks a lot! Seems some good progress here! I had set timeout to 60 secconds, seems it was not enought and caused timeout, now I have set to 120 secconds and donesome small modification, hope we get luck now, new version is out

Code:
--------------------------------------------------------
newflasher.exe by Munjeni @ 2017
--------------------------------------------------------
Device path: \\?\usb#vid_0fce&pid_b00b#5&15c311e1&0&2#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
Class Description: USB-Controller
Device Instance Id: USB\VID_0FCE&PID_B00B\5&15C311E1&0&2
- Successfully write 0x18 bytes to handle.
- Successfully read 0xd bytes from handle.
Raw input [0xD]:
00000000 4F 4B 41 59 31 30 34 38 35 37 36 30 30 OKAY104857600
- Successfully write 0xe bytes to handle.
- Successfully read 0x9 bytes from handle.
Raw input [0x9]:
00000000 4F 4B 41 59 47 38 31 34 31 OKAYG8141
- Successfully write 0xe bytes to handle.
ERROR: GetOverlapped_in_Result: failed with error code 31 as follows:
Ein an das System angeschlossenes Gerõt funktioniert nicht.
- Error reaply: less than 4!
Drücken Sie eine beliebige Taste . . .
and this, without disconect a view seconds later again start the exe
Code:
--------------------------------------------------------
newflasher.exe by Munjeni @ 2017
--------------------------------------------------------
Device path: \\?\usb#vid_0fce&pid_b00b#5&15c311e1&0&2#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
Class Description: USB-Controller
Device Instance Id: USB\VID_0FCE&PID_B00B\5&15C311E1&0&2
- Successfully write 0x18 bytes to handle.
ERROR: TIMEOUT: failed with error code 997 as follows:
▄berlappender E/A-Vorgang wird verarbeitet.
- Error reaply: less than 4!
Drücken Sie eine beliebige Taste . . .

Hmm strange realy. See https://www.lifewire.com/how-to-fix-code-31-errors-2623184 its seems your driver is not working propertly, maybe you have old flashtool driver and not one for newer device (which can be installed by installing sony pc companion software), I have no idea by now, unable to figure out why that happens Did you flashed by sony pc companion your device allready and you are sure it is working, can you confirm? Probably if you allready installed flashtool driver you will need to uninstall and reinstall pc companion, have no idea by now what might be a problem

so, i have erase the driver. restart windows, install the flashtool driver. start the exe:
Code:
--------------------------------------------------------
newflasher.exe by Munjeni @ 2017
--------------------------------------------------------
Device path: \\?\usb#vid_0fce&pid_b00b#5&15c311e1&0&2#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
Class Description: USB-Controller
Device Instance Id: USB\VID_0FCE&PID_B00B\5&15C311E1&0&2
- Successfully write 0x18 bytes to handle.
- Successfully read 0xd bytes from handle.
Raw input [0xD]:
00000000 4F 4B 41 59 31 30 34 38 35 37 36 30 30 OKAY104857600
- Successfully write 0xe bytes to handle.
- Successfully read 0x9 bytes from handle.
Raw input [0x9]:
00000000 4F 4B 41 59 47 38 31 34 31 OKAYG8141
- Successfully write 0xe bytes to handle.
ERROR: GetOverlapped_in_Result: failed with error code 31 as follows:
Ein an das System angeschlossenes Gerõt funktioniert nicht.
- Error reaply: less than 4!
Drücken Sie eine beliebige Taste . . .
now i erase the driver, restart windows and let windows install the driver over windows.
(i hope you can undersood my english)

Many thanks! Yes I understand you. I must go now, hope somebody figure out if driver is problem or bug in my tool, see you guys tommorow

New version is out, let me know please! I have researched a bit, seems get overlapped result caused some problems and returns imediatelly before thing complete, I have set to "wait complete" hope it is ok now

good morning, so i have reinstall sony companion and start the repair, the new driver is isntall but:
Code:
--------------------------------------------------------
newflasher.exe by Munjeni @ 2017
--------------------------------------------------------
Device path: \\?\usb#vid_0fce&pid_b00b#5&15c311e1&0&2#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
Class Description: USB-Controller
Device Instance Id: USB\VID_0FCE&PID_B00B\5&15C311E1&0&2
- Successfully write 0x18 bytes to handle.
- Successfully read 0xd bytes from handle.
Raw input [0xD]:
00000000 4F 4B 41 59 31 30 34 38 35 37 36 30 30 OKAY104857600
- Successfully write 0xe bytes to handle.
- Successfully read 0x9 bytes from handle.
Raw input [0x9]:
00000000 4F 4B 41 59 47 38 31 34 31 OKAYG8141
- Successfully write 0xe bytes to handle.
ERROR: GetOverlapped_in_Result: failed with error code 31 as follows:
Ein an das System angeschlossenes Gerõt funktioniert nicht.
- Error reaply: less than 4!
Raw input [0x0]:
Drücken Sie eine beliebige Taste . . .
---------- Post added at 10:27 AM ---------- Previous post was at 10:18 AM ----------
and this is from my windows7 32bit pc, only sony companion is install.
Code:
--------------------------------------------------------
newflasher (2).exe by Munjeni @ 2017
--------------------------------------------------------
Device path: \\?\usb#vid_0fce&pid_b00b#5&448f588&0&1#{a5dcbf10-6530-11d2-901f-00
c04fb951ed}
Class Description: USB-Controller
Device Instance Id: USB\VID_0FCE&PID_B00B\5&448F588&0&1
- Successfully write 0x18 bytes to handle.
- Successfully read 0xd bytes from handle.
Raw input [0xD]:
00000000 4F 4B 41 59 31 30 34 38 35 37 36 30 30 OKAY104857600
- Successfully write 0xe bytes to handle.
- Successfully read 0x9 bytes from handle.
Raw input [0x9]:
00000000 4F 4B 41 59 47 38 31 34 31 OKAYG8141
- Successfully write 0xe bytes to handle.
ERROR: GetOverlapped_in_Result: failed with error code 31 as follows:
Ein an das System angeschlossenes Gerõt funktioniert nicht.
- Error reaply: less than 4!
Raw input [0x0]:
Drücken Sie eine beliebige Taste . . .