Can someone tell me why I keep getting the directory error at the bottom on my linux box? Sorry am learning linux as i go. I created a zip directory under bin so not sure why I am still getting this error?
no files for configid 26220739write xip block starting at 81800000, with 3 fileswrite xip block starting at 81980000, with 0 filesthis rom seems to be 3.17.03 ENG 2003-05-15 o2eurothis bootloader seems to be V5.22 2003-05-15 17:46:5580000000 - 80040000 -- bootloader 0 files 1 modules80040000 - 8026a804 -- kernel 13 files 11 modules802c2000 - 8057d330 9 OS 15 files 32 modules80580000 - 8075a69c 8 SHELL 79 files 27 modules80780000 - 80a13b04 7 BROWSING 9 files 14 modules80a40000 - 80d8a33c 6 COREAPPS 46 files 30 modules80dc0000 - 80ebd150 5 SYNC 12 files 22 modules80ec0000 - 810388e0 4 24MAPPS 13 files 13 modules81080000 - 81348248 3 24MCONSUMER 69 files 1 modules81400000 - 814019a4 -- xip chain 10 xip entries81440000 - 817f6f14 1 MISC 209 files 40 modules81800000 - 8184ac20 10 XDA_DEVELOPERS1 3 files 0 modules81900000 - 81925800 -- bitmap : 101a301a .. beb6fc8d81940000 - 81960278 -- operator rom 10 files81980000 - 81981054 11 XDA_DEVELOPERS2 0 files 0 modules./mkrom.sh: /bin/zip: No such file or directory
It looks as though you do not have an appropriate ZIP program...
You may want to see if bzip2 will work instead of zip, or get the linux version of RAR.
The issue though, is you do not have /bin/zip, which is an executable file, not a directory.
Maybe someone can verify what compression executable to use instead of /bin/zip...
J
Ok got that resolved but now when doing zip it gets permission denied. Any other assistance is greatly appreciated. Then should be able to have yorch and company's kitchen running
I would verify that the user that is executing the shell (mkrom) has execute permissions to the zip program...
you can run (as root)
Code:
chmod 755 /usr/bin/bzip2
to change permissions on the bzip2 executable file.
That will give root all access, and everyone else read/execute access.
Also, if the zip program uses any temp directories, make sure the same user has read/write permissions to those directories as well (Probably not your problem, though)
J
Ok got that resolved....now here's what i get....is this a safe error or something I need to worry about? How can I correct it?
./mkrom.sh: ./tounicode: Permission deniedwrite xip block starting at 81720000, with 6 fileswrite xip block starting at 81cb0000, with 72 filesCan't exec "./dumprom": Permission denied at drparse.pl line 22.readline() on closed filehandle FH at drparse.pl line 24.Can't exec "./dumprom": Permission denied at drparse.pl line 22.readline() on closed filehandle FH at drparse.pl line 24.Can't exec "./dumprom": Permission denied at drparse.pl line 22.readline() on closed filehandle FH at drparse.pl line 24.!!! your rom is not known to me: md5: dad2e3cad6095282bf1d58ccf12171e8this bootloader seems to be V5.22 2003-05-15 17:46:55no operator rom found80000000 - 80040000 -- bootloader 0 files 1 modules80040000 - 8015df78 9 XIPKERNEL 5 files 5 modules80180000 - 80376f10 8 KERNEL 10 files 14 modules80380000 - 8064306c 7 OS 20 files 36 modules80670000 - 80be66a8 6 SHELL 107 files 88 modules80c00000 - 8102ce98 5 BROWSING 11 files 36 modules81050000 - 813ef114 4 COREAPPS 95 files 44 modules81400000 - 815d2238 3 EXAPPS 34 files 7 modules815f0000 - 8171bc7c 2 PHONE 56 files 19 modules81720000 - 8177ffe0 10 XDA_DEVELOPERS1 6 files 0 modules81780000 - 81781c34 -- xip chain 11 xip entries817c0000 - 81ca1b44 1 MISC 225 files 42 modules81cb0000 - 81d4eb7c 11 XDA_DEVELOPERS2 72 files 0 modules81ec0000 - 81ee5800 -- bitmap : ffffffff .. ffffffff../rom.exe: found a preamble of 35328 bytes adding: English/NK.nbf (deflated 44%)Archive: rom.exe;The comment below contains SFX script commandsSetup=start.batTempModeSilent=1Overwrite=1 Length Method Size Ratio Date Time CRC-32 Name-------- ------ ------- ----- ---- ---- ------ ---- 0 Stored 0 0% 07-28-03 15:28 00000000 English/ 262144 Defl:N 11018 96% 05-20-02 18:27 f4419bea English/CLoader_serial.nb 262144 Defl:N 12683 95% 05-20-02 18:17 d576b33c English/CLoader_usb.nb 4608 Defl:N 1094 76% 07-17-02 17:22 578b9c86 English/GetConnectionType.dll 18432 Defl:N 7650 59% 04-24-02 15:44 e4ed8f0a English/remote_flash.exe 3584 Defl:N 856 76% 08-21-01 16:43 da38a539 English/SetSystemTime.dll 73728 Defl:N 36119 51% 07-09-03 07:09 95cf7c18 adaptrom.exe 155648 Defl:N 50839 67% 08-28-02 15:23 f5a4ac25 PROGRAMME A.exe 3548 Defl:N 1078 70% 08-28-02 15:25 65d98105 readme.rtf 25 Stored 25 0% 07-28-03 15:28 ecfe543d start.bat32505888 Defl:N 18306975 44% 10-11-03 21:28 34cc9720 English/NK.nbf-------- ------- --- -------33289749 18428337 45% 11 files
Looks like you have the same execute permission problem with the tounicode exe.
Try to fix that.
About the drparse.pl, I have to look at that file, to see what it is trying to do...
Ok, here is the line:
Code:
open FH, "./dumprom $romfile|";
Looks like it is trying to open (as a file) the output of the dumprom executable.
So, dumprom is failing, probably ... yes, I see it now..
Verify the permissions on dumprom as well...
In fact, all *.pl and *.sh files should have execute permissions, use the same command as above to set them.
This reply is a rambling one, I know, but I wrote is as I was doing the research.
Let me know if it helps you.
J
Here's what is weird. I have changed those permissions as you said previously and still get the same error. What's strange to me though is I can run the kitchen with rom ver 3 something, but all of the ver 4 roms come back with the error. Any idea as to what the cause of that might be?
btw jta thanks for all the help. If you have time and would like to look at the box for me I will get access to it for you. Thanks.
I got it all working now. Thank you thank you thank you very much for the help.
Ah, good to hear that you have it all working now!
So, when do we get to try it out?? (wink wink)
J
Very soon....we are now putting finishing touches with other software installs....so will be very very soon.....
type:
cd /usr/local/bin
# ln -s /usr/bin/zip zip
I'm here to recruit help from XDA-Developers for open-source development. I can offer UnBrickable Mod to any Developer who thinks they can help with this C++ issue. This will allow you to play with Loki (the device's side of Odin/Heimdall) and not worry about it.
The only thing keeping the Linux and Mac platforms from being better then Windows at developing ROMs and other firmware is Heimdall's ability to repartition. Once this barrier is broken down, we will have an entire open source chain for developing and Linux will be the premeire platform for developing on Samsung devices. There will be no reason to use Closed Source Windows, Odin, or Samsung Drivers... This is the last barrier.
I am offering debug logs which show the UART output during the flashing of Heimdall and Odin.
here are Heimdall logs/uart logs: http://pastebin.com/srhG7yJA
here are Odin Uart Logs: http://pastebin.com/AiKspmxR UART coming soon.
Here are both Heimdall and Odin USB logs via Wireshark.
http://www.mediafire.com/file/2wccdcuf87q2i3l/odinheimdallUSBLog.zip
Benjamin Dobell has set up code for Heimdall here: https://github.com/Benjamin-Dobell/Heimdall/
This is not a bounty thread. It is an open source development/improvement thread. I have spoken to Benjamin Dobell, the creator of Heimdall, and he is too busy with a new job and working loads of overtime hours. He has approved of this action. Fixing this issue with Heimdall will allow the entire Samsung community to utilize Heimdall as a total replacement for Odin on all platforms.
What's my role/interest in this? I want Linux to be as good or better then Windows.. I'm an Open Source guy. I'm also not good at C++ programming language. I understand the headers, but not the CPP files. I can provide debugging and beta testing though. I've created the cross-platform Heimdall One-Click . I brought UnBrickable Mod to the Captivate and the only thing left in the entire open-source chain of software from complete destruction of data on the device to completely stock is getting Heimdall to repartition.
Once this final hurdle in Heimdall is completed, we've got a full open-source stack of cross-platform, community-based software by XDA-Developers for XDA-Developers and users. Open-Source software will be able to provide more then closed source software, and once again XDA-Developers will prove that we can do things better then the Manufacturers.
There is an issue tracking system here: https://github.com/Benjamin-Dobell/Heimdall/issues
I believe the underlying cause of all 3 of the existing issues in the Heimdall Repostiory lies with Heimdall's ability to repartition.
issue 21: "Failed to confirm end of file transfer sequence!" signifies that the information sent overran the partition area and therefore it never responded that the end was confirmed.
Issue 19: "Could not find end of file or end of file transfer, something similar." Likely the same as issue 21.
Issue 14: "Expected file part index" again, dealing with partition tables. "ERROR: Expected file part index: 0 Received: 1"
I believe all three of these issues could be worked into a single "Heimdall Repartitioning" issue for the reasons stated above.
I got some experience in C++ and Java...
once I get home ill take a look at the heimdall source, and give it a shot.
Smasher816 said:
I got some experience in C++ and Java...
once I get home ill take a look at the heimdall source, and give it a shot.
Click to expand...
Click to collapse
Hey great.. I have a special test setup with UART output.
First I totally thrashed my partition table by uploading the Bada OS SBL.. This SBL rewites partition tables. Then I used the HIBL to unbrick my phone and load a proper SBL. This is the UART during booting up to "Download Mode".
Code:
-------------------------------------------------------------
Hummingbird Interceptor Boot Loader (HIBL) v1.0
Copyright (C) Rebellos 2011
-------------------------------------------------------------
Calling IBL Stage2 ...OK
Testing DRAM1 ...OK
iRAM reinit ...OK
cleaning OTG context ...OK
Chain of Trust has been successfully compromised.
Begin unsecure download now...
0x00000000BL3 EP: 0x40244000
Download complete, hold download mode key combination.
Starting BL3 in...
Set cpu clk. from 400MHz to 800MHz.
IROM e-fused - Non Secure Boot Version.
-----------------------------------------------------------
Samsung Secondary Bootloader (SBL) v3.0
Copyright (C) Samsung Electronics Co., Modified by Rebell
Build On: Jun 8 2011 21:44:47
-----------------------------------------------------------
Re_partition: magic code(0xffffffff)
[PAM: ] ++FSR_PAM_Init
[PAM: ] OneNAND physical base address : 0xb0000000
[PAM: ] OneNAND virtual base address : 0xb0000000
[PAM: ] OneNAND nMID=0xec : nDID=0x50
[PAM: ] --FSR_PAM_Init
fsr_bml_load_partition: pi->nNumOfPartEntry = 7
partitions loading success
board partition information update.. source: 0x0
.Done.
read 1 units.
==== PARTITION INFORMATION ====
ID : *unknown id* (0x9)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 0
NO_UNITS : 1
===============================
ID : *unknown id* (0x0)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 1
NO_UNITS : 7
===============================
ID : *unknown id* (0x1)
ATTR : RW SLC (0x1001)
FIRST_UNIT : 8
NO_UNITS : 796
===============================
ID : *unknown id* (0x14)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 804
NO_UNITS : 716
===============================
ID : *unknown id* (0x15)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 1520
NO_UNITS : 372
===============================
ID : *unknown id* (0x17)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 1892
NO_UNITS : 56
===============================
ID : *unknown id* (0x18)
ATTR : RW SLC (0x1001)
FIRST_UNIT : 1948
NO_UNITS : 56
===============================
FlashDevOpen 232: Error(nErr=0x80000002)
j4fs_open 136: Error(nErr=0x40000000)
loke_init: j4fs_open failed..
init_fuel_gauge: vcell = 4051mV, soc = 82
check_quick_start_condition_with_charger- Voltage: 4051.25000, Linearized[55/70/85], Capacity: 85
init_fuel_gauge: vcell = 4051mV, soc = 82, rcomp = d01f
FlashDevRead 63: Error(offset,length,j4fs_end,nErr)=(0x40000,0x1000,0xffffffff,0x80040001)
nps status file does not exist..
nps status is incorrect!! set default status.(completed)
nps status=0x504d4f43
PMIC_IRQ1 = 0x3c
PMIC_IRQ2 = 0x0
PMIC_IRQ3 = 0x0
PMIC_IRQ4 = 0x0
PMIC_STATUS1 = 0x40
PMIC_STATUS2 = 0x2c
get_debug_level current debug level is 0x0.
get_debug_level current debug level is 0x0.
get_debug_level current debug level is 0x0.
aries_process_platform: Debug Level Invalid
keypad_scan: key value ----------------->= 0x0
CONFIG_ARIES_REV:48 , CONFIG_ARIES_REV03:48
FlashDevRead 63: Error(offset,length,j4fs_end,nErr)=(0x40000,0x1000,0xffffffff,0x80040001)
nps status file does not exist..
nps status is incorrect!! set default status.(completed)
nps status=0x504d4f43
==> Welcome to ARIES!
==> Entering usb download mode..
DISPLAY_PATH_SEL[MDNIE 0x1]is on
MDNIE setting Init start!!
vsync interrupt is off
video interrupt is off
[fb0] turn on
MDNIE setting Init end!!
Error : Current Mode is Host
EP2: 0, 2, 0; len=7
EP2: 0, 2, 0; len=7
sug: IN EP asserted
I gave the command in Heimdall to repartition and flash the boot.bin to partition 1.
Code:
heimdall flash --repartition --pit ./part.pit --1 ./boot.bin
At this point it should have downloaded the partition, saved it, and then heimdall should request the partition back and use that as its guide.
The boot.bin is only 1 block long so this log is short.
Code:
- Odin is connected!
FlashDevRead 63: Error(offset,length,j4fs_end,nErr)=(0x40000,0x1000,0xffffffff,0x80040001)
j4fs_write_file_bootloader 192: Error(nErr=0x40000000)
process_packet: request id(100), data id(0)
process_rqt_init: platform number(0x0), revision(0x0)
process_packet: request id(100), data id(1)
process_packet: request id(100), data id(2)
process_packet: request id(103), data id(0)
process_rqt_close: xmit completed!
FlashDevRead 63: Error(offset,length,j4fs_end,nErr)=(0x40000,0x1000,0xffffffff,0x80040001)
j4fs_write_file_bootloader 192: Error(nErr=0x40000000)
process_packet: request id(103), data id(1)
process_rqt_close: target reset!
ARIES MAGIC_ADDR=0x0 / INFORM5=0x12345678
and this is the log from Heimdall
Code:
Initialising connection...
Detecting device...
Claiming interface...
Attempt failed. Detaching driver...
Claiming interface again...
Setting up interface...
Beginning session...
Handshaking with Loke...
Ending session...
Rebooting device...
Re-attaching kernel driver...
At this point the device "resets" and attempts to boot from the bootloader.
If you need any testing let me know. I can compile source, I can get UART logs. I can repartition the heck out of this device as it is UnBrickable and my test phone.
I believe the device uses the SBL> prompt when it is in download mode.. You can see from this UART log that the device attempted to "saveenv" but it could not. http://code.google.com/p/badadroid/...ompare_logs/SBL_mode_help.txt?spec=svn61&r=57
It also returned the same "FlashDevRead 63 error)
The final action the device needs to do is "savepart" if the partition tables were saved after the pit were uploaded then it would be good to go. There are several other commands as well.. "addpart" and "removepart".. If it comes to using this, let me know. I've worked with Benjamin Dobell's libpit before and I can help out greatly with repartitioning as I've worked extensively in the SBL prompt.
I'm not sure how the Download Mode works exactly, but if it uses the SBL prompt, then I can write pseudocode of how it should work.
This probably isn't going to help much, but it may be a start.
I figured the best way to solve this would be to find the differences between a successful Odin flash and an unsuccessful Heimdall flash. So I delved right in to the wireshark dumps. It seems likely that Heimdall is missing a step.
I do not understand the protocol (yet), but I can see the raw data in the stream. In the Heimdall process, there is some protocol traffic, then the entire PIT file is sent, then some more protocol traffic, then the kernel data is sent. But in the Odin process, there is some protocol traffic, then the entire PIT file is sent, then some more protocol traffic, then the PIT file is sent again in 512 byte chunks, then some protocol traffic (more than usual), and then the kernel data is sent.
At the moment, I can't be sure if this is functionally equivalent or not. I'll need to do quite a bit of deciphering on the protocol to get up to speed on what's really going on. Unfortunately, this is the sort of thing that's easiest if one can watch the action in real time, but as I only have my one phone that I need for work, that's not really an option for me at this time.
Hopefully, I'll return with more info after I've absorbed the communication layer details to see what the non-data chatter actually is.
Could that extra protocol data possibly be Odin commanding delete partitions and add partitions? I'm hypothesizing... nothing more. I see some similarities to the UART logs during SBL> prompt and Odin, so I'm thinking that maybe the SBL prompt is used, or at least some of the methods... In this thread you can see all of the SBL commands http://forum.xda-developers.com/showthread.php?t=1209288
Sure it's from an Infuse, but they're all based on i9000 which is like the mother of our entire generation of devices. The SBLs are interchangeable with different entry points for each "version".
AdamOutler said:
Could that extra protocol data possibly be Odin commanding delete partitions and add partitions? I'm hypothesizing... nothing more. I see some similarities to the UART logs during SBL> prompt and Odin, so I'm thinking that maybe the SBL prompt is used, or at least some of the methods... In this thread you can see all of the SBL commands http://forum.xda-developers.com/showthread.php?t=1209288
Sure it's from an Infuse, but they're all based on i9000 which is like the mother of our entire generation of devices. The SBLs are interchangeable with different entry points for each "version".
Click to expand...
Click to collapse
I have a feeling that it is using the SBL prompt somehow after the flash because everything else seems pretty much identical (besides the timing). If anyone needs to understand the protocol then I recommend just looking at Heimdall's source code, in particular the packet header files store all the constants that are sent and received over USB.
Found the problem - the End Transfer packet is missing. There is also some additional strangeness, though.
Heimdall:
Packet 1: 65 00 00 00 (Init pit transfer)
Packet 2: 65 00 00 00 02 00 00 00 D0 06 00 00 (Want to send 1744 bytes)
Packet 3: [full contents of pit]
Packet 4: 66 00 00 00 (Init file transfer - probably starting the kernel send)
Odin:
Packet 1: 65 00 00 00 (Init pit transfer)
Packet 2: 65 00 00 00 02 00 00 00 D0 06 00 00 (Want to send 1744 bytes)
Packet 3: [full contents of pit]
Packet 4: 65 00 00 00 03 00 00 00 D0 06 00 00 (Finished sending 1744 bytes)
The odd part is what odin does next, after the "finished sending":
Packet 5: 65 00 00 00 01 00 00 00 (Dump pit file)
Packet 6: 65 00 00 00 02 00 00 00 00 00 00 00 (Sending chunk 0)
Packet 7: [first 512 bytes of pit]
Packet 8: 65 00 00 00 02 00 00 00 01 00 00 00 (Sending chunk 1)
Packet 9: [next 512 bytes of pit]
Packet 10: 65 00 00 00 02 00 00 00 02 00 00 00 (Sending chunk 2)
Packet 11: [next 512 bytes of pit]
Packet 12: 65 00 00 00 02 00 00 00 03 00 00 00 (Sending chunk 3)
Packet 13: [next 512 bytes of pit]
- repeat for 8 chunks - data past the end of the actual pit file is sent as zeroes -
Packet 22: 65 00 00 00 03 00 00 00 (Done)
Packet 23: 66 00 00 00 (Init file transfer - probably kernel)
I couldn't begin to tell you why any of this exists at all, but my strong suspicion is that duplicating the Odin behavior will make Heimdall work properly.
So, Adam, the first thing I would try would be to simply add the "finished sending" packet. Try recompiling with this replacement for BridgeManager.cpp and this additional file EndPitFilePacket.h in the project.
psych0phobia said:
So, Adam, the first thing I would try would be to simply add the "finished sending" packet. Try recompiling with this replacement for BridgeManager.cpp and this additional file EndPitFilePacket.h in the project.
Click to expand...
Click to collapse
That did it! Problem solved!
1.I uploaded the Bada bootloaders to my device in order to totally destroy my partition tables.
2.I tried to flash with heimdall 1.3 and it did not work to restore
3.I compiled and installed the new 1.3modified version
4.I flashed with heimdall 1.3modified and it worked
to be sure I repeated the Bada bootloaders once again. The only thing wrong with my device now is that it has no /efs/ partition... which is understandable because bada turned the OneNAND into it's *****.
Great job psych0phobia If you need anything from me just let me know. I mean anything ...
Let me know when you can spare your device so I can modify it. Please push this change upstream.
Here's the UART log
Code:
[���������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������
Uart negotiation Error
-------------------------------------------------------------
Hummingbird Interceptor Boot Loader (HIBL) v1.0
Copyright (C) Rebellos 2011
-------------------------------------------------------------
Calling IBL Stage2 ...OK
Testing DRAM1 ...OK
iRAM reinit ...OK
cleaning OTG context ...OK
Chain of Trust has been successfully compromised.
Begin unsecure download now...
0x00000000BL3 EP: 0x40244000
Download complete, hold download mode key combination.
Starting BL3 in...
Set cpu clk. from 400MHz to 800MHz.
IROM e-fused - Non Secure Boot Version.
-----------------------------------------------------------
Samsung Secondary Bootloader (SBL) v3.0
Copyright (C) Samsung Electronics Co., Modified by Rebell
Build On: Jun 8 2011 21:44:47
-----------------------------------------------------------
Re_partition: magic code(0x0)
[PAM: ] ++FSR_PAM_Init
[PAM: ] OneNAND physical base address : 0xb0000000
[PAM: ] OneNAND virtual base address : 0xb0000000
[PAM: ] OneNAND nMID=0xec : nDID=0x50
[PAM: ] --FSR_PAM_Init
fsr_bml_load_partition: pi->nNumOfPartEntry = 12
partitions loading success
board partition information update.. source: 0x0
.Done.
read 1 units.
==== PARTITION INFORMATION ====
ID : IBL+PBL (0x0)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 0
NO_UNITS : 1
===============================
ID : PIT (0x1)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 1
NO_UNITS : 1
===============================
ID : EFS (0x14)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 2
NO_UNITS : 40
===============================
ID : SBL (0x3)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 42
NO_UNITS : 5
===============================
ID : SBL2 (0x4)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 47
NO_UNITS : 5
===============================
ID : PARAM (0x15)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 52
NO_UNITS : 20
===============================
ID : KERNEL (0x6)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 72
NO_UNITS : 30
===============================
ID : RECOVERY (0x7)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 102
NO_UNITS : 30
===============================
ID : FACTORYFS (0x16)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 132
NO_UNITS : 1146
===============================
ID : DBDATAFS (0x17)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 1278
NO_UNITS : 536
===============================
ID : CACHE (0x18)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 1814
NO_UNITS : 140
===============================
ID : MODEM (0xb)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 1954
NO_UNITS : 50
===============================
loke_init: j4fs_open success..
load_lfs_parameters valid magic code and version.
reading nps status file is successfully!.
nps status=0x504d4f43
load_debug_level reading debug level from file successfully(0x574f4c44).
init_fuel_gauge: vcell = 4192mV, soc = 90
check_quick_start_condition_with_charger- Voltage: 4192.50000, Linearized[77/92/100], Capacity: 94
init_fuel_gauge: vcell = 4192mV, soc = 90, rcomp = d01f
reading nps status file is successfully!.
nps status=0x504d4f43
PMIC_IRQ1 = 0x28
PMIC_IRQ2 = 0x0
PMIC_IRQ3 = 0x0
PMIC_IRQ4 = 0x0
PMIC_STATUS1 = 0x40
PMIC_STATUS2 = 0x2c
get_debug_level current debug level is 0x574f4c44.
aries_process_platform: Debug Level Low
keypad_scan: key value ----------------->= 0x0
CONFIG_ARIES_REV:48 , CONFIG_ARIES_REV03:48
reading nps status file is successfully!.
nps status=0x504d4f43
==> Welcome to ARIES!
==> Entering usb download mode..
DISPLAY_PATH_SEL[MDNIE 0x1]is on
MDNIE setting Init start!!
vsync interrupt is off
video interrupt is off
[fb0] turn on
MDNIE setting Init end!!
Error : Current Mode is Host
EP2: 0, 2, 0; len=7
EP2: 0, 2, 0; len=7
sug: IN EP asserted
- Odin is connected!
set_nps_update_start: set nps start flag successfully.
process_packet: request id(100), data id(0)
process_rqt_init: platform number(0x0), revision(0x0)
process_packet: request id(100), data id(1)
process_packet: request id(100), data id(2)
process_packet: request id(101), data id(0)
process_packet: request id(101), data id(2)
process_packet: request id(101), data id(3)
[FNW: ] STL read to partition ID: 20
Done.
read 25 units.
partition_backup: efs. meta data=3(units), real size=6553600
.....Done.
read 5 units.
partition_backup: sbl. buf=0x46e00000, size=1310720(bytes)
.....Done.
read 5 units.
partition_backup: sbl2. buf=0x46f40000, size=1310720(bytes)
fsr_bml_format_device start
set_dynamic_partition: pit magic code=0x12349876
bbm format success
bbm_erase_all: step 1. Start unit=1, End unit=2.
.
bbm_erase_all: step 1. Start unit=52, End unit=2004.
..............................................................................................................................................................................................................................................
bbm eraseall success.
fsr_bml_load_partition: pi->nNumOfPartEntry = 12
partitions loading success
Erasing: 1 to 2
.
bbm erase part success
.Done.
Written 1 units.
current percent: 0 (1/1110)
board partition information update.. source: 0x403ee838
Erasing: 2 to 42
........................................
bbm erase part success
[FNW: ] STL formatted (partition ID: 20)
[FNW:INF] nVol : 0, partition_id : 20, stSTLInfo.nTotalLogScts : 12800, buf :0x46400000
TotalLogSct : 12800, size : 6553600
Done.
Written 25 units.
current percent: 2 (26/1110)
Erasing: 42 to 47
.....
bbm erase part success
.....Done.
Written 5 units.
current percent: 2 (31/1110)
Erasing: 47 to 52
.....
bbm erase part success
.....Done.
Written 5 units.
current percent: 3 (36/1110)
process_packet: request id(102), data id(0)
process_packet: request id(102), data id(2)
process_packet: request id(102), data id(3)
process_rqt_xmit: size(5445016), id(6), final(1)
Save Image (KERNEL) to flash ......
Erasing: 72 to 102
..............................
bbm erase part success
.....................Done.
Written 21 units.
current percent: 5 (57/1110)
current write_count=1
process_packet: request id(102), data id(0)
process_packet: request id(102), data id(2)
process_packet: request id(102), data id(3)
process_rqt_xmit: size(12582912), efs_clear(0), boot_update(0), final(1)
xmit_complete_phone: cp partition found!(11)
Save Image (MODEM) to flash ......
Erasing: 1954 to 2004
..................................................
bbm erase part success
................................................Done.
Written 48 units.
current percent: 9 (105/1110)
current write_count=1
process_packet: request id(102), data id(0)
process_packet: request id(102), data id(2)
process_packet: request id(102), data id(3)
process_rqt_xmit: size(104857600), id(22), final(0)
Save Image (FACTORYFS) to flash ......
Erasing: 132 to 1278
..............................................................................................................................................................................................................................................
bbm erase part success
[FNW: ] STL formatted (partition ID: 22)
[FNW:INF] nVol : 0, partition_id : 22, stSTLInfo.nTotalLogScts : 569344, buf :0x46400000
TotalLogSct : 204800, size : 104857600
Done.
Written 394 units.
current percent: 45 (505/1110)
current write_count=1
process_packet: request id(102), data id(2)
process_packet: request id(102), data id(3)
process_rqt_xmit: size(104857600), id(22), final(0)
Save Image (FACTORYFS) to flash ......
[FNW:INF] nVol : 0, partition_id : 22, stSTLInfo.nTotalLogScts : 569344, buf :0x46400000
TotalLogSct : 204800, size : 104857600
Done.
Written 394 units.
current percent: 81 (905/1110)
current write_count=2
process_packet: request id(102), data id(2)
process_packet: request id(102), data id(3)
process_rqt_xmit: size(58163200), id(22), final(1)
Save Image (FACTORYFS) to flash ......
[FNW:INF] nVol : 0, partition_id : 22, stSTLInfo.nTotalLogScts : 569344, buf :0x46400000
TotalLogSct : 113600, size : 58163200
Done.
Written 219 units.
current percent: 101 (1127/1110)
current write_count=3
process_packet: request id(102), data id(0)
process_packet: request id(102), data id(2)
process_packet: request id(102), data id(3)
process_rqt_xmit: size(1376256), id(23), final(1)
Save Image (DBDATAFS) to flash ......
Erasing: 1278 to 1814
..............................................................................................................................................................................................................................................
bbm erase part success
[FNW: ] STL formatted (partition ID: 23)
[FNW:INF] nVol : 0, partition_id : 23, stSTLInfo.nTotalLogScts : 263168, buf :0x46400000
TotalLogSct : 2688, size : 1376256
Done.
Written 6 units.
current percent: 102 (1133/1110)
current write_count=1
process_packet: request id(102), data id(0)
process_packet: request id(102), data id(2)
process_packet: request id(102), data id(3)
process_rqt_xmit: size(1245184), id(24), final(1)
Save Image (CACHE) to flash ......
Erasing: 1814 to 1954
............................................................................................................................................
bbm erase part success
[FNW: ] STL formatted (partition ID: 24)
[FNW:INF] nVol : 0, partition_id : 24, stSTLInfo.nTotalLogScts : 64000, buf :0x46400000
TotalLogSct : 2432, size : 1245184
Done.
Written 5 units.
current percent: 102 (1138/1110)
current write_count=1
save param.blk, size: 5268
FlashDevRead 63: Error(offset,length,j4fs_end,nErr)=(0x40000,0x1000,0xfffff,0x80040001)
j4fs_write_file_bootloader 192: Error(nErr=0x40000000)
process_packet: request id(102), data id(0)
process_packet: request id(102), data id(2)
process_packet: request id(102), data id(3)
process_rqt_xmit: size(262144), id(0), final(1)
Save Image (IBL+PBL) to flash ......
binary version: EVT1.
boot.bin is the one-binary.
relocate & fusing continue..
completed.
Erasing: 0 to 1
.
bbm erase part success
.Done.
Written 1 units.
current percent: 102 (1139/1110)
current write_count=1
process_packet: request id(102), data id(0)
process_packet: request id(102), data id(2)
process_packet: request id(102), data id(3)
process_rqt_xmit: size(1310720), id(3), final(1)
Save Image (SBL) to flash ......
=== SBL signature information ===
File Size : 677052
=================================
read part info
id = 0x3
attr = 0x1002
first unin = 0x2a
number units = 0x5
pages per unit = 0x40
n1st page = 0xa80, page offset = 0x13f, len = 0x48
read part info
id = 0x4
attr = 0x1002
first unin = 0x2f
number units = 0x5
pages per unit = 0x40
n1st page = 0xbc0, page offset = 0x13f, len = 0x48
Found bootable SBL ID: 4
save SBL partition id: 3
Erasing: 42 to 47
.....
bbm erase part success
.....Done.
Written 5 units.
current percent: 103 (1144/1110)
current write_count=1
save sbl id: 3 / erase sbl id: 4
.
process_packet: request id(102), data id(0)
process_packet: request id(102), data id(2)
process_packet: request id(102), data id(3)
process_rqt_xmit: size(872448), id(21), final(1)
Save Image (PARAM) to flash ......
FlashDevClose 262: Error(nErr=0x80040001)
Erasing: 52 to 72
....................
bbm erase part success
[FNW: ] STL formatted (partition ID: 21)
[FNW:INF] nVol : 0, partition_id : 21, stSTLInfo.nTotalLogScts : 2560, buf :0x46400000
TotalLogSct : 1704, size : 872448
Done.
Written 4 units.
current percent: 103 (1148/1110)
current write_count=1
set_nps_update_start: set nps start flag successfully.
process_packet: request id(103), data id(0)
process_rqt_close: xmit completed!
set_nps_update_completed: set nps completed flag successfully.
process_packet: request id(103), data id(1)
process_rqt_close: target reset!
ARIES MAGIC_ADDR=0x0 / INFORM5=0x12345678
1
-----------------------------------------------------------
Samsung Primitive Bootloader (PBL) v3.0
Copyright (C) Samsung Electronics Co., Ltd. 2006-2010
-----------------------------------------------------------
+n1stVPN 2688
+nPgsPerBlk 64
PBL found bootable SBL: Partition(3).
Set cpu clk. from 400MHz to 800MHz.
IROM e-fused - Non Secure Boot Version.
-----------------------------------------------------------
Samsung Secondary Bootloader (SBL) v3.0
Copyright (C) Samsung Electronics Co., Ltd. 2006-2010
Board Name: ARIES REV 03
Build On: Jun 8 2011 21:44:47
-----------------------------------------------------------
Re_partition: magic code(0x0)
[PAM: ] ++FSR_PAM_Init
[PAM: ] OneNAND physical base address : 0xb0000000
[PAM: ] OneNAND virtual base address : 0xb0000000
[PAM: ] OneNAND nMID=0xec : nDID=0x50
[PAM: ] --FSR_PAM_Init
fsr_bml_load_partition: pi->nNumOfPartEntry = 12
......... everything after this is standard data... just included this far to show it booted.
Everything worked..
Would you like WireShark to verify things?
As far as logging, the only thing I could see is this:
Code:
FlashDevRead 63: Error(offset,length,j4fs_end,nErr)=(0x40000,0x1000,0xfffff,0x80040001)
j4fs_write_file_bootloader 192: Error(nErr=0x40000000)
which means it tried to read some garbage from the OneNAND and failed.
AdamOutler said:
That did it! Problem solved!
1.I uploaded the Bada bootloaders to my device in order to totally destroy my partition tables.
2.I tried to flash with heimdall 1.3 and it did not work to restore
3.I compiled and installed the new 1.3modified version
4.I flashed with heimdall 1.3modified and it worked
to be sure I repeated the Bada bootloaders once again. The only thing wrong with my device now is that it has no /efs/ partition... which is understandable because bada turned the OneNAND into it's *****.
Great job psych0phobia If you need anything from me just let me know. I mean anything ...
Let me know when you can spare your device so I can modify it. Please push this change upstream.
Click to expand...
Click to collapse
Yay for a properly working Heimdall! Once this fix gets officially implemented I'll update my Heimdall =D
How much do you charge to make the Captivate Unbrickable? X3
I have a darn huge iq... Classified as genius level... Yet, try as I might, cannot make head or tail of Adams post...
Sent from my cell phone. DUH.
psycho2097 said:
I have a darn huge iq... Classified as genius level... Yet, try as I might, cannot make head or tail of Adams post...
Sent from my cell phone. DUH.
Click to expand...
Click to collapse
Don't give me credit... this is the real genius here...
psych0phobia said:
So, Adam, the first thing I would try would be to simply add the "finished sending" packet. Try recompiling with this replacement for BridgeManager.cpp and this additional file EndPitFilePacket.h in the project.
Click to expand...
Click to collapse
Basically, heimdall could not repartition the OneNAND. I identifed the problem, provided detailed debug level information and asked for help. psych0phobia looked at the Odin/Loki protocol, learned it, found the differences between Odin and Heimdall based on the output of both programs and then wrote the fix. Make sure you thank him. Thank Benjamin Dobell as well, he wrote Heimdall in the first place.
now... if you want to compile it under Linux... open a terminal and copy-pasta.
Code:
sudo apt-get install build-essential curl git
mkdir heimdall
cd heimdall
git clone https://github.com/Benjamin-Dobell/Heimdall.git
cd Heimdall/heimdall
curl http://android.merseine.us/BridgeManager.cpp> ./BridgeManger.cpp
curl http://android.merseine.us/EndPitFilePacket.h >./EndPitFilePacket.h
cd ..
cd ..
cd libpit
./configure
make
cd ..
cd heimdall
./configure
make
sudo make install
This will give Heimdall the ability to fully recover a bad partition table.
NOTE: This should only be used until a version greater then Heimdall 1.3.0 is released.
Yea, kinda got that part.... So my understanding would be now we can successfully flash nexus s. Firmware without screwing everything up... Right? In layman-geek's terms, not super-duper-mega-geek terms....
Sent from my cell phone. DUH.
psycho2097 said:
Yea, kinda got that part.... So my understanding would be now we can successfully flash nexus s. Firmware without screwing everything up... Right? In layman-geek's terms, not super-duper-mega-geek terms....
Sent from my cell phone. DUH.
Click to expand...
Click to collapse
I wont say anything about nexus s just yet... We have a 100% open-source, DIY, and free method of restoring a device to stock. Linux, UnBrickable Mod and heimdall.
In other words....
In yo face jtag
whiteguypl said:
In other words....
In yo face jtag
Click to expand...
Click to collapse
Hell yeah! 3 cheers 4 the unbrickable mod!
Sent from my cell phone. DUH.
Just thought I should let you guys know that I've pushed the source for the 1.3.1 updates to Github and it includes a fix, thanks psych0phobia! 1.3.1 also includes substantially improved no-reboot functionality that allows Heimdall to detect and use an existing session (i.e. previous operation with the --no-reboot parameter). Basically this means that you can do things like dump your PIT and then flash your phone without rebooting in between.
I should note that I kind of forgot to update the make files So it won't actually build on Linux/OS X until I do that when I get home (at work now). Windows users can give it whirl though.
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.