Боря программирует

TON Hack Challenge

Поучаствовали сегодня в TON Hack Challenge. Было весело (по крайней мере мне)! Участникам дали 8 смарт-контрактов, в каждом из которых есть баг, который позволяет забрать из него все деньги. Причем контракты лежат а реальном блокчейне TONа, и на них есть реальные деньги (суммарно 30к TON = 34к$). Так что если вы поняли, как воспользоваться багом, сразу можете перевести выигрыш на свой кошелек.

Такой формат выглядит довольно прикольно, явно добавляет азарта во время соревнования. Но есть и обратная сторона — если вы решили задачу вторым, то выигрываете 0. У нас, собственно, так и получилось. Почти во всех задачах мы нашли баги и придумали нужные идеи, но не смогли их реализовать. Тут явно не хватило реального опыта взаимодействия с продакшен контрактами в реальном блокчейне (из него у нас только "я вчера за вечер научился отправлять запросы через какую-то javascript библиотеку"). А соревноваться в скорости с людьми, которые что-то делают с TON-ом каждый день, очень сложно.

Интересно, можно ли придумать схему, в которой участники, которые решили задачи медленнее, тоже что-то получают? Не понятно как это реализовать технически. Все транзакции в блокчейне публично доступны, так что когда кто-то решил задание, другие смогут понять, как он это сделал. И ничего не мешает человеку, который уже решил задание, получить выигрыш еще раз с другого аккаунта.

Расскажу еще кратко про наш прогресс по некоторым заданиям, вдруг будет интересно. Сами задания (и решения) можно посмотреть тут.

1. Mutual funds. Почти сразу поняли, что проблема в отсутствии impure у функции authorize, так что нужно только составить нужный request. Request потом кладется в c5. Что такое c5? (Этот вопрос же явно не возникает у людей, которые пишут смарт контракты каждый день?). Ага, с5 это output actions. А какой у него формат? Вроде бы какой-то связный список из действий, которые будут исполнены, но где бы найти его точное описание? У TON-а явно есть проблема с тем, что документация все разбросана по разным местам, и никогда не знаешь, где именно найдешь ответ на свой вопрос. Какой-нибудь TL-схемы с форматом output actions мы так и не нашли, поэтому просто запустили какой-то другой контракт локально, который их генерирует и смотрели, как они выглядят. Начали пытаться сформировать такие же клетки руками, но на этот момент кто-то уже успел взломать контракт, так что смысла в этом уже не было.

3. dao. Баг с отрицательным количеством голосов мы тоже нашли довольно быстро, оставалось только им воспользоваться. Естественно, пока я разбирался в каком формате что нужно отправлять, этот контракт тоже уже кто-то взломал.

4. Lottery. Из первых 5 контрактов этот не взламывали дольше всего. И тут опять же идейно все было понятно. По сути было две задачи. Нужно подобрать seed, что set_seed(seed); rand(10000) = 7777 было бы правдой. А потом понять, как предсказать cur_lt() во время транзакции. Цикл, чтобы найти нужный seed, я написал довольно быстро, осталось разобраться с cur_lt(). Для начала мы не знали, что это вообще такое. И тут происходит стандартная цепочка по поиску документации. Идешь в stdlib.fc, видишь, что интересует asm функция LTIME, идешь в tvm.pdf. Там написано, что это "logical time", а еще что это "GETPARAM 5". Отлично, а что делать с этой информацией? Как это связано с реальной жизнью и откуда он вообще берется не очень понятно. Потом мы нашли, что какой-то "LT" показывается во всяких explorer-ах с транзакциями, и что в принципе текущий lt можно узнать через javascript библиотеку. Но как он связан с тем, который будет потом, когда будет исполняться наша транзакция? Экспериментально мы установили, что с момента его получения в коде, до исполнения транзакции он увеличивается на несколько миллионов и два. Но угадать на сколько миллионов, видимо, сложно. Мы подумали, что можно было бы посылать internal сообщения не через стандартный кошелек, а через свой собственный, который бы в коде вычислил cur_lt, но деплоить свои кошельки мы не умели =/ В общем, к этому моменту уже кто-то и эту задачу решил.

👍7🔥2

www.tgoop.com/bminaiev_blog/19

