Buggy HP iPAQ ROM Update Utility
October 29, 2007 by RD · Leave a Comment
Last weekend I tried to re-flash a HP ipaq rw6828 using the latest HP iPAQ ROM Update 1.01.03 from HP website.
After about 20 minutes, the ROM flash process crashed at 90% and the phone became dead and was not able to power on any longer (tried different suggested methods to get it boot into the bootloader mode but all failed).
I did a quick google on “ipaq 6828 ROM update fail 90%” keywords. Quite a lot of people got the same problem. Some were lucky enough to be able to re-flash the phone again as the phone still can boot into bootloader mode. But many other people had to send the phone to HP Service Center to replace the main board.
So I decided to take a look at the HP iPAQ ROM Update Utility binary (hpRUU.exe – v3.3.2 build 831) to find out the reason.
It didn’t take long to find out that the “90%” problem is caused by a lame buggy code of the HP iPAQ ROM Update Utility itself.
The buggy code is inside the sub_409DA0() (I renamed it to Client_StartFlash()). Below is the reverse C code snippet of ROM update function (not exactly as the asm code)
void sub_409520(int c)
{
DebugLog("odmLib/Client_StartFlash -- Flashing would start here");
hEvent = CreateEventA(0, 0, 0, 0);
dword_425B04 = CreateThread(0, 0, &sub_409DA0, 0, 0, 0);
SetEvent(hEvent);
DebugLog("odmLib/Client_StartFlash: pReturnCode->dwError = %d", 65520);
}
#define FLASH_ERROR(fmt, ...) \
{ \
DebugLog(fmt, ...); \
IsErrorFlag = 1; \
pReturnCode_dwError = 401; \
return; \
}
void Client_StartFlash() //sub_00409DA0()
{
//WORD SelectFile[2];
WaitForSingleObject(hEvent, INFINITE);
DebugLog("DownloadFile: SelectFile = 0x%x TotalFileSize = 0x%x..\r\n",
SelectFile, TotalFileSize);
if (DeviceInBLMode == -1) {
DebugLog("DownloadFile: DeviceInBLMode has a wrong value!");
IsErrorFlag = 1;
pReturnCode_dwError = 602;
return;
}
if (SelectFile[0] & 8) {
DebugLog("DownloadFile: COM_OS ..\r\n");
wsprintfA(StatusBuffer, "Updating the ROM Image ...");
byte_425884 = (DeviceInBLMode != 0) + 17;
memset(_tFilename, 0, 0x64);
pReturnCode_dwExtraInfo = 3;
dHeaderLen = 0;
sub_40A580(3, _tFilename, (int) &dHeaderLen);
DebugLog("DownloadFile: tFilename = %s dHeaderLen = %d\r\n",
&_tFilename, dHeaderLen);
_hFile = CreateFileA(_tFilename, GENERIC_READ | GENERIC_WRITE, 0, 0,
OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);
if (_hFile == INVALID_HANDLE_VALUE) {
FLASH_ERROR("Jcs-CreateFile %s fail .. ", _tFilename);
}
HeaderBuffer = malloc(dHeaderLen);
HeaderBuffer = malloc(dHeaderLen);
ReadFile(_hFile, HeaderBuffer, dHeaderLen, &NumberOfBytesRead, 0);
dFileLen = GetFileSize(_hFile, 0);
dDataLen = dFileLen - dHeaderLen;
DataBuffer = calloc(dFileLen - dHeaderLen, 1);
ReadFile(_hFile, DataBuffer, dDataLen, &NumberOfBytesRead, 0);
free(HeaderBuffer);
ROMDecode(dDataLen, DataBuffer);
if (memcmp(DataBuffer, 'R000ff\n', 7)) {
IsErrorFlag = 1;
pReturnCode_dwError = 401;
DebugLog("Jcs-Warning: The Image is invalid ... ");
wsprintfA(StatusBuffer, "Warning: The Image is invalid ...");
return;
}
if (!bDownLoadThrUSB(DataBuffer, dDataLen, dword_425B20,
SelectFile)) {
IsErrorFlag = 1;
pReturnCode_dwError = 503;
return;
}
free(DataBuffer);
CloseHandle(_hFile);
}
if (SelectFile[0] & 4) {
DebugLog("DownloadFile: COM_BL ..\r\n");
wsprintfA(StatusBuffer, "Updating the Bootloader ...");
dHeaderLen = 0;
memset(_tFilename, 0, 0x64);
pReturnCode_dwExtraInfo = 2;
byte_425884 = 2;
sub_40A580(2, _tFilename, (int) &dHeaderLen);
DebugLog("DownloadFile: tFilename = %s dHeaderLen = %d\r\n", _tFilename, dHeaderLen);
_hFile = CreateFileA(_tFilename, GENERIC_READ | GENERIC_WRITE, 0, 0,
OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);
if (_hFile == INVALID_HANDLE_VALUE) {
FLASH_ERROR("Jcs-CreateFile %s fail .. ", _tFilename);
}
HeaderBuffer = malloc(dHeaderLen);
ReadFile(_hFile, HeaderBuffer, dHeaderLen, &NumberOfBytesRead, 0);
dFileLen = GetFileSize(_hFile, 0);
dDataLen = dFileLen - dHeaderLen;
DataBuffer = calloc(dFileLen - dHeaderLen, 1);
ReadFile(_hFile, DataBuffer, dDataLen, &NumberOfBytesRead, 0);
free(HeaderBuffer);
ReadFile(_hFile, DataBuffer, dDataLen, &NumberOfBytesRead, 0);
free(HeaderBuffer);
ROMDecode(dDataLen, DataBuffer);
FILE = fopen("c:\\ipaq\\downloadEboot.txt", "wb");
fwrite(DataBuffer, 1, dDataLen, FILE);
fclose(FILE);
if (!bDownLoadThrUSB(DataBuffer, dDataLen, dword_425B20,
SelectFile)) {
IsErrorFlag = 1;
pReturnCode_dwError = 503;
return;
}
free(DataBuffer);
CloseHandle(_hFile);
}
if (!bDownLoadThrUSB(&unk_4253F0, 0x80, 0, SelectFile)) {
IsErrorFlag = 1;
pReturnCode_dwError = 401;
DebugLog("Jcs-Download version infomation to device fail ..");
return;
}
dTmp = SelectFile[1];
if (SelectFile[0] & 0x20) {
DebugLog("DownloadFile: COM_FS ..\r\n");
dTmp = SelectFile[1];
}
if (dTmp & 0x80 && dTmp & 0x20) {
DebugLog("DownloadFile: COM_WANOS + COM_WANBL ..\r\n");
wsprintfA(StatusBuffer, "Updating the Radio Stack ...");
dHeaderLen = 0;
memset(_tFilename, 0, 0x64);
pReturnCode_dwExtraInfo = 15;
byte_425884 = 4;
sub_40A580(13, _tFilename, (int) &dHeaderLen);
DebugLog("DownloadFile: tFilename = %s dHeaderLen = %d\r\n",
_tFilename, dHeaderLen);
_hFile = CreateFileA(_tFilename, GENERIC_READ | GENERIC_WRITE, 0, 0,
OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);
if (_hFile == INVALID_HANDLE_VALUE) {
FLASH_ERROR("Jcs-CreateFile %s fail .. ", _tFilename);
}
HeaderBuffer = malloc(dHeaderLen);
ReadFile(_hFile, HeaderBuffer, dHeaderLen, &NumberOfBytesRead, 0);
dFileLen = GetFileSize(_hFile, 0);
dDataLen = dFileLen - dHeaderLen;
dFileLen = GetFileSize(_hFile, 0);
dDataLen = dFileLen - dHeaderLen;
DataBuffer = calloc(dDataLen, 1);
dword_425B1C = DataBuffer;
ReadFile(_hFile, DataBuffer, dDataLen, &NumberOfBytesRead, 0);
free(HeaderBuffer);
CloseHandle(_hFile);
memset(_tFilename, 0, 0x64)
sub_40A580(15, _tFilename, (int) &dHeaderLen)
DebugLog ("DownloadFile: tFilename = %s dHeaderLen = %d\r\n",
&_tFilename, dHeaderLen)
_hFile = CreateFileA(_tFilename, GENERIC_READ | GENERIC_WRITE, 0, 0,
OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);
if (_hFile == INVALID_HANDLE_VALUE) {
FLASH_ERROR("Jcs-CreateFile %s fail .. ", _tFilename);
}
HeaderBuffer = malloc(dHeaderLen);
ReadFile(_hFile, HeaderBuffer, dHeaderLen, &NumberOfBytesRead, 0);
dDataLen = GetFileSize(_hFile, 0) - dHeaderLen;
dword_425B84 = dDataLen;
DataBuffer = calloc(dDataLen, 1);
dword_425B10 = DataBuffer;
ReadFile(_hFile, DataBuffer, dDataLen, &NumberOfBytesRead, 0);
free(HeaderBuffer);
CloseHandle(_hFile);
DataBuffer = calloc(dDataLen + nNumberOfBytesToRead + 88, 1);
szBuffer = _msize(DataBuffer);
memset(DataBuffer, -1, szBuffer);
if (sub_40A5E0()) {
if (sub_40A770()) {
if (sub_40A8F0()) {
ROMDecode(Count, DataBuffer);
if (DataBuffer) {
FILE = fopen ("c:\\ipaq\\downloadMot.txt", "wb");
fwrite(DataBuffer, 1, Count, FILE);
fclose(FILE);
if (bDownLoadThrUSB(DataBuffer, Count, dword_425B20, SelectFile)) {
if (sub_40B270()) {
free(DataBuffer);
free(dword_425B10);
free(dword_425B1C);
dword_425F58 = 1;
} else {
IsErrorFlag = 1;
} else {
IsErrorFlag = 1;
pReturnCode_dwError = 401;
DebugLog ("Jcs-bGetMOTBurnStatus fail ..");
}
} else {
IsErrorFlag = 1;
pReturnCode_dwError = 401;
DebugLog ("Jcs-Download Mot fail ..");
}
} else {
IsErrorFlag = 1;
pReturnCode_dwError = 401;
DebugLog ("Jcs-(pMOTBuf==NULL) fail ..");
}
} else {
IsErrorFlag = 1;
pReturnCode_dwError = 401;
DebugLog("Jcs-PrepareMOTData fail ..");
}
} else {
IsErrorFlag = 1;
pReturnCode_dwError = 401;
DebugLog("Jcs-PrepareMOTAgent fail ..");
}
} else {
IsErrorFlag = 1;
pReturnCode_dwError = 401;
DebugLog("Jcs-PrepareMOTPara fail ..");
}
} else {
dword_425F58 = 1;
}
}
The codes at line 110->112 and 200->202 inside Client_StartFlash() function try to write the ‘decrypted’ EBOOT and MOT ROMs data to hard-coded file locations at c:\ipaq\downloadMot.txt and c:\ipaq\downloadEboot.txt. It doesn’t check whether the fopen() return a successful FILE pointer or not before writing the content.
So, If you install the ROM upgrade program in a different location (in my case, i installed it in d:\tmp\ipaq) instead of default location (c:\ipaq), the update program will get crashed at 90%. This stupid error had killed many ipaq and many people had to spend their time and money for the service & mainboard replacement since the update had been released by HP for almost a year. The HP developer who wrote this code should go back to college to learn how to code properly.
After knowing the problem, I sent the ipaq to HP Service Center a day after and got the mainboard replaced. After few hours of waiting, complaining and giving live proof of the bug to HP technical guy, I did not need to pay for mainboard replacement cost :). The technical guy was a nice guy. He even brought me inside HP technical service center for re-flashing few ipaqs to reproduce the problem. However, the experience with the girl at HP Customer Service Center was kind of bad though.
Links:
Software Exploitation Training – Successfully Completed
October 23, 2007 by lamer · Leave a Comment
During the HITB 2007 Malaysia I met a young smart group of students from Singapore Polytechnic. They took part in the Capture the Flag competition and managed to score better than some professionals (need I make it clear?) in total contrast to their name: t3nth (they ranked eighth, by the way).
I thought that was impressive enough for these young chaps and maybe if they had proper training, they could turn as capable as any other qualified security engineer. And so I offered them a free workshop on software exploitation to serve as a primer. It was received enthusiastically.
An intensive four (or five, I dont quite remember)-session training was given on every week end through out last month. It covered all basic concepts, techniques, and some few advanced skills. I don’t know but it seemed like the boys grasped them pretty quickly. Actually, they surprised me! I didn’t expect that Paul could understand the stack diagram I drew on the white board in an instance, Louis would get the return-to-libc technique immediately when I mentioned it, Jeremy were able to analyze binary files in a few minutes, and Choon Rui mastered format string with no difficulty at all.
Through out the training, challenges from the CtF (no, not the binary, but with reconstructed source by yours truly) were used but these boys weren’t informed at all. They solved them, fluidly. What others weren’t able to do in Dubai 2007, and Malaysia 2007, they did it in only one or a few hours. Brilliant, ain’t they?
I hope it was a conducive workshop to them and that they loved it as much as I loved teaching them. It’s always a pleasure to work with smart guys. I believe these chaps will score much better in subsequent challenges. And if you are looking for interns, get them!
hashcrack v1.0
October 9, 2007 by lamer · Leave a Comment
hashcrack is a fast (as fast as OpenSSL allows) hash cracker. It features an additive hash checking to speed up the process. For example, to check for the hashes of abc and abd, hashcrack only computes the hash of ab, then computes one round each for c and d totaling 4 rounds (two for ab, one for c and one for d). This eliminates a good number of rounds if we calculate hashes from the beginning (6 in this case). The longer the key, the more the saving.
A draw back to this feature is it does not work with non-additive hash algorithms. Luckily, popular algorithms, such as SHA-1, RIPEMD160, MD5, are additive.
Compared to vshark (another hash cracker by rd), hashcrack is so much faster. An unscientific benchmark to RIPEMD160-scan the whole 6-character a-zA-Z0-9 space ended in about 6 minutes with hashcrack, and more than 2 hours with vshark. To be fair to vshark, there was another version of hashcrack written in pure Python. It was 6 times slower than vshark.
