Курс по С++ с уклоном в тематику форума

[weaver]

Добавил опрос на тему того, что будем писать.

Есть предположение что это будет очередная статья про стиллер. Я не малварщик и мало что понимаю в этих ваших троянах. Но чтобы писать надо наверно изучить всякие малварные техники инъекции кода. Было на много круче если бы ты сделал полный обзор. А потом уже браться за всякие стиллеры хвнц итд. Я говорю о ....

Process injection
Process Injection Thread Pools
.NET Threadless Process Injection
Process Doppelganging
Process Herpaderping
Process Hollowing
Transacted Hollowing
Process Ghosting
Process Stomping
DLL Injection
Reflective DLL Injection
DirtyVanity

итд. На каждую технику одна статья. Можно было потом бы сделать карту статей и в закреп.

Ну а если всё таки писать какой-то стиллер, то главное в статье должно быть это не сам код. А объяснить алгоритмическим языком, последовательность действий. Можно даже простым языком, даже не алгоритмическим. Таким образом можно будет видеть картину в целом, как должен выглядеть проект код в целом. А так же дать рекоментации что можно улучшить, и где черпать новые идеи. Я уже не говорю о том что люди вбивают в нейронку запрос напиши мне стиллер. А всё почему? потому что не знают алгоритма, как это программа должна выглядить объективно.

 

[вавилонец]

давайте уже на переправе коней менять не будем, вроде говорили в архитектуру с примерами на форумном гите...

объяснить алгоритмическим языком, последовательность действий. Можно даже простым языком, даже не алгоритмическим

 

[weaver]

давайте уже на переправе коней менять не будем, вроде говорили в архитектуру с примерами на форумном гите...

Толку на много будет больше, если будет алгоритм, чем код. Потому, что ты будешь сам писать свой код. Это на много полезнее и практичнее. Где алгоритмы, там и архитектура. Ведь продумывая архитектуру зловреда, условно надо накидать как это будет все выглядить алгоритмически.

Условно алгоритм может быть таким. Как пример.

1. Собираем информацию в реестре о системе
2. На основе собранной информации сгенерировать имя файла
3. Разместится в %AppData%
4. Изменить ключи реестра для автозапуска
5. Мониторить ключи и восставливать их в случае необходимости
6. Скрытие процесса в диспетчере задач
7. При остановки процесса, запуск самого себя вторым процессом.
8. Получаем системное время GetSystemTime() для генерации доменного имени (DGA)
9. Коннектимся c2c
10. Генерируем до тех пор пока не будет установлен коннект
11. Сервер генерирует 2 ключа RSA открый и закрытый
12. Скачиваем открый ключ и сохраняем его в реестре
13. Получаем список всех дисков GetLogicalDrives()
14. Определяем тип дисков
15. Ищем рекурсивно файлы по маске FindFirstFile(), FindNextFile()

итд....

 

[вавилонец]

Толку на много будет больше, если будет алгоритм, чем код.

в этом треде алгоритм и архитектура - первое ценное, потому что код без морф/крип/т.д. впалят ахнуть не успеешь, второе - общественное действо, возможно наш снежный друг проложит PATH к образованию новый крутых команд, как говорил Матросскин - "...совместный труд, он объединяет...".

 

[Whisper]

Есть предположение что это будет очередная статья про стиллер. Я не малварщик и мало что понимаю в этих ваших троянах. Но чтобы писать надо наверно изучить всякие малварные техники инъекции кода. Было на много круче если бы ты сделал полный обзор. А потом уже браться за всякие стиллеры хвнц итд. Я говорю о ....

итд. На каждую технику одна статья. Можно было потом бы сделать карту статей и в закреп.

Ну а если всё таки писать какой-то стиллер, то главное в статье должно быть это не сам код. А объяснить алгоритмическим языком, последовательность действий. Можно даже простым языком, даже не алгоритмическим. Таким образом можно будет видеть картину в целом, как должен выглядеть проект код в целом. А так же дать рекоментации что можно улучшить, и где черпать новые идеи. Я уже не говорю о том что люди вбивают в нейронку запрос напиши мне стиллер. А всё почему? потому что не знают алгоритма, как это программа должна выглядить объективно.

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

 

