The goal, as far as I can tell, is to have a successful appraisal that sees "type=gold" in the decrypted text

Requests begin with a 07, and start being read at byte #5
Appraisals begin with a 08, and start being read at byte #5
(I don't think the contents of byte 2, 3, and 4 matter at all)
Both stop reading until either the packet ends or they hit an FF.
(The appraisal packets sent from the game contain a bunch of unused garbage data if you're using a short holder name, everything after the first FF can be ignored)

Requesting a certificate will get you an encrypted text back, which when decrypted, is in the form of `authority=CrackerFour/serial=#######/holder=whateveryouput/type=silver`
It's decrypted in 16-byte chunks of characters, so if you compare two encrypted texts, you'll notice they always have the same first 16 bytes (`authority=Cracke`)

Appraisal is refused if the authority isn't "CrackerFour", or the type isn't "silver" (or "gold", presumably)
However, appraisal is not refused if there's no type field at all (possibly if there's no authority field either, but that's seemingly impossible to cause), only if the field exists and has an unexpected value
The serial field doesn't have to be only numbers or anything

Appraisal/requests don't seem to mind if the same field is defined more than once, or nonsense fields. If defined more than once in a request (like multiple holder), only the last one is kept for the new certificate
However, they are refused if there's an unfinished declaration (like, if there is a forward slash, there needs to be an equals sign after it)

When you request a certificate, you can:
Omit the "type" field entirely, but it will be filled in with "undefined" and appraisal will get refused, doesn't seem useful
Modify the "holder" field, but you can't use /, =, or FF in it

My current suspicion is that you need to do something like this, by transferring the final 16-byte chunk from a different certificate:
```
authority=Cracke
rFour/serial=391
2928/holder=This
istehurn!!/type= -snip-
gold/type=silver <--- "gold" from the tail end of a name
```
This is the only way I can see to get the string "type=gold", assuming the type=silver right after it wouldn't ruin it.

But, transplanting doesn't seem to work all the time.
I don't quite understand what prevents it from working. If I modify one byte of some random input, only the line that byte was on gets corrupted; the ones after it are fine. So that suggests you should be able to copy those future lines somewhere else and they'd still work. But it's not that simple...

I'm thinking that perhaps, each line's result is based on the bytes of the previous line. For instance, if I copy the first two lines over and over again, Line #1's will be corrupted but Line #2's will be fine; this is because Line #2 uses the undeciphered bytes of Line #1 to decrypt itself?
But then why does modifying one byte only corrupt that one line? Shouldn't it also corrupt the next one?
And can this "gold/type=silver" transplant work at all?

I've been using the Repeater tab in Burp Suite, with a copy of each packet type sent over there, so you don't need the proxy server on to intercept/mess with packets.
And a lot of decoding/encoding from base64 is needed, the Decoder tab is kind of annoying but useful, I also had websites open for encoding/decoding base64, plus encoding hex bytes to base64 ( https://cryptii.com/pipes/hex-to-base64 ) for when I was transplanting groups of 16