[In-Dev] K-SAK: permanent jailbreak, unbricker, & more

[yifanlu]

Originally Posted by hawhill

Please let me suggest to create a new thread for the viral vs. non-viral license dispute :-) I think we all know how these discussion are determined to never end...

And back to topic: I have a bit of C code here using libusb(x) for talking to the K3's USB loader (ROM kernel part is implemented, RAM kernel part is not). I'll publish it when I'm back home, it could be also starting grounds at least for the K3. The K3 does not use USB HID as wrapper but uses a proprietary USB protocol (basically just serial I/O over two USB bulk transfer endpoints).

I agree that a one-stop unbricking tool would be really, really nice. However, let's see where this is heading. Maybe we will get something like Android's "custom ROM" culture. I'm not sure if I would like that, however. It's a bit messy to deal with tens and hundreds of more-or-less broken device images...

Yes, I've read the protocol. I can't say for certain, but custom roms aren't part of my goal. There will be no part of the tool that flashes the NAND, all the work is done in memory. And for K3, what I'm hoping is for the GUI app, I'll just link to both libraries that use K3's usb download (maybe your work) and my library that use k4's usb download to do the work. Very modular.

And I'm mostly interested in this working for the next kindle.

[geekmaster]

Originally Posted by yifanlu

And for K3, what I'm hoping is for the GUI app, I'll just link to both libraries that use K3's usb download (maybe your work) and my library that use k4's usb download to do the work.

I have eink draw and update code that works on all the eink kindles that I have, in all modes (main and diags). The k4 uses different eink drivers in main and diags mode. I also support full grayscale in the newtrix demo, which dithers 256-shades down to 16, as required even for the 8-bit framebuffers (where the bottom 4 bits must be a copy of the top 4-bits for predictable behavior, according to the eink driver GPL code). My newer stuff (like the video player) does dithering with no dither table and uses ioctl() eink updates. Because it is native code, it might work within your framework.

[NiLuJe]

Welcome back! \o/

All this sounds way off my usual playground, so I'll probably mostly stay on the sidelines, but have fun & good luck!

[yifanlu]

Ok, I'm thinking of ditching the "menu on kindle" idea. For easier usability, I want all the settings to be done on the computer, press "Start" and let the app do all the work. No need for a user to sit down with the kindle and try to choose various options.

So far, I have the following options in the (so far only OSX) app:
1) Jailbreak/Unjailbreak
2) Backup/Restore (the entire nand)
3) Export (nand over usb)
4) Advanced (export shell over serial usb, load custom initrd)

The user will choose one of those options, type in any custom settings if applicable, and press start. The paramaters will be flashed to a set location in memory, and my custom initrd will read the option and do whatever.

Any suggestions for other features?

[eureka]

@yifanlu, I have a side question. Now, you have a reliable way to backup/restore eMMC content (i.e. stock KT software). Does it include also backuping/restoring stock U-Boot? (I do know that one can make stock U-Boot from source provided by Amazon, I'm interested mostly in possibility to replace or restore stock U-Boot at KT).

[yifanlu]

Originally Posted by eureka

@yifanlu, I have a side question. Now, you have a reliable way to backup/restore eMMC content (i.e. stock KT software). Does it include also backuping/restoring stock U-Boot? (I do know that one can make stock U-Boot from source provided by Amazon, I'm interested mostly in possibility to replace or restore stock U-Boot at KT).

Serial and boot loader are on a different partition of the NAND. I haven't looked into it but there may be a way to make it show up through kernel configurations. Uboot's mmc driver has it so worst case, I can port it over.

[yifanlu]

Quick update:

1) OSX GUI is almost done. I really want this to look nice and pretty in an Apple fashion. After this, I'll quickly make a windows version, since looks don't matter there

2) Embedded initramfs image is done. 7.7MB uncompressed. 4.7MB compressed. Includes a busybox linux image with shell and many tools. Everything is in RAM.