2.15K viewsOct 23, 2022 at 18:15

TON Hack Challenge

Поучаствовали сегодня в TON Hack Challenge. Было весело (по крайней мере мне)! Участникам дали 8 смарт-контрактов, в каждом из которых есть баг, который позволяет забрать из него все деньги. Причем контракты лежат а реальном блокчейне TONа, и на них есть реальные деньги (суммарно 30к TON = 34к$). Так что если вы поняли, как воспользоваться багом, сразу можете перевести выигрыш на свой кошелек.

Такой формат выглядит довольно прикольно, явно добавляет азарта во время соревнования. Но есть и обратная сторона — если вы решили задачу вторым, то выигрываете 0. У нас, собственно, так и получилось. Почти во всех задачах мы нашли баги и придумали нужные идеи, но не смогли их реализовать. Тут явно не хватило реального опыта взаимодействия с продакшен контрактами в реальном блокчейне (из него у нас только "я вчера за вечер научился отправлять запросы через какую-то javascript библиотеку"). А соревноваться в скорости с людьми, которые что-то делают с TON-ом каждый день, очень сложно.

Интересно, можно ли придумать схему, в которой участники, которые решили задачи медленнее, тоже что-то получают? Не понятно как это реализовать технически. Все транзакции в блокчейне публично доступны, так что когда кто-то решил задание, другие смогут понять, как он это сделал. И ничего не мешает человеку, который уже решил задание, получить выигрыш еще раз с другого аккаунта.

Расскажу еще кратко про наш прогресс по некоторым заданиям, вдруг будет интересно. Сами задания (и решения) можно посмотреть тут.

1. Mutual funds. Почти сразу поняли, что проблема в отсутствии impure у функции authorize, так что нужно только составить нужный request. Request потом кладется в c5. Что такое c5? (Этот вопрос же явно не возникает у людей, которые пишут смарт контракты каждый день?). Ага, с5 это output actions. А какой у него формат? Вроде бы какой-то связный список из действий, которые будут исполнены, но где бы найти его точное описание? У TON-а явно есть проблема с тем, что документация все разбросана по разным местам, и никогда не знаешь, где именно найдешь ответ на свой вопрос. Какой-нибудь TL-схемы с форматом output actions мы так и не нашли, поэтому просто запустили какой-то другой контракт локально, который их генерирует и смотрели, как они выглядят. Начали пытаться сформировать такие же клетки руками, но на этот момент кто-то уже успел взломать контракт, так что смысла в этом уже не было.

3. dao. Баг с отрицательным количеством голосов мы тоже нашли довольно быстро, оставалось только им воспользоваться. Естественно, пока я разбирался в каком формате что нужно отправлять, этот контракт тоже уже кто-то взломал.

4. Lottery. Из первых 5 контрактов этот не взламывали дольше всего. И тут опять же идейно все было понятно. По сути было две задачи. Нужно подобрать seed, что set_seed(seed); rand(10000) = 7777 было бы правдой. А потом понять, как предсказать cur_lt() во время транзакции. Цикл, чтобы найти нужный seed, я написал довольно быстро, осталось разобраться с cur_lt(). Для начала мы не знали, что это вообще такое. И тут происходит стандартная цепочка по поиску документации. Идешь в stdlib.fc, видишь, что интересует asm функция LTIME, идешь в tvm.pdf. Там написано, что это "logical time", а еще что это "GETPARAM 5". Отлично, а что делать с этой информацией? Как это связано с реальной жизнью и откуда он вообще берется не очень понятно. Потом мы нашли, что какой-то "LT" показывается во всяких explorer-ах с транзакциями, и что в принципе текущий lt можно узнать через javascript библиотеку. Но как он связан с тем, который будет потом, когда будет исполняться наша транзакция? Экспериментально мы установили, что с момента его получения в коде, до исполнения транзакции он увеличивается на несколько миллионов и два. Но угадать на сколько миллионов, видимо, сложно. Мы подумали, что можно было бы посылать internal сообщения не через стандартный кошелек, а через свой собственный, который бы в коде вычислил cur_lt, но деплоить свои кошельки мы не умели =/ В общем, к этому моменту уже кто-то и эту задачу решил.

BY Боря программирует