- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
int hardinfo_updata( struct UPINFO * headinfo, struct HARDINFO * hardinfo )
{
char sbuf[128] ;
int sn_len = 0 ;
char *psn ;
printf("%s\n",__FUNCTION__ ) ;
memset( sbuf, 0xFF, 128 ) ;
if( strcmp( hardinfo->flag, "hardinfo") != 0 )
{
psn = (char *)hardinfo ;
sn_len = *psn ;
psn += 1;
memcpy( sbuf, psn , 127 ) ;
}
else
{
sn_len = hardinfo->sn_len ;
memcpy(sbuf, hardinfo->sn, 128 ) ;
}
memcpy( hardinfo, &(headinfo->hardinfo), sizeof( struct HARDINFO ) ) ;
hardinfo->sn_len = sn_len ;
if( hardinfo->sn_len > 128 ) hardinfo->sn_len = 128 ;
memcpy( hardinfo->sn, sbuf, hardinfo->sn_len ) ;
memset( 0x30008000, 0xFF, 0x20000 ) ;
memcpy( 0x30008000, hardinfo, sizeof( struct HARDINFO ) ) ;
memset( sbuf, 0xFF, 128 ) ;
sprintf( sbuf, "%s %x %x\0", "nand erase 80000 80000 ;nand write 0x30008000", 0x80000, 0x20000) ;
run_command( sbuf,0);
memset( sbuf, 0, 128 ) ;
sprintf( sbuf, "%s %x\0", "nand read 0x31000000 80000 ", 0x20000 ) ;
run_command(sbuf, 0 ) ;
if( memcmp( 0x30008000, 0x31000000, sizeof( struct HARDINFO) ) != 0 )
{
printf("bootloader data crc error\n") ;
return 0 ;
}
else
{
printf("update hardinfo is ok\n") ;
}
return 1 ;
}
CRC через memcpy. Из пропатченного китайцами u-boot
j123123 15.06.2016 07:08 # 0
bormand 15.06.2016 07:16 # +2
Вот у меня сразу в мозгу триггернулось: "ага, в верхней ветке psn заполнили, а в нижней - нет, если внизу её заюзают - всё распидорасит... а, не юзают, ну и слава богу".
guest 18.06.2016 11:20 # +1
dxd 18.06.2016 11:27 # 0
bormand 18.06.2016 11:29 # 0
kegdan 20.06.2016 11:33 # 0
Antervis 20.06.2016 16:10 # 0
guesto 21.06.2016 03:09 # 0
а мне нравится)
сразу представляю себя таким юникс хакером за PDP в больших очках, клечатой рубашке и с бородой
roman-kashitsyn 21.06.2016 15:43 # +2
Смотрит на таких хипстеров с неодобрением
3.14159265 21.06.2016 15:52 # 0
Потому что заедушные сишкобляди?
bormand 15.06.2016 07:42 # 0
j123123 15.06.2016 08:29 # 0
bormand 15.06.2016 08:40 # 0
Ну а если кешируется, и мы там можем увидеть кусок старых данных от старой прошивки - ну тут только какой-то системнозависимой инструкцией кеш прочищать... memcmp не виноватый, тут совершенно любая проверка обосрётся.
j123123 15.06.2016 08:49 # 0
Ну если сделать нечто вроде
То все должно пройти гладко. Вообще, я не особо курил код этого u-boot, может таких извратов делать не надо
bormand 15.06.2016 08:53 # 0
Ну здесь же именно так и делают :)
З.Ы run_command() это чё-то типа system()?
j123123 15.06.2016 08:59 # 0
bormand 15.06.2016 08:46 # +1
j123123 15.06.2016 08:52 # 0
bormand 15.06.2016 08:52 # 0
Dummy00001 15.06.2016 12:11 # 0
так как у-буут стартует рано, и как правило архитектура известна, то и лэйаут памяти тоже известен - почему в у-бууте использование фиксированых хардкоженых адресов памяти (0x30008000, 0x31000000) и популярно.
код на самом деле не так плох. учитывая что писали хардварщики - так почти идеал. и сообщение об ошибке и не так плохо: можно было бы "consistency check" написать - но типичные пользователи уже знают CRC ошибки, и просто не имеет смысл их грузить деталями. в конце концов, CRC это дешевая имитация memcmp().
codemonkey 15.06.2016 10:35 # 0
bormand 15.06.2016 10:44 # 0
Ты лучше объясни, зачем там memset на 0xFF
j123123 15.06.2016 10:45 # 0
codemonkey 15.06.2016 11:06 # 0
Иногда тупо выгодней сделать
и потом заполнить payload, чем
Особенно если payload состоит из 20 байт, ибо по Стандарту, unused bytes shall be set to 0xFF.
bormand 15.06.2016 11:14 # 0
З.Ы. Я понимаю, зачем это делается с бинарными данными.
codemonkey 15.06.2016 11:15 # +1
Reserved for chinese backdoor :^)
Dummy00001 15.06.2016 12:17 # 0
может копипаситили memset из другого места в коде. некоторые флеши перед программированием надо в 0xFF ставить.
bormand 15.06.2016 12:28 # 0
Видимо вот отсюда пробралось.
bormand 15.06.2016 12:30 # 0
Ну скорее просто чтобы не дрочить хвост флешки лишними переключениями 1 -> 0. 0xFF один хер получается только после отдельной команды стирания...
Dummy00001 15.06.2016 12:46 # 0
bormand 15.06.2016 13:25 # 0
А NOR/NAND - как соединены между собой ячейки. В NOR параллельно (wired-or) и можно любой бит зарядить независимо, но плотность хуёвая, получаются от силы мегабайты. В NAND'е - последовательно (wired-and), поэтому можно записать только всю цепочку разом (единички маскируются, нолики заряжаются), зато лишнего обвеса минимум, можно делать гигабайтные флехи.
А выкачивается заряд (забиваются единички) в обоих типах только большими блоками...
j123123 16.06.2016 09:10 # 0
Даже если и так, sprintf не будет разбирать строку дальше нуля. Китайцы вероятно решили, что чтобы в буфер попал ноль в конце, надо обязательно "\0" добавить в конце строки скармливаемой этому sprintf, а иначе там сразу после текста полезут эти 0xFF
j123123 15.06.2016 10:44 # 0
элементарно заменяется на:
bormand 15.06.2016 10:45 # 0
j123123 15.06.2016 10:47 # 0
bormand 15.06.2016 10:49 # 0
j123123 15.06.2016 10:50 # 0
bormand 15.06.2016 10:53 # 0
Dummy00001 15.06.2016 12:28 # 0
TarasB 15.06.2016 12:30 # +2
> char sbuf[заранее_угадай] ;
Как я сука ненавижу сишколибу для строк
codemonkey 15.06.2016 12:57 # +1
bormand 15.06.2016 13:28 # +2
Можно подумать, что в пасцале не так, когда куча недоступна и строки надо на стеке объявлять.
inkanus-gray 15.06.2016 14:11 # +1
bormand 15.06.2016 14:11 # 0
kipar 15.06.2016 14:24 # 0
bormand 15.06.2016 14:25 # 0
j123123 16.06.2016 00:47 # 0
256, разве нет?
Soul_re@ver 16.06.2016 00:55 # +4
inkanus-gray 16.06.2016 01:50 # +2
http://ideone.com/0fJrLY
TarasB 15.06.2016 14:40 # +3
Soul_re@ver 15.06.2016 20:26 # +5
LispGovno 16.06.2016 01:03 # 0
3_14dar 16.06.2016 01:33 # +3
3_dar 16.06.2016 23:41 # +1
CHayT 16.06.2016 23:49 # +3
j123123 17.06.2016 02:42 # +2
bormand 17.06.2016 09:22 # 0
j123123 17.06.2016 09:29 # 0
3.14159265 21.06.2016 03:08 # 0
От каких кодов?
Уязвимость?
Своё говно?
Искусственно сделанный тест?
j123123 22.06.2016 19:51 # 0
TarasB 21.06.2016 16:12 # +1
http://risovach.ru/upload/2015/12/mem/palki-v-kolesa_99340943_orig_.jpg
inkanus-gray 23.06.2016 01:07 # +2
Доступ к запрашиваемому Вами Интернет-ресурсу ограничен в
соответствии с требованиями законодательства и/или во исполнение
решения суда.
3_14dar 23.06.2016 03:11 # −1
И
Д
О
Р
А
Х
А
1024-- 23.06.2016 06:23 # +3
0
2
4
-
-
3_14dar 23.06.2016 06:41 # +2