[Snow]

коллеги, вы все правы одновременно. Таки да, курс, в первую очередь, про технологию разработки ПО. Таки да, малварь выбрана в качестве проекта, который мы будем делать именно по причине тематики форума и, таки да, нам таки придется, в той или иной степени, изучать всё, о чем упомянул weaver

если бы ты сделал полный обзор. А потом уже браться за всякие стиллеры хвнц итд. Я говорю о ....
итд. На каждую технику одна статья. Можно было потом бы сделать карту статей и в закреп.

насчет отдельной статьи по каждой теме - это, конечно, заманчивое предложение, но тогда мне придется идти по пути инфоцыган и просить денег за статьи, поскольку они отнимают довольно много времени, в данный момент я к этому не готов.

 

[Snow]

И еще, не будет очередной статьи про стиллер. Будет описаниее архитектуры, в разработке которой всем будет предложено принять активное участие. Форумный гит - хорошо, но я таки настаиваю на связке openproject+gitlab - опять таки для подключения как можно большего количества желающих к КОМАНДНОЙ разработке, ибо прав Кот Матроскин: "совместный труд, для моей пользы, от объединяет" (вавилонец - хорошая цитата )

 

[Snow]

Ну а если всё таки писать какой-то стиллер, то главное в статье должно быть это не сам код. А объяснить алгоритмическим языком, последовательность действий. Можно даже простым языком, даже не алгоритмическим. Таким образом можно будет видеть картину в целом, как должен выглядеть проект код в целом. А так же дать рекоментации что можно улучшить, и где черпать новые идеи. Я уже не говорю о том что люди вбивают в нейронку запрос напиши мне стиллер. А всё почему? потому что не знают алгоритма, как это программа должна выглядить объективно

ну, как я и говорил ранее, нам до первого кода, как до Китая раком. Сначала вот это вот всё - выделение требований, составление ТЗ, наброски архитектуры - всё то, чего так не любят те, кто просит нейронку написать им стиллер, не вкуривая вообще що це таке. Один из основных заветов Дядюшки Боба (Роберта Мартина ) гласит: "откладываю конкретную реализацию настолько, насколько это вообще возможно".

 

[horker_kalix]

Статья крутая, уже прочитал и закинул себе библиотеку на мобилку, читать везде Snow, ты лучший, для меня как для тупого ноускильнного кодера статья максимально крутая

 

[weaver]

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

Тогда ладно... Жду главу про шеллкоды.

 

[rand]

Условно алгоритм может быть таким. Как пример.

Угу. IMHO новичков нужно прежде всего научить думать алгоритмически при подходе к написанию какого-либо ПО, а потом уже объяснять синтаксис и как оно работает это ваше программирование. По крайней мере если я за что-то приступаю, сначала рисую схему в голове или на бумажке (если много) по аналогии с алгоритмом weaver, а потом уже пишу код.

 

[Whisper]

Один из основных заветов Дядюшки Боба (Роберта Мартина ) гласит: "откладываю конкретную реализацию настолько, насколько это вообще возможно".

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

 

[Snow]

Готовь главу о - нисходящей, восходящей, сендвич и риск интеграции, что это и когда что применять, какие могут быть тут проблемы.

добавил в to do, это очень сложный вопрос, на самом деле.

В случае с малварой у вас кроме ос и библиотек есть еще и фактор ав, и все че вы там напланировали в любой момент может оказаться не жизнеспособным.

таки да, аверы нам могут сильно спутать карты. Но мы ведь хотим быть на пол шага впереди их и научиться оперативно реагировать на их попытки вставить нам палки в колёсв. Тут тоже надо думать. Если получится спроектировать такой софт... Это вообще реально?

 

[Snow]

Насчет второй главы думаю, наброски есть кой какие, но быстро не ждите. Как будет что-то вменяемое - выложу черновик.

 

