2 ms·

I don't understand what you're saying. The way I understand it, he managed to find a way to retrieve ids assigned to functions that have an action in game. By

by aatd86 3y ago

I don't understand what you're saying. The way I understand it, he managed to find a way to retrieve ids assigned to functions that have an action in game. By trial and error and because the ids are generated by a PRNG which he knows. He just needs to retrieve the starting state and then boom. It matters to know whether an in-game action/function is mapped to a given id, contrary to what you're claiming. Otherwise, what's the point? These ones can't not just arbitrary. That's what he is looking for. (Why these unnecessarily complex explanations is my question though.)

nkrisc 3y ago
The ids for the actions are not secret. Everyone knows them. I can go on wowhead.com right now and tell you the spell ID for any ability in the game. If I want to cast Fireball it’s spell id 133 https://www.wowhead.com/spell=133/fireball https://www.wowhead.com/spell=133/fireball It’s right there in the URL, even. The whole point was predicting the next result of random call so that it could be used to smuggle in data. He just called random until the next value was one he wanted. The secure context did not have access to the information necessary to make a good decision. However you could call random and get a number back, so if you could predict the next value then you can call it from the insecure context until the next value matches the data you want to send, then you pass control to the secure context where it calls random and assumes the the return value is the id to cast or lookup in a table for the actual id. If the return value range of random() includes 133, then no mapping is necessary. If it doesn’t, then you just hard code a mapping in the secure context function that is keyed with values it can return. It makes no difference either way.
- aatd86 3y ago
  Securzd actions have a known id but actions defined in the insecure environment have a randomly attributed id no? Anyway, that doesn't matter too much. :o) My understanding is still a bit fuzzy.

by aatd86 3y ago

nkrisc 3y ago

The ids for the actions are not secret. Everyone knows them. I can go on wowhead.com right now and tell you the spell ID for any ability in the game. If I want to cast Fireball it’s spell id 133 https://www.wowhead.com/spell=133/fireball https://www.wowhead.com/spell=133/fireball It’s right there in the URL, even. The whole point was predicting the next result of random call so that it could be used to smuggle in data. He just called random until the next value was one he wanted. The secure context did not have access to the information necessary to make a good decision. However you could call random and get a number back, so if you could predict the next value then you can call it from the insecure context until the next value matches the data you want to send, then you pass control to the secure context where it calls random and assumes the the return value is the id to cast or lookup in a table for the actual id. If the return value range of random() includes 133, then no mapping is necessary. If it doesn’t, then you just hard code a mapping in the secure context function that is keyed with values it can return. It makes no difference either way.

aatd86 3y ago
Securzd actions have a known id but actions defined in the insecure environment have a randomly attributed id no? Anyway, that doesn't matter too much. :o) My understanding is still a bit fuzzy.