3) "Packages" are in the format of initramfs files. Since most of the system files are already in the embedded initramfs in the kernel, all you need is recovery.sh and optionally splash.png inside an external initramfs file. The shell script can do pretty much anything. I've built packages for exporting NAND over usb, jailbreaking, and exporting a Shell over usb serial. The nice thing about this system is that it's very modular. Mix and match kernels (for different devices) and packages (for different tasks).

4) Expert users can, instead of initramfs packages, load initrd images (support ext3, squashfs, cramfs) (with compression) and basically boot any linux image they want with a 64MB limit (for performance).

What I need to do now is to modify u-boot to load my custom kernel automatically and finish the GUI. Before that, I may release a command line beta for win/linux/osx for advanced users.

[geekmaster]

Originally Posted by yifanlu

Quick update:

1) OSX GUI is almost done. I really want this to look nice and pretty in an Apple fashion. After this, I'll quickly make a windows version, since looks don't matter there

2) Embedded initramfs image is done. 7.7MB uncompressed. 4.7MB compressed. Includes a busybox linux image with shell and many tools. Everything is in RAM.

3) "Packages" are in the format of initramfs files. Since most of the system files are already in the embedded initramfs in the kernel, all you need is recovery.sh and optionally splash.png inside an external initramfs file. The shell script can do pretty much anything. I've built packages for exporting NAND over usb, jailbreaking, and exporting a Shell over usb serial. The nice thing about this system is that it's very modular. Mix and match kernels (for different devices) and packages (for different tasks).

4) Expert users can, instead of initramfs packages, load initrd images (support ext3, squashfs, cramfs) (with compression) and basically boot any linux image they want with a 64MB limit (for performance).

What I need to do now is to modify u-boot to load my custom kernel automatically and finish the GUI. Before that, I may release a command line beta for win/linux/osx for advanced users.

This sounds great. I am very much looking forward to playing with it.

With this, we could also make a stock unmodified kindle act like a USB I/O (extra eink video monitor, touchscreen keyboard and mouse emulation, sound output device, or whatever).

Exporting the entire MMC is nice too, for studying new firmwares.

[twobob]

Originally Posted by yifanlu

For my Kindle related projects, including detailed, technical descriptions: http://yifan.lu/tag/kindle/

Hi mate. That returns no content at the moment.

Nothing Found: Apologies, but no results were found for the requested archive. Perhaps searching will help find a related post.

http://yifan.lu/?s=kindle works fine though

HTH

[twobob]

Originally Posted by thomass

http://yifan.lu/?s=kindle

ahh good man

[yifanlu]

Originally Posted by geekmaster

This sounds great. I am very much looking forward to playing with it.

With this, we could also make a stock unmodified kindle act like a USB I/O (extra eink video monitor, touchscreen keyboard and mouse emulation, sound output device, or whatever).

Exporting the entire MMC is nice too, for studying new firmwares.

Yup. And I'm very suprised that nobody is (publically) porting android over to the touch. I'm hoping with this tool, there will be no fears of "bricking my $100 device" and more developers can do more risker stuff.

[geekmaster]

Originally Posted by yifanlu

Yup. And I'm very suprised that nobody is (publically) porting android over to the touch. I'm hoping with this tool, there will be no fears of "bricking my $100 device" and more developers can do more risker stuff.

Yup, "more riskier" is "more better" (greater risk can achiever greater rewards), especially when you have a safety net like your upcoming toolset, where rebooting restores stock behavior.

[Dylan Tomorrow]

yifanlu, are you still working on this? I was really looking forward to it, but I guess maybe you are bummed out by the Paperwhite like many of the devs here and not motivated any more? I don't mean to rush you, just want to know if you are still working on it or not?

[geekmaster]

Originally Posted by Dylan Tomorrow

yifanlu, are you still working on this? I was really looking forward to it, but I guess maybe you are bummed out by the Paperwhite like many of the devs here and not motivated any more? I don't mean to rush you, just want to know if you are still working on it or not?

Like many of us, yifanlu has other non-kindle toys to occupy his time too. You can see what he is up to at: http://yifan.lu

Embrace your technolust!

[eureka]

AFAIK, Yifan Lu is now hacking PS Vita, not Kindle Touch.