[DEV] Changing Splash Screen - Gen9 Android Development

So, I was doing some research on how you can change it and I ended up finding this in initramfs/etc/scripts/init_sde:
Code:
# Show a nice boot image
case "$PRODUCT_NAME" in
A80S)
BOOT_IMAGE=$BOOT_IMAGE_BASE-1024x768.gz
;;
A80H)
BOOT_IMAGE=$BOOT_IMAGE_BASE-1024x768.gz
;;
A101S)
BOOT_IMAGE=$BOOT_IMAGE_BASE-1280x800.gz
;;
A101H)
BOOT_IMAGE=$BOOT_IMAGE_BASE-1280x800.gz
;;
esac
$ZCAT $BOOT_IMAGE > /dev/fb0
And at the top of that file:
Code:
BOOT_IMAGE_BASE="/SDE"
Now, if we could either find those gz files and edit them or extract and link the file to the right place, we'd change it
Any ideas?

Well, first idea would be using root explorer to check, if /SDE folder exists. If not, rooting stock rom, like 4.0.5, with universal rooting tools, and check if it's visible in that rom. I mean, root the stock rom which you install with aos.

julle131 said:
Well, first idea would be using root explorer to check, if /SDE folder exists. If not, rooting stock rom, like 4.0.5, with universal rooting tools, and check if it's visible in that rom. I mean, root the stock rom which you install with aos.
Click to expand...
Click to collapse
Hi
I'll save you the trouble as you won't find an SDE directory anywhere on a rom, "SDE" is just the prefix used for the gz file, e.g SDE-1024x768.gz. The script and Image live in the archos gitorious gpl repo.The image is a bitmap so is simple to change.
Archos GPL Code is built using BuildRoot which is a popular build system for embedded devices, but it's kinda of non-standard for Android.
If you want to do anything with it you will need to run the full Build first by running "make" in the buildroot directory, then afterwards run "make sde" which will create the gzipped image files. The full build takes about an hour as you cannot pass an -j modifies to make when using buildroot . However you only need to do the full make once, Obviously if you know what you're doing you can just run the bitmap through whatever conversion process is being run, then gzip it up but for the easy life it's recommended to do the full build first.
I think the bitmap is being converted to a raw argb file, although don't quote me on that! . Once it's been converted you don't even have to gzip it really as you can replace the "zcat" call with a call to "cat" but it makes no odds either way really apart from in size
To get started have a look here [ gitorious archos-gpl-gen9 tree ], read both the readme files, then you can find the image and build script in the buildroot/packages/sde directory.
Thanks
EDIT: I'll also add that this won't change the "power on" splash, I believe that is displayed by avboot which, from what I can gather is the 3rd stage bootloader, If I recall it was possible ( although dangerous ) to change it on earlier archos devices but due to checks in the gen 9 version there is a very real risk of bricking the device. From the various threads I've read, I believe Letama and Scholbert know more about this.

Hi Quinny899!
Quinny899 said:
So, I was doing some research on how you can change it and I ended up finding this in initramfs/etc/scripts/init_sde:
Code:
# Show a nice boot image
case "$PRODUCT_NAME" in
A80S)
BOOT_IMAGE=$BOOT_IMAGE_BASE-1024x768.gz
;;
A80H)
BOOT_IMAGE=$BOOT_IMAGE_BASE-1024x768.gz
;;
A101S)
BOOT_IMAGE=$BOOT_IMAGE_BASE-1280x800.gz
;;
A101H)
BOOT_IMAGE=$BOOT_IMAGE_BASE-1280x800.gz
;;
esac
$ZCAT $BOOT_IMAGE > /dev/fb0
And at the top of that file:
Code:
BOOT_IMAGE_BASE="/SDE"
Now, if we could either find those gz files and edit them or extract and link the file to the right place, we'd change it
Any ideas?
Click to expand...
Click to collapse
I'd suggest to read this thread in the Gen8 section completely.
http://forum.xda-developers.com/showthread.php?t=1290242
AFAIK, nothing changed on the Gen9 devices.
To point it out again:
It's risky... if you mix things up in the rawfs, you'll brick your tablet... at least it will stuck in bootloader.
Someday we'll be able to recover
Anyway, please be aware of this!
By wiping the boot logo you're entering low level hacking.
trevd said:
EDIT: I'll also add that this won't change the "power on" splash, I believe that is displayed by avboot which, from what I can gather is the 3rd stage bootloader, If I recall it was possible ( although dangerous ) to change it on earlier archos devices but due to checks in the gen 9 version there is a very real risk of bricking the device. From the various threads I've read, I believe Letama and Scholbert know more about this.
Click to expand...
Click to collapse
Nothing to add here... anyway here i am
Letama wrote a tool to parse the files inside rawfs and tweak them. See the thread i pointed to in my above statement!
Best regards,
scholbert

