Crash when used in Burp proxy

[pwntester]

Hi,

Im using the trial version to evaluate kindavim but when I use it on any Burp Proxy (https://portswigger.net/burp/communitydownload) window (for example to edit a request on the Repeater tab), it crashes kindavim

It is a Java GUI app if that helps.

Other than that, really excited about the project idea and looking forward to subscribe to it if it works for me

[godbout]

hola!

good news is i can reproduce. bad news is this is a Java app ☹️

i was excited to see why it crashed because i'm guarding against all the possible shits that can happen so i'm always very curious. well, it seems that Burp is using Windows style line-breaks \r\n and everything explodes. not sure why yet. i hope it's on my side and not the macOS Accessibility that therefore returns wrong length etc., because else there would be not much we could do. except if there's an option in Burp to change that?

i'll have a better look tomorrow. (and will add Burp to The Wizard for kV23. if you have no idea what i mean that's fine for now!)

[godbout]

it seems it's doing some custom key remapping also, so the Key Mapping Family doesn't work, and the 911 crashes. till now i was able to catch all the apps through the 911 last resort. maybe Burp is gonna be the winner. anyways, more in the following days.

[godbout]

posted on their forum, let's see what they say: https://forum.portswigger.net/thread/wrong-linefeed-under-macos-is-breaking-the-accessibility-apis-eaf8e02e?CategoryId=bug-reports will still investigate more on my side, but tbh this is a hard case. kV crashes because the length reported by the Accessibility API is different from the real length of the text. i'm not sure if it's even possible to counter that. not to make it work, but even just to avoid the crash without breaking or slowing the whole kindaVim. sad.

[godbout]

after some more investigation, it happens that the Key Mapping Family doesn't work because the option key doesn't work in Burp. or at least it's not macOS standard again. not sure if they override for something else. will flood their forum.

[godbout]

i hope i have been polite enough: https://forum.portswigger.net/thread/under-macos-keyboard-shortcuts-using-option-don-t-work-in-burp-s-text-areas-07aaca09?CategoryId=bug-reports

[godbout]

if we can get the Key Mapping to work, that would be great already i believe. unfortunately you wouldn't have all the best Vim moves goodies as as long as they don't fix that Windows linefeed, we'll not be able to do text calculations, but at would you be able to use the most common moves. let's think and pray.

[godbout]

something a bit cooler tho:

https://user-images.githubusercontent.com/121373/171929697-a5e109ed-d5da-46b9-9a16-aca1cd10c6bc.mp4

(there's still issues on the last line. it doesn't crash but moves don't work. haven't dug yet. but having the proper macOS linefeed encoding already solves a lot of issues.)

[godbout]

btw if this was not clear in the video above, things work fine once we replace the Windows linefeed encoding by the macOS/Linux one.

[pwntester]

Thanks for looking into it. How did you change the line feed? Can I do the same?

[godbout]

Thanks for looking into it. How did you change the line feed? Can I do the same?

you could, but it's definitely not a sustainable solution.

what i did was showing the non printable characters, then replacing manually the \r\n by \n. this will still fail (but not crash) on the last line, because the returned length is still wrong. you can solve this by adding a \n on the last line too, so that your text actually ends up with an empty line.

[godbout]

i had a quick look intro trying to replace the Window encoding by the macOS/Linux one programmatically, but it didn't work. i'm not sure also about side effects. like what about if you had \r\n in the text, rather than as the linefeed encoding? i guess it definitely would have to be escaped, but my experience is: don't make assumption, you're always gonna eat shit you don't expect 😂️

i'll look into that a bit more, while we wait for Burp to do something.

[godbout]

anyways it's not stable for now. if i were you i would add Burp into the Off Family for now, so that kV doesn't crash. (still a bit sad about that one ☹️)

[godbout]

