AdamOutler

Due to contractual obligations, I did nothing. I watched. I like watching.

I'd like to see all of the posts on this page and a few on the previous page, just disappear. As for the thread.. Prepare yourselves for some huge news from bass_rock, whatisbypass and myself soon.

Heh, they probably made the password a checksum of the serial.

What, like this?

Oh yeah! My AVIC-8100NEX works! I managed to get it to copy by simply sticking the new SDCard into my deck and letting it boot. It booted right into Android and brought up the selection screens! After I rebooted using key 1, it went into this mode where i wrote the programs. But.. I wrote the programs to a new SDCard.. 80X. The darn thing boots in 10 seconds now! and works great in Android Auto! It lives again!

I will be doing that soon. Tell me, are there any commands that allow memory read in U-Boot? U-Boot has the ability to get through many memory protections which it emplaces. If anything can read the password from inside the device it's U-Boot. I forget the commands, but I believe it was two letters, then two parameters for offset and length.. yep.. just found it. http://www.denx.de/wiki/publish/DULG/to-delete/UBootCmdGroupMemory.html The command is "md". Is that in the u-boot sources we are working with?

Ok. Does that need to be accounted for/encoded, on the new image?

I wanted to save the extra SDCard if possible. The SDCard is expensive (80x SDCard). The SDCard password is set by the deck according to bass_rock's similar experiment. This renders the SDCard unusable after power on, because we don't know the password.

Key 1 just sits at software error. Key 2 copies the SDCard. Just to verify, key 2 copies TO internal SD, not from, correct?

Ok. I got the full SDCard image from my AVIC-8100NEX deck. You can find it here https://builds.casual-dev.com/index.php?dir=random%2FAVIC%2F8100%2F. I verified the sha256sum after upload. root@adamoutler-desktop:/var/www/html/sd# sha256sum ./fullsd.img.gz e5682db410963d0b57b5eec94f3aa66eb9ae078ffeb1dc3ec4c02c0b7f426da6 ./fullsd.img.gz This file and the others which are required to enter testmode and obtain this image were included. Place them on a USB stick, insert into USB1 port to reboot into test mode, then use the write program forcedly>Copy Script option to recreate. This i

Using copy_script.sh, get the output of 'netcfg' before and after the usb device is connected. if that doesn't work, check "ifconfig eth0", "ifconfig usb0", and "ifconfig wlan0", then change the 0's to 1s

I got the image from the deck. Attached is a picture. adamoutler@adamoutler-desktop:~/Desktop/Untitled Folder 3$ fdisk -l ./fullsd.img Disk ./fullsd.img: 16.1 GB, 16130244608 bytes 128 heads, 16 sectors/track, 15383 cylinders, total 31504384 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System ./fullsd.img1 1050624 1071103 10240 83 Linux ./fullsd.img2 1071104 10

Usually it is accessible through uart. I'm waiting on a new bus pirate to tackle this job. I keep blowing them up.

I've developed a safer solution for this. https://play.google.com/store/apps/details?id=com.adamoutler.extremebricksimulatorprofessional Be very careful.

Yeah. Which sector would you like? I can get any sector on the disk... All 16G of sectors are available... One at a time.

I think you're right. That looks like it is drawing the entire screen once per cycle. Unless there is a way to bypass the screen drawing, updates would not be possible. Still pulling the SDCard. I've got 3 parts out of 7. That .2 is coming out 0-length every time still.

Where is the code behind this menu?

That would be helpful, but it will come later. For now I'm still working on getting a backup... running into backup 2 producing a 0-length file. Got file 1, but It seems to be running extremely slowly. #!/system/bin/sh #dd if=/dev/block/mmcblk0 of=/mnt/udisk/backup.1 count=5859375 bs=512; dd if=/dev/block/mmcblk0 of=/mnt/udisk/backup.2 skip=5859375 count=5859375 bs=512; dd if=/dev/block/mmcblk0 of=/mnt/udisk/backup.3 skip=11718750 count=5859375 bs=512; dd if=/dev/block/mmcblk0 of=/mnt/udisk/backup.4 skip=17578125 count=5859375 bs=512; dd if=/dev/block/mmcblk0 of=/mnt/udisk/backup.5 s

Maybe it's not important, but there should be a way to utilize it and if we are creating custom/long-install packages, we should utilize it. I was wanting it to see progress on a multi-part DD operation.

Any chance you have seen how to increment the menu progress bar? I would assume there is a linux device somewhere which would allow for the progress/UI in copy_script to be updated.

Copy device allows you to select a device, but doesn't specify to or from. We know it deals with the internal SD, but we don't know how copy device works. I copied 3 sectors manually, then stopped. I'm not doing 16G of sectors into individual files

Mine turned off on its own after 1.5hr, it got 4.5GB For 8gb, in 3gb chunks, it only took 20-30 minutes. I'm going to try breaking it up into 6-3GB chunks. BTW, it did a 0gb to me once as well, on the same file. But that is the same script I used on the successful run. I purposefully didn't modify it and left those additional commands in place to ensure integrity.

Ah ha!!! That's it! I formatted a different thumb drive (sacrificed my Ubuntu installer), and it worked with ntfs. The image is writing now.

I tried and ntfs and ext4, at least on my thumb drive and my 8100 deck, didn't show up in file maintenance and didn't work for copyscript. There are a few partitions missing from my attempt last night so I'm trying again.

This is from my car. You can reverse the IFs and OFs and change seek to skip to flash to your deck. I'm going to combine it all tomorrow.