[Whisper]

добавил в to do, это очень сложный вопрос, на самом деле.

таки да, аверы нам могут сильно спутать карты. Но мы ведь хотим быть на пол шага впереди их и научиться оперативно реагировать на их попытки вставить нам палки в колёсв. Тут тоже надо думать. Если получится спроектировать такой софт... Это вообще реально?

У меня в голове смешались книги - чистый код, совершенный код, соврешенная архитектура, они по сути все про одно и тоже и дополняют друг друга, поэтому не могу точно указать в какой из книг это было, а была там поучительная история про гибкость, откладывание на потом, про уверенных в себе опытных разрабов которые соснули хуя.
Перескажу в кратце своими словами:
Взялись крутые кодеры писть 2 схожие проги, поскольку проги схожие во многом они решили что сначала напишут им общую библиотеку пусть на это и уйдет много времени а потом на базе этой библиотеки быстренько соберут обе проги. Они крутые оопшники и боги абстракций архитектур и проектирования. И во значит нахерачили они свою абстрактную крутую библиотеку которая ни нашим ни вашим(проги то две) и начали ебашить проги, и тут выснилось что проги то не такие похожие как хотелось бы а либа вообще ни то ни се, и понеслось - костыли, кочующие данные, жиреющий коуплинг и худеющий кохешен, и вот сроки вышли а у пацанов на руках неработающая залупа и вместо кода который можно как то использовать - куча мусора в котором х#й проссышь че твориться, проги как бы работают но так что заказчкику лучше такое не показывать.
И пришли пацаны к выводу что без вариантов - надо все заново переписывать и сформулировали правило - сначла хоть как то работающий код, без траты времени на тесты, правила, чистоту, лишь бы работал и пох что постоянно крешит. А уже потом с нуля не используя ничего из грязного кода пишут чистый. А все потому что если проект достаточно большой и сложный то никакие методики тебе не позволят тебе все предусмотреть, о многих нюансах вы даже не подозреваете на этапе проектирования, попытка же все предусмотреть и сделать супер гибко будет равносильно подстелить соломки тупо везде, оверхед работы и вы все равно облажаетесь. Печальная истина в том что бы понять как надо было сделать - надо сначала сделать хоть какнибудь, разведка боем бл#ть. Максимально быстрый прототип и ягни всего на свете.
Про гладкую бумагу это как раз про умные принципы и приемчики в арсенале не битых.
Вот такая вот х#йня малятки.
Надесь автор нас всех научит как делать красиво и быстро.

 

[Snow]

Надесь автор нас всех научит как делать красиво и быстро.

меня самого бы кто научил...
будем пробовать, глядишь и получится чего.

 

[Snow]

сформулировали правило - сначла хоть как то работающий код, без траты времени на тесты, правила, чистоту, лишь бы работал и пох что постоянно крешит. А уже потом с нуля не используя ничего из грязного кода пишут чистый. А все потому что если проект достаточно большой и сложный то никакие методики тебе не позволят тебе все предусмотреть, о многих нюансах вы даже не подозреваете на этапе проектирования, попытка же все предусмотреть и сделать супер гибко будет равносильно подстелить соломки тупо везде, оверхед работы и вы все равно облажаетесь. Печальная истина в том что бы понять как надо было сделать - надо сначала сделать хоть какнибудь, разведка боем бл#ть. Максимально быстрый прототип и ягни всего на свете.