Related

[TOOL] redbend modification

I hacked on redbend_ua to make it a better phone hacking tool
first thing that has to go was the rebooting after any command
and the second thing was the stupid installing software splash screens
the first mod will probably segfault if used to batch install delta files
as I suspect there is some more code to update the progress bar on
the now NOP'ed installing software splash screen.
the second mod has batch mode NOP'ed so it wont do anything unless
you pass the dump,restore or compare commands which is fine for scripting
zImage and modem.bin installs.
/* This program is free software. It comes without any warranty, to
* the extent permitted by applicable law. You can redistribute it
* and/or modify it under the terms of the Do What The **** You Want
* To Public License, Version 2, as published by Sam Hocevar. See
* http://sam.zoy.org/wtfpl/COPYING for more details. */
Click to expand...
Click to collapse
Nice thanks
Sent from my vibrant
untermensch said:
I hacked on redbend_ua to make it a better phone hacking tool
first thing that has to go was the rebooting after any command
and the second thing was the stupid installing software splash screens
the first mod will probably segfault if used to batch install delta files
as I suspect there is some more code to update the progress bar on
the now NOP'ed installing software splash screen.
the second mod has batch mode NOP'ed so it wont do anything unless
you pass the dump,restore or compare commands which is fine for scripting
zImage and modem.bin installs.
Click to expand...
Click to collapse
sorry if this is dead info but how is this a tool? i need as many tools as possible. and i do not understand is there a place for specific knowledge on this that may go into a bit more detail?
justlovejoy said:
sorry if this is dead info but how is this a tool? i need as many tools as possible. and i do not understand is there a place for specific knowledge on this that may go into a bit more detail?
Click to expand...
Click to collapse
redbend_ua is used for installing OTA updates, but it also has other functions.
RedBend Update Agent %s
commands:
img [partition name] [delta file] [device node] [temp path]
fs [partition name] [delta file] [mount point] [temp path]
all
dump <source dev> <dest file>
restore <source file> <dest dev>
compare <dev1> <dev2>
png [png file name]
all
Click to expand...
Click to collapse
normally when you run a command it will take over the screen with a "Installing Software"
splash, and then reboot. you can get around the reboot by unlinking reboot but that is kinda
a kludge and the splash usually just scrambles the screen.
the mod does away with the splash and the reboot making redbend_ua less annoying to use.
you could even probably install kernels and modems without rebooting into recovery, though
you will have to reboot to use the new code.
for example if you want to install a kernel the command might look something like this
Code:
/data/local/redbend_ua restore /sdcard/zImage /dev/block/bml7
So I'm bumping this because tbh I was a little surprised to see it die out. I was expecting more to come out of it. I imagine you could potentially create an app to flash kernels and modems and then you just reboot for it to take effect. Might be worth looking into...
Edit: I'm going to look into it. I feel this would be extremely convenient for multiple reasons.
Whitehawkx said:
So I'm bumping this because tbh I was a little surprised to see it die out. I was expecting more to come out of it. I imagine you could potentially create an app to flash kernels and modems and then you just reboot for it to take effect. Might be worth looking into...
Edit: I'm going to look into it. I feel this would be extremely convenient for multiple reasons.
Click to expand...
Click to collapse
Whitehawk, dude, kick some butt doing this! It would be very convenient
Sent from the helm of Vibrant Territory!
Whitehawkx said:
So I'm bumping this because tbh I was a little surprised to see it die out. I was expecting more to come out of it. I imagine you could potentially create an app to flash kernels and modems and then you just reboot for it to take effect. Might be worth looking into...
Edit: I'm going to look into it. I feel this would be extremely convenient for multiple reasons.
Click to expand...
Click to collapse
Guess what i already did: SGS kernel flasher
Btw: Thanks untermensch.
neldar said:
Guess what i already did: SGS kernel flasher
Btw: Thanks untermensch.
Click to expand...
Click to collapse
I saw that and briefly hacked into it to pack it with vibrant kernels - gave it 1 try which failed and I moved on because I assume you have a check in place that didnt let me replace the kernel. Like to see this for us though.
Edit - reading your signature, I must have been working from an early or I9000 version at the time.

[Q] Porting Meego to the Tab, some Android noob questions before I start