(brain dumping here.) a sustainable solution would be for Burp to at least, in their Preferences, allow Burp to use the standard, OS linefeed encoding. would be \r\n on Windows, and \n on macOS/Linux. then it'll be all fine. the other good thing would be for them to use the standard macOS keyboard shortcuts (https://support.apple.com/en-us/HT201236). currently Burp is doing its own funky stuff. when the text is not readable and writable, kV needs to revert to basic key remapping (the Key Mapping and 911 Families). so like 0 is translated to control a, which goes to the beginning of a physical file line. but Burp overrides all that, doing weird stuff.

[godbout]

i'm gonna make a few changes in the Accessibility engines so that at least kV doesn't crash when used in apps like Burp. will see if i can also make some moves work. but might not be able to get all of them working. next release should be available next week, should help a bit already.

[godbout]

kV24 should be out tomorrow. from the manual tests i've done, no crash should happen anymore. you can move around using the Accessibility Strategy (don't add Burp to any Family). but current Visual Mode and moves that go to the beginning/end of line will not work, as the line delimiter is still the macOS one, not the Windows one.

let me know then how you feel using kV24. i'll keep checking what i can do on my side.

[godbout]

Burp answered on the forum btw.

1. regarding the Windows encoding, they're currently saying we need to delete them manually...: https://forum.portswigger.net/thread/wrong-linefeed-under-macos-is-breaking-the-accessibility-apis-eaf8e02e?CategoryId=bug-reports
2. there seems to be option for the key remapping, but i couldn't make it work when i checked the first time. will try again. maybe you can have a look there too? https://forum.portswigger.net/thread/under-macos-keyboard-shortcuts-using-option-don-t-work-in-burp-s-text-areas-07aaca09?CategoryId=bug-reports

[godbout]

2. there seems to be option for the key remapping, but i couldn't make it work when i checked the first time. will try again. maybe you can have a look there too? https://forum.portswigger.net/thread/under-macos-keyboard-shortcuts-using-option-don-t-work-in-burp-s-text-areas-07aaca09?CategoryId=bug-reports

for the key remapping, there's indeed some place in Burp's settings. but you can't remap using option only, and command is grabbed as control by Burp. so basically nothing's standard.

[godbout]

out: https://github.com/godbout/kindaVim.theapp/releases/tag/24

[pwntester]

Thanks!! Will try it out later!

[godbout]

they've raised the key mapping issue (non standard macOS) as bug. so hopefully a fix will be coming in Burp: https://forum.portswigger.net/thread/under-macos-keyboard-shortcuts-using-option-don-t-work-in-burp-s-text-areas-07aaca09?CategoryId=bug-reports

[godbout]

regarding the Windows encoding, this is due to HTTP/1 specification. that makes a lot of sense: https://forum.portswigger.net/thread/wrong-linefeed-under-macos-is-breaking-the-accessibility-apis-eaf8e02e?CategoryId=bug-reports

so this needs to be resolved on Apple's side, or in kV.

@pwntester have you tried kV24? how does it go?

[pwntester]

@pwntester have you tried kV24? how does it go?

Its working which is great! but its doing weird things. For example:

• x removes two characters instead of one.
• d$ removes the new line character as well
• diw on the first word of a line, removes line break from previous line
• ... I guess this is all related with there non-standard config and their windows line-endings, but its great to be able to use modal editing any how so huge thanks!

[pwntester]

BTW, Im not using any family, should I?

[godbout]

BTW, Im not using any family, should I?

as stated in The Wizard, currently no Family needed no. at a later stage, when they fix the bug with the macOS standard key mapping, probably the best will be to add it to the Key Mapping Family. but you will not have all the Vim moves.

[godbout]

• x removes two characters instead of one.
• d$ removes the new line character as well
• diw on the first word of a line, removes line break from previous line
• ... I guess this is all related with there non-standard config and their windows line-endings, but its great to be able to use modal editing any how so huge thanks!

