Related
In the Excalibur forum we are struggling to flash a file to a particular offset in NAND (samsung onedisk flash). The file is 4Mbyte and was dumped with bkondisk (by itsme). Deploying pof's ideas, I have patched Excalibur SPL which bypasses vendor/model and signature checking and raises security level to 0. Using this SPL the flash commands can be used w/o restrictions
A similar patched bootloader exists for Vox S710. That SPL includes same commands as the Excalibur SPL.
The SPL offers 2 commands to interactively flash files from MTTY: ls ("load signed"??) and lnbs ("load new binary signed"??)
Afaik the commands are invoked as:
Code:
lnbs [pathname [StartAddr [Length [SkipOffset ["cp"]]]]]
ls [pathname [StartAddr [Length [SkipOffset ["cp"]]]]]
The question is what format the files must have and how to figure out start address. I found some info in the Hermes Wiki. I also suggested Excalibur various tests:
1. The file test3.nbs in this case has a 0x20 byte header ("R000FF") which includes data blocksize and signature size and flag. But somehow it doesn't like the start address of which I also don't know how to figure it out for the various ROM parts. How was that done for Hermes? (reversing SPL or sniffing USB)
Code:
Cmd>lnbs test3.nbs 500a0000
clean up the image temp buffer at 0x8C080000 Length 0x03900000
MTTYDownloadImage "test3.nbs"
:F=test3.nbs
start download
S
HAddress A0000000h Length 0040034Dh
Start Address out of boundary
checking image header
2. The file test.nb w/o any header, just the 4MB binary file with no modifications
Code:
Cmd>ls test.nb 500a0000
clean up the image temp buffer at 0x8C080000 Length 0x03900000
MTTYDownloadImage "test.nb"
:F=test.nb
start download
S
HAddress A0000000h Length 00400000h
Start Address out of boundary
checking image header
3. The file test2.nbh with a full .nbh header and given type 0x300 (GSM Radio code, although the 4MB file also includes config and simlock data etc.). This was actually the most succesful since it passed mosts tests in the SPL. So it seems a valid file, but it couldn't be confirmed that anything was flashed at all.
Code:
Cmd>lnbs test2.nbh 500a0000
clean up the image temp buffer at 0x8C080000 Length 0x03900000
MTTYDownloadImage "test2.nbh"
:F=test2.nbh
start download
S
HAddress 00000000h Length 0040054Dh
Start Address out of boundary
checking image headerFirst MTTY record empty
Image Download Finish... please check your image
Please reset the device to restart the program!!
DownloadImage success.
Can anyone with more knowledge about this subject please drop some feedback? Thx!
Cheers
JockyW
Edit: I totally forgot about the wdata command which is used by the official RUU. It can not be used interactive from MTTY, but it is possible to use it from self written programs. I think the idea is that only signed .nbh files (which include ROM type information in the header) can use be flashed using this command:
Code:
wdata length checksum
Once all data and the last signature (flag == 2) has been sent to SDRAM and all CRC and sig checks are passed the flashing process starts. The funny thing is that the help text of wdata suggests that also unsigned data can be flashed or be dropped at any memory location. Is this intentional deceiving by HTC ??
Code:
Cmd>wdata
Usage:
wdata [StartAddr Len]
Write data to memory(if write to ROM, need erase first).
StartAddr : Start address of memory.
Len : How many bytes will be written.
Length must not more than 0x10000 bytes(buffer limitation).
Write to RAM: 4 bytes(CRC checksum limitation).
1 byte(in user mode).
Write to ROM: 4 bytes(CRC checksum limitation).
2(16-bit)/4(32-bit) bytes(in user mode).
Write to ROM(16-bit data bus): 32 bytes(writebuffer mode).
Write to ROM(32-bit data bus): 64 bytes(writebuffer mode).
Length must be 4 bytes boundary(CRC checksum) if not in user mode.
After command execute, then send out the data to terminal.
Data format: HTCS(4 bytes)+DATA+checksum(4 bytes, if not in user mode)+HTCE(4 bytes).
while flashing test2.nbh, wlan data doesn't be modified.
jockyw2001's question is very important to find our wi-fi back. plz help us!Thanks!
details about our problem and what we have done can be seen at http://forum.xda-developers.com/showthread.php?t=328690
jockyw2001
You may use method imei-check - they for flash of the area CID have changed address of the flash splash screen - hereinafter they form file nbh (consists only of splash screen) with necessary area CID.
arc said:
jockyw2001
You may use method imei-check - they for flash of the area CID have changed address of the flash splash screen - hereinafter they form file nbh (consists only of splash screen) with necessary area CID.
Click to expand...
Click to collapse
Ah great! You've got a link as well? Thx!
Hi jocky,
interesting thing..
why don;t u try its utils for the above and check..
issue pdcocread -l command and get the header and rom address.
then try with lnbs or ls command to flash back.From whatever I know, lnb and lnbs/ls command can b used when yr device is Super CID.
While flahing ROM, RUU issues set le 1 command and write the ROM using wdata command.You can check these things, with USB monitor
hdubli
The commands lnb and lnbs different -
lnb - load the unsigned code.
lnbs- load signed code -have other structure and headline
hdubli said:
issue pdcocread -l command and get the header and rom address.
then try with lnbs or ls command to flash back.From whatever I know, lnb and lnbs/ls command can b used when yr device is Super CID.
Click to expand...
Click to collapse
hi,
pdocread -l returns:
Code:
>pdocread.exe -l
58.82M (0x3ad1000) DSK1:
| 2.09M (0x217400) Part00
| 3.20M (0x333000) Part01
| 53.53M (0x3586800) Part02
59.31M (0x3b4f000) DSK2:
| 59.06M (0x3b0e800) Part00
...
You mean the values in parantheses?
On excalibur only signed data is accepted by ls or lnbs (dunno the difference between the two. Anyone?).
I disassembled spl and found the startaddress boundary check routine. In it I see the hardcoded nand address boundaries which have no resemblance whatsoever with pdocread.
I'm now checking arc's hint to patch splash screen flashroutine in same way as imei-check does it. I just hope I can use ls and lnbs (with USPL of course), since that would be far more comfortable
I have XDA O2 Orbit ATRE200 HTC INNovation
Tried it 2 flash with Wm6.5 Rom, now it just stucked in bootloader 3 colors showing
IPL 3.04.0001
SPL 1.11.0000
Tried to hard rest but when press send key its shows format failed
after that tried to SD card but wont work just showing checking SD contents but after that enter into bootloader mode nothing happened
tried to use mtty.exe
Cmd>set 32
set 32
+ SD Controller init
- SD Controller init
+StorageInit
SDInit+++
SDCmd1 Command response time-out. MMC_STAT = 80
SDCmd1 Command response time-out. MMC_STAT = 80
SDCmd1 Command response time-out. MMC_STAT = 80
SD clock to 24MHz
***** user area size = 0x3BE00000 Bytes
SDInit---
SDInit OK
g_cKeyCardSecurityLevel = 0
HTCE
but when tried to use commands
Cmd>task 29
task 29
Invalid command : task 29
For a help screen, use command ? or h
Cmd>task 28
task 28
Invalid command : task 28
For a help screen, use command ? or h
Cmd>info 2
info 2
Invalid command : info 2
For a help screen, use command ? or h
etc etc
can any one let me know what i do to get rid from this problem
...
hey, you bricked your device, you need to try and revive it using your original/official/ship rom..
you can find it here:
wiki.xda-developers.com/index.php?pagename=Artemis_Upgrades
when you have your original rom flashed back to the device, do Uspl 1.11.cmon
spl 1.11.0000 checks the size, and failed.. which is why your device is a brick..
spl 1.11.cmon - this means you can flash roms no matter what their size.. its doesnt check it..
(click Uspl 1.11.cmon on my signature to download)
I'm curious if the problem is solved.
i cannot connect my device via activsync so how can i flash it???
How can i put 2 cabs of spl 1.11.cmon in the device? i cannot connect my device via activsync so how can i flash it???
...
cutetaurus, add me to msn messenger..
ill try and help you..
[email protected]
we gingerbread guys need to get serious on this fricken flash counter, else we can't truely clone our SGYs.
reedit: by this time Doky has found it in bml15 and resets it in his galaxy tool app. ty !!
Kies knows about it and it has implications for asec stuff too.
manufacturing tried to keep the info on the flash counter's whereabouts a tightly guarded secret like some Bill Clinton sex affair, but now it is busted all out in the open ! <-- link
we gotta be able to reset that data to a fricken pristine state!
then we got a 100% CLONE !!
quote :
The flash counter and triangle state had to be stored somewhere. Everybody knew that ... You can dump and compare the entire /dev/block/mmcblk0 and you won't find a difference (you'll find a few unallocated and unused gaps, though).
on SGY mmcblk0 is the sd card, /dev/block/bml0!c = total internal NAND storage - which is what we are looking for. see: http://forum.xda-developers.com/showthread.php?t=1998471
however, the flash disk actually has two hidden boot partitions,
/dev/block/mmcblk0boot0 and
/dev/block/mmcblk0boot1
The MMC driver in the kernels used for Gingerbread did not present these partitions in the past, the MMC driver in the ICS kernel does.
Dump and compare the partitions and you'll have found them in no time.
Structure /dev/block/mmcblk0boot0 @ 0x00020000:
0x00020000 header magic: 32bit - 0x12340011
0x00020004 flash count: 16bit
0x00020006 future: 16bit - 0x0000
0x00020008 type: 16bit - 0x0000 unknown, 0x0001 custom (triangle), 0x0002 Samsung Official
0x0002000A name: max 16 chars
0x0002001A end: 16bit - 0x0000
The boot partitions are presented as readonly by default, but allowing modification is a simple matter of executing the following before writing the data:
### does not fullly apply to SGY ! other phones only !! ###
echo 0 > /sys/block/mmcblk0boot0/force_ro
A number of bytes trailing this structure also change between flashes and appear to be checksum related.
click Tags below for more related info !
neither I'm able to confirm nor negate, but I'm afraid the SGY have other storage areas.
and keep in mind, on SGSII this hidden device has appears only on the leaked beta ICS kernel. Moreover I don't see any good reason, why is it accessible under Android. Kies does not care about the bin counter. I was able to restore factory state with bin counter>0 and Kies recognized my devce as valid upgradeable. On the other hand, the bin counter is handled on the sbl runlevel, where kernel and android not yet loaded.
For further reference please see my research on the SGY partition system, decoded from the pit file:
Code:
[B]minor bml stl image[/B]
1 /bml1 /stl1 BcmBoot.img
2 /bml2 /stl2 sbl.bin
3 /bml3 /stl3 bl.bin
4 /bml4 /stl4 totoro.pit
5 /bml5 /stl5 BcmCP.img
6 /bml22 /stl6 param.lfs
7 /bml6 /stl7 boot.img
8 /bml7 /stl8 (boot backup)
9 /bml21 /stl9 system.img
10 /bml23 /stl10 csc.rfs
11 /bml24 /stl11 userdata.img
12 /bml8 /stl12 (efs)
13 /bml9 /stl13 sysparm_dep.img
14 /bml10 /stl14 HEDGE_NVRAM8_RF_LE.bin
15 /bml11 /stl15 (cal)
On much deeper details please see my spreadsheet:
https://docs.google.com/spreadsheet/ccc?key=0Arilp8uJromLdHdrdGpiZ2FSN3daRzRQMkIxR0pCZXc
Minor #12 and #15 is suspicious, might have some data, which not used by the OS, and not affected by ROM update packs.
This is good research, doky. I bookmarked your spreadsheet for future reference.
efs
Doky73 said:
12 /bml8 /stl12 (efs)
15 /bml11 /stl15 (cal)
Minor #12 and #15 is suspicious, might have some data, which not used by the OS, and not affected by ROM update packs.
Click to expand...
Click to collapse
efs is directly related to the SIM card file system, I take it.
"the /efs folder is a very sensitive system folder that contains Phone-specific information such as the IMEI (encrypted in the nv_data.bin), wireless devices MAC addresses, product code (also in the nv_data.bin), and much more. Often users trying to change product codes or trying to unlock the mobile will end up corrupting data in this location."
<post deleted>
cal : calibration data
Doky73's SGY layout table: now, spot the flash counter
minor Start-offset --- End-offset ------ Size (hex) units ------- SIZE (bytes) -- BML --------- STL -- Internal name Image name ------ Description
01 0x00000000 0x00040000 0x00040000 001 000262144 /bml1 _/stl1 _bcm_boot BcmBoot.img Primitive boot loader
02 0x00040000 0x00240000 0x00200000 008 002097152 /bml2 _/stl2 _Loke sbl.bin Secondary boot loader
03 0x00240000 0x00440000 0x00200000 008 002097152 /bml3 _/stl3 _loke_bk bl.bin backup sbl
04 0x00440000 0x00480000 0x00040000 001 000262144 /bml4 _/stl4 _systemdata totoro.pit partition table
05 0x00480000 0x01100000 0x00c80000 050 013107200 /bml5 _/stl5 _Modem BcmCP.img modem/phone
06 0x01100000 0x01600000 0x00500000 020 005242880 /bml22 /stl6 _param_lfs param.lfs
07 0x01600000 0x01b00000 0x00500000 020 005242880 /bml6 _/stl7 _boot boot.img kernel & initramfs
08 0x01b00000 0x02000000 0x00500000 020 005242880 /bml7 _/stl8 _boot_backup - backup kernel & initramfs
09 0x02000000 0x10600000 0x0e600000 920 241172480 /bml21 /stl9 _System system.img ROM
10 0x10600000 0x12e00000 0x02800000 160 041943040 /bml23 /stl10 Cache csc.rfs CSC
11 0x12e00000 0x1f340000 0x0c540000 789 206831616 /bml24 /stl11 Userdata userdata.img data
12 0x1f340000 0x1f380000 0x00040000 001 000262144 /bml8 _/stl12 Efs - efs unique phone data
13 0x1f380000 0x1f3c0000 0x00040000 001 000262144 /bml9 _/stl13 sysparm_dep sysparm_dep.img
14 0x1f3c0000 0x1f400000 0x00040000 001 000262144 /bml10 /stl14 umts_cal HEDGE_NVRAM8_RF_LE.bin
15 0x1f400000 0x1f500000 0x00100000 004 001048576 /bml11 /stl15 cal - calibration data
note: not all /bml & /stl devices are visible, some of them not linked under the OS
------------------------------------------------------------
I guess, cloning all of minor 12 would be a mistake.
14 & 15 are sets of calibration data, probably for RF part (gsm radio)
mai77 said:
Darky's SGY layout table: now, spot the flash counter
Click to expand...
Click to collapse
Well, Darky is working on a custom rom for SGY???
Yep, we're saved!
Factory mode
also there is a difference between ODIN mode (via DOWN+HOME+POWER) and FACTORY MODE via USB jig 301KOhm.
makes a diff for displayed "official" vs. "custom" ROM
Any new ideas on this guys? I was wondering if this cant be hacked via the .pit file?
I wish I could find this damn partition and forcefully reset this
Apparently the max count is 255 so if you flash it the 256th time you should be on zero. Take this info with a pinch of salt.
Sent from my GT-I9100
Princeomi said:
Apparently the max count is 255 so if you flash it the 256th time you should be on zero. Take this info with a pinch of salt.
Sent from my GT-I9100
Click to expand...
Click to collapse
Are you sure?where did uou get that info??
Sent from my GT-S5360 using xda premium
Princeomi said:
Apparently the max count is 255 so if you flash it the 256th time you should be on zero. Take this info with a pinch of salt.
Sent from my GT-I9100
Click to expand...
Click to collapse
Very interesting bro
Hmmmm.... That actually does make sense to me, because due to screen size limitations, I can't see the numbers carrying on into infinity. As it is when it gets to the teens, it starts screwing up the text on screen, so an ultimate limit would make sense.
I guess besides the fact that it voids your warranty if anybody had to see it from Samsung, I guess it does nothing but just annoy you cause you cant reset it
Not sure if I will try your method Princeomi but I will keep that in mind
---------- Post added at 08:23 PM ---------- Previous post was at 08:09 PM ----------
What I don't understand though is why does the USB jig not reset it on our phones but it does on the SGS2? I just watched a vid on you tube and Odin mode looks exactly the same as it does on our phones.
I read it in the news section of XDA, never tried it though as I am on zero
Sent from my GT-S5360
NanoSurfer said:
[/COLOR]What I don't understand though is why does the USB jig not reset it on our phones but it does on the SGS2? I just watched a vid on you tube and Odin mode looks exactly the same as it does on our phones.
Click to expand...
Click to collapse
actually it does not resets neither on SGSII. Only on some old/initial ROMs. The SBL has been modified by Samsung, to prevent users resetting the counter simply by USB JIG. To reset my SGSII's counter, I have to downgrade the SBL. (or upgrade to ICS , there's an other method, based on a new feature of the 3.x kernel)
Sent from my SGSII using Tapatalk 2 & Swype
Doky73 said:
actually it does not resets neither on SGSII. Only on some old/initial ROMs. The SBL has been modified by Samsung, to prevent users resetting the counter simply by USB JIG. To reset my SGSII's counter, I have to downgrade the SBL. (or upgrade to ICS , there's an other method, based on a new feature of the 3.x kernel)
Sent from my SGSII using Tapatalk 2 & Swype
Click to expand...
Click to collapse
Interesting Sir Doky
I kinda figured that Samsung would wise up to that trick sooner or later. BTW what you think of the max count trick?
doky's SGY partn table from above attached
remember,
dd if=/dev/block/bml0!c
gives you the complete NAND storage 501 MB file on SGY:
so this shell cmds gave me a 501 MB file which is probably the NAND dump :
adb shell
su
stop
dd if=/dev/block/bml0!c of=/sdcard/bml0c.outfile
## wait 2 minutes to finish
start
## wait 30 sec
I believe, the last 1 MB of the file is junk data or duplicate
bml0!c dump
the dump says:
OneNAND boot rev. 0.2
+cboot_uart_speed_handshake(0x%x)
Set Baudrate to 115k.
Set Baudrate to 230k.
¼:”Set Baudrate to 460k.
Set Baudrate to 921k.
Set Baudrate to 3m.
Invalid Baudrate, try again.
cboot_uart.c
assert at line %d in %s -cboot_uart_speed_handshake
###################################
Secondary Bootloader v3.1 version. Copyright (C) 2011 System S/W Group. Samsung Electronics Co., Ltd.
Board: %s %s / %s %s TOTORO REV 03 Jan 14 2012 07:01:28
%s: debug level 0x%x %s: debug level low! PUMR: %d FOTA_BOOT FOTA_UAUP PUMR: 0x40 (AP only boot mode) loadmodem loadCPDATA loadkernel
boot SBL> %s: parse command error! (%s)
Autoboot (%d seconds) in progress, press any key to stop
Autoboot aborted..
booting code=0x%x stl init failed.. %s: j4fs_open.. success failed %s: bye~ bye! %s: booting stop.
%s: booting stop and power off..
S5360 console=ttyS0,115200n8 mem=362M kmemleak=off root=/dev/ram0 rw
androidboot.console=ttyS0 /mnt/rsv SNBL main
#############
prob. kernel command line for UART FOTA boot or whatever
#############
loke_exit
loke_init
command_loop
boot_kernel
SERIAL_SPEED LOAD_RAMDISK BOOT_DELAY LCD_LEVEL SWITCH_SEL PHONE_DEBUG_ON LCD_DIM_LEVEL LCD_DIM_TIME MELODY_MODE REBOOT_MODE NATION_SEL LANGUAGE_SEL SET_DEFAULT_PARAM PARAM_INT_13 PARAM_INT_14 VERSION CMDLINE DELTA_LOCATION PARAM_STR_3 PARAM_STR_4
mtdparts=bcm_umi-nand: %[email protected]%dK(%s)ro, %[email protected]%dK(%s)rw, fota_reboot FOTA
Boot cause : %s FOTA_BOOT FOTA_UAUP LOKE3 : FOTA_UPDATE_FOTA_BOOT
BOOT_FOTA=1 BOOT_FOTA=0
ATAG_CORE: %x
ATAG_INITRD2: %x
Linux-based NAND Flash software solution, offering higher performance and cost effectiveness for next-generation mobile phones. Samsung's Linux NAND Flash memory software allows the NAND Flash memory to store code as well as data. By eliminating the need for NOR Flash memory and supporting the Linux operating system with a demand-paging function, Samsung can lower overall costs and reduce space requirements in mobile handhelds.
Samsung's Linux file system, Robust File System (RFS), also offers greater data preservation capabilities in case of power disruption as well as wear-leveling for higher reliability. To address the problem of data loss from corrupted file allocation tables (FAT), Samsung's Linux-based NAND Flash memory solution also supports Transactional FAT for external memory cards. Compared to the conventional JFFS2 and YAFFS open file systems, Samsung's Linux file system enhances the NAND Flash write-speed up ten and four times , respectively.
This Flash memory solution is also available with Samsung's OneNAND (tm) Flash memory, which boasts a faster read speed compared to the conventional NAND Flash. With its advanced multi-tasking function, Linux will further accelerate the adoption of NAND Flash in next-generation mobile phones.
Importantly, as Samsung's new Linux NAND Flash memory software, RFS has completed verification in the Linux kernel 2.4.20-based Montavista Linux environment, Samsung's NAND Flash solution addresses the diverse needs of system developers for advanced performance, high reliability, shortened development time, and reduced costs.
SGY heimdall
with UBI running on oneNAND and UBIfs we SGY users can have our own "mobile ODIN" and Heimdall.
UBI is open source and part of the Linux kernel.
This is my usb log. Plz help me!
PPP Widget version 1.3.3
USB_ModeSwitch log from Tue Oct 01 17:36:52 ICT 2013
Raw args from udev: 1-1/1-1:1.0
Using top device dir /sys/bus/usb/devices/1-1
----------------
USB values from sysfs:
manufacturer HSPA,Incorporated
product HSPA WCDMA Technologies MSM
serial MF190SVIED010000
----------------
bNumConfigurations is 1 - don't check for active configuration
SCSI attributes not needed, moving on
checking config: /data/data/de.draisberghof.pppwidget/app_tmp/19d2.2000
! matched. Reading config data
devList 1:
config: TargetVendor set to 19d2
config: TargetProductList set to 0001,0002,0015,0016,0017,0031,0037,0052,0055,0061,0063,0064,0066,0091,0108,0117,0128,0157,0177,1402,2002,2003
Driver module is "option", ID path is /sys/bus/usb-serial/drivers/option1
Command to be run:
usb_modeswitch -I -W -D -s 20 -u -1 -b 1 -g 2 -v 19d2 -p 2000 -f $cB
Verbose debug output of usb_modeswitch and libusb follows
(Note that some USB errors are to be expected in the process)
--------------------------------
Reading long config from command line
* usb_modeswitch: handle USB devices with multiple modes
* Version 1.2.7 (C) Josua Dietze 2012
* Based on libusb0 (0.1.12 and above)
! PLEASE REPORT NEW CONFIGURATIONS !
DefaultVendor= 0x19d2
DefaultProduct= 0x2000
TargetVendor= 0x19d2
TargetProduct= not set
TargetClass= not set
TargetProductList="0001,0002,0015,0016,0017,0031,0037,0052,0055,0061,0063,0064,0066,0091,0108,0117,0128,0157,0177,1402,2002,2003"
DetachStorageOnly=0
HuaweiMode=0
SierraMode=0
SonyMode=0
QisdaMode=0
QuantaMode=0
GCTMode=0
KobilMode=0
SequansMode=0
MobileActionMode=0
CiscoMode=0
BlackberryMode=0
PantechMode=0
MessageEndpoint= not set
MessageContent="5553424312345678000000000000061e000000000000000000000000000000"
MessageContent2="5553424312345679000000000000061b000000020000000000000000000000"
MessageContent3="55534243123456702000000080000c85010101180101010101000000000000"
NeedResponse=1
ResponseEndpoint= not set
InquireDevice disabled
Success check enabled, max. wait time 20 seconds
System integration mode enabled
Use given bus/device number: 001/002 ...
Looking for default devices ...
bus/device number matched
searching devices, found USB ID 19d2:2000
found matching vendor ID
found matching product ID
adding device
Found device in default mode, class or configuration (1)
Skipping the check for the current configuration
Using interface number 0
Using endpoints 0x01 (out) and 0x81 (in)
USB description data (for identification)
-------------------------
Manufacturer: HSPA,Incorporated
Product: HSPA WCDMA Technologies MSM
Serial No.: MF190SVIED010000
-------------------------
Looking for active driver ...
OK, driver found; name unknown, limitation of libusb1
OK, driver "unkown" detached
Setting up communication with interface 0
Using endpoint 0x01 for message sending ...
Trying to send message 1 to endpoint 0x01 ...
OK, message successfully sent
Reading the response to message 1 (CSW) ...
OK, response successfully read (13 bytes).
Trying to send message 2 to endpoint 0x01 ...
OK, message successfully sent
Reading the response to message 2 (CSW) ...
OK, response successfully read (13 bytes).
Trying to send message 3 to endpoint 0x01 ...
OK, message successfully sent
Reading the response to message 3 (CSW) ...
Response reading got error -32
Device is gone, skipping any further commands
Bus/dev search active, referring success check to wrapper. Bye.
ok:busdev
--------------------------------
(end of usb_modeswitch output)
Checking success of mode switch for max. 20 seconds ...
Reading attributes ...
Reading attributes ...
Reading attributes ...
Reading attributes ...
Waiting for device file system (5 sec.) ...
Reading attributes ...
Mode switch has completed
Mode switching was successful, found 19d2:0108 (HSPA,Incorporated: HSPA WCDMA Technologies MSM)
Device class of first interface is ff
Now checking for bound driver ...
No driver has bound to interface 0 yet
Module loader is /system/bin/insmod
Trying to find and install main driver module "option"
Checking for active driver path: /sys/bus/usb-serial/drivers/option1
Driver not active, try to find module "option"
Can't find module "option"
Existing path found:
No way to use driver "option"
- try falling back to "usbserial"
Module "usb_serial" not found, can't do more here
Driver binding did not work for this device
All done, exiting
Hello folks,
Been hacking firmwares for Allwinner SOC-based tablets for a while. The key to "porting" firmwares bertween similar tablets used to be the script.bin / script0.bin files found in the bootloader (nanda) FAT partition.
However since Kitkat things have changed and these files are no more. The data still is somewhere though, and probably in the same format.
When a stock flashable image is available, imgRePacker or DragonFace allows for extracting the binary (config.fex) file and corresponding source (sys_config.fex). However I'm wondering how to get this from a tablet for which no such Livesuit/Phonenixsuit image is available.
After many hours of hacking, I've eventually found a way to extract it from a live, booted (and rooted) tablet because the data is mapped into the SOC's virtual address space (details will come in a later post if there's interest).
I have yet to find a way to dump it from the tablet's NAND flash memory. AFAIK this data is *not* in a section of the NAND flash memory that's accessible through the /dev/block/nandX partition devices.
I've made some progress by using the Phoenixcard tool and make it generate a bootable SD card with a full Android firmware aboard (as opposed to the minimal system used for an upgrade). The binary "script.bin" data can be found in a section of the SD card formatted in what looks like a proprietary, very rudimentary filesystem (well, more like subpartitions with a name really). Reverse-engineeering this doesn't look very difficult, it's basically a table of contents with a name and a logical block number. However I have found no way yet to reach this area of the tablet's internal NAND flash memory.
Not sure that studying the publicly released A23 SDK v1.0 code will lead to a solution because AFAIK it seems to be for Jellybean (4.2) firmwares, which still used the old script.bin in bootloader partition scheme.
I've spent much time Googling for this and haven't found any public information on this, so I'm opening this thread with the hope that it will catch the right people's eyes.
just picked up a generic a83 tablet and i'm anticipating this sort of thing. my hardware info is at your disposal. i'll be digging in myself in the next few days to dump the nand and see what i can and can't to with the stock rom.
cpuinfo is reporting sun8i, i thought the a83 was sun9i, so i need to clarify that. stock rom is KK 4.4.4 no su. let me know if you want to collaborate.
Maybe not perfect but the fastest way is use /sys/class/script/dump, you only need to know the section names
Code:
[email protected]:/sys/class/script # echo lcd0_para > dump
echo lcd0_para > dump
[email protected]:/sys/class/script # cat dump
cat dump
++++++++++++++++++++++++++__sysfs_dump_mainkey++++++++++++++++++++++++++
name: lcd0_para
sub_key: name type value
lcd_bl_en gpio (gpio: 25, mul: 1, pull 0, drv -1, data 1)
lcd_power gpio (gpio: 204, mul: 1, pull 0, drv -1, data 1)
lcd_pwm gpio (gpio: 161, mul: 2, pull 0, drv 2, data 1)
lcd_gpio_0 gpio (gpio: 158, mul: 1, pull 0, drv 2, data 1)
lcd_gpio_1 gpio (gpio: 159, mul: 1, pull 0, drv 2, data 1)
lcd_gpio_2 gpio (gpio: 23, mul: 1, pull 0, drv 2, data 0)
lcd_gpio_3 gpio (gpio: 157, mul: 1, pull 0, drv 2, data 1)
lcd_gpio_4 gpio (gpio: 26, mul: 1, pull 0, drv 2, data 1)
lcdd2 gpio (gpio: 72, mul: 2, pull 0, drv 2, data -1)
lcdd3 gpio (gpio: 73, mul: 2, pull 0, drv 2, data -1)
lcdd4 gpio (gpio: 74, mul: 2, pull 0, drv 2, data -1)
lcdd5 gpio (gpio: 75, mul: 2, pull 0, drv 2, data -1)
lcdd6 gpio (gpio: 76, mul: 2, pull 0, drv 2, data -1)
lcdd7 gpio (gpio: 77, mul: 2, pull 0, drv 2, data -1)
lcdd10 gpio (gpio: 80, mul: 2, pull 0, drv 2, data -1)
lcdd11 gpio (gpio: 81, mul: 2, pull 0, drv 2, data -1)
lcdd12 gpio (gpio: 82, mul: 2, pull 0, drv 2, data -1)
lcdd13 gpio (gpio: 83, mul: 2, pull 0, drv 2, data -1)
lcdd14 gpio (gpio: 84, mul: 2, pull 0, drv 2, data -1)
lcdd15 gpio (gpio: 85, mul: 2, pull 0, drv 2, data -1)
lcdd18 gpio (gpio: 88, mul: 2, pull 0, drv 2, data -1)
lcdd19 gpio (gpio: 89, mul: 2, pull 0, drv 2, data -1)
lcdd20 gpio (gpio: 90, mul: 2, pull 0, drv 2, data -1)
lcdd21 gpio (gpio: 91, mul: 2, pull 0, drv 2, data -1)
lcdd22 gpio (gpio: 92, mul: 2, pull 0, drv 2, data -1)
lcdd23 gpio (gpio: 93, mul: 2, pull 0, drv 2, data -1)
lcdclk gpio (gpio: 94, mul: 2, pull 0, drv 3, data -1)
lcdde gpio (gpio: 95, mul: 2, pull 0, drv 2, data -1)
lcdhsync gpio (gpio: 96, mul: 2, pull 0, drv 2, data -1)
lcdvsync gpio (gpio: 97, mul: 2, pull 0, drv 2, data -1)
deu_mode int 0
lcdgamma4iep int 22
smart_color int 90
lcd_used int 1
lcd_if int 6
lcd_driver_namestring "b079xan01"
lcd_x int 768
lcd_y int 1024
lcd_width int 0
lcd_height int 0
lcd_dclk_freq int 66
lcd_pwm_freq int 50000
lcd_pwm_pol int 1
lcd_bl_0_percentint 2
lcd_bl 5_percentint 5
lcd_bl_10_percentint 15
lcd_bl_25_percentint 20
lcd_bl_50_percentint 37
lcd_bl_75_percentint 58
lcd_bl_100_percentint 73
lcd_hbp int 120
lcd_ht int 948
lcd_hspw int 64
lcd_vbp int 80
lcd_vt int 1140
lcd_vspw int 50
lcd_hv_if int 0
--------------------------__sysfs_dump_mainkey--------------------------
@lolet: thanks for the tip. I was already aware of this. It's a handy way to grab the textual contents of a particular section but there are drawbacks: you can't request too long of a section or the complete data, on my A23 tablet it causes a kernel panic. Probably an unhandled buffer overflow.
I've found another way to get the full, binary (compiled) data by running the following script on the tablet:
Code:
#!/system/bin/sh
SYS_CONFIG_MEMBASE="0x43000000"
SYS_CONFIG_MEMSIZE="0x10000"
CHUNK="0x200"
OUTFILE=/mnt/sdcard/sysconfig_dump.txt
rm $OUTFILE
let address=$SYS_CONFIG_MEMBASE
let "end=(SYS_CONFIG_MEMBASE+SYS_CONFIG_MEMSIZE)"
while [ $address -lt $end ]; do
let "last=(address+CHUNK-1)"
busybox printf "%04x,%04x\n" $address $last
busybox printf "%04x,%04x\n" $address $last > /sys/class/sunxi_dump/dump
cat /sys/class/sunxi_dump/dump >> $OUTFILE
let "address=(address+CHUNK)"
done
This produces a file going like:
Code:
0x43000000: 0x00000045 0x00000000 0x00000001 0x00000002
The next Perl script will put back the data in the correct byte order and convert it to raw binary data:
Code:
#!/usr/bin/perl
while(<>) {
chomp;
@words = split;
shift @words;
foreach $w (@words) {
$w =~ s/^0x//;
$w = reverse(pack('H*', $w));
print $w;
}
}
(reads hex dump on stdin, produces binary data on stdout)
The resultant binary file has passed the "fexc -I bin -O fex binfile fexfile" test successfully and checking a sample of sections against the data returned by the method you have mentioned has shown the data as consistent.
However, neither of this provides an answer to my main question: where is the bloody data in the NAND flash of the tablet when it's no longer in the script.bin/script0.bin files from the bootloader partition?
lanning: is uboot even using script.bin? I've just started poking around, and the uboot output over serial during startup includes this peculiar line:
Code:
mount part name bootloader
cant open script.bin, maybe it is not exist
looks like maybe my tablet is asking your question too...?
@jawbonegroove: well, I haven't got as far as hooking a serial interface to my Allwinner tablets yet, because I need to buy a converter first. It's in my todo list.
So I haven't seen this message.
I presume that uboot does use sysconfig data, but it might be able to get it from the legacy location (script.bin file in bootloader FAT partition) and the new one (somewhere well hidden on the NAND flash). Not finding it in the legacy location might cause this message to be sent out, don't know.
What I know for sure is that the kernel does find and use sysconfig data, wherever it is, because it's mapped to the kernel VM and kernel modules use this data to configure themselves.
And by the way, it's "Lannig", no "n" before the "g", thanks
lanniG: (sorry) I also haven't done much with serial yet, mainly just logged a normal boot. It does also show this nand layout...
Code:
--------fastboot partitions--------
-total partitions:10-
-name- -start- -size-
bootloader : 1000000 1000000
env : 2000000 1000000
boot : 3000000 1000000
system : 4000000 30000000
misc : 34000000 1000000
recovery : 35000000 2000000
cache : 37000000 30000000
metadata : 67000000 1000000
private : 68000000 1000000
UDISK : 69000000 0
-----------------------------------
@jawbonegroove (now I'm trying not to misspell it ): you said you got this chinglish message "cant open script.bin, maybe it is not exist". From what log did you get it? It comes from u-boot, I'm fairly sure of this. The dmesg command doesn't show messages coming from that early in the boot process, only kernel messages.
The partitioning: nothing out of the usual here. These can be addressed through the /dev/block/nandX (X=a,b,...) and /dev/block/by-name/* device files.
AFAIK from my searches, the binary configuration data formely contained in script.bin is nowhere to be found in any of these partitions. So my guess is that it's outside of the NAND flash memory addressable through these devices files. Possibly in between the MBR and the nanda partition.
yeah, that was uboot over the serial console. i just used serial again to root it last night so i've got nand images to play with now. in regards to the op:
Code:
[email protected]:/ # mount -t vfat /dev/block/nanda /data/nanda
[email protected]topus-ibt:/ # cd /data/nanda/
[email protected]:/data/nanda # find .
.
./font24.sft
./bat
./bat/low_pwr.bmp
./bat/bat0.bmp
./bat/bat1.bmp
./bat/bat3.bmp
./bat/bat9.bmp
./bat/bat8.bmp
./bat/bat2.bmp
./bat/bootlogo.bmp
./bat/bat4.bmp
./bat/bempty.bmp
./bat/bat5.bmp
./bat/bat7.bmp
./bat/bat6.bmp
./bat/battery.bmp
./bat/battery_charge.bmp
./bat/low_pwr_bak.bmp
./bat/bat10.bmp
./bootlogo.bmp
./font32.sft
./magic.bin
./data.notfirstrun
i don't have a script.bin, but i've got a magic.bin. (and, it does try and boot from an sdcard partitioned for uboot. i'll probably try to put together a bootable sd image sooner than later.)
what do your nanda and kernel cmdline look like?
[edit] also, have you used meminfo?
I've had a few A23 tablets in my hands, most KK-based and one JB (4.2).
Some don't have any script0.bin/script.bin file in the bootloader partition, but a magic.bin file just as you mention. However if you open this file you'll see that it has most likely nothing to do with h/w configuration. It's just a few hex strings looking like filesystem UUIDs.
Some of them do have a script0.bin file only (no script.bin) which I'm almost sure is completely ignored (I've tried modifying it with no visible effect). Checking its contents against the config data extracted from the live tablet as explained above (kernel memory dump through the /sys interface) shows that it does not even match 100%. I suspect it's a leftover.
Besides this, bootloader partition's contents looks exactly like what you've listed.
Command line: nothing unusual:
Code:
console=ttyS0,115200 rw init=/init loglevel=4
Have you actually managed to make a fully bootable SD yet for an A23 tablet? I'm not sure I get what you wrote. If you did, please tell us more. That's something I've done in the A10 times but it was using a special version of u-boot I don't know where to find for the A23.
hm, good to know. i haven't found many resources for sunxi hardware...linux-sunxi has some good info but its scattered and they seem kind of militant about joining their cause before they'll help you...
ill keep digging.
didn't see that last sentence before. no, this a83 is my first allwinner...i say it tried to boot because when i put in an sd card with uboot mbr and friends (semi-random device fs image), it powered on but with no visible response -- it didn't just continue with a nand boot until i pulled the card and hard reset it. maybe all that tells me is that i don't need to muck about with button sequences or whatnot to boot from sd.
Oh well, no need to try this actually.
Allwinner devices do have the SD card before the internal NAND in the boot sequence. So they will try booting from the SD if they find an uboot structure there. This is true since the A10 days (and still is).