?

Log in

No account? Create an account
Записки ироничного джентльмена
Мы джентельмены если есть удача...
Китайские машины. 
14th-Jan-2014 11:56 am
Default
Камент получился слишком длинный, так что я решил его вывесить отдельным постом.

Китайский автопром можно и нужно воспринимать всерьёз, но не поэтому, что китайско-израильское Qoros 3 получило 5 звёздочек в европейских краш тестах.

Для начала Китай самый быстро растущий рынок и кроме того уже вроде бы официально самый большой по количеству продаваемых ежегодно автомобилей. Во вторых многие крупные конторы уже наладили там не только сборку автомобилей, но и производство запчастей. В третьих иностранные фирмы не владеют своими заводами в Китае, каждый иностранец обязан скооперироваться с местными производителями. То есть реально в Китае уже практически отстроена огромная производственная база, которая пока работает на Китайский рынок.

Но учитывая особенности китайского рынка больше всего стоит переживать АвтоВАЗу и Тате когда китайцы пойдут на внешний рынок в первую очередь они сожрут нишу этих ребят.

Более того Great Wall уже бороздят российские просторы, но пока люди привыкшие в АвтоВАЗу отзываются о китайский машинах матерно.
Comments 
16th-Jan-2014 07:41 pm (UTC)
//Ну, stack overflow - это все-таки не запись в чужую память.
Хммм... а что? Я был уверен, что stack overflow это когда программа пишет в память вне место отведённого для этого операционной системой. Что в общем то не страшно, при условии что оно не записывает поверх чужих данных, которые туда были записаны с разрешения операционной системы.
16th-Jan-2014 07:49 pm (UTC)
Нет, это ровно то, как оно и называется - переполнение стэка. Следствием этого может являться как аварийное завершение программы, так и успешная запись в "не ту" память.

https://ru.wikipedia.org/wiki/%D0%A1%D1%82%D0%B5%D0%BA_%D0%B2%D1%8B%D0%B7%D0%BE%D0%B2%D0%BE%D0%B2


Edited at 2014-01-16 07:50 pm (UTC)
16th-Jan-2014 07:54 pm (UTC)
// запись в "не ту" память.
Именно это я и имел в виду. Если верить той статье то анализ показал использование до 92% памяти в то время, как тойотовские ребята считали что там не больше 50%. Думается мне, что это наиболее вероятный ответ, потому как если бы что-то было в алгоритмах, они бы таки это откопали при проверке.
Хотя конечно, я человек довольно далёкий от программирования, и вообще маску на стройке нашёл.
16th-Jan-2014 08:00 pm (UTC)
> потому как если бы что-то было в алгоритмах

Так ведь stack overflow на ровном месте не случается, это вещь всегда рукотворная.
16th-Jan-2014 08:07 pm (UTC)
Я исхожу из того что я видел... в мою бытность в универе, в мою обязанность младшего помошника эникийщика входило обходить утром лаборатории и проверять компьютеры. Каждое утро я там обнаруживал две или три синенькие NT, я их перезагружал, на следующие день синели опять две или три машины, но уже на следующих компьютерах. Когда лабы за апргейдились до Вынь2к синенькие машины практически исчезли, а когда появлялись в большинстве случаев означали умирающее железо.
И из рассылок freebsd "срочно пчтесь, в sendmail обнаружен очередной buffer overflow, с потенциальным получением прав админа"

16th-Jan-2014 08:48 pm (UTC)
Ну так а в чем портиворечие - синий экран смерти обычно вызван ошибками в ОС или драйверах.

А buffer overflow и stack overflow - таки немного (или много) разные вещи. В общем случае непонятно, какой адрес окажется в стэке в момент его переполнения и кому он принадлежит, поэтому эта ситуация уявзвимостью не считается. Переполнение же определенного буфера (области памяти) в программе - вещь исследуемая и предсказуемая, потому что перепоняется буфер в нашей собственной программе, а не в чужой, соответственно, ОС не предпринимает никаких действий по защите (она резонно считает, что со своей памятью программа должна сама разбираться). Поэтому достаточно изучить, где в скомпилированной программе какой буфер и как далеко после него находится какой-нибудь исполняемый код. Дальше готовится код, который туда нужно поместить (который будет что-то делать, нужное нам) и генерируется последовательность данных, которая и засылается в атакуемый sendmail, который, в итоге сам себя модифицирует тем, что ему прислали, и передает в эту область кода (уже чужого) управление.

Знаменитый червь Моррисона именно это и использовал. Почти 30 лет прошло, а до сих пор не вымерли программисты, которые не проверяют длину принимаемых/пересылаемых данных. Повбывав бы. :)
16th-Jan-2014 08:53 pm (UTC)
//до сих пор не вымерли программисты, которые не проверяют длину принимаемых/пересылаемых данных. Повбывав бы. :)
А почему ты так уверен, что в случае с тойотой собака порылась не там?
16th-Jan-2014 08:54 pm (UTC)
Да не, не уверен. А что это меняет? Рукотворная ошибка, все-равно ж.
This page was loaded Jun 17th 2019, 9:55 am GMT.