приведу аналогичный пример из собственной практики. Только было немного иначе. Я сначала написал рабочий кусок говна. Потом прикинул как сделать его более гибким и расширяемым. Переписал его уже по фэншую оопешному. Типа гибкость и расширяемость. А потом софт стал продаваться и продаваться довольно хорошо. Только вот возникла проблема, напрямую связанная с недостатком знаний предметной области. То есть заказчики просили расширить функционал. Но не тот, расширение которого я запроектировал. А тот, о существовании которого я даже не подозревал, шо так можно. А поскольку сроки были сжатыми и всем всё надо "вчера", то это очень быстро превратилось в очередной кусок говна, который я теперь сижу и переписываю с нуля (

 

[Whisper]

приведу аналогичный пример из собственной практики. Только было немного иначе. Я сначала написал рабочий кусок говна. Потом прикинул как сделать его более гибким и расширяемым. Переписал его уже по фэншую оопешному. Типа гибкость и расширяемость. А потом софт стал продаваться и продаваться довольно хорошо. Только вот возникла проблема, напрямую связанная с недостатком знаний предметной области. То есть заказчики просили расширить функционал. Но не тот, расширение которого я запроектировал. А тот, о существовании которого я даже не подозревал, шо так можно. А поскольку сроки были сжатыми и всем всё надо "вчера", то это очень быстро превратилось в очередной кусок говна, который я теперь сижу и переписываю с нуля (

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

 

[Snow]

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

я бы еще добавил про опыт взаимоотношений с заказчиком, на примерах из жизни. Тут, думаю, многие смогут поделиться интересными историями. Например, был у меня один заказчик, дотошный донельзя. Временами мы готовы были порвать друг друга на британский флаг. То есть он докапывался до всего, вплоть до количества пробелов или табов в файле отчета. НО!!! При всём при этом он давал очень дельные и точные советы по развитию продукта. Да, он мне вынес весь мозг. Да, сделку в гаранте здесь раз 15 продлевали, но в итоге он помог мне сделать продукт сильно лучше. Вот такие заказчики на вес золота. Главное их распознать и определить, что он не по всякой ху#не тебе мозг делает, а его требования объективны. Поскольку таких заказчиков очень легко спутать с теми, кто готов удавиться за лишнюю сотню баксов и будет тебе делать голову за всё подряд, при этом не предоставляя своего видения решения проблемы. Еще один случай из практики. Продукт продается. Количество отзывов растет. Все хорошо. Пишет чел, мол так и так, хочу купить. Схема отработана. Гарант. Условия сделки прописаны. Тестируем на моем материале - всё отлично. Тестируем на его. Вроде всё неплохо. Просит пару дней на более детальное тестирование. Потом пишет, что там то не так, это не эдак. И началось. В итоге договорились, что он отпускает сделку, а я возвращаю ему 50% от суммы. Поверьте, свои нервы и время вы не купите ни за какие бабки. Поэтому я согласился даже не думая, хотя прекрасно понимал, что меня красиво поимели на полторы штуки баксов.

 

[Whisper]

я бы еще добавил про опыт взаимоотношений с заказчиком, на примерах из жизни. Тут, думаю, многие смогут поделиться интересными историями. Например, был у меня один заказчик, дотошный донельзя. Временами мы готовы были порвать друг друга на британский флаг. То есть он докапывался до всего, вплоть до количества пробелов или табов в файле отчета. НО!!! При всём при этом он давал очень дельные и точные советы по развитию продукта. Да, он мне вынес весь мозг. Да, сделку в гаранте здесь раз 15 продлевали, но в итоге он помог мне сделать продукт сильно лучше. Вот такие заказчики на вес золота. Главное их распознать и определить, что он не по всякой ху#не тебе мозг делает, а его требования объективны. Поскольку таких заказчиков очень легко спутать с теми, кто готов удавиться за лишнюю сотню баксов и будет тебе делать голову за всё подряд, при этом не предоставляя своего видения решения проблемы. Еще один случай из практики. Продукт продается. Количество отзывов растет. Все хорошо. Пишет чел, мол так и так, хочу купить. Схема отработана. Гарант. Условия сделки прописаны. Тестируем на моем материале - всё отлично. Тестируем на его. Вроде всё неплохо. Просит пару дней на более детальное тестирование. Потом пишет, что там то не так, это не эдак. И началось. В итоге договорились, что он отпускает сделку, а я возвращаю ему 50% от суммы. Поверьте, свои нервы и время вы не купите ни за какие бабки. Поэтому я согласился даже не думая, хотя прекрасно понимал, что меня красиво поимели на полторы штуки баксов.

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