so yes, like stated in a few comments above, basically it doesn't crash anymore and should move around properly. but stuff deal with linefeeds are gonna break. even the Visual Mode, because it works on lines and the linefeed encoding is wrong, it V takes the whole paragraph... i was waiting for Burp's answers on the forum. now i get that nothing is gonna change there. nothing is gonna change on Apple's side either. so i'll have to see if i can make kV more robust with that Windows encoding. will try to improve it for the next release.

that being said, where are you using it? in the repeater, x and diw work here. d$ doesn't because he doesn't stop at the linefeed for now.

https://user-images.githubusercontent.com/121373/173895993-4bb21dda-49bf-4831-b012-581b551a4c43.mp4

[godbout]

i've made more changes that didn't require a big rewrite. some more moves will work. but some will still not work properly for now. those changes will be available in kV25.

i need to investigate deeper parts of the Accessibility engine to get more moves working, if possible at all. i will probably research next week.

[godbout]

kV25 out: https://github.com/godbout/kindaVim.theapp/releases/tag/25

[godbout]

@pwntester any update on the usage? how is it going.

[pwntester]

@godbout tbh, I could not try it because, since I was still evaluating it, its sleeping on work hours 😄 I will make a reminder to give it a try this evening and will let you know how it goes

[godbout]

@pwntester wait. it's sleeping after 1pm??? should be from 5am to 1pm, your own local time. let me know if it sleeps after that. if yes that's a bug and i'm gonna have to kick kV's ass.

thanks for following up! making kV more resilient with weird encodings is still in my todo list, it's just a bit of hard work so i just wanna make sure it's useful :D gracias!

[godbout]

also, you're only using it on Burp?

[pwntester]

No, you are right, it wake up at 1pm, but because Ive not been using it during the morning, I completly forgot about it 😓 But will try later today (in 30 mins).

Burp is one of the apps I tried back in the day, but another app I want to try today is LogSeq (Electron)

[pwntester]

I just tried it and it works much better than it used to do, thanks!

However, there are two carets shown at the same time (insert and normal modes?) and its confusing to see how any operations is going to be applied. Also, as you can see in this video, these carets get out of sync

https://user-images.githubusercontent.com/125701/176686604-011545e6-ef5b-489a-90cb-b595763c87e6.mov

[pwntester]

For Logseq, it seems to work pretty well too but I miss having a different caret for normal mode, commands such as diw and being able to define new operators such as adding surrounding characters. Would that be possible in the future?

[godbout]

but because Ive not been using it during the morning, I completly forgot about it 😓

oh interesting. didn't not foresee this.

Burp is one of the apps I tried back in the day, but another app I want to try today is LogSeq (Electron)

yes, Logseq is handled. you can always add (or send from the menu icon) an app to The Wizard and see what kV suggests you. see:

for example it tells you that if you use the Electron Family, you have the full kV experience on a per line basis. to go from one line to the other, use press fn while using j/k.

[godbout]

However, there are two carets shown at the same time (insert and normal modes?)

the insert caret is, again, a custom shit from Burp. fucking hell. try without kV, the same thing will happen when you select text... they're still showing a custom caret. this will be impossible to remove.

and its confusing to see how any operations is going to be applied. Also, as you can see in this video, these carets get out of sync

yeah i mentioned this earlier, the last line is still not working properly, but you shouldn't have an issue with all the other lines. have you checked the Preferences, and try to show the Characters Window? that should help to where in which mode or move you're in. you have several options for positioning the Characters Window. (the one in the video comes in kV27.) see below:

https://user-images.githubusercontent.com/121373/176716017-67e16cb6-0eaf-4a53-a3b4-4f63cbca914d.mp4

[godbout]

For Logseq, it seems to work pretty well too but I miss having a different caret for normal mode, commands such as diw and being able to define new operators such as adding surrounding characters. Would that be possible in the future?

ok this one i need more precision, because it's confusing to me. see below.

I miss having a different caret for normal mode