Hi chaps,
I've just bought a Galaxy tab with plans to port Meego to the device.
I'm new to all the Android stuff, and tbh the myriad methods for doing this/that/the other and the relative lack of explanation of what's actually being done in these various methods/tools is quite confusing (and worrying).
So, if you'll bear with me, I have a few questions which are probably quite basic.
I've rooted my Tab using SuperOneClick, no problems there, I also understand that there is a leaked flashing tool called (Multi)Odin and an open source flashing tool called Heimdall. I understand adb.
So onto the questions:
Before I start messing about, how should I backup my existing firmware image? I see people talking about taking image dumps using dd, or Odin or Heimdall. What is the preferred method? And how should one then restore the device from these backups?
Alternatively is it possible to simply download the firmware directly from Samsung (I see links to later firmware, but really I'd be happy with what I have currently - P1000XXJK5 and FROYO.XWJJ7)?
I'm assuming that the best installation method would be to replace recovery, then I can add my own kernel and have it boot a rootfs mounted on the external SD card for example. Any thoughts?
I've seen one thread about people compiling their own kernels, with panics and the like which are solved by giving the full path to the initramfs extracted from the existing image. Any clues as to why the built version doesn't work? This is not so important as I can have a look at this when I build the Samsung source.
Is anyone looking at the bootloaders? Is there any information anywhere about them (as changing the bootloader to allow selection of the kernel to be booted would make life easier)?
Thanks for your patience!
Ok, so to partly answer myself, I see www dot samfirmware dot com has links to downloads of firmware images.
I'd really prefer to generate my own image of what's currently on the device rather than trusting a download site, but I guess it's better than nothing. Does anyone know how these images were generated anyway?
lardman said:
Ok, so to partly answer myself, I see www dot samfirmware dot com has links to downloads of firmware images.
I'd really prefer to generate my own image of what's currently on the device rather than trusting a download site, but I guess it's better than nothing. Does anyone know how these images were generated anyway?
Click to expand...
Click to collapse
Samfirmware get their images direct from Samsung insiders. They are not dumps.
If you want to dump from your device search "rotobackup" here in the dev forum.
Sent from my GT-P1000 using Tapatalk
alias_neo said:
Samfirmware get their images direct from Saunaing insiders. They are not dumps.
Click to expand...
Click to collapse
Ok that's reassuring.
alias_neo said:
If you want to dump from your device search "rotobackup" here in the dev forum.
Click to expand...
Click to collapse
Great, just what I was looking for, many thanks
So some more questions:
Any limit to the size of the kernel? Presumably just the size of the partition (which after extracting the image for backup seems to be a pretty large 15.4MB)?
What do all the .rc files in the raminitfs do? They are as follows: fota.rc, init.goldfish.rc, init.rc, init.smdkc110.rc, lpm.rc, recovery.rc
The init.rc is the normal init.rc file, so that's fine. Presumably the recovery.rc file is run if the bootloader detects that recovery mode is wanted (holding down keys during boot). The init.goldfish.rc? I guess this is to do with the emulator, though why it would be in a release image I don't know.
I assume that init.smdkc110.rc is automatically run somewhere along the line, though I don't see where it's started.
Any thoughts on lpm.rc and fota.rc? Are multiple .rc files run for the normal and recovery boots?
Thanks
lpm.rc is for low power mode that displays battery charging animation
goldfish is for running the rom under qemu.
backup your rom using rotobackup. compile samsung's kernel from sources, mix up default initramfs with meego's init scripts. pack all Meego stuff into loop mounted disk image. then flash zImage to kernel and your disk image to factoryfs using heimdall. I assume you have experience hacking N8xx/N900 and Maemo or Meego?
factoryfs is around 300MB so I think it should fit Meego and it (and kernel) can be easily restored with heimdall.
Thanks for the comprehensive reply
Yes I do have experience hacking Maemo/Meego, though have never really had to fiddle with init scripts before and this is as good a reason as any to learn.
I'd actually like to dual boot, so am modifying recovery.rc to bring up the Meego system on the external SD card.
Am just fiddling about building extra kernel modules now (needs btrfs for my image for example) and modifying the recovery.rc file.
Hmm, well I was all set to go and flash my new zImage and was looking for the heimdall command line, when I saw this at the top of one of the threads in this part of the forum (http://forum.xda-developers.com/showthread.php?t=870690):
Restoring to factory after using this process (you need using stock images):
heimdall flash --kernel stockzImage --recovery stockzImage --factoryfs factoryfs.rfs
Click to expand...
Click to collapse
Which has made me worry a bit that I've missed a recovery partition with its own kernel and wrongly assumed that the same kernel is used for both recovery and normal running, just with a different .rc file to be interpreted by init.
Any thoughts?
Do we trust the partition sizes reported here: http://forum.xda-developers.com/showpost.php?p=9471190&postcount=14
They seem very small for the kernel partition. I used RotoHammer's dd method to grab the contents of the partitions as a backup, so am assuming the sizes shown above are not correct (or represent something else?)
Going back to RECOVERY and ZIMAGE partitions - the ZIMAGE partition contains a recovery.rc, the question is really whether, even if they use the same zImage in both the ZIMAGE and RECOVERY partitions, the version in the RECOVERY partition is actually booted if recovery mode is selected (by holding the up volume key, etc.)? OTOH it may be that the RECOVERY partition is either empty or unused, has anyone tested specifically to see whether recovery.rc is run from the ZIMAGE partition?
Well I think I can answer my own question there, I flashed my modified kernel (modified recovery.rc) only to the KERNEL partition, and it boots normally if I don't touch anything, and just gets stuck on the first Samsung screen if I boot in recovery mode.
So it's doing something, I just can't tell what. Not sure if any kernel messages are getting lost behind that image, or perhaps they aren't even output to the framebuffer at all. I seem to remember seeing something about disabling the splashscreen so I'll go and have a look for that. Anyone got any other suggestions?
P.S. I also note there's a flash of screen corruption as the device starts up with my new kernel, I don't remember seeing that before. Is this a usual occurance?
I see from the Nexus S port that including adbd in the image seems to be the way to go for early messages, I'll need to generate a new Meego image and have another go later on.
Interesting, I can't see that I've done anything wrong, and my extra init shell script is not started. I am trying to use the "exec" keyword in recovery.rc to start a shell script which will pass control to the Meego rootfs. At the start of my shell script I start adbd (i.e. still within the initramfs), so I should be able to tell if it has started, and it doesn't appear to do so.
Therefore I did some Googling, and I've seen that in some cases the initramfs init does not implement the "exec" keyword (http://forum.samdroid.net/f9/new-init-exec-import-implemented-3280/). This is troublesome for me as it's what I'm trying to use, but at least would explain why I don't seem to leave the init process
I couldn't see the Samsung specific source for init anywhere, has anyone found any? I'm not happy to replace it using the standard Android source as I'm guessing there's code missing which allows the bootloader to tell init how the device was started so that it knows which of the .rc files to run. Has anyone looked into this?
Thanks
Looking at the code in that link it looks pretty straightforward, just a case of parsing the kernel command line (though I might just reverse engineer the existing init first to make sure I'm not missing anything).
Would still be easier to get the actual source code from Samsung, so I've emailed their Open Source group.
lardman said:
P.S. I also note there's a flash of screen corruption as the device starts up with my new kernel, I don't remember seeing that before. Is this a usual occurance?
Click to expand...
Click to collapse
I get it with CM
Does CM use a compressed initramfs? I'm using one of those and wondering if it's something to do with the (admittedly small) extra time required to move to init.
I don't have my Tab with me here, could someone post the output of /proc/cmdline please? You'll need to be root. Thanks.
Well it's booting you'll all be glad to hear.
More details to follow, but from memory the following were required:
Custom kernel to add btrfs support (as the image I'm booting is a btrfs partition on the external SD); kernel patch to allow compile-time cmdline to be added to the end of the bootloader cmdline (to enable console=tty0); replace Android init with init script to perform some basic setup then pivot_root to the Meego partition.
Next steps are to get the Meego system running usefully (which includes getting a terminal as currently I just have a login prompt but no way of inputting anything!) and also seeing whether I can get dual booting working with an Android system standard boot and Meego replacing the recovery boot.
Poor pic, but still: http://people.bath.ac.uk/enpsgp/Tab/PICT0040.JPG
Good stuff. Thanks for keeping us informed.
After you've got the groundwork for this done, how easy would it be to get Ubuntu running?
Try google http://lmgtfy.com/?q=ubuntu+on+galaxy+tab
Sent from my GT-P1000 using XDA App
brilldoctor said:
Try google http://lmgtfy.com/?q=ubuntu+on+galaxy+tab
Sent from my GT-P1000 using XDA App
Click to expand...
Click to collapse
That's using chroot, which I don't want. I want it running natively.
Sent from my Galaxy Tab

[DEV][BRAINSTORM] Fully-working CWM Recovery

While the recovery we have at the moment, fruit of the hard work of xantaro, unclecracker and digitalfrost, is enough for most operations there are some things bugging me that is in our interest to fix with the ultimate aim of adding it to ROM Manager and thus get official support.
Current issues:
1. It isn't the latest version of CWM and isn't official.
2. It doesn't have USB mount working.
3. It doesn't have ADB working.
4. It doesn't support EXT4.
Now, I have tried to fix these but recoveries are a new domain for me and at a first attempt I couldn't bring some of these to work. Compiling the latest version was easy and an important first step towards official; however, all others I couldn't do it and I don't think we should talk with koush before fixing all this.
Here are my short attempts:
- For USB mount I defined on the BoardConfig the path for UMS lun0 file. The path seems to be correct and there's no other file in /platform/ as I've found out by running a ls -R. I have no idea why it's not working.
- For ADB, I made sure the persist.adb.service is set to 1 and the init.rc is starting it. This being said, I don't know what's missing. Perhaps this is of interest?
- For EXT4 support I thought it was just a matter of adding alternative FS to recovery.fstab. Seems I was wrong though.
So, does anyone want to join in and help?
This is really new territory to me and I have a quite faint idea of what I'm doing.
A few guidelines:
- Read this to get an idea.
- You'll need CM sources (repo init... repo sync...)
- The CWM recovery source is in /bootable/recovery
- Here is my device source and a patch file for some changes on recovery src *
- Run build commands (. build/envsetup.sh, lunch full_p970-eng, make -j4 recoveryimage)
* If you don't change what I did on the recovery source you won't have a key to select.
Also, I have CWM 4.x at the moment on my OB but since it does the same as the already posted 3.x I don't deem necessary to share it; but if anyone wants, I'll upload it.
I'll join the party when I come from the mini-vacations, hope there'll be some progress meanwhile!
Great
i'll try to do some help,maybe little
If anyone wants you can request a pull from my source.
Also, here's a flashing CWM 4.x. I renamed it Nova recovery for the lulz.
http://www.multiupload.com/R7WGNYTL7G
Changes on the Source to get selectbutton to work shouldn´t be necessary. Adding "BOARD_HAS_NO_SELECT_BUTTON := true" to boardconfig.mk suffices to get selectbutton to work.
EXT4 Backup and Restore worked for me after editing the fstab file.
For the ADB and USB mount problem i have no Idea what is missing. Like you said, adb daemon should get started througt the initscript.
BTW. seems like the Progressbar isn´t working on the newer Versions of CWM
xantaro said:
EXT4 Backup and Restore worked for me after editing the fstab file.
Click to expand...
Click to collapse
Could you release a new version or tell us how to do it? Thanks
To get EXT4 working in my O2X builds my /data line looks like this:
Code:
/data ext3 /dev/block/mmcblk0p9 NULL auto
xantaro said:
Changes on the Source to get selectbutton to work shouldn´t be necessary. Adding "BOARD_HAS_NO_SELECT_BUTTON := true" to boardconfig.mk suffices to get selectbutton to work.
Click to expand...
Click to collapse
I thought the flag wasn't suffice. Thanks.
Rusty! said:
To get EXT4 working in my O2X builds my /data line looks like this:
Code:
/data ext3 /dev/block/mmcblk0p9 NULL auto
Click to expand...
Click to collapse
Nice tip, I'll try.
knzo said:
While the recovery we have at the moment, fruit of the hard work of xantaro, unclecracker and digitalfrost, is enough for most operations there are some things bugging me that is in our interest to fix with the ultimate aim of adding it to ROM Manager and thus get official support.
Current issues:
1. It isn't the latest version of CWM and isn't official.
2. It doesn't have USB mount working.
3. It doesn't have ADB working.
4. It doesn't support EXT4.
Click to expand...
Click to collapse
Hey,
I know this is an old thread but still if u have not resolved the problem with ADB and USB follow these instruction:
Before we start:
My mobile is Spice Mi-410 (Qualcomm made), also known as Cherrymobile magnum, Wellcomm, Motorola triumph in different countries. So may be these tweak will not work with your device. (But you can give it a try )
I hope you know how to unpack recovery.img of your device (or boot.img if your recovery ramdisk is stored in boot.img like Xperia Arc) if not then follow this guide to unpack recovery.img and extract recovery ramdisk into a folder.
Tweak
For ADB: Open init.rc file from recovery ramdisk/initram using any editor of your choice
Put this line at the end of "on init" section
Code:
write /sys/module/g_android/parameters/product_id ####
where #### should be replaced by your device's product id.
(if you dont know what it is then connect your mobile to PC and issue "lsusb" command in ubuntu terminal, you should see something like this
Bus 001 Device 027: ID 0489:c000 Foxconn / Hon Hai
Here c000 is my devices product id and Foxconn is my device's manufacturer)
Though /sys/module/g_android is not present in our device but this worked for me.
Please note that the device id is case sensitive, so write what you see on PC
For USB: For this add following line at the end of "on boot" section in init.rc file
Code:
echo 1 > /sys/class/usb_composite/usb_mass_storage/enable
For your device first confirm the location of /sys/class/ ###### / ####/usb_mass_storage/enable
Since this location vary from device to device.
This should enable usb storage mounting from recovery.
Best of luck!!
One option for load rootfs image in native mode is necesary
enviado

A pure C implementation of 'cuber' using OpenSSL's BigNum library

In case anybody cares, here's a pure C reimplementation of 'cuber.py'
(my own earlier reimplementation of @vortox's signature.py).
This is what I'm using in my '1-Click' bootloader unlock VM...
See 'grep ^gcc' for "build instructions".
Hack, you can probably build this for ARM and run it right on your very HDX tablet... (-;
UPDATE (JanuaryFebruary 2017):
OK; so, @zivimo had built this for ARM, but people still haven't noticed.
I repacked his binary from a .tar.gz to a .zip archive and decided to spell out the instructions for use.
Perhaps, this helps... With the right bootloader in place, and adb/fastboot installed (and working),
the unlock is as easy as follows...
Download and extract unlock.zip (SHA256: e40e3010f8eccfa9cbd1e73eecac30cf799099d183de23b2d256fc3407f143f6e5db0b8d82c8fd2a25a22b0a598014d22a2ec33cef27a8d4b65a36acde08f27a)
to the same directory that holds the adb and fastboot executables (unless you have added them to your PATH)
Click on get_code.bat in the extracted folder
-- optional (but commonly required) step(s) --
fix root (roll back, if you need to), flash vulnerable bootloader
[you'll definitely need to perform at least some of these if the last step fails]
Click on unlock.bat in the extracted folder
The archive also includes .sh variants of the .bat files for convenience.
You could also just click to show the hidden section and cut&paste... (-;
Code:
[STRIKE]unzip cuber.zip[/STRIKE]
adb push cuber /data/local/tmp/
adb shell chmod 0755 /data/local/tmp/cuber
adb shell 'id=$(cat /sys/class/block/mmcblk0/device/{manfid,serial}); echo "$id"; echo 0x${id:6:2}${id:11:8} | /data/local/tmp/cuber > /sdcard/unlock.code'
adb pull /sdcard/unlock.code
adb shell rm /sdcard/unlock.code /data/local/tmp/cuber
adb reboot-bootloader
fastboot -i 0x1949 flash unlock unlock.code
NOTE: download and extract the attached 'cuberunlock.zip' and run the above commands
in the directory where 'cuber' got extracted to.
Nice job! Originally I wanted to use OpenSSL BigNum too, but I hadn't enough time and Python was easier to use
hey,
made a static compile with an arm debian (jessie). seemed the easiest solution to me. compile command:
Code:
# gcc -fPIE -static cuber.c -o cuber -lssl -lcrypto
# strip cuber
# ldd cuber
not a dynamic executable
# ./cuber
Usage: cuber [RSA-bytes] < data > sig
seems to work. arm(!) binary attached.
ok draxie, you pointed me here but something seems to be missing. i downloaded unlock.zip, put the files in my adb directory. when i run get_code.bat, it pushes cuber to the kindle in the right directory, changes permissions (dont see any errors there) but then stops saying the system can't find the specified path. Whats funny is i used es file explorer to check the paths in the script, and they are there so not sure where the hang up is.
chin_bone said:
ok draxie, you pointed me here but something seems to be missing. i downloaded unlock.zip, put the files in my adb directory. when i run get_code.bat, it pushes cuber to the kindle in the right directory, changes permissions (dont see any errors there) but then stops saying the system can't find the specified path. Whats funny is i used es file explorer to check the paths in the script, and they are there so not sure where the hang up is.
Click to expand...
Click to collapse
Did you check all three paths?
/data/local/tmp
/sdcard
/sys/class/block/mmcblk0
The 2nd one _may_ be problematic if you're on SafeStrap.
I don't know why. I'm yet to install that on one of my test
devices to investigate. (Or, was that the 1st... )
The 0 in the 3rd one may actually be a 1 on some systems.
I have a few extra lines in my VM script to work around
that, I can easily add that here as well, if that turns out
to be the issue.
BUT, to try and troubleshoot: how far does the script get?
If it didn't complain with the permissions, the 1st path is probably OK.
Does it print your manfid/serial?
If so, mmcblkX would be right as well.
Any chance that you're on SafeStrap?
Can you push/pull to/from /sdcard?
- - - - -
On a second thought: I've only ever tested this on Linux.
String quoting on Windows may work differently, and could *royally* mess up how that more complex command is interpreted.
I'll test tomorrow; it's like 20 past 1am here. I need to get some sleep.
In the meantime, as a workaround, you could just hard-code your manfid/serial, and replace this line:
Code:
adb shell 'id=$(cat /sys/class/block/mmcblk0/device/{manfid,serial}); echo "$id"; echo 0x${id:6:2}${id:11:8} | /data/local/tmp/cuber > /sdcard/unlock.code'
by the decidedly much simpler:
Code:
adb shell 'echo 0xmmssssssss | /data/local/tmp/cuber > /sdcard/unlock.code'
draxie said:
Did you check all three paths?
/data/local/tmp
/sdcard
/sys/class/block/mmcblk0
The 2nd one _may_ be problematic if you're on SafeStrap.
I don't know why. I'm yet to install that on one of my test
devices to investigate. (Or, was that the 1st... )
The 0 in the 3rd one may actually be a 1 on some systems.
I have a few extra lines in my VM script to work around
that, I can easily add that here as well, if that turns out
to be the issue.
BUT, to try and troubleshoot: how far does the script get?
If it didn't complain with the permissions, the 1st path is probably OK.
Does it print your manfid/serial?
If so, mmcblkX would be right as well.
Any chance that you're on SafeStrap?
Can you push/pull to/from /sdcard?
- - - - -
On a second thought: I've only ever tested this on Linux.
String quoting on Windows may work differently, and could *royally* mess up how that more complex command is interpreted.
I'll test tomorrow; it's like 20 past 1am here. I need to get some sleep.
Click to expand...
Click to collapse
It's all good draxie, i figured out what i was doing wrong with the other procedure, that damn STEP 2, once i did it, everything fell into place. Bootloader unlocked and now just trying to figure out which rom to try first. Thanks again, you guys are great and i know how valuable everyones time is. :good:
I keep hitting road blocks, I am rooted and on Fire OS 4.5.5.2 I click get code a screen flashes up then I click Unlock and my Kindle boots to the Grey Kindle screen with Fastboot underneath and nothing else happens. Same happens when I copy and past the code into ADB. What step am I failing at? Thanks for the help!
pdanforth said:
I keep hitting road blocks, I am rooted and on Fire OS 4.5.5.2 I click get code a screen flashes up then I click Unlock and my Kindle boots to the Grey Kindle screen with Fastboot underneath and nothing else happens. Same happens when I copy and past the code into ADB. What step am I failing at? Thanks for the help!
Click to expand...
Click to collapse
@draxie - I have no experience with this tool; python/gmpy2 works reliably for me. Sorry to pull you in ...
Davey126 said:
@draxie - I have no experience with this tool; python/gmpy2 works reliably for me. Sorry to pull you in ...
Click to expand...
Click to collapse
I am up and running now, unlocked and running kk-fire-nexus-rom-thor-20161017. Play store is also up and running.
pdanforth said:
I am up and running now, unlocked and running kk-fire-nexus-rom-thor-20161017. Play store is also up and running.
Click to expand...
Click to collapse
Did you end up using some other method, or did these scripts work for you in the end?
Either way, others may find useful if you could share whatever worked for you. (-;
Unfortunately, I still haven't had a chance to test these scripts in Windows;
so, I couldn't answer your first call for help in a good way. If there's something
wrong and there's enough interest, I'll be happy to fix it as soon as I can.
draxie said:
Did you end up using some other method, or did these scripts work for you in the end?
Either way, others may find useful if you could share whatever worked for you. (-;
Unfortunately, I still haven't had a chance to test these scripts in Windows;
so, I couldn't answer your first call for help in a good way. If there's something
wrong and there's enough interest, I'll be happy to fix it as soon as I can.
Click to expand...
Click to collapse
@stangri did my unlock file and I used this thread to unlock https://forum.xda-developers.com/kindle-fire-hdx/general/thor-unlocking-bootloader-firmware-t3463982
I had trouble making the Unlock file, once that was done and some help from other users I am now up and running!

[CLOSED: REPLACED] [HELP NEEDED] Running a full custom ROM using the AVD tool of Andr

Hi everyone,
Today I'd like to dust an old subject that was quite discussed: emulating a custom Android ROM.
There are in threads arround here or in some Stack Overflow subjects (for instance) peoples talking about this, providing ideas or even complete tutorials.
These tutorials show how to use the SDK tools to create an Android Virtual Device to run the desired ROM.
But all these informations are purely deprecated and can't be applied exactly for new touch phones (higher than Jellybean you can't do that!)
Didn't realizing it yet and wanting to try it out I personnally downloaded the latest Android Studio software with the basic SDK tools.
I tried to run commands specified in the tutorials to test some things out (like creating an avd) and actually creating an avd this way is purely deprecated. Well.
 What a good start.
So instead I used the avd tool of the Studio software and I successfully created one.
Got into the C:\Users\%USERNAME%\.android\avd\avdname.avd folder to check components of the avd. I even read .2cow things files to know the location of the missing components (like system.img)
So I am almost done. I prepared my .img files to replace avd img basic components to test my emulated firmware out. But...
I have no idea where to start!!
I am missing some img files that would be necessary to run the avd correctly, like the kernel.img or userdata thing...
I just don't know what to replace or not, how to obtain necessary files without breaking something, I need help...
Here is finally the question of the subject:
Can somebody post out a complete updated tutorial on how to emulate a full custom rom using the AVD tool provided by Android Studio, please? (If possible of course)
This would be really nice and pretty useful for ROM development. I'm still experiencing things, trying to modify the close-to-my-devive avd I generated but this is just messing arround with things, I am pretty inexperienced so I don't think I could help...
Ok, no contribution as expected...
Fortunately I started reasearches despite the fact that I'm not a dev so I have a really really little idea of what I'm doing...
So here are what my researches led to (report with my memory, I will re-edit my post soon to add what I missed) :
Note: I used my SM-G361F pre-rooted ROM to test emulation.
==========*#1*==========
Operations:
•Created a close-to-device AVD (Same API Level etc.)
•Found out AVD dependencies folders: [C:\Users\%USERNAME%\.android \avd\x86 (I guess?)\(devicemodel).avd then another location containing kernel, system.img etc. thanks to .qcow2 files in the previously presented folder ("link" were in.)
•Made a backup of these folders **obvious**
•Edited some configurations (config.ini etc.) to make the final emulated system as close to the real device as possible to avoid incoherences
•Replaced some components of the AVD (build.prop, cache.img, userdata-qemu.img, etc.)
•Replaced the system image in the second folder
•After an hard struggle to get boot.img file of my device, decompiled it to get the ramdisk.img and kernel.img I used to replace kernel-qemu
Test:
•Starting the AVD from Android Studio
=> Outputs option "repair device"
•Attempted a repair: selected... My device SM-G361F to repair.
(=> Weird...)
•Repair seemed to work well according to the fact I could run the AVD
•Statut of the AVD: Black screen. Using power button and all doesn't make anything working: the AVD doesn't react.
=> Quiting made the emulator crash
Initial reason: see troubleshooting section
Result: FAIL
Troubleshooting:
•I shouldn't had to replace kernel-qemu by the stock extracted kernel: it has nothing to do with the actual system because it isn't purely system but device related. Will fix that next time
•ramdisk was badly recompiled: after extracting it from boot.img using Android Image Kitchen I recompiled it with the recompile.bat that ouputs two files: img-new.img (cannot figure what's its utility...) and new-ramdisk.cpio.gz that I simply renamed ramdisk.img. This could be the main reason why the AVD isn't working.
Will look up how to deal with ramdisk soon.
==========**2**==========
Operation:
•Restored the original kernel-qemu from backup
Test:
•The AVD still not show anything but quiting the emulator doesn't trigger any crash now.
Result: FAIL
Troubleshooting:
•As mentionned before will look up ramdisk.img file that seems problematic
Thread closed. But the project of emulating a custom rom is not abandoned.
Actually I didn't find a way to use the new AVD tool provided by Google to reach this goal. Instead I am heading over the new idea of creating a software generating an environment for Android emulation with given components (kernel, system, data etc. prealably extracted or, better, from a backup)
I hope I'll get help in the future because I'm pretty sure I won't be able to do such enormous task alone...
New thread here: https://forum.xda-developers.com/android/development/help-environment-builder-custom-rom-t3758360

Categories

Resources