[spam][crazy][fiction][random] Non-Canon MCBoss Spinoffs

[Undescribed Horrific Abuse, One Victim & Survivor of Many]

On Sun, Feb 25, 2024 at 18:01 Undescribed Horrific Abuse, One Victim &
Survivor of Many <gmkarl at gmail.com> wrote:

> how does celebration get into traffick boss’s prison?
> 2105 02-24 -0500
>
> (happy people leak it to him because they are so happy, and then he gets
> (resentful?) and starts triggering them with memories of their torture and
> hypnotizing them to travel out and stop whatever is being celebrated (it’s
> like an angry habit?)
> 2109
>
2024-02-26 0817-0500
so to counter the old heavy anticognition/antisuccess mind control i’ve
gone back to the same area where i celebrated (possibly missed: chess post)
and parked in the same spot.
my original plan was to fix all 3 of my funny phones of the same model. i
know now i can almost certainly fix the 3rd. the 1st might have a damaged
usb socket that might get more reliable maybe with the addition of
something to pressure a cracked solder joint, unsure. the 2nd the
german-appearing one might need an exploit or maybe just secure boot
disabled unsure.
0820
0537ish (computer open, computer is -0800, ipad is -0500)
i got to the same chair and table and had a sugar thing to try to
reward/rewire my neurons to tell a better story around celebration (good
rather than bad, do again rather than avoid).
i tried out the teest points and i still get dmesg on that same testpad :D
question is: is it emmc or kpcol0? probably kpcol0 since i'm [0553: +not
yet] finding a pair, but we'll maybe see
rather than soldering it, since i don't have a soldering iron atm ([]),
i've placed tape over the other test pads to insulate them and am taping
the wire onto the one with the factory boot functionality.
0540
(the other end of the wire is screwed into the ground plane using one of
the case screws)
0540
0547
i got the wire to stay, it was hard. the approach i ended up using involved:
1. stripping the wire a little bit more (it was only stripped about 1 mm)
and bending the stripped copper over so it ran back alongside the wire and
was bundled together
2. pressing the whole wire onto the test pad with the bent wire under it,
and verifying it worked
3. taping it in place with a long tape (because the thick wire has a lot of
bounciness), pressing it with my finger, and verying it worked while pressed
4. snapping the back (without screws) back onto the phone in some spots to
replace my removed finger, and verifying it worked
now i have a phone that uses the factory bootrom when powered :D
0549
0555
i'm successfully reflashing the phone with the stock firmware from xda
using spflashtool for linux v5.2228 !
i think this means the test pad is kpcol0 as i imagine if it was emmc clock
or data then the device would not be able to communicate with the emmc
don't know for sure we'll see if it boots or something
if it doesn't i can also look for the bootrom image from the partial image
i took from it before changing it. if it's not there then i guess i might
need to reverse engineer the bootrom or something to see how to disable the
softrom manually :S
i want to start making a pic of the testpad to share on xda to find kpcol0
0558
after a reflash it still wouldn't seem to boot
so i unscrewed the test pad cable from the body, put the battery in, and
plugged it in, and watched dmesg
it vibrates now when plugged in! and it shows on dmesg with the cable
disconnected!
nothing visible on screen yet 0601
0602
i held power down for a long time and saw it reboot into the brom again on
dmesg
then another vibrate or something and it showed booting into the preloader!
still no display i wonder if i disconnected the screen when disassembling it
but i'd stil see it as android when it booted if so
0602
oh there it is cdc_acm USB acm device
so it likely booted into android but the screen is black :(
i guess i'll pull my tape and wires out, sadly, since it has a further issue
at a future time maybe i can figure out if you can hardground this pad as
one avenue when trying to secure the bootrom
0603
0605
when unscrewing the screw i was using to connect the ground wire i'm
holding my hands over my screw tray (the user-removable phone back) so that
when they spasm it will fall in
0606
ok
1. i noticed that cdc_acm shows when it is only in the preloader, so that
doesn't indicate android
2. after some time plugging in with the hijinx removed and pressing power
here and then and letting it sit to charge, the screen did eventually power
and show the logos.
it looks restored to factory :) at least, the factory from xda which is
actually newer than it came from
0607
it hasn't booted to android yet, still showing the
hide-the-kernel-messages-style logo
ok there it goes. i'll replace the wire i suppose and see if -- maybe i'll
check the battery charge first
0608
0609
the interface is really really slow :( not what i expect from a factory
situation
it's just the hello welcome to your phone interface, it takes like 5
seconds to press some of the buttons O_O not all
desktop says "NO GoogleKey" in big red letters on entry
reasonably responsive in desktop
battery is at 0%
so that dead battery may be why (0611) i'm having troubles booting. oops!
and it just powered itself off on its own while in the settings interface.
given i have 3 phones maybe i can leave it charging and swap it for a more
charged one.
0611
battery in phone 3 had s/n: A95JGH21050608886 charge at 1% when removed
battery in phone 1 has s/n: HTT2201202336
they appear to have the same model number
battery in phone 2 has s/n: A95JGH22032802018
I'm guessing the HTT battery is actually from phone 2 (the german-appearing
phone) since it has a different s/n prefix and i could have swapped them
around since they look practically identical
0616
the phone isn't booting with the HTT2201 battery in it. i'll leave it a
bit, and the other battery charging, while croppoing the fcc photo for xda
... 0617

> 0630
looks like the HTT battery was just at 0 too. they're both now at 10% or
above. i've made the attached images and am trying to figure out sending
them to xda.
0635
https://xdaforums.com/t/hot-pepper-serrano-hpp-l55b.4470523/#post-89366158
> I've been spending a little time learning to repair these phones, and I
identified
> a test pad that runs the factory bootrom when grounded. There's a
reasonable
> chance this testpad is KPCOL0, which can be used to unbrick phones. Ground
> this pad of a bricked phone, and then it should be detected by flashers
again
> to reflash a factory preloader. The pad I found is the one nearest to the
triangle
> image by the card slot on the side.
> Attachments
0637
0709
with difficulty i shortened the wire (by too much accidentally) and
eventuall jerry-rigged the phone so i could put the battery in while the
pad was grounded
although it could have slipped out again, it does indeed move from the
bootrom (idVendor=0e8d, idProduct=0003) to the preloader (idVendor=0e8d,
idProduct=2000) with this grounded and the battery in, but it doesn't seem
to boot the phone, so i guess this isn't a quick fix for preloader issues
0711
but that does mean that i can remove the funny stuff from the hardware at
least
0711
0712 ohhh my jerryrigging had the power button held down!
0713 looks like i slid the button out of its socket somehow so i'm
realigning it
0714
0715
the phone appears to be booting now with kpcol0 grounded. it loaded the
preloader, showed the logo, showed the battery charging % (powered the
display, more than i've gotten yet)
0716
yeah it's loading the kernel after holding power (slowly)
and is in android
so this can be grounded to use original preloader
my experiment now is to try reflashing with the image from another phone
and see what happens. just in case i can transfer my situation that easily.
0717
0726 spent some time trying to store the fcc pdf on my repo
0728 strangely 'git status --porcelain=2' is suddenly going incredibly
slowly right after a successful commit immediately prior
0729 there we go
0730 ok while i'm rebricking my phone maybe it can test the usb port of
phone #1 using something like the approaches in the motherboard repair video
maybe i can ground kpcol0 too if that helps
whoops one moment phone 1 is stuck in connection
hmm mtkclient is trying to use kamakiri, but it crashes after reboot
0732
0734
i ran `mtk brute` and it found var1 0xe3e8 and dumped brom_699.bin, attached
0735 it's nice to have a downloaded bootrom !
0736
0737 so i have issues when i look at the mtkclient source, because of past
attempts, but i have it opened up to try to look for paths forward
i'm interested in trying the 'wf' command to see what happens if i put the
wrong image on and the pad is grounded.
options of use:
- it can use --loader to bypass autodetection of da loader
- it can use --vid, --pid to specify the vendor id/pid of the preloader;
this might help me make it use the preloade rinstead of the bootrom or vice
versa
- it can use --debugmode to be verbose
- something called --skipwdt or --wdt [addr] to engage watchdog
- three crash modes with --mode 0/1/2 (da send1, send2, read)
- --var1 set the kamakiri var1, here is where i would pass 0xe3e8
- --*_addr for uart, da, brom
- --ptype amonet/kamakiri/kamakiri2/carbonara , kamakiri2/da used by default
- --verifystage2 to verify stage2, this could be interesting as it hangs at
stage2
- [--parttype might provide access to different regions]
- --crash enforce to crash to brom from preloader
- --auth, --cert it can actually load auth files to change signed data
0743
--debugmode is awesome ! it shows all the usb traffic!
0745
0747
i think this found at https://github.com/bkerler/mtkclient/issues/158 [i
think i found this at]
use --preloader option to provide preloader from firmware.
i just flashed firmware with a preloader in it :) it even separates the
partitions out into files
0747
0748
checking MT6739_Android_scatter.txt , although there are a number of
preloader images in the firmware bundle, the one it is flashing
is preloader_x038_k39tv1_bsp.bin . i'll pass that
0749
0750 totally worked passing this :D :). now on to the other phone while it
rebricks by reuploading the wrong image.
0754
engaging phone #1 i vaguely recall i hit 'format' in a flasher thinking it
was like a disk and i could just image and format and reflash again.
doesn't work because if you corrupt the preloader then the usb port doesn't
go up. so i guess i'll try kpcol0 first in phone #1 too.
0755 means unscrewing the back, tiny screws
0812 i got phone #1 to show up in dmsg using kpcol0. it took a little
finegling, i'm still not certain there isn't a loose connection issue
compounding.
the rebrick flash of phone #3 has 4.5 mins left (out of 30)
0819 i broke my screw connection, my new ground wire for phone #1, but
fixed it
the other flash is done. i'm going to secure this new kp0col wire before
engaging it.
0825 i manually held the wire in place during flashing and phone #1 is
booting again with the same stock firmware
i think i'll look a little bit into identifying via dmesg whether kcol0 is
pressed. i read in one post that it might be wired to a volume button and
pressable without disassembling the phone.
0826
without kpcol0, with the factory preloader, when plugged without a battery
it pauses a bit then loads the preloader device
with kpcol0, with the factory preloader, when plugged without a battery it
immdeiately shows the bootrom device, then pauses maybe for a bit longer
than without and shows the preloader device
pressing one or both volume buttons does not seem to make it behave as if
kpcol0 is grounded, nor pressing power, if held when plugged without a
battery
ok
0830
to keep things simpler, i guess i'll fully reassemble phone #1 and then
return to phone #3.
0833
it's notable that phone #1 still says "your device has been unlocked"
whereas phone #3 has not, despite having both experienced both entire
manual and factory flashing of the emmc, including the preloader regions.
maybe this unlock state is held in the mediatek chip and not the emmc.
0834
0835
when going to reassemble the phone i'm noticing a few of the screws are
long (maybe 4) whereas most are shorter. uh-oh.
0835
maybe i'll try the long screws in all the screw places, see where they fit.
gently.
0837 long screw #1 fits by the sd card slot
0839 two long screws fit at the bottom of the phone near the speaker.
helpfully this phone repair screwdriver is magnetic, really helps with
shaking hands
i don't know if these long screws actually go where i'm putting them. i
could be damaging things. one idea is when the head sits low it's a good
sign.
0840
0841 i put the last long screw in the upper left corner because there
weren't many screws near it. it seems like they fit multiple places.
0845 i have 5 screws left. i'm daydreaming a little on adding a hole to the
back of the phones to access kpcol0. with it marked on the fcc photos, you
could pretty much figure out where to place it, maybe
0848 phone #1 is reassembled and functional with factory image
i think i'll dump it's brom before moving back to phone #3 to compare their
checksums
0853 mtkclient doesn't like it, one of the issues appears to be that it's
skipping the bootrom. i should have done this with kcol0 held.
back to phone #3
0859 it's about 1200 est. i paid only for 4 hours of parking, the max. i
did it the same as the celebration event, to [try to] help :). it seems
unideal to go, unsure.
0900 i reflashed all partitions of phone #3 to factory except for userdata
and cache and it still won't light the display. just realized i don't have
a battery in it.
0901 lights as soon as battery is inserted. i guess the experiment is
incomplete, since i'd have to image it again
let's call this a success and leave just in case of parking fines :S what
um do i want a working phon esituation to be, between phones 1 and [0902:
3]?
oh let's try imaging phone #1 with its old image
also i'll unlock phone #3
0902
0903 uhhhh i jiggled the usb cable while plugged when mtk was waiting for
kamakiri and it started the kamakiri while i was unplugging it and now it
doesn't show up on dmesg anymore despite kpcol0 being grounded >_>
> [110921.813283] usb 1-2: device descriptor read/64, error -71
> [110921.914297] usb usb1-port2: attempt power cycle
0906
i reset the host system but it looks like what was needed was removing the
battery from the device
0907 i unlocked device 3 using `mtk da seccfg unlock
--preloader preloader_x038_k39tv1_bsp.bin`
0908
0908 device 3 still has its screws out. it has kpcol0 hardwired now, but
the wire i found at a hardware store (the wire salesperson wasn't in yet)
is pretty thick and the back might not fully screw on
maybe i'll close it up as-is the best i can. lotsa screws. oh maybe i can
use the long screws for the bulging parts.
i should probably make notes on the states of these phones :S
0909
0910
waitaminute, the slots on this phone are covered in tape. that makes it not
usable as a phone. maybe i'll leave the screws taped to it by the battery
or something
0914 i've made notes for phone 3 and uploaded to git,.
i'm flashing phone 1 with an image. it actually succeeded running kamakiri
without arguments this time. i had the battery in.
reviewing it wasn't using kamakiri, it was using DA. (DAXFlash - Uploading
xflash stage 1 from MTK_DA_V5.bin ; then it patches it a bunch, and jumping
to stage 2 succeeded).
i guess i didn't get to phone 2 today, but i'm thinking that kamakiri would
likely require opening it and grounding kcol0 again, could be wrong.
{went to xkcd, still has friday's regarding middle views, thinking randall
might have accidentally made a pro-conflict comic. it is of course a
notable point that there are a few situations where one view is clearly
more true than another, i wouldn't agree that the bulk of our society and
research would benefit from that view.[one way we thought of holding
together "the sun moves around the earth" and "the earth moves around the
sun" is speaking of different experiences: "the sun moves around the earth"
would be talking about the visual and living experience of the sun's
relative position moving around the earth every day. since we live on the
earth, this is incredibly useful for daily planning. meanwhile, "the earth
moves around the sun" relates to more of an absolute-location view; it's
the coordinate assumption that produces the simplest and clearest
description of all the bodies of the heavens together, and is incredibly
useful when you are planning around anywhere other than life on the surface
of the earth.][possible mistakes; the guess to express was shorter than the
resulting expression.][sorry for expressing out of context-topic here :)]}
0924 19 minutes left flashing backup back to original device.
i guess i'm thinking of trying device #2. maybe not unsure.
basically, since DA mode is used so far for flashing with kcol0 set, it
won't work with phone 2 because i don't know what DA has the right
signature. the flashers try DAs that are rejected.
meanwhile, opening it to ground kcol0 could take some time.
0925
maybe i could reopen phone #3 and ground it to get the bootrom?
maybe i'll look at the bootrom a little bit :S
0943
so i reflashed phone 1 with a backup taken from it,
and it's again acting bricked. no usb device.
strange. maybe i don't understand the imaging process well. i'm curious
what could possibly be wrong.
i guess it would make sense to ground kcol0 on this phone so as to
troubleshoot the issue
but i guess i'm done for now and will close out! happy monday!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 20706 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20240226/43e41ccd/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: STS2103148-003-KPCOL0.png
Type: image/png
Size: 259408 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20240226/43e41ccd/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: STS2103148-006-KPCOL0.png
Type: image/png
Size: 320781 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20240226/43e41ccd/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: brom_699.bin
Type: application/octet-stream
Size: 131072 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20240226/43e41ccd/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: preloader_x038_k39tv1_bsp.bin
Type: application/octet-stream
Size: 120420 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20240226/43e41ccd/attachment-0003.bin>