Hello everyone. I read this forum for quite a while now and i got here some precious informations that helped me developing a new linux-based solution for qualcomm-chipped devices that are *totally* bricked.
I bricked my HTC One (m7) while trying to tweak it a few days ago and i was quite desperate since i only had it working for 1 day... My phone was consistently disconnecting from network and as a software developer, i thought it was a software problem of course. Once bricked i saw a small piece of paper stuck in the simcard slot when i opened it... Too late
Ok, that's all for the story. Once "dead", my phone started to show the infamous "DLOAD 9006" mode and i found some interesting pieces of software designed to fix that. But, no luck, that phone seems stuck in some kind of "bastard" mode, telling 9006 mode but refusing to act like a usb storage disk. Lots and lots of errors looking at the kernel log with dmesg.
Tried several kernels, 2.6, 3.16 & 4.4 & macintosh too, but really no luck.
And then i came with an idea : making my own stuff to unbrick that sh*t.
I found lots of informations on Qualcomm-based machines, including some info on iPhones and routers. Impossible to get a hold on the official Qualcomm DLOAD documentation, but some others seem to have better luck, and by reading engouh source code, i merged everything i found and made my own project on github.
So here it is, the "dloadtool" : github.com/jnaulet/dloadtool
Sorry i can't post links as i'm a newbie here, you'll have to copy it in your browser by yourself
Don't expect any documentation yet, don't expect binaries, i started to work on this on the 10th of march.
But i can tell you about the main syntax :
# dloadtool [ -F device] command [args...]
By default, the device is /dev/ttyUSB0, but you can change that with the F flag.
Commands are the following (for now) :
- reset (resets the Qualcomm, can be *really* useful)
- magic (sends a magic number) -> as i understood, will only work if chip is correctly loaded
- info (displays some info about the device)
- send XXXX... (sends hexadecimal values directly to the phone, useful for testing, no 0x prefix equired)
- loadhex file.hex (loads a .hex file in memory)
- loadbin file.mn (loads a .mbn file in memory and executes it)
- execute XXXX (executes code at XXX hex address, no 0x prefix required)
Now, you'll need an extra library called libcintelhex to build this program. Here's the source : github.com/martin-helmich/libcintelhex (same problem as above). This lib is required to load intel32 hex files (the MPRGXXX.hex files).
If, like me, you have no luck, your phone will be stuck in a undocumented 9006 mode. That's why you'll need to build the qcserial module i put in my project and patched for the HTC One M7. Just use the build.sh script and everything should go right. Then you'll probably need to type something like that :
# modprobe usb_wwan
# insmod qcserial.ko
So now's the deal. I successfully put my phone from "bad' 9006 mode to clean 9008 mode by using :
# ./dloadtool reset
Then, i could successfully load a piece of code typing
# ./dloadtool loadhex MPRG8064.hex
But program refuses to execute and seems to crash the Qualcomm. I need to unplug & re-plug it, reset it again.
I found lots of MPRGXXX.hex & .mbn files in the UFIBox.com software (if you're looking for them) but none seems to make a difference. Some don't load cause of a different memory map, some crash. :crying:
Maybe, as the chip is a 8064T (Krait 300 core), 8064 (Krait 200) code is not working, i don't know. If you got any kind of information that could help me, please, share ! Thank you. :fingers-crossed:
Some news
Here are some news...
I could finally get a hold a some Qualcomm documentation thanks to this forum, especially the 80-39912-1-E_DMSS_Download_Protocol.pdf on a thread i lost since (sorry).
I made some major updates to my source code, adding lots & lots of commands, some useless, some not so.
So here are the commands i designed :
Code:
#./dloadtool info -> Displays some basic info
#./dloadtool reset -> Hard reset
#./dloadtool magic -> Send magic (Streaming DLOAD protocol, useless for the moment)
#./dloadtool send <hex value> -> Send raw hex values (for testing purposes)
#./dloadtool loadhex <hexfile> [address] -> Loads a .hex file into RAM (IMEM for Snapdragon 600)
#./dloadtool loadmbn <mbnfile> [address] -> loads a .mbn file into RAM
#./dloadtool loadbin <binfile> [address] -> load a raw binary file into memory
#./dloadtool execute <address> -> Executes code at address (More info on this)
#./dloadtool infombn <mbnfile> -> Displays info about the mbn file (reads header)
#./dloadtool signhex <hexfile> <signaturefile> -> experimental. Concatenates hexfile & signature in a .mbn file & modifies header accordingly. Useless at the moment
#./dloadtool signmbn <mbnfile> <signaturefile> -> Same as above
#./dloadtool read <address> <length> -> Reads length bytes at address. Doesn't work in my PBL (only SBL)
#./dloadtool erase <address> <length> -> Erases length bytes at address. Warning: addresses are 20bits segment:offset calculations so probably useless on modern phones (probably used only in old qualcomm NOR flash stuff)
Now let's talk a little more about the HTC One i'm trying to unbrick with this tool.
Here are some info :
Code:
# ./dloadtool -F /dev/ttyUSB2 info
Software Version: PBL_DloadVER2.0
Protocol Version: 0x8
Min Protocol Version: 0x1
Max Write Size: 0x600
Model: 0x90
Device Size: 0x0
Device Type: 0x0
According to the documentation i have, protocol version 8 means the corresponding sheet is 80-39912-1-E_DMSS_Download_Protocol.pdf. Ok, i have it. And if i look inside, Min Protocol Version 1 means non-secure implementation :fingers-crossed: (no need for UNLOCK command at least). Device size & type are no relevant information.
I can load a hex file : :good:
Code:
#dloadtool -F /dev/ttyUSB2 loadhex MSM8064/MPRG8064.hex
< Software Version: PBL_DloadVER2.0
< Protocol Version: 0x8
Min Protocol Version: 0x1
Max Write Size: 0x600
Model: 0x90
Device Size: 0x0
Device Type: 0x0
Loading file MSM8064/MPRG8064.hex...
File size is 53658 bytes
Load address is 0x2a000000
< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< . Done
But i still can't run any file i have, CPU crashes.
So i tried something... Typing every command that's in the spec... And when i typed
Code:
#./dloadtool -F /dev/ttyUSB2 send 18
< 18 01 00 ba 21 02 da 99 c9 24 05 8c 75 8f a9 f4 | ....!....$..u...
25 08 47 c9 2c ab de 17 fd ce f0 1d 4d af f8 df | %.G.,.......M...
5d 67 53
0x18 command stands from "Public Key Hash Request". So there's a public key security system even in this little PBL emergency downloader... Very bad news... :crying::crying::crying:
According to ARM's documentation (didn't re-read Qualcomm's docs yet), this means it's highly possible that even this small primary boot loader needs to check a certificate & signature to allow the "go/exec" commmand.
Unlock command is probably obsolete (only 64 bits), now welcome to RSA encryption secured bootloaders !
This could explain why the MPRG8084.hex file is in fact an intel32-formatted version of a small .mbn file. If i show you the headers of a .mbn file, you'll probably understand what i mean :
Code:
#./dloadtool -F /dev/null infombn MSM8064/8064_msimage.mbn
Read successful
codeword : 0x844bdcd1
magic : 0x73d71034
Image type : SBL1
Load address : 0x2a000000
Body length : 83072
Code length : 83072
Signature address : 0x2a014480
Signature length : 0
Certificate address : 0x2a014480
Certificate length : 0
If i use a .hex file i converted, here's the result
Code:
#./dloadtool -D /dev/null mbninfo mprg8064.mbn
Read successful
codeword : 0x844bdcd1
magic : 0x73d71034
Image type : eHostDl
Load address : 0x2a000050
Body length : 53572
Code length : 53572
Signature address : 0x2a00d194
Signature length : 0
Certificate address : 0x2a00d194
Certificate length : 0
Now, my hypothesis is the CPU refuses to exec cause he wants to check the certificate & signature of the files i upload. But i don't have any of this, only Qualcomm & HTC own these files & they keep them no matter what, cause it's a source of profit for their customer services. :crying:
After two weeks of hard work, unbricking this phone not using JTAG seems hopeless and i'm very frustrated , i'm really mad at Qualcomm & HTC for not letting educated people take total control of a device they bought at a considerable price . Ok, mine was a bargain (before it crashed...), but that's not the point.
I will try to make contact with HTC to see if they can provide my some stuff, but i don't think they will cooperate.
To be continued ?
Some news again
Hello,
Here are the news i got... I made some research and i don't have any good news. :crying:
I started to look at some specs and found information about "the root of trust", part of a security system by ARM called "TrustZone".
Briefly, it's a certificate-based system, put once and for all in the SoC's ROM. Its goal is to ensure no "untrusted" code can be executed. By untrusted, they mean, not signed by the "correct" authority (whose public key hash is available by using the 0x18 command).
More info here : www dot embedded.com/design/safety-and-security/4438300/Securing-the-IoT--Part-2---Secure-boot-as-root-of-trust- AND here : www dot arm.com/products/processors/technologies/trustzone/
I'm no security specialist, but i can tell it will be really difficult to create a certificate that has the same 256 bits hash to sign any code. Collisions may exist in SHA-1 and MD5, but SHA256 is still considered solid.
So I asked Qualcomm about the files i needed to unlock my HTC One phone and here's their answer :
Any information other than what is listed on our website (URL listed below for your reference) is Proprietary to Licensees.
Unfortunately we are unable to assist with your inquiry. We recommend you follow-up with a vendor that carries this product and seek their feedback on your technical questions.
Please note, Qualcomm is the technology provider, not a manufacturer of consumer products and therefore we are unable to answer your product specific question. We hope this direction helps.
Thank you for your inquiry,
Qualcomm Technologies Inc.
Click to expand...
Click to collapse
In short, "ask HTC".
That's what i did and i have little hope. No answer at the moment. :fingers-crossed:
So now's the moment i complain about this exaggerated use of security. This is ridiculous. Exploits exist in Android itself, no need to access the service ports for that, so what's the point ? It seems really unlikely that anyone would install a trojan using the 9008 mode, counting on a user's mistake is a much safer bet.
Boot loaders have become a real pain in the *ss because of this technology. There's a primary boot loader (which requires certification), a secondary boot loader (same thing), a third boot loader (idem) and then android's boot loader (signed too). Is that a phone or a safe ?
For my last words, i recommend that we stay away from the manufacturers that use these technologies to make more and more profit, treating their customers as prisoners.
Stay safe, stay away from this sh*t !
I am looking at this thread here for the first time and thanks for your contribution. Do your tools only work on linux kernels, what about Solaris? I have both is why I ask...
I too am having an issue finding the right programmers...I noticed when using windows based tools to send binaries in 9008 mode that my phone would reset or lose the ability to do the handshaking process. I am going to mark your site on github and take a deeper look at this. This tool may be what I am looking for or at least another option. Thanks!
nate0 said:
I am looking at this thread here for the first time and thanks for your contribution. Do your tools only work on linux kernels, what about Solaris? I have both is why I ask...
I too am having an issue finding the right programmers...I noticed when using windows based tools to send binaries in 9008 mode that my phone would reset or lose the ability to do the handshaking process. I am going to mark your site on github and take a deeper look at this. This tool may be what I am looking for or at least another option. Thanks!
Click to expand...
Click to collapse
As long as you device is recognized as /dev/<something>, this should work in either system, using the -F option to select the right device, if needed. The kernel patch is for linux only and should not be required at all (unless your phone shows as 9006 mode but is in fact 9008, like mine was).
As i'm a linux user, i got some more info by using dmesg (to know if a driver was loaded correctly) and lsusb (to get the phone's mode). I don't know if these tools are available on Solaris. But there are probably alternative commands, though.
Beware, using this tool, i was able to reset & load files into the phone's memory, but not to run any code. I hope you're lucky enough to have a phone that's not "secure boot"-protected.
I tried a hex file labelled GPP8064.mbn and I believe it executed on my Nexus 7.
Dmesg was flooded with 14 devices that looped but could not connect successfully.
Perhaps this information would help you further?
Sent from my ONE A2005 using Tapatalk
when I launch your program (dloadtool) I got
./dloadtool -F /dev/ttyUSB0 info
< Invalid CRC!!!
Error receiving software version!!
< Invalid CRC!!!
Errore di segmentazione
marte3707 said:
when I launch your program (dloadtool) I got
./dloadtool -F /dev/ttyUSB0 info
< Invalid CRC!!!
Error receiving software version!!
< Invalid CRC!!!
Errore di segmentazione
Click to expand...
Click to collapse
Same here, trying to use it on a US s8+ (sd835)
can anyone supply me the download link please
Related
I upgraded my XDA Exec with the new ROM 1.30.162 WWE and Activesync 4.1 but each time I sync, I get a "bad_pool_header" error on a blue background which crashes my machine.
I installed Activesync 4.1 on another laptop to check if this problem was due to drivers etc on my main laptop, and discovered that the device syncs with no problems. There is, therefore, a conflict between the new Activesync 4.1 or the new ROM, and something on my main laptop.
Has anyone come across this problem?
Thanks
The problem is definitely on your PC. Reinstall motherboard drivers, reflash bios, remove antivirus, reinstall windows, etc.
Thanks - pretty drastic...!
Is there a short cut? ie reinstalling drivers one by one? If so, which are likely to be the main culprits? Motherboard? Broadband modem? etc
The error code after reboot of the laptop is:
BC code 19 BCP1:00000020 BCP2: 89A76000 BCP3: 89A766C0 BCP4: 0AD8000
OS Ver 5_1_2600 SP: 2_0 Product 256_1
\WER22c7.dir00\Mini052506-06.dmp
\WER22c7.dir00\sysdata.xml
Does this reveal anything that could explain which driver?
Thanks
10860 said:
Does this reveal anything that could explain which driver?
Click to expand...
Click to collapse
no.
You should create a complete crash dump, and use microsoft debugging tools to find faulting driver. Or better reinstall windows.
I looked at the minidump file and used MS debugger, the readout is below. I am not sure if I did the debugging ok, or how to interpret it. Anything useful in the readout?
Thanks
Loading Dump File [C:\Mini052406-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: C:\WINDOWS\Symbols
Executable search path is:
Unable to load image ntoskrnl.exe, Win32 error 2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
Windows XP Kernel Version 2600 (Service Pack 2) UP Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055a420
Debug session time: Wed May 24 20:25:34.038 2006 (GMT+1)
System Uptime: 0 days 0:52:32.633
Unable to load image ntoskrnl.exe, Win32 error 2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
Loading Kernel Symbols
.......................................................................................................................................................................................................
Loading User Symbols
Loading unloaded module list
.................................
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 19, {20, 88187000, 881876c0, ad80000}
Probably caused by : Unknown_Image ( nt!KeBugCheck2+4d4 )
Followup: MachineOwner
---------
kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
BAD_POOL_HEADER (19)
The pool is already corrupt at the time of the current request.
This may or may not be due to the caller.
The internal pool links must be walked to figure out a possible cause of
the problem, and then special pool applied to the suspect tags or the driver
verifier to a suspect driver.
Arguments:
Arg1: 00000020, a pool block header size is corrupt.
Arg2: 88187000, The pool entry we were looking for within the page.
Arg3: 881876c0, The next pool entry.
Arg4: 0ad80000, (reserved)
Debugging Details:
------------------
BUGCHECK_STR: 0x19_20
POOL_ADDRESS: 88187000
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: DRIVER_FAULT
LAST_CONTROL_TRANSFER: from 00000000 to 8053331e
STACK_TEXT:
f78cab74 00000000 00000000 00000000 00000000 nt!KeBugCheck2+0x4d4
STACK_COMMAND: kb
FOLLOWUP_IP:
nt!KeBugCheck2+4d4
8053331e ?? ???
FAULTING_SOURCE_CODE:
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: nt!KeBugCheck2+4d4
IMAGE_NAME: Unknown_Image
DEBUG_FLR_IMAGE_TIMESTAMP: 0
BUCKET_ID: ZEROED_STACK
MODULE_NAME: Unknown_Module
Followup: MachineOwner
---------
Nothing useful, minidump does not have enough information
It is very difficult to debug pool corruptions.
Hi there,
I've done some reverse engineering on the LG DZ files, and here is the layout of these files.
DZ File Format
Code:
Offset Length (bytes) Description
0x0 0x8 Magic code "MSTXMETX"
0x8 0x2 Unknown, same value in all files (value 0x01)
0xA 0x2 Separator ? (value 0x0)
0xC 0x2 Unknown, same value in all files (value 0x0B)
0xE 0x2 Separator ? (value 0x0)
0x10 0x6 Unknow, value differs from file to file
0x16 0x2 Unknown, same value in all files (value0x01C8)
0x18 0x8 String, phone model ? (value "KS20")
0x20 0x50 String, file title ?
0x70 0x1C Two null terminated string concatened ("[chipmodel]\0[osname]\0")
0x8C 0x80 String, DZ filename
0x10C 0x20 Separator (filled with 0xFF)
0x12C 0x10 Header MD5 hash
0x13C Variable Concatened subfiles (see Subfile format)
-- 0x78 Offset Table, unknown useage (see OffsetTable format)
-- -- Optionnal data, present in some DZ file (unknown)
Subfile format
Code:
Offset Length (bytes) Description
0x0 0x4 Magic code "SSTX"
0x4 0x2 Unknown, same value for all subheaders (value 0x01)
0x6 0x2 Separator ? (value 0x0)
0x8 0x2 File Type ?
0xA 0x6 Separator ? (filled with 0x0)
0x10 0x4 Data length
0x14 0x80 Filename, null terminated string
0x94 0x10 Separator (filled with 0xFF)
0xA4 0x10 Uncompressed data MD5 hash
0xB4 0x10 Subheader MD5 Hash
0xC4 Data length Gzip compressed data
File type (in subheader)
Code:
Type Filename Description
0x3 amss.mbn AMSS modem
0x8 partition.mbn Partition table
0xA qcsblhd_cfgdata.mbn QCSBL header
0xB qcsbl.mbn QCSBL
0xC oemsblhd.mbn OEM boot header
0xD oemsbl.mbn OEM boot
0xE amsshd.mbn AMSS modem header
0x13 appsboothd.mbn APPS boot loader header
0x14 appsboot.mbn APPS boot loader
0x15 FLASH.bin
0x16 apps.mbn APPS
It's not complete, but that's a start.
I also made a tool to extract the subfiles contained in the DZ file (see attached file).
Hope this helps,
JP.
Check also the tool to extract the content of the Flash.Bin file : LGFlashParser
Great news !
I tested your soft with different lg ks20 dz files downloaded on the web and files seem to be extracted as they should. I didn't try to flash though, as I'm at work and I don't have usb cable here.
Now we still need to find how to edit those files (*.mbn and especially flash.bin which contains windows file system). Anyway, it's a great step towards lg rom cooking. Thanks again!
I have updated the DZExtract tool...
It now checks all the known MD5 hash, so the extracted files can be considered valid.
Here are the command line options :
Code:
dzextract.exe [options] path [outputpath]
options : default -p
-p Print and check header information
-x extract subfiles
path : path to dz file
outputpath : path to output directory (must exists)
Hope this helps,
JP.
Wow, sounds great!
Thank you very much for this excellent work.
it's possible to extract also the files of .mbn or FLASH.bin ?
For mbn files you can try with this soft :
http://forum.modopo.com/diskussionen-rund-ums-modding/t-19197-qc-bqs-firmware-analyzer.html
Great.....a good start............
How does it work? Can it work in vista? Coz i double click the DZextract.exe, a dos window came out for 1 sec then closed and nothing happen.
raykisi said:
How does it work? Can it work in vista? Coz i double click the DZextract.exe, a dos window came out for 1 sec then closed and nothing happen.
Click to expand...
Click to collapse
This is a command line tool, so you need to open a command window and follow the instructions.
About the contained files :
The flash.bin seems to be the windows image (found old infos here : Rom file format)
The mbn files reflect the firmware structure :
- QCSBL = QC Secondary Boot Loader
- OEMSBL = OEM Secondary Boot Loader
- AMSS = Advanced Mobile Subscriber Software
...
(infos from the link posted by DomZ)
JP.
Great application !
Files identical (same CRC) from unbranded to branded roms:
apps.mbn
appsboothd.mbn
oemsbl.mbn
oemsblhd.mbn
partition.mbn
qcsbl.mbn
qcsblhd_cfgdata.mbn
All the remaining files are different, inclueding the flash but that is obvious.
(amss.mbn, amsshd.mbn, appsboot.mbn, Flash.bin)
I guess we have to compare the unidentical mbn files to find out what prevents the unbranded roms to work in phones with branded NVs.
Then if nothing is conclusive we will have to check the flash itself.
mbn files seem plain/uncompressed binaries.
In fact I believe the CID checks are performed by amss.mbn which seems to be somehow the true bootloader (It is a true ELF binary and likely the very first to be running)
This is just a guess based on my todays reading and disassembling: the msm7200 has two processor, and one is dedicated to the radio functions. This processor actually runs the AMSS file which is an arm elf executable (you can to disassemble this file with IDA).
Apparently, the AMSS part is based on an L4 microkernel, and running iguana embedded os (see here).
On the QC BQS analyzer page, the boot process is explained (it's for another phone, but I think it's the same). The QCSBL (Qualcomm secondary boot loader) load the OEMSBL (probably on the first processor) and then also load the AMSS Elf.
Both the oemsbl and the amss run in parrallel (i guess they communicate with some kind of IPC mechanism).
After that, the oemsbl start the windows kernel.
I think, we should concentrate on the flash.bin file, as i think the other files are either encrypted or at least signed.
My post is just a guess as it's very hard to find information on the msm7200 processor and as I do not have a KS20 phone (nor a qualcomm based phone) to check all these informations.
JP.
The other files are plain text. They may however indeed be signed although this is not sure, since they did not bother to add any kind of encryption (at least not that I could spot) , perhaps they did not bother adding a signature either. I think LG did not expect us to access these files/ressources from the phone, I do not expect them to be accessible through software (running on the phone that is) we can actually access it thanks to the leaked service tools from LG using their recovery mode.
I think you are right about LG as I found that the files contained in the DZ file were supposed to be crypted : when disassembling the LG sofware, I found that the fonction that extracts the subfiles could also decrypt the files, however none of the DZ files I have are encrypted.
But regarding the qcsbl file for example, I'm not so sure : this file is certainly built (or at least coded) by Qualcomm and is probably part of the SDK they send to their customers.
I've seen posts about similar phone using qualcomm chipset reporting that some of the bootloaders were signed.
JP.
Spend money...
Hi,
its cool what you have find out about the DZ Format. But the problem is that misterjp has no KS20. What do you think if we all spend a little money, so that misterjp can buy a KS20 because with this he can find more about the DZ Format? If we know a lot of the DZ format in the future someone will release new Windows Mobile Version.
Dear Dussel
in fact need to knew more about .mbn file format ... not .dz (that is simpliest pack method /container for multiple .mbn /)
on net i'm saw .mbn extractor ... but not .mbn creator ... that format more complicated than .dz - so better to spend money for that, who can work with .mbn - it's more perspectivelly, or anybosy, who can find alternate way to flash (without .mbn)
so firstly take a look to :
1. MBN-Resourcer = Qualcomm firmware resource viewer
2. QPST - Qualcomm Product Support Tools
3. QXDM - Qualcomm eXtensible Diagnostic Monitor
4. QC BS analizer - similar to mbn-resourcer, but other maintainers
5. BREW Resource editor - it's more for high level programming ...
that will be primarilly tools for decryting ... but crypting - possible need signing key for creating .mbn and that key must be trusted by device ...
@ DomZ
Thanx for info.
@ misterjp
Nice work.
@ all
Like DaLiV said. I think also. It is an good idea to collect more infos about Qualcomm. Many manufacturer use Qualcomm Hardware...
Samsung, LG, Motorola, Huawei... many more.
AMSS is ever used. If Qualcomm MSMxxxx works as heart of mobile.
Best Regards
Edit...
1. I have looked into QPST 2.7 Build 264 (good Description in Manual) See Screenshot...
2. It looks that RSA2048 Signature at End of AMSS is not used.
Check amssHD.mbn
First 2 adresses the same and means End of AMSS... And 0x1D is 00 instead 01
Why the other 2 adresses exceed AMSS? I don't know...
So in theory Manipulation of AMSS seems possible.
3. BREW is "obsolete". Not an part of AMSS. Because the WM OS is used as an "Layer"...
4. NVM folder I can see... So I think also NV items are used...
5. Funny GZIP is used also from BenQ for EF91... To hide AMSS...
I agree with you. Now that misterjp has partially reversed dz format, we need to concentrate on files contained inside it (as you may all know, lgmdp can actually flash firmware from a directory containing mbn+bin files, not only dz, so there is no point in trying to reassemble a dz from a list of mbn files (at least, it's not a priority).
On the other side, misterjp has proved to be a good reverser on a format for which he doesn't even own a phone. To be totaly honest, (and as I already said on a french forum), he did this on my demand because I was not really efficient in reversing lgmdp. I'm pretty sure he could go further (and with no doubt could cook an english firmware, for those of you waiting for this). I think the least thing would be for him to have a phone to test his development. So misterjp, if you're ok to continue your work and would like some donations, don't hesitate to update your first post with a paypal link, at least til you get a phone.
Hi there,
Thanks for the support ! I did not have many time this week end, so I do not have many informations today : the flash.bin is using a Windows flash format, very easy to extract :
Code:
Offset Length (bytes) Description
0x0 0x7 Magic code "B000FF\n"
0x7 0x4 Image start adresse
0xB 0x4 Image Length
0xF --- List of memory block
-- 0x4 Always zero
-- 0x4 Image entry point
-- 0x4 Always zero
Each memory block is composed of
Code:
Offset Length (bytes) Description
0x0 0x4 Memory destination of block
0x4 0x4 Block size
0x8 0x4 Block checksum (sum32)
0xC --- Data
JP.
So,
I have sucessfully extracted the imgfs from the flash file. So here is the tool to do it.
It's a bit late, so I'm not giving explanation now, but I will !
To use the tool, just run
Code:
LGFlashParser.exe FLASH.bin
It will generate 3 files (BOOT, RAW and IMGFS), then you can use ImgfsToDump to extract the content of the IMGFS file.
At the moment, ImgFsToDump crash at the end of the processing (but the content is extracted), this is probably due to an invalid char in my generated imgfs, but it's too late to investigate.
Apparently, some files extracted from the imgfs part have no data. It could be related to the problem exposed before. I am working on this problem.
I have also checked the part_2_RAWFS : for this file, you can use the dumprom utility to extract it's content :
Code:
dumprom.exe part_2_RAWFS.bin -5 -d dump-xip
SecretKey.key
Any idea what this is for?
Searched little bit through folder Security...
Found in S8500XPKJ1.
Best Regards
For quick insight:
Main function is SpkiDispatch , it does create this file by calling SpkiSaveMasterSecretKey, together with that key it does create directories
"/Security/Log/"
"/Security/Log/Cert/"
"/Security/CM"
SpkiSaveMasterSecretKey does use functions
SecFrameGetIMEI
SpkiBase64Decode
SecCrDecodeRSAPublicKeyEx
Whole "Spki" functions family seems to be related with OS certificate manager. And yeah, looks like it is based on IMEI, or does include IMEI itself.
//edit:
Oh yes, string which is hardcoded into APPS and is being decoded by Base64 during runtime (probably kind of init state of the key) is
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDKyA2m2/PTRbsv9Y+39R6wroIniRv3nAUcOPH6dhg/9+2sCoWk0BgDtmfNMtUpueEzAr1OmAtxIfxt+gcaaFGDTr2NiY4ML9NhIv0frmlEsE8CLZFcMLYnCaeo7IMpDhnkUJA/aFhm42hmHM//e9sW2zOeN/oFrZ6wH7BEJmVEpQIDAQAB
Click to expand...
Click to collapse
from the looks of that string - I think you're looking at ... ahem wait for it ... a secret key -- or perhaps one half of a public/private key pair. Something that AES128 would be perfect for... good luck cracking that one.
Compared between S8500 and S8530... both on KJ1:
Code:
535730310093C300064D4F42494C45C5000431303234C60080
Something human readable like this:
Code:
SW01 MOBILEÅ 1024
So first 25 Bytes are for header...
Then 128 Bytes...
Hmmm... 128 Bytes could be RSA 1024 encrypted...
Best Regards
Factory Production Mode
This seems interesting... for me...
Tested on XXJEB...
If I play with Developer Commands... for instance:
Code:
> *> cmd="[B]CheckFPM[/B]"
> DevGetHomeDLFlag : Address(0x1dcc0000) flag(0xffffffff)
> RbmCHCheckHomeDLFlag : FLAG value=0x8,result=0
> *> return value = -1 (0xFFFFFFFF)
Code:
> *> cmd="[B]EnableFPM[/B]"
> DevGetHomeDLFlag : Address(0x1dcc0000) flag(0xffffffff)
> DevSetHomeDLFlag : Address(0x1dcc0000) flag(0x0000fff7)
> DevGetHomeDLFlag : Address(0x1dcc0000) flag(0x0000fff7)
> RbmCHEnableHomeDLFlag : FLAG value=0xfff7,result=1
> *> return value = 1 (0x00000001)
and...
Result is, after next Boot Wave starts with this funny Screen blue, then green... known by wrong key combination...
If I have changed to Qualcomm before... I can also write NV items via QPST...
Maybe here are more funny Flags possible... Check in JTAG dump at 0x1DCC0000...
Best Regards
I have found reason, how Wave checks "valid" apps_compressed.bin... also Boot...
Multiloader or every Flashing action writes own 512 Byte Info Block...
You can find them in 512 MB Full dump... from JTAG or from Ram Dump eXtractor:
http://forum.xda-developers.com/showpost.php?p=39658811&postcount=23
Search for this HEX value...
Code:
3412CDAB02000000
Now you can see your PC name... and your Country too...
your own IP address is also stored...
The other data are from last 1024 Bytes from boot_loader.mbn and apps_compressed.bin... parts of it... later more...
Sometimes I can see this... no idea yet why... or what:
Code:
Init Case 2
or
Code:
C#O#D#E Set
Hmmm... if I see this about Code... searching for and I find this in Boot...
Code:
Samsung:UNLOCK-KEY:/Security/Disabled
Fixed one for Samsung 3G platform. This string should be long ecnough maximum length is 128 bytes
[B]A#D#D#R[/B] Set C#O#D#E Set
Hmmm, will try later...
Anyway, with this I have solved my BIG problem after M210S Firmware...
For now only with JTAG possible, but maybe later other solution... for instance via FOTA...
Best Regards
Code:
gHostInfo.pComputerName =
gHostInfo.pIP =
gHostInfo.pLocation = Germany
gHostInfo.pToolVer =
gHostInfo.uDatePC =
Nand Read ECC count 0, Retry total count 0
=================================
BootDebugBuffNandWrite
=================================
Taken from S8000 Jet dump...
Here more clear what Multiloader writes from your private data...
Best Regards
I'm trying to remove this from MultiLoader V5.67.exe...
Found in .exe
Code:
GetLocaleInfo
GetComputerName
Leads to kernel32.dll ...
Maybe I can find something else...
GetDateFormat crashes Multiloader...
Also
GetCalendarInfoA
To change into Set... I think its dangerous not to kill my Windows...
Best Regards
Edit 1.
GetComputerNameW for Unicode instead GetComputerNameA
Now Multiloader only writes first Character of your Computername... :angel:
Back to the Info Block with 512 Byte....
With Command PrtSecBoot
Code:
> SecBoot : slot num(2), mass production(0), verSecurity(2), slot age(3)
> SecBoot : invalid binary key detected
> SecBoot : slot age(3) Usb Version("S8530+XX+LA1"), usb age(1), Usb Creation time stamp "42/01/05 10:05"
> SecBoot : Code Version(""), code age(1), Code Creation time stamp ""
> SecBoot : Code Download device time("00/01/01 00:00:GMT"), host PC time("43/06/06 15:23:GMT")
> SecBoot : Used Downloading Tool is FastMultiLoader 0 5.6.7
> SecBoot : Download hostname("[COLOR="Red"][B]yourPCname[/B][/COLOR]"), location("Germany"), ip(1x3.1x3.9.xx)
> SecBoot : SysInfo change device time("00/01/01 00:00:GMT"), host PC time("00/01/01 00:00:GMT"), tool ver(""), change Method(0), age(0)
In this Info Block are stored 2 RSA 512 Signatures from Boot and 1 from apps_compressed.bin... from apps_c the second RSA 512 Sig... see here:
http://forum.xda-developers.com/showpost.php?p=38088383&postcount=68
I was able to try few things...
I can manipulate
verSecurity(2), slot age(3)
Click to expand...
Click to collapse
But tried to find
mass production(0)
Click to expand...
Click to collapse
tool ver("")
Click to expand...
Click to collapse
Here I can see Init Case 2... so this should be position for ... also:
C#O#D#E Set
I think this is set, if Unlock via Code... in theory...
A#D#D#R
No idea yet...
Maybe in this Info Block it is possible to complete disable Security check...
Best Regards
Little progress...
I am able to erase/overwrite address in 512 MB OneNAND manually via sending Commands...
http://forum.xda-developers.com/showpost.php?p=42919458&postcount=31
For now only 2000+ Bytes in FOTA area tested...
Code:
7E02EE[B]00005009[/B]8000...
7E00DD[B]00005009[/B]0008...
0x9500000 from XXLA1 S8530...
Later I hope I can erase this damn Info Block to repair my S8530 with M210S Firmware... without JTAG...
Best Regards
1.
How to find IMEI in JTAG dump?
1.1
Where is EFS address ...
2.
Contains sysinfo IMEI ?
2.1
How to find sysinfo in JTAG dump?
bada 1.x if Wave alive... in Security folder...
Then it is possible to search for in dump...
But it seems not on every Firmware on same position...
sysinfo is 6560 Bytes (19A0 HEX ) ...
Will do few tests with XXJL2... maybe laaaaaater I can identify IMEI and/or sysinfo in strange unkown JTAG dumps...
Best Regards
Edit 1.
For study maybe this:
S8500_Full512MB_IMEI_38178104728484_NandEC50_Alive
Test 1.
Search by text + Unicode... (if IMEI is correct in name...)
14 Digits instead 15...
Test 2.
Converting into NV item 550 Format...
083A...
Edit 2.
Maybe little progress... to find sysinfo in dump...
Found Header before... but there is no unique Header... with Joker between 3000 or 0 hits...
Different positions maybe "randomly" or apps_compressed Version specific...
To be sure I'm now downloading XXJF5 to compare with dump...
Strange...
I have remove sysinfo from my own JTAG dump, written back dump...
sysinfo restored or rebuild or copied from somewhere else?
Because 1:1 same...
Next attempt, to remove "Info Block" from 1FFC5000...
This is so strange...
Best Regards
http://forum.xda-developers.com/showpost.php?p=43436279&postcount=6
I'm using now this as template...
Changed only at 1FFC5000...
Then flash complete XXJL2 for compare...
Result is working S8500...
sysinfo is generated different...
And Imiation_IMEI.dat file is different...
Now will try to check few "INFO Blocks"... and compare results...
if sysinfo and/or Imiation_IMEI.dat will be different..
Best Regards
1.
How to find IMEI in JTAG dump?
1.1
Where is EFS address ...
Click to expand...
Click to collapse
Sometimes my brain works slooow...
1.
IMEI is stored in Format used in QC handsets 15 + years...
Near "MP" ... Hardwareversion...
1.1
Header of EFS seems:
Code:
ABEFCDAB
So address is:
0x1E700000
In older Firmware where Hardwareversion is PV... instead MP 2.000 or MP 1.000
Here I will check later again with open eyes... to find IMEI.
For now I will do some tests with replace ... to fully start foreign JTAG dumps to learn more about sysinfo...
Best Regards
Tested with S8500 and S8530 JTAG dumps... (on S8500)...
Attached PFS contain sysinfo and Imiation_IMEI.dat...
This force apps_compressed.bin to start with IM.. not active...
If NAND/Header Info at 0x1FFC5000 will be removed/deleted...
With RIFF JTAG for instance erase 0x1FFC 0000 to end...
For repair and educational purpose... only.
How to decrypt sysinfo?
Whole file ?
Parts of it ?
Best Regards
Little progress...
https://code.google.com/p/badadroid/source/browse/trunk/FOTA
100 years later I am able to compile these examples...
Easy under Windows 7 tested with FASMARM:
http://forum.xda-developers.com/showpost.php?p=46788023&postcount=35
I have tried with XXJEE Boot... because I need bada 1 for find sysinfo for my studies...
Very interesting.
In syssec.uniqueKey.bin I have found now S/N ...
S/N is also on Label under battery... before Samsung killed Service via Kies. It was also helpfull to download Firmware...
I was ever wondering, why I am not able to find S/N...
Anyway. These FOTA examples helps me to increase my little brain.
For now tested only these:
Code:
[B]dump[/B]_netlock_info.fota
[B]dump[/B]_unique_keys.fota
nv_[B]dump[/B].fota
Next will be write_netlock_info.ASM...
Maybe this is what I think...
Yes, I know about FLOCK. But I need this for my JTAG Fullflash journey ... and for my little brain to understand how this work...
Btw.
I have no device here with SIM or Netlock...
To look into decrypted sysinfo and see the SHA1 Hashes is also possible via these FOTAs...
Thanx.
Best Regards
Few tests later...
It seems I have to play with DEcrypted sysinfo...
http://forum.xda-developers.com/showpost.php?p=47851350&postcount=49
First test failed with write_netlock_info.ASM before...
I have used DEcrypted Version, but nothing happens...
Maybe again my fault... anyway... tiny little step forward.
1 Goal is to identify sysinfo in JTAG dump... but here I need encrypted sysinfo...
Best Regards
Aha...
The reason is not only IMEI, because normally you can find IMEI in JTAG dump, but it seems Wave can not find anymore correct sysinfo... if fulldump from other Wave is flashed via JTAG.
http://forum.xda-developers.com/showpost.php?p=47851350&postcount=49
Result is working handset without IMEI... but this no problem...
Will check if now S/N is my or also gone with the other FOTAs...
But now I can flash 512 MB Fulldump WITHOUT modification of this file...
Then restore/rebuild sysinfo via bterm + correct FOTA...
Later more.
Best Regards
"Strange"...
sysinfo contain more then 1 or 2 SHA1 Hashes...
The others looks like "not available/not active" or something...
I have no handset with Lock...
I have only compared few DEcrypted sysinfo...
Simple copy and Paste not activate the Locks...
Later more...
Best Regards
Interesting...
Unique Key known from Header Info...
Stored in 512 MB OneNAND...
Is written into MBR (512 Byte) of moviNAND...
http://forum.xda-developers.com/showpost.php?p=49989727&postcount=68
If OneNAND is full erased, by JTAG RIFF for instance... Then text instead number:
Code:
PRODUCTCODEINVALID
Hmmmm, maybe this helps me later to restore sysinfo from JTAG dumps...
Best Regards
Hi all.
This thread only for developers! Only! No questions - when?!!!!!!!
This is my attempt to porting android on S8600.
I wrote custom bootloader - emmcboot, based on codeaurora LK-bootloader.
Bootloader is successfully start, work and trying to load android kernel from internal
microsd card.
Now is unsuccessfully,after type message "Uncompressing Linux... done, booting the kernel." device rebooted or stopped.
[370] Panel is power on
[370] Display initialized
[370] Display logo
[370] Waiting for modem+++
[370] Waiting for modem: Done
[370] smem ram ptable found: ver: 0 len: 6
[370] scratch: 0x8000000
[370] Starting in SD mode!
[370] SD_DETECT pin : 0x0
[380] Initializing MMC host data structure and clock!
[380] Error No. 2: Failure Initializing MMC Card!
[400] Decoded CID fields:
[400] Manufacturer ID: 27
[400] OEM ID: 0x5048
[400] Product Name: SD16G
[400] Product revision: 3.0
[400] Product serial number: 7C88FF04
[400] Manufacturing date: 2 2012
[410] Serial number -[410] serial number:
[410] partition misc doesn't exist
[410] error in emmc_recovery_init
[580]
kernel @ 208000 (4132528 bytes)
[580] ramdisk @ 1200000 (175204 bytes)
[580] cmdline = 'console=null androidboot.hardware=qcom user_debug=31'
[580]
Booting Linux
[580] smem ram ptable found: ver: 0 len: 6
[580] booting linux @ 0x208000, ramdisk @ 0x1200000 (175204)
[590] cmdline: console=null androidboot.hardware=qcom user_debug=31
Uncompressing Linux... done, booting the kernel.
source code for lk-bootloader for S8600:
https://github.com/Oleg-k/LK_BOOT_S8600
To build for S8600, type: "make -j4 s8600 EMMC_BOOT=1"
Also, i got memory dump, stage - after load oemsbl and before loading my bootloader.
as we see, oemsbl decompress and load apps_compressed.bin into memory,
starting at 0x200000.
https://www.dropbox.com/s/5wf6dp5gfgudkdc/MEM_DUMP_128MB.rar
And for for understanding boot process on MSM7x30, read this:
http://tjworld.net/wiki/Android/HTC/Vision/BootProcess#BootProcess
Welcome back my friend ))
If you able to port,I 100% will buy S8600
Good Luck
I was actually going to ask you what happened to the wave 3 port. Anyway Welcome back . But a question why don't you help rebellos and volk in the wave and wave II porting ? So the porting can be a bit more better. Just my question. :good:
Sounds interesting.
1.
You found ELF files for S8600 Boot ?
2.
You found way without JTAG, or JTAG is needed to write your Boot?
Thanx in advance.
Best Regards
CONFIG_DEBUG_LL
and
CONFIG_EARLY_PRINTK
plx <3
it's my current config for my kernel:
adfree said:
Sounds interesting.
1.
You found ELF files for S8600 Boot ?
2.
You found way without JTAG, or JTAG is needed to write your Boot?
Thanx in advance.
Best Regards
Click to expand...
Click to collapse
No, don't ELF files for S8600, i wrote new bootloader for boot linux kernel.
Now i use JTAG, but if we find a way to cript my bootloader,like appsboot.mbn,we will use regular multiloader
So cool!
http://forum.xda-developers.com/showthread.php?t=1443575
Blowfish encryption
Click to expand...
Click to collapse
Maybe PlatformDownloader_S8600_KI5.exe maybe have unsecured Boot...
But I can't flash nor I have connected my S8600 with RIFF...
TPs seems to small for my big Fingers...
Best Regards
oleg_k said:
it's my current config for my kernel:
Click to expand...
Click to collapse
Thanks. I'd check debug macros and debug uart configuration. There's few UART ports in it, and maybe kernel is printing to the wrong one... though this wouldn't explain why kernel unpacker is printing something (Uncompressing and booting comes already from zImage) - this would indicate that debug port number is correct. Are you sure that kernel and ATAGs location is correct, and RAM is set up properly by LK? Maybe something bad happens when kernel proceeds to enabling MMU and caches... I'm pretty clueless. :<
I collected some links I found useful in this article: http://xda-university.com/as-a-developer/porting-android-to-non-android-devices
Especially interesting for you might be last link in "Custom bootloader" section.
No, don't ELF files for S8600, i wrote new bootloader for boot linux kernel.
Now i use JTAG, but if we find a way to cript my bootloader,like appsboot.mbn,we will use regular multiloader
Click to expand...
Click to collapse
For S8500 I found way to write direct into OneNAND at:
Code:
0x0010 0001
No need to encrypt something...
With Multiloader... choose ETC.
http://forum.xda-developers.com/showpost.php?p=37229969&postcount=37
S8600 not tested...
This is far far away from perfect... but maybe helpfull.
Need someone who is able to remove restriction from ML to use lower adresses then 0x10000...
I was only able to change text strings... in ML...
Best Regards
On first page i posted bootloader source and memory dump, stage - after load oemsbl and before loading my bootloader.
To Adfree,
S8600 don't use OneNAND, used EMMC flash memory (like sd-card).
Today I've found S8600XXKI9.zip
I have forgotten this Firmware... but I have now short compared with Bootfiles from XXKJC... BIG differences... So I think this should be nearly identical with PlatformDownloader_S8600_KI5.exe
Still unsolved to decrypt or extract content of:
PlatformDownloader_S8600_KI5.exe
and
PlatformDownloader_S8600_KJ7.exe
Best Regards
Not my S8600... but user tried PlatformDownloader_S8600_KJ7.exe
It seems it was wrong Partition Table aka partition.bin...
Code:
Boot Binary Download Start Ch[0]
Appsboot 338.7KB OK[1.1s]
OemSbl 1757.7KB OK[1.8s]
ERR : NAK_FLASH_ERROR 0
Error : [B]partition Write[/B] [0.2s]
ERR : NAK_FLASH_ERROR 0
Download Start Ch[0]
Amss 16654.3KB OK[15.6s]
Apps 29622.3KB OK[54.1s]
_Open_Europe_Common 40370.2KB OK[73.5s]
(Low) 2980.3KB OK[1.9s]
ERR : NAK_INVALID_CONTENT 0
ERR : _Open_Europe_Common Erase
Now S8600 ask for QHSUSB_DLOAD
My first idea is Qualcomm QPST now...
Or maybe if Driver used, then Multiloader will work again... for second attempt..
Found only 64 Bit Driver yet... not tested nor Thread... only attachment...
http://forum.xda-developers.com/attachment.php?attachmentid=631288&d=1308601930
Will check also QPST to check what is needed...
Best Regards
Edit 1.
More Driver...
http://forum.xda-developers.com/showpost.php?p=21911621&postcount=2
Okay...
It seems for QPST fsbl.mbn is missing...
I can remember from old MSM6250 handsets it is mandatory to have all files for QPST... because otherwise you need JTAG...
Important...
Qualcomm not use Encryption for QPST files...
This is Samsung thingie + "end.bin" last 1024 Byte...
So decrypt all Bootfiles and cut last 1024 Byte...
For fsbl.mbn I will check JTAG dump from S8600...
Best Regards
Edit 1.
http://forum.xda-developers.com/showthread.php?t=1367055
downgrade_WM6_boot.zip contain fsbl.mbn ... maybe as example...
http://forum.gsmhosting.com/vbb/f634/htc-desire-s-qhsusb_dload-driver-1436354/
Found this...
Here is also fsbl.mbn maybe not available... or...
But maybe if we can attach such S8600 we can see few infos...
Best Regards
Edit 1.
About QPST Version contain this eMMC...
Code:
4. RELEASE NOTES
...
10/27/11 QPST [B]2.7.378[/B]
1) Add support for QSC11x5 CDMA only (4073) and CDMA+GSM (4074).
2) Fix problem with eMMC Software Download not correctly patching addresses > 8 GB.
10/13/11 QPST 2.7.377
1) Fix crash when QPSTServer.config are NULs (bad format).
2) Add model ID 4072 = "APQ8064". Apps processor only, no service programming.
3) Change flash programmer name from nprg9615.hex to nprg9x15.hex.
4) Add emergency download support for user partitions.
5) Fix case where user partition download fails if the flash programmer is on a file share.
6) Fix error case when add port is used but no port is specified.
7) Fix case where restoring an EFS file doesn't work if the file was modified by QXDM.
8) In Service Programming BC SMS fix case where if user enters 32 as the service type it get written to NV as 4096.
9) Fix case where a phone will stay in "no phone" state if the phone takes > 20 seconds to reboot.
10) Take care of cases in eMMC Software Download where we try to lock the disk volume but the drive letter isn't available.
11) Fix "server busy" issue when a device connects but it's modem isn't running.
12) Insert more status message in Memory Debug app so that we can see why fast unframed dump failed.
8/17/11 QPST 2.7.375
1) Add support for MDM9615 (model 4070). Rename model 4068 to 7627A-ANDROID from SURF7627A.
Add model 4071 (7627A-WinMob). Add 1x/UMTS service programming to 4068 and 4071.
2) eMMC Software Download: Don't try to lock volume if drive letter not present.
Devices that use GPT will not mount and get a drive letter assigned.
7/22/11 QPST 2.7.374
1) Added missing file to installer to fix Service Programming problem in 2.7.373.
2) For eMMC Software Download, abort the download if a sparse="true" directive is present.
Sparse files cannot be downloaded with QPST, only with fastboot.
3) Began the process of moving QPST application and server settings from registry to
configuration files.
4) Added more error checking to EFS Explorer file drop code.
7/5/11 QPST 2.7.373
1) Add support for SURF8960 model ID 4069.
2) Fix issue with Port Enable/Disable for IP Ports.
3) NAND Software Download: Correct flash programmer descriptions for 7225A, 7625A, 7227A, and 7627A.
4) Roaming List Editor: Added two new bands LTE 24 and LTE 25.
5) eMMC Software Download:
- Fix problem where some file names print as "(null)".
- Add support for Meta Build contents.xml file ("Build Contents"). The contents file will provide the path for the
rawprogram and patch files, extra search paths, and names of flash programmer and boot image files.
- Ignore unexpected elements in schema.
- Support zeroout directive to zero parts of partitions.
- Allow usage by app of "orderly" as well as surprise removal storage devices.
- Add support for computations in the <patch> (CRC32 for GPT support), <program>, and <zeroout> directives.
6) EfsExplorer:
- Enable reset button in Efs Explorer even if target not in offline mode.
- More text description in Mode column for Efs Explorer
- Modify the list context menu of Efs-Explorer.
- If the proposed item file size copy is > 2048 bytes, warn the user and bail out.
...
Adfree,
link pls for founded S8600XXKI9.zip
link pls for founded S8600XXKI9.zip
Click to expand...
Click to collapse
http://hotfile.com/dl/145796951/79ecec6/S8600XXKI9.zip.html?lang=de
Try this. If not then I search again...
About fsbl.mbn...
I have searched for fsbl_hw.c string in 4 GB JTAG dump SAMSUNG_GTS8600_FullFlash.bin...
Can not find so I think fsbl is not or in other area...
About your Memory Dump FROM_MEM_0_128MB.bin
I am not 100 % sure but maybe read problems...
Short tried to extract Cert, but string Qualcomm is not written correct...
Q5alcomm1
qualcoem.com
Click to expand...
Click to collapse
Best Regards
I try to read again memory dump )
thanks for links...
Also,
i find,what samsung used OKL4 Microkernel 3.0 (maybe 4.0)
http://wiki.ok-labs.com/Release/3.0
About ver 4.0 --
The OKL4 Microvisor is designed from the ground up as a high-performance mobile virtualization platform. It is a microkernel-based embedded hypervisor - called a Microvisor, with a small footprint and the right combination of performance and hardware support to target mobile telephony use. The OKL4 Microvisor 4.0 is distinguished by supporting mobile virtualization, componentization, and security, enabling a new generation of applications and capabilities with impact across the mobile ecosystem.
OKL4(with Qualcomm RTOS) also used in modem AMSS
http://forum.xda-developers.com/showthread.php?t=1829915
Need overview/list with Firmware packages with Bootfiles included...
Here this is what I have...
Later I will compare if difference...
Code:
XXKI9
XXKJC
S8600BOKJ1_TPLKJ1.rar
S8600BOKK6_S8500TPLKK7_T-Mobile.rar
S8600JPKK2_S8500OJPKK2_OJP.rar
S8600ZCLA1.7z
S8600NAKL1_S8600EPLKL1
Best Regards
Last Update : August, 19, 2014
Hi,
I'm still try to bypass the MMU protection.
I have fixe a lot of bug, like memory misalignment, bad adresses allocation, dtb correction, etc...
Last sources and binaries here :
kexec-tools V11.zip : http://forum.xda-developers.com/attachment.php?attachmentid=2902912&stc=1&d=1408401794
kexec-tools binaries V11.zip : http://forum.xda-developers.com/attachment.php?attachmentid=2902913&stc=1&d=1408401794
Sorry, i have always 13 sec reboot after new kernel boot.
"cpu_proc_fin" use a "mcr p15" to init cache and proc that cause freeze.
I try to find solution for that.
Last Update : June, 22, 2014
Hi,
My sources are horrible... but i give something new.
This kexec is for stock kernel only (tested on .757). I thinks theses sources work on other kernel too.
In "kexec-tools V10.zip", you have all my sources. It's highly recommended to mod them to have something OK.
In "kexec binaries.zip", you have binaries to install
=> "kexec_load.ko" and "procfs_rw.ko" must be placed in "/system/lib/modules" folder with "chmod 777"
=> "kexec" must be placed in /system/bin" folder with "chmod 777"
=> cd /system/lib/modules
=> insmod kexec_load.ko
For sources :
Mod and adapt all you want, it's free.
You have 2 scripts in Zip : "./compil-kexec" in "kexec-tools" folder to rebuild and send in device directly (install Adbtcp on device and send by tcp with : adb connect xxx.xxx.xxx.xxx) = work perfectly with me.
"scriptZ1" is for compil stock kernel or another kernel (doomlord kernel for eg)
You must rename "custom_final_files" folder after compil to "final_file" manually ; You can have guest kernel in "custom_final_files" and stock kernel in "final_files" for "kexec-tools" path ... Don't mix a guest and host kernel please ^^
I am tired... i let you test and say if it's ok for you...
Thank a lot to munjeni for his help.
kexec-tools V10.zip : http://forum.xda-developers.com/attachment.php?attachmentid=2811994&stc=1&d=1403456181
kexec binaries.zip : http://forum.xda-developers.com/attachment.php?attachmentid=2811995&stc=1&d=1403456181
Last Update : November, 23, 2013
Hi,
For few days now, i haven't no more kernel panic with my kexec.
I have fixed few stuffs into sources, and add a lot.
These adds are, to include a "dt.img" image file into kexec load process.
This image file is a "device_tree" image to match hardware to software.
So, i assume to don't include atags into boot process, but pass bootloader informations by this DT.
I have programmed a little scan memory to found dynamicly all magic tags, because i found 3 device_tree into memory (magic is "0xd00dfeed").
These 2 device_tree are echo from first and nice structure.
The boot process need to have informations from this DT, and need all informations to initialize hardware (no HDW initialisation by the kernel)
I must first fix issues ; Regroup zImage and dt.img into memory to load a solid bloc to kexec_load module to boot into, and second, fix an offset i can't explain, 0x800 in memory causing misalignment memory
Keep tuned..
Last Update : November, 17, 2013
Hi everybody,
My kexec-tools work for Sony Xperia Z1 stock kernel "3.4.0-perf"
This tools can work on all locked bootloader for all locked device, not only Sony or Z1 models.
This kexec-tools add a kexec_load kernel module (LKM) and use a driver to grant a communication between "kexec" user program and kexec_load.ko module
what is for ?
"kexec" user program load in memory a custom kernel in zImage format, but can load ".tar" image too
This user tool load ramdisk in memory if necessary
This tool is for this purpose only, and don't keep in memory the custom kernel at device reboot.
It is a "user" program, not a "kernel" extension... So, to really do the magic, we need the host kernel (stock sony locked kernel) have a kexec_load capability to reboot in a new gest kernel (custom kernel).
Infortuntly, stock kernel don't have kexec_load capability.
Sony have compiled his stock kernel without this option, and "standard" kexec-tools "need" this option to work.
To see all system call capability of kernel, you can run theses command :
Code:
echo 0 > /proc/sys/kernel/dmesg_restrict
echo 0 > /proc/sys/kernel/kptr_restrict
cat /proc/kallsyms
Do all grep you want here.
The "echo 0" "restrict" is here to unmask logical adresses to "system calls"
Like you can see, "__NR_kexec_load" capability isn't here.
To add kexec_load capability in stock locked kernel, we need to add manualy a kernel module wich add this function into the kernel.
Why ? Because the way to keep in memory a custom kernel need to know a lot of parameters, and keep a specific memory range alive at reboot.
Only kernel can do this.
All user program will be terminated at reboot.
"Standard" kexec_load.ko module use a method to implement the "__NR_kexec_load" function in system call table.
Since 2.6.0 kernel, linux for security reason, have locked in memory the "system_call_table" ; No more add or modification is authorized.
If kexec tool try to add a value, "kexec_load" for us, we causes a kernel panic, and reboot device.
For this reason, i have modify kexec user program and kexec_load module to implement a driver to talk to each other.
this driver replace syscall method, and we no more need to use a system call table.
For this reason, this tool is now compatible with modern kernel like our "3.4.0"
For this reason, this tool must work for other device (Xperia X, P, S, etc...) and another brand
For this reason, if kernel is locked, we can bootstrap to run a new kernel.
Installation
First, you can compil your own kexec tool
Here, sources : http://forum.xda-developers.com/attachment.php?attachmentid=2397299&stc=1&d=1384689174
And here, the binaries : http://forum.xda-developers.com/attachment.php?attachmentid=2397305&stc=1&d=1384689406
(it's not a cwm zip, i have no time to create an installer for now ; use "./compil-kexec" if you want an automatic install)
Install *.ko in /system/lib/modules
Install kexec and kdump in /system/bin
Grant with "chmod 777"
Unzip in kexec-tools folder
Install a toolchain (sudo apt-get install gcc-arm-linux-gnueabi)
launch => ./compil-kexec
what's all
This script can do everythinks for you
- Compilation of tools
- Compilation of modules
- installation in device
This script can compil for every brand you have.
Except you must remove or adapt the patch (see below why)
Patch ??
This patch is because a module must be compiled in the same time the kernel himself.
For this reason a "vermagic", an identifier, is used by system to block every module not compil with kernel
Some custom kernel bypass this to authorize every modules.
But for stock kernel, it is not allowed.
You can easely strapp this by busybox.
"busybox modprobe" for help
"-f" to force load without vermagic
To see this vermagic :
Code:
# uname -r
This "uname -r" must be the same that
Code:
# strings kexec_load.ko | grep vermagic
vermagic=3.4.0-perf-g66807d4-02450-g9a218f1 SMP preempt mod_unload modversions ARMv7
If you want use automaticaly this vermagic, you can modify into the custom kernel this file :
Code:
"include/config/kernel.release" and add :
"3.4.0-perf-g66807d4-02450-g9a218f1"
This file will be use at module compil to match the vermagic.
Infortunatly, it is not enought. :silly:
The infamous "no symbol version for module_layout"
When a module compil is created, it use symbols link to system call function, translate by adresses
Theses symbols are not at same physical adresses in stock kernel and modules (compiled from DooMLoRD kernel).
So, theses adresses must be convert into modules itself to match with stock symbols adress.
A patch is needed.
If you use my script, modules are automatically patched.
Here patches :
Code:
sed -i 's/\x32\x76\x86\x29/\x72\xFF\x5E\x20/' procfs_rw.ko
sed -i 's/\x32\x76\x86\x29/\x72\xFF\x5E\x20/' kexec_load.ko
sed -i 's/\xBB\xD0\xF8\x4D/\x0E\x1C\x63\x77/' kexec_load.ko
sed -i 's/\xA6\x26\x81\x1A/\xD4\x56\x02\x7E/' kexec_load.ko
sed -i 's/\xA3\xD1\xEC\x96/\xEC\x43\x28\x1A/' kexec_load.ko
sed -i 's/\x8C\xE6\x6A\x5F/\x3D\xDF\x02\xF2/' kexec_load.ko
sed -i 's/\x3E\xF3\xEF\xE9/\x18\x7F\xA6\x8A/' kexec_load.ko
sed -i 's/\x8B\xD2\x92\x10/\xC8\x19\x08\x9C/' kexec_load.ko
sed -i 's/\x1C\xE8\x18\xE1/\x7C\x71\x9E\xEF/' kexec_load.ko
sed -i 's/\xAB\x2C\x2F\x8B/\x8E\xD7\x63\xC0/' kexec_load.ko
sed -i 's/\xF5\x62\xAA\x4B/\x34\x80\x1B\x74/' kexec_load.ko
sed -i 's/\x00\x52\xD6\xD7/\x6F\x80\x91\x20/' kexec_load.ko
sed -i 's/\x4F\x77\x57\x6A/\x0C\x57\xC7\x63/' kexec_load.ko
sed -i 's/\xCA\x2F\x65\x71/\x92\xB8\x7F\x53/' kexec_load.ko
sed -i 's/\x0F\xD0\xA0\x91/\xFA\x80\x15\xB4/' kexec_load.ko
sed -i 's/\x29\xA0\x6D\x48/\x6C\x6B\x96\x54/' kexec_load.ko
sed -i 's/\x6D\x1F\x1F\x37/\xCC\x5E\x79\x8B/' kexec_load.ko
sed -i 's/\xFD\x23\xD0\xFB/\xE3\xE3\x68\x52/' kexec_load.ko
You can use hexedit or hexdump to see these adresses :
Code:
hexdump kexec_load.ko | grep ff72
0003d50 b0b0 80ac ff72 205e 6f6d 7564 656c 6c5f
how does it work ?
# kexec --help
For kexec help... nothing more to say.
# lsmod
List loaded modules... You must see
kexec_load 31369 0 - Live 0x00000000 (O)
# rmmod kexec_load.ko
Remove kexec_load module from memory.
# grep kexec /proc/device
To see installed driver.
You must see :
100 kexec_driver
First number is "major" number to identify your driver in system.
# mknod /dev/kexec_driver c 100 0
Install driver.
Major number (here 100), is important for module.
This Major must be the same between module and driver.
By default, 100 is used.
# insmod kexec_load.ko
To install "LKM", kexec_load kernel module.
If another Major is needed, you can use "insmod kexec_load.ko 101" for Major 101
You can use "modprob" if you want, but you must configure the module folder.
How kexec and module exchange informations ?
By the driver.
Normal output for a kernel module is to write in "dmsg" file.
To see kernel output, launch this command :
Code:
# dmesg
To see last kernel log, see in :
Code:
# cat /proc/last_kmsg
For kexec module, this normal way still exist, and give a lot of informations, but to speak with, you must use the driver.
/dev/kexec_driver
You can yourself test communication:
Code:
# cat /dev/kexec_driver
You can send kernel by this communication channel.
Type following commands for help
=> echo help >/dev/kexec_driver
=> dmesg | grep Kexec
Code:
# echo help >/dev/kexec_driver
# cat /dev/kexec_driver
Last command : 'help'
Please type following command :
=> dmesg|grep Kexec
Every command send into driver is receive by kexec_load.ko module and running into the kernel.
The answer can by read thru the driver
Here, you can see that normal way to see messages is allway dmesg.
Code:
# dmesg|grep Kexec
<4>[15050.521628] Kexec: Starting kexec_module...
<6>[15050.521656] Kexec: kexec_driver_contener allocation
<6>[15050.521673] Kexec: kexec_memory_buffer allocation
<4>[15050.521691] Kexec:----------------------------------------------------
<4>[15050.521710] Kexec: kexec_driver created with major : '100'
<4>[15050.521728] Kexec: Please, prepare by typing the following commands :
<4>[15050.521746] Kexec: => mknod /dev/kexec_driver c 100 0
<4>[15050.521761] Kexec: => cat /dev/kexec_driver
<4>[15050.521775] Kexec:-----------------------------------------------------
<4>[15050.521791] Kexec: For help
<4>[15050.521803] Kexec: => echo help >/dev/kexec_driver
(...)
I have add a lot of informations to help to configure kexec.
rdtags, atags ??
Not sure for this part of kernel.
"atags" is the most used method to bootloader to parse commands and informations to kernel at boot.
"atags" is a form of structure in memory to organise informations.
At boot, a address chain is created and can be compulse in /proc/atags file.
This file is read only system.
"rdtags" is another way to bootloader to parse information to kernel.
"rdtags" is not stocked in "/proc"
But, as i see, stock kernel can use "atags" from bootloader.
kexec can substitute bootloader function to create fromscratch a atags chain, and parse to new kernel.
I have change this part to stock atags in "/data/atags", and reuse or change if need.
If this don't work, i must create a rdtags chain to replace atags ; It's not a hard work.
Status
For the moment, kexec tools works.
=> Phase one OK.
I can start Phase Two : new kernel patch.
If you want to help me...
Actually, load a custom kernel and boot into with kexec tools work.
But at boot into, a kernel panic occurs.
It seems, a part of kexec patch is missing in custom kernel.
Hi new thread created for kernel kexec development.
Status: not working: wrong values for mem defines under the kernel is giving segmentation fault as its attempting to write to memory areas that are currently being used byyyyy the system
Instructions:
Make kernel compatible?:
1. Download kernel diff patch from below
2. Terminal - diff patch > diff.txt
How to use:
1. Download kexec-tools (kexec binary) from below
2. Copy into system/bin directory and give it executable permission
3. Download compatible kernel
4. Terminal - kexec --load-hardboot zImage --initrd=initrd.img --mem-min=0x20000000 --command-line="$(cat /proc/cmdline)"
kexec -e
Download links:
Kexec tool- https://db.tt/8DZXQ9eV
Ramdisk firmware 1.548 : https://db.tt/8DZXQ9eV
zImage (kernel):
Source code:
Kernel diff patch: https://db.tt/Xi2htT7Q (currently contains wrong values for mem defines)
Kexec-tools: https://db.tt/I22ofr3b
Special thanks: @delewer @krabappel2548
Reserved
Please move this thread to Xda Devdb, then I can also edit first post etc if I find new stuff
Sent from my C6903 using xda app-developers app
krabappel2548 said:
Please move this thread to Xda Devdb, then I can also edit first post etc if I find new stuff
Sent from my C6903 using xda app-developers app
Click to expand...
Click to collapse
Devdb?
Pm me i dont know what Devdb is lol
Recieved segmentation fault with delewers calculated mem values too
We need to write to memory where we have write access to, maybe lockedbootloader is not allowing us to write? Orrr we are just writing to wrong area of memory
If kexec works on the Z1, can it be ported over to Xperia Z/ZL/T/Ultra? I believe they don't all share the same processor.
Shaky156 said:
Devdb?
Pm me i dont know what Devdb is lol
Click to expand...
Click to collapse
Shaky156 said:
Recieved segmentation fault with delewers calculated mem values too
We need to write to memory where we have write access to, maybe lockedbootloader is not allowing us to write? Orrr we are just writing to wrong area of memory
Click to expand...
Click to collapse
I'll discuss with Kali- today if he's available.
Knucklessg1 said:
If kexec works on the Z1, can it be ported over to Xperia Z/ZL/T/Ultra? I believe they don't all share the same processor.
Click to expand...
Click to collapse
Doesn't need to be same processor, can be ported
Sent from my C6903 using xda app-developers app
Knucklessg1 said:
If kexec works on the Z1, can it be ported over to Xperia Z/ZL/T/Ultra? I believe they don't all share the same processor.
Click to expand...
Click to collapse
Yes it wont matter much, since its not s800 it should be easier for you guys , take the kexec-tool use that, implement the patch write to the correct mem addresses which is free, it should boot if you guys have issues let me know,
I need to calculate the correct addresses.
Ive noticed s800 uses a dt.img, might need to modify kexec-tool to support dt.img, not sure what dt.img does yet, only know it holds values
Shaky156 said:
I need to calculate the correct addresses.
Ive noticed s800 uses a dt.img, might need to modify kexec-tool to support dt.img, not sure what dt.img does yet, only know it holds values
Click to expand...
Click to collapse
the dt.img is needed by the kernel to boot, so I guess we need to load that too in kexec.
EDIT: people that wanna try add kexec patch to their kernel, check github: android_kernel_sony_msm8974/commits/kexec
krabappel2548, i have compil your kernel by my script (fromscratch)
My script (instruction in "DoomLord Build kernel thread" : scriptZ1 http://forum.xda-developers.com/attachment.php?attachmentid=2346163&d=1382568778
(for thoses who want to help us...)
You have a little mod to do here (bad compil) :
In "sound/soc/msm/qdsp6v2/rtac.c"
you must change
#include <q6voice.h>
by
#include "q6voice.h"
btw : no more ideas to load kexec for the moment ...
delewer said:
krabappel2548, i have compil your kernel by my script (fromscratch)
My script (instruction in "DoomLord Build kernel thread" : scriptZ1 http://forum.xda-developers.com/attachment.php?attachmentid=2346163&d=1382568778
(for thoses who want to help us...)
You have a little mod to do here (bad compil) :
In "sound/soc/msm/qdsp6v2/rtac.c"
you must change
#include <q6voice.h>
by
#include "q6voice.h"
btw : no more ideas to load kexec for the moment ...
Click to expand...
Click to collapse
Sorry, I'm trying to get caught up on the forum, but what seems to be the current standing issue to get kexec working?
Knucklessg1 said:
Sorry, I'm trying to get caught up on the forum, but what seems to be the current standing issue to get kexec working?
Click to expand...
Click to collapse
Read the OP
Status paragraph
Memory regions
00000000-07afffff : System RAM
00008000-00b79383 : Kernel code
00d04000-00f0cddb : Kernel data
0ff00000-779fffff : System RAM
7ff00000-7ff3ffff : rdtags_mem
7ff80000-7ffa0fff : last_kmsg
7ffa1000-7ffa5fff : last_amsslog
System RAM MEM = 00000000
So --min-mem=0x20000000
Now need to find a free memory area thatll allow us to write and hopefully the mmu/pmu on locked bootloader wont cancel it
@delewer? @DooMLoRD @kali @Bin4ry
I know I shouldn't disturb, but i must ask: if You achieve Your goal, would it be possible to port it to devices like Xperia P, S, T, U and other NXT? It would be great, many ppl are ready to give a prize for it. Thanks in advance, good luck and sorry again.
Sent from my LT22i using xda app-developers app
king960 said:
I know I shouldn't disturb, but i must ask: if You achieve Your goal, would it be possible to port it to devices like Xperia P, S, T, U and other NXT? It would be great, many ppl are ready to give a prize for it. Thanks in advance, good luck and sorry again.
Sent from my LT22i using xda app-developers app
Click to expand...
Click to collapse
These devices are not 2013 devices, they arent s800 socs, so they are much easier to do, simply take the kexec-tools from op, implement the patch in your kernel, write the correct memory values for your specific device and execute in terminal via the command in op, minmem depends on your device too, good luck
I think some1 tried it already, but it works only for unlocked devices... Anyway, thanks for help.
Sent from my LT22i using xda app-developers app
king960 said:
I know I shouldn't disturb, but i must ask: if You achieve Your goal, would it be possible to port it to devices like Xperia P, S, T, U and other NXT? It would be great, many ppl are ready to give a prize for it. Thanks in advance, good luck and sorry again.
Sent from my LT22i using xda app-developers app
Click to expand...
Click to collapse
Does doing this require having an Unlocked Boot loader prior to implementation?
Sent from my C6603 using xda app-developers app
A few informations about kexec-tools debug
in kexec.c
Fonction :
if (file_type.load(argc, argv, kernel_buf,
kernel_size, &info) < 0) {
fprintf(stderr, "Cannot load %s\n", kernel);
return -1;
}
With a forced execution of kexec (bypass error to see...)
--mem-min=0x90000000
kernel: 0xb6b9d008 kernel_size: 3e9340
debug: 1 - after get memory range
debug: 2 - after type test
debug: 3 - after type test
debug: 4 - after info.kexec
debug: Focus 1 - argc '5' ; argv 'be856774' ; kernel_buf 'b6b9d008' ; kernel_size '3e9340' ; info 'be856548' ; i '1' ; file_type.name 'zImage'
Could not find a free area of memory of 3f1340 bytes...
Cannot load zImage
debug: 10 - before trampoline
debug: 11 - after trampoline
debug: 12 - before segment load
debug: 13 - after segment load
debug: 8 - before sort_segment
debug: 9 - after sort_segment
debug: 6 - before purgatory
debug: 7 - after purgatory
kexec_load: entry = (nil) flags = 280004
nr_segments = 0
kexec_load failed: Function not implemented
entry = (nil) flags = 280004
nr_segments = 0
debug: 5 - return result : ffffffff
With a forced bypass on file_type.load , we have this :
--mem-min=0x20000000
debug: Focus 1 - argc '5' ; argv 'bef18774' ; kernel_buf 'b6bc7008' ; kernel_size '3e9340' ; info 'bef18548' ; i '1' ; file_type.name 'zImage'
Segmentation fault
delewer said:
A few informations about kexec-tools debug
in kexec.c
Fonction :
if (file_type.load(argc, argv, kernel_buf,
kernel_size, &info) < 0) {
fprintf(stderr, "Cannot load %s\n", kernel);
return -1;
}
With a forced execution of kexec (bypass error to see...)
--mem-min=0x90000000
kernel: 0xb6b9d008 kernel_size: 3e9340
debug: 1 - after get memory range
debug: 2 - after type test
debug: 3 - after type test
debug: 4 - after info.kexec
debug: Focus 1 - argc '5' ; argv 'be856774' ; kernel_buf 'b6b9d008' ; kernel_size '3e9340' ; info 'be856548' ; i '1' ; file_type.name 'zImage'
Could not find a free area of memory of 3f1340 bytes...
Cannot load zImage
debug: 10 - before trampoline
debug: 11 - after trampoline
debug: 12 - before segment load
debug: 13 - after segment load
debug: 8 - before sort_segment
debug: 9 - after sort_segment
debug: 6 - before purgatory
debug: 7 - after purgatory
kexec_load: entry = (nil) flags = 280004
nr_segments = 0
kexec_load failed: Function not implemented
entry = (nil) flags = 280004
nr_segments = 0
debug: 5 - return result : ffffffff
With a forced bypass on file_type.load , we have this :
--mem-min=0x20000000
debug: Focus 1 - argc '5' ; argv 'bef18774' ; kernel_buf 'b6bc7008' ; kernel_size '3e9340' ; info 'bef18548' ; i '1' ; file_type.name 'zImage'
Segmentation fault
Click to expand...
Click to collapse
Did you compile this kexec yourself? Or did you get this from krapabbel? I issued krapabbel to compile a new debug version have gave him the code but never heard back from him :/
Anywayz so cannot find free memory is the issue