you mean different caret from Normal Mode to what? Visual Mode? or you mean different from macOS and/or the app you're into? currently kV uses the default macOS caret selection yeah. writing a custom one (and not using the default) will/would be a lot of work, if possible.

commands such as diw

diw is implemented, both for the Accessibility Strategy (https://github.com/godbout/kindaVim.theapp/blob/master/AccessibilityStrategyImplementation.md#accessibility-strategy) and for the Keyboard Strategy (https://github.com/godbout/kindaVim.theapp/blob/master/KeyboardStrategyImplementation.md#keyboard-strategy). it doesn't work in your case?

if you're missing other moves, please specifically list them, and i will implement them.

being able to define new operators such as adding surrounding characters.

i'm not sure what you mean by "define new operators". custom mappings? regarding the surrounding, are you talking about the surround plugin (https://github.com/tpope/vim-surround)?

the surround plugin could be added. but because i'm not using a Vim backend but using all of macOS APIs to act like Vim, that would need to be implemented from scratch. which is possible. the only thing i don't want to do is add stuff that are "people's specific". i want kV to come as vanilla as possible. but i can make plugins optionals, and the surrounding one could be one of them, yes.

mostly with kV, most of the current moves there are are firstly moves i use myself. then moves asked by users. i'm open to add more stuff definitely, if it's requested and make kV better.

[godbout]

new forum post regarding the insert caret issue when text is selected: https://forum.portswigger.net/thread/the-insert-caret-shows-up-even-when-text-is-selected-44379985?CategoryId=bug-reports

[pwntester]

yeah i mentioned this earlier, the last line is still not working properly, but you shouldn't have an issue with all the other lines. have you checked the Preferences, and try to show the Characters Window? that should help to where in which mode or move you're in. you have several options for positioning the Characters Window. (the one in the video comes in kV27.) see below:

Thats pretty cool, will give it a try for sure

oh interesting. didn't not foresee this.

Yep, when I get the second or third "please not disturb Im sleeping" because I unconciously press jk I quit kV and then dont get to test it later in the day

for example it tells you that if you use the Electron Family, you have the full kV experience on a per line basis. to go from one line to the other, use press fn while using j/k.

I was using the mapping strategy but will give the per-line accessiblity strategy a go since it seems way better (and does show a different caret for normal mode)

the insert caret is, again, a custom shit from Burp. fucking hell. try without kV, the same thing will happen when you select text... they're still showing a custom caret. this will be impossible to remove.

oh man, 🤦🏼

it doesn't work in your case?

diw was not working, but as I said I was using the mapping strategy

the surround plugin could be added. but because i'm not using a Vim backend but using all of macOS APIs to act like Vim, that would need to be implemented from scratch. which is possible. the only thing i don't want to do is add stuff that are "people's specific". i want kV to come as vanilla as possible. but i can make plugins optionals, and the surrounding one could be one of them, yes.

That would be great, I use it a lot to add delimiters such as backticks in markdown files or double square brackets in wikilinks (obsidian, logseq, etc.)

Thanks a lot for all your work

[godbout]

Yep, when I get the second or third "please not disturb Im sleeping" because I unconciously press jk I quit kV and then dont get to test it later in the day

interesting. i would have expected people to then test it in an afternoon (or more) and seeing/deciding quite quickly if kV is worth to them or not. maybe in your case kV doesn't actually bring you much value? (which is totally fine.)

diw was not working, but as I said I was using the mapping strategy

diw is implemented in both Strategies. so it would help if you let me know what was the situation, or when it happens again.

That would be great, I use it a lot to add delimiters such as backticks in markdown files or double square brackets in wikilinks (obsidian, logseq, etc.)

i see. thanks for letting me know.

[godbout]

diw is implemented in both Strategies. so it would help if you let me know what was the situation, or when it happens again.

ok i think i got it. should work now in the Keyboard Strategy as well in kV27